1 / 22

Teachable Static Analysis Workbench

Teachable Static Analysis Workbench . by Igor Konnov, Dmitry Kozlov. Project goal. To build a tool, teachable by security analyst, which helps to verify that web application has the appropriate security mechanisms and they are used in right way.

tacita
Download Presentation

Teachable Static Analysis Workbench

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Teachable Static Analysis Workbench • by Igor Konnov, • Dmitry Kozlov

  2. Project goal To build a tool, teachable by security analyst, which helps to verify that web application has the appropriate security mechanisms and they are used in right way. One more idea: look at this project as integration project: investigate can different OWASP tools and docs work together?

  3. Motivation • Manual code review is boring, so error-prone work. Static analysis tools are helpful to perform routine checks. • Web apps varies in frameworks, libraries, security technologies. So, static analysis tool have to support every technology, library, etc. to be applicable. • Vulnerabilities varies depending on technologies used in web app: XSS, SQLI, LDAPI, etc.

  4. Teaching static analyzer Input validation vulnerabilities: XSS, SQLI, HTTP Response Splitting, and more. Are they so different? • All of them are dataflow from some source of “tainted” data provided by malicious user to some sensitive function (system call, HTTP headers, HTML page,…) • They differ in technologies: when using LDAP sensitive function is LDAP modification, for SQL – query execution, etc. • They differ in source of tainted data: request parameters, database records, files, etc.

  5. Teaching static analyzer Security mechanisms are different • mysql_real_escape_string() • public static boolean validateRequired(Object bean, Field field) {    String value = ValidatorUtil.getValueAsString(bean, field.getProperty());    return GenericValidator.isBlankOrNull(value);} • XML validators: <name>email</name> <pattern>^[\w-]+(?:\.[\w-]+)*@(?:[\w-]+\.)+[a-zA-Z]{2,7}$</pattern>

  6. ESAPI Secure Coding Guide’s patterns • Authentication • All HTTP requests for transactions shall be verified using the HTTPUtilities.verifyCSRFToken() • All requests for pages that require authentication shall call the ESAPI.authenticator().login() method. • Access Control • The application shall use assertAuthorizedForFile() to verify authorization before allowing access to files. • Input Validation • The application shall add all custom cookies with ESAPI.httpUtilities().safeAddCookie() to ensure they are properly secured. • Banned API • Replace ServletResponse.setContentType() withHTTPUtilities.setContentType()

  7. Teaching static analyzer to ESAPI ESAPI Secure Coding Guide: “call stack at some program point should (not) contain some call”: HTTPServlet.service() method shouldn’t call ServletResponse.addCookie(), but HTTPUtilities().safeAddCookie(). => SA must be capable of searching patterns on Call Graph or Control Flow Graph. Teaching is creating logical expressions on these graphs.

  8. Key requirements to Security Analysis Workbench • Teachable: • about technologies • about vulnerabilities • about security mechanisms • Reuse of analyst knowledge: teach once and reuse for many web applications • Recalculation of results on the fly • The tool should work as part of Eclipse IDE

  9. How to work with Teachable Static Analysis Workbench

  10. What is inside Teachable Static Analysis Workbench

  11. Static analyzers • LAPSE • unsupported, no users community, lastest source is unavailable, doesn’t work with current stable Eclipse, very primitive analysis, works slow. • FindBugs • alive project: good documentation and code, broad users community, intraprocedural analysis for XSS: need to be extended, Eclipse integration. • PQL • interesting analysis, lack of documentation, very limited community, immature implementation. • Indus • mature project, good community, very sophisticated, slower than FindBugs.

  12. Workbench architecture TeSA Eclipse Plugin HelloWorld.java: … Request.getParameter(“login”) … Analysis configuration TeSA Eclipse Plugin Mark method as tainted source modified FindBugs .class SecBugs plugin for FindBugs javac modified FindBugs Eclipse Plugin JSP Precompiler Eclipse source code markers *.java *.jsp

  13. Status and Future Steps Current status is beta. Reviewers promised to finish 100% review soon Future work: • GUI improvements: view vulnerabilities in Eclipse Project explorer. • Support for XML-based and annotation-based validations. • Support for ESAPI-like patterns: give analyst ability to create expressions on Call Graph and CFG. • Support “on the fly” analysis. • Backports of FindBugs improvements to FindBugs project.

  14. Closing: project contribution • Secbugs - interprocedural tainted analysis, configurable to different types of input validation vulnerabilities. • TeSA – “teaching” environment, which allows security analyst to markup code Eclipse source editor and creates configuration for Secbugs. • JSP support • SA can rerun continuously but it’s real “on the fly”. • LAPSE port to Eclipse 3.4. But actually our tool makes use of LASPE deprecated.

More Related