Hi all, XSS vulnerability scanner is an utility to statically analyze JSP/Servlets and to detect potential XSS vulnerabilities in the code segments. Which can be latter extend into detect more vulnerability types.
Available solutions and their drawbacks YASCA: http://www.scovetta.com/yasca.html YASCA is a similar utility which uses static code analysis techniques to detect potential vulnerabilities in JSP/Servlet (and other platforms) for XSS. YASCA is using Grep techniques to detect locations where XSS injection can be done. YASCA is only capable of detecting locations with a XSS attack can be performed and does not validate the locations for whether they are encoded or not. Since YASCA is using grep techniques to detect possible locations with XSS vulnerabilities, there can increased number of false positives. There are multiple ways to encode the output to prevent an XSS attack and YASCA does not consider about them. OWASP LAPSE+: https://www.owasp.org/index.php/OWASP_LAPSE_Project OWASP LAPSE is another static code analysis tool designed to find vulnerabilities in JAVA EE applications. LAPSE is designed as Eclipse plugin which scans code and give suggestions about possible data injection sinkholes. LAPSE also lacks the capability to detect different encoding patterns as YASCA. Which will eventually increase the average of false positives. OWASP Zed Attack Proxy: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP ZAP is a penetration testing utility which is capable of detecting XSS vulnerabilities. ZAP mainly focuses on detecting reflective XSS attacks using common attack patterns. ZAP can works as a proxy and can be used to scan incoming traffic. ZAP does not use static code analyzation techniques to detect vulnerabilities of a site instead of it uses dynamic techniques to detect vulnerabilities. RIPS: http://rips-scanner.sourceforge.net RIPS is a static code analysis tool for PHP. RIPS has the capability to define encoder patterns using own configuration but currently RIPS only support PHP scanning. Proposed Solution The proposed solution is to overcome the issues that are found in the previous section and to provide a better and more agile solution to the problem. The major problems that are identified in the previous section are, 1. Using Grep like techniques to find the vulnerable sections. 2. No mechanism to define the different encoder patterns. 3. Lack of extendability or ability to couple with other projects. The provided solution will address these issues using, 1. Instead of grep techniques, scanner will identify java code as expressions and scan each expression for the vulnerabilities. 2. There will be a set of user defined rule set to use with scanners and user can define the encoder patterns to scan with. 3. Components will be developed as a library which can be extended more or can be used with different projects. High level architecture Diagram 1.0 explains the high level architecture of the utility. Utility contains 3 main component types. Parsers, Scanners, and Printers and each section briefly described in the below. [image: XSSVS.png] Diagram 1.0 Parsers Parsers will extract the required content from the JSP/Servlet files and will make a syntactically valid java blocks to use for the scanners. Each parser will validate the java code for syntax errors and when it comes to JSP files, it will create valid java blocks by extracting java code from the scriptlets. Scanners Scanners are used to scan each java block against the provided rules and to detect any potential vulnerabilities. Diagram 2.0 (sequence diagram) explains the process of scanning a JSP document. Given JSP/Servlet will be analyzed against the provided rule set. Rules are defined by the user and more information will available in the later section. [image: XSSVS-Seq.png] Diagram 2.0 Rules Rules are defined by the user to suggest the scanner to identify the encoding patterns that are used in the each JSP/Servlet. Rules are given as a simple regular expression which contains how the encoder is used. Below is a sample rule to detect whether the given JSP is encoded using the OWASP default encoder. Each rule has the context which defines the context which the rule should be applied and the rule sets are having a type which defines whether this rules are used to check for encoder validations or other uses. (Other uses are later to be defined). <Rules> <RuleSet type="ENCODER_CHECK"> <Rule context="ATTRIBUTE">.*?(Encoder\.encodeForHTMLAttribute)(\(.*\))</Rule> <Rule context="HTML">.*?(Encoder\.encodeForHTML)(\(.*\))</Rule> </RuleSet> </Rules> Printers Printers are used to print the generated warnings to the user. Current printer will give the available warnings as a XML document. As a Maven Plugin for WSO2 components Utility will be used as a maven plugin to detect and give potential warnings that are identified in each WSO2 component as a XML document. Utility will be running in the pre-compile phase of the maven. Please share your thoughts. Thanks! *Jayanga Kaushalya* Software Engineer Mobile: +94777860160 WSO2 Inc. | http://wso2.com lean.enterprise.middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
