Open Hub Project Analysis
|Lines Of Code:||35,319|
|Published On:||May 25, 2013 (09:02 PM)|
Project MotivationCross-site scripting is one of the most pervasive web application security vulnerabilities present in today's applications, ranking at the top of the most recent OWASP Top Ten (2007). Recently, UI frameworks have emerged that allow application developers to create web components quickly and effortlessly. Java EE facilitates this ability by providing JSP tags that can be conglomerated as a tag library, such as was done with Java Server Faces (JSF). These tags allow developers to create rich user interfaces by parameterizing attributes of the web component. With the advent of this design, a unique opportunity arises to prevent cross-site scripting. If tag libraries offered built-in protection from cross-site scripting, then using parameterized web components to prevent cross-site scripting could become analogous to using parameterized queries to prevent SQL injection. However, security is not always in mind when such tag libraries are developed and thus it is not clear which libraries, if any, offer such built-in protection. This project would allow developers to quickly determine the protection mechanisms provided by any tag libraries they develop or of any third-party tag libraries they are considering using for their application. This will enable a push to parameterize web components which will serve to make web applications safer. ObjectivesThe goal of this project is to create an easy to use, freely available tool that can be used to quickly ascertain the level of protection that each component of a JSP tag library offers. This information can serve two purposes: It provides a means for projects to create a coding standard. By identifying which components are safe or unsafe, a project can establish a preference order of useable components. For those components identified as unsafe, extra security requirements can be imposed on any pages using those components It provides tag library providers development guidance. Providers can target security enhancements to the components that are most susceptible to cross-site scripting attacks. They can also use these results to demonstrate their performance relative to other competing tag libraries. It also provides feedback for developers that create small custom tag libraries for internal development usage. Ideally, the input to the tool will be the Tag Library Descriptor file along with a compiled version of the tag library. The resulting output will be a report of all tags in the library and their associated attributes with annotations for each attribute indicating whether or not it safely handles tainted input. Additionally, the framework for this tool should be robust enough to enable the functionality indicated by the future work section. Future VisionWhile tag libraries offer a means to parameterize web components and potentially better protection from XSS, there are still applications that use raw JSPs and scriptlets. With the insight gained from generating test cases, the JSP Testing Tool should be enhanced to test not only pages using JSP tag libraries, but also basic JSPs as well. One possible strategy is to create a wrapper HttpServletRequest class that overrides methods to provide input directly from test cases generated from the earlier stages of this project. A similar wrapper HttpServletResponse class can then be used to test the results. The tool could then be used to quickly test the XSS protection level of any Java EE application that uses JSP technology. Unlike automated web scanners, this tool enhancement would have the benefit of internal insight to the application to determine injectable parameters. Additionally, this tool enhancement would be an improvement to static code analysis as it could reduce the number of false positives with the ability to invoke actual rendering of the HTTP response.