This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
OWASP Projects Dashboard 2.0/By Alphabetical Order
| Project | Purpose
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Alchemist Project | Alchemist enables a software development team in realization of highly secure and defensible application with built-in defenses/controls against security‐related design, coding and implementation flaws.
Alchemist is focused to present this solution by architecting a real-life high stakes application with security built into it right from the inception, step-by-step as it falls under an SDLC. The current exercise is targeted at demonstrating this on a J2EE based web application that is developed using Spring framework. Spring framework was chosen due to its widespread adoption in the financial products. However, it is important note that Alchemist is not limited to J2EE or more specifically Spring framework. The idea is to demonstrate the upper spectrum of security practices that are often neglected or are done in bits and pieces by picking a well known widely adopted technology. Since the emphasis is on security architecture and defensibility, the future road-map is to demonstrate the same for applications built using other leading programming languages and frameworks. Although this project is more than useful for existing/already developed applications, Alchemist is not the ideal solution to retrofit security into existing applications. It is aimed at offering more to applications that are at least in development, most in design phase. Allowing for language-specific differences, Alchemist builds this application with a strong foundation of security architecture that covers following main practices:
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Application Security Assessment Standards Project | *The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed and what level of assessment is appropriate based on business requirement.
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Application Security Program for Manager | *Create an OWASP Roadmap for the world wide Companies Type
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Application Security Skills Assessment | The OWASP Application Security Skills Assessment (OWASP ASSA) is an online multiple-choice quiz built to help individuals understand their strengths and weaknesses in specific application security skills with the aim of enabling them to focus their training in the most efficient and appropriate manner.
Upon completion of the quiz, for each question, it will tell the quiz taker whether they had the correct or incorrect answer, a discussion of the question, the specific application security areas the question focused on, a discussion about the correct an incorrect answers, and links to further references. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Application Security Verification Standard Project | The primary aim of the OWASP Application Security Verification Standard (ASVS) Project is to normalize the range in the coverage and level of rigour available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP AppSensor Project | Real Time Application Attack Detection and Response
Overview
The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application. Current efforts are underway to create the AppSensor tool which can be utilized by any existing application interested in adding detection and response capabilities.
ASIDE project has been continuously under active research, development, and evaluation. Involvement in the development and promotion of ASIDE is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help:
ESIDEThe education branch of ASIDE, named ESIDE (Educational Security in the IDE), is led by Michael Whitney and Heather Richter Lipford. Other major contributors include Bill Chu and [Jun Zhu]. IntroductionESIDE (Educational Security in the IDE) enhances the secure coding instructional process by turning the student's IDE into a real-time secure programming instructional resource. This approach capitalizes on the out of class, in the IDE time by providing layered educational opportunities whenever the student writes specific code patterns (i.e., vulnerable code) in a fashion similar to Microsoft's Grammar Checker. In this manner, ESIDE provides students with the opportunity to learn secure coding principles and practices concurrently with the lessons they are learning in their respective courses. DescriptionDeployed as an Eclipse IDE Java plugin, ESIDE continuously searches for predetermined code patterns (e.g., request.getParameter();). Whenever a student writes targeted code, they are provided with an interactive system that provides a layered educational opportunity. Because students are contextually “in the moment” when the support becomes available, they are more receptive to making the connection between classroom principles and coding practices. A secondary effect is the exponential increase in instructional exposure which has been proven to be successful in other instructional areas. The overall goal of ESIDE is to serve as an effective means to educate students at every level on the principles and practices of secure coding throughout their educational experience. To this end, we have developed ESIDE's interactive process as follows: The moment target code is written, ESIDE initiates a layered educational intervention based on the targeted code. The first layer is a warning icon that is placed in the left margin of the code editor. Hovering the icon reveals a short message that encourages further interaction. When the student clicks the icon, ESIDE generates a content specific list of educational options. Each of these options are accompanied with a short explanation of the issue at hand. For each generated list, there also exists the option to access an explanation page that provides a more comprehensive explanation of what was discovered, why it is important, and how to integrate the provided principles into coding practices. A video of an interaction designed for early students can be found at http://www.youtube.com/watch?v=k-FIcrr1ff8 What ESIDE provides?• Real-time IDE support for secure code education (Java). • Identification of targeted Java code patterns. • Interactive instructional opportunities for students in the IDE. Publications1. Michael Whitney, Heather Richter Lipford, Bill Chu, and Jun Zhu. Embedding Secure Coding Instruction into the IDE: A Field Study in an Advanced CS Course. In Proceedings of the 46th ACM Technical Symposium on Computer Science Education (SIGCSE '15). ACM, New York, NY, USA, 60-65. DOI=10.1145/2676723.2677280 http://doi.acm.org/10.1145/2676723.2677280 2. Jun Zhu, Heather Richter Lipford, and Bill Chu, Interactive Support for Secure Programming Education, In Proceedings of ACM Technical Symposium on Computer Science Education (SIGCSE), March 6-9, 2013, Denver, Colorado, USA Runnable ESIDE Prototype and Installation GuidelinesThe recent publicly available ESIDE plugin can be downloaded from here. You also need to download the complementary logging facility to make ESIDE work properly. ESIDE is built upon Eclipse IDE for Java EE Developers Version 3.5+. To make it work, please place the two jar files under the plugins folder of your Eclipse installation directory and then restart your Eclipse. Open Source CodeThe most recent source code of ESIDE can be accessed via https://github.com/witny23/ESIDE. Priorities and get involvedAs of March 17, 2015 the priorities are: 1. Move xml into a database. 2. Create a public repository of customized ESIDE support for specific courses. Involvement in the development and promotion of ESIDE is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help: Individuals who are interested in content contribution, usability evaluation or deploying ESIDE in their classroom would be wonderful!! | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Browser Security ACID Tests Project | ||||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Cloud ‐ 10 Project | Goal of the project is to maintain a list of top 10 security risks faced with the Cloud Computing and SaaS Models. List will be maintained by input from community, security experts and security incidences at cloud/SaaS providers. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Codes of Conduct | To create and maintain OWASP Codes of Conduct. In order to achieve our mission, OWASP needs to take advantage of every opportunity to affect software development everywhere. At the OWASP Summit 2011 in Portugal, the idea was created to try to influence educational institutions, government bodies, standards groups, and trade organizations. We set out to define a set of minimal requirements for these organizations specifying what we believe to be the most effective ways to support our mission. We call these requirements a “code of conduct” to imply that these are normative standards, they represent a minimum baseline, and that they are not difficult to achieve. | |||||||||||||||||||||||||||||||||||||||||||||||||
| The OWASP "Green Book" | This effort envisages to create and maintain The OWASP Application Security Code of Conduct for Government Bodies/The OWASP "Green Book". | |||||||||||||||||||||||||||||||||||||||||||||||||
| The OWASP "Blue Book" | This effort envisages to create and maintain The OWASP Application Security Code of Conduct for Educational Institutions/The OWASP "Blue Book". | |||||||||||||||||||||||||||||||||||||||||||||||||
| The OWASP "Yellow Book" | This effort envisages to create and maintain The OWASP Application Security Code of Conduct for Standards Groups/The OWASP "Yellow Book". | |||||||||||||||||||||||||||||||||||||||||||||||||
| The OWASP "Purple Book" | This effort envisages to create and maintain The OWASP Application Security Code of Conduct for Trade Organizations/The OWASP "Purple Book". | |||||||||||||||||||||||||||||||||||||||||||||||||
| The OWASP "Red Book" | This effort envisages to create and maintain The OWASP Application Security Code of Conduct for Certifying Bodies/The OWASP "Red Book". | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Code Review Project | The code review guide is currently at release version 1.1 and the second best selling OWASP book in 2008. Many positive comments have been feedback regarding this initial version and believe it’s a key enabler for the OWASP fight against software insecurity. It has even inspired individuals to build tools based on its information. The combination of a book on secure code review and tools to support such an activity is very powerful as it gives the developer community a place to start regarding secure application development.
Going forward I hope to further integrate with the ASVS and other guides such as the testing and ASDR guides shall be perfromed for version 2.0. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Common Numbering Project | An exciting development, a new numbering scheme that will be common across OWASP Guides and References is being developed. The numbering is loosely based on the OWASP ASVS section and detailed requirement numbering. OWASP ASVS, Guide, and Reference project leads and contributors as well as the OWASP leadership plan to work together to develop numbering that would allow for easy mapping between OWASP Guides and References, and that would allow for a period of transition as Guides and References are updated to reflect the new numbering. This project will provide a centralized clearinghouse for mapping information. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP CTF Project | The purpose of this Project is to create a competitive environment which can be used at conferences and to have fun and teach in a playful way the various mistakes which are made in regards to web applications. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Enterprise Application Security Project | Enterprise applications security is one of the major topics in overall security area because those applications controls money and resources and every security violation can result a significant money loss. Purpose of this project is to aware people about enterprise application security problems and create a guideline for EA security assessment. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP ESAPI Objective - C Project | The OWASP ESAPI Objective-C is the Objective-C (Cocoa) implementation of ESAPI.
| |||||||||||||||||||||||||||||||||||||||||||||||||
| Owasp Esapi Ruby | The Owasp Esapi Ruby is a port for outstanding release quality Owasp Esapi project to the Ruby programming language. The idea is to build a Ruby gem (the standard ruby library archive format) containing the Esapi concepts implemented in Ruby classes so people using Ruby in their Rails application can have security into them. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP ESAPI Swingset Demo Project | The ESAPI Swingset DEMO is a web application which demonstrates the many uses of the Enterprise Security API (ESAPI) | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP ESAPI Swingset Interactive Project | *This a web application which demonstrates common security vulnerabilities and asks users to secure the application against these vulnerabilities using the ESAPI library.
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Enhancing Security Options Framework (ESOP Framework) | Purpose of the framework is to provide a security layer to a given web application / web site via web service which can use the functions / modules to protect the site from following vulnerabilities:
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Exams Project | The OWASP Exams project will establish the model by which the OWASP community can create and distribute CC-licensed exams for use by educators. The purpose of the exams is to improve the effectiveness of OWASP training through the use of exams as a means of measurement and student progress tracking. The project will include creation of a set of CC-licensed exams, a model for exam usage, and a roadmap for future exam creation.
The exams may be distributed either in text format as well as in Moodle (an open source LMS) format so that they can be re-purposed for use in any system or an educator can use them directly in Moodle to administer exams to students. Ideally the exams will be tied to OWASP Academies learning blocks so that there is good learning and training content that can be used to motivate the usage of the exams. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Forward Exploit Tool Project | This projects aims to develop a tool to exploit Top 10 2010 - A10 - Unvalidated Forward vulnerability to bypass access control to protected Java application files (config, binary -source code, etc.). It aims also to automate the download of known files in Java Web applications. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP German Language Project | ||||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Hackademic Challenges Project | *The Hackademic Challenges is an open source project that can be used to test and improve one's knowledge of web application security.
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Hatkit Datafiddler Project | *The Datafiddler is a tool for performing advanced analysis of http traffic. It currently consists of two main views, one table-based and one tree-based. These views allow the user to study different aspects of the http traffic, with very high degree of configurability. The tool is also meant to be a framework which can utilize existing tools to analyze traffic post mortem (or real-time).
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Hatkit Proxy Project | *The Hatkit Proxy is an intercepting http/tcp proxy based on the Owasp Proxy, but with several additions. These additions are:
| |||||||||||||||||||||||||||||||||||||||||||||||||
| HTMLReg | Converts malicious HTML/CSS into a safe form of HTML. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP HTTP Post Tool | A tool for the purpose of performing web application security assessment around the availability concerns.
{{Template: OWASP Project About/Rows2 |
project_name =OWASP iGoat Project | project_home_page =OWASP iGoat Project | project_description =The iGoat project aims to be a developer learning environment for iOS app developers. It was inspired by the OWASP WebGoat project in particular the developer edition of WebGoat.
Similar to WebGoat (developer), the user is presented with a series of lessons surrounding numerous vulnerabilities associated with iOS apps. The student exploits each vulnerability to validate its existence, and then he implements a remediation in the lesson's source code. Further, iGoat is designed and implemented modularly, similar conceptually to WebGoat's modular Java EE servlet model. It is intended to provide a foundational framework to build lessons on top of, starting with a core set of lessons provided in the first release. iGoat can be downloaded here: https://github.com/owasp/igoat |
project_license =GPL v3 | leader_name1 =Swaroop Yermalkar | leader_email1 [email protected] | leader_username1 = | leader_name[2-10] = | leader_email[2-10] = | leader_username[2-10] = | contributor_name1 =Jonathan Carter | contributor_email1 [email protected] | contributor_username1 = | contributor_name[2-10] = | contributor_email[2-10] = | contributor_username[2-10] = | pamphlet_link = | presentation_link = | mailing_list_name =https://lists.owasp.org/mailman/listinfo/owasp-igoat-project | project_road_map =https://www.owasp.org/index.php/OWASP_iGoat_Project/Roadmap | links_url[1-10] = | links_name[1-10] = | release_1 =iGoat v1.1 | release_2 =iGoat v2.0 | release_3 =iGoat v2.1 | release_4 =iGoat v2.3
| project_about_page =Projects/OWASP_iGoat_Project }}
| |||||||||||||||||||||||
| OWASP JavaScript Sandboxes | To produce a simplified version of Javascript by using regular expressions to remove dangerous functionality and then use Javascript itself to evaluate the results. The goal is to allow normal web users to safely code javascript on a site without exposing sensitive information. This project has three 'sub'-projects: OWSP JSReg + OWASP HTMLReg + OWASP CSSReg.
The general API pattern is to utilize the Java Encoder Project in your user interface code and wrap all variables added dynamically to HTML with a proper encoding function. The encoding pattern is "Encode.forContextName(untrustedData)", where "ContextName" is the name of the target context and "untrustedData" is untrusted output. Basic HTML Context<body><%= Encode.forHtml(UNTRUSTED) %></body> HTML Content Context<textarea name="text"><%= Encode.forHtmlContent(UNTRUSTED) %></textarea> HTML Attribute context<input type="text" name="address" value="<%= Encode.forHtmlAttribute(UNTRUSTED) %>" /> Generally Encode.forHtml(UNTRUSTED) is also safe but slightly less efficient for the above two contexts (for textarea content and input value text) since it encodes more characters than necessary but might be easier for developers to use. CSS contexts<div style="width:<= Encode.forCssString(UNTRUSTED) %>"> <div style="background:<= Encode.forCssUrl(UNTRUSTED) %>"> Javascript Block context<script type="text/javascript"> var msg = "<%= Encode.forJavaScriptBlock(UNTRUSTED) %>"; alert(msg); </script> Javascript Variable context <button
onclick="alert('<%= Encode.forJavaScriptAttribute(UNTRUSTED) %>');">
click me</button>
JavaScript Content Notes: Encode.forJavaScript(UNTRUSTED) is safe for the above two contexts, but encodes more characters and is less efficient. Encode URL parameter values<a href="/search?value=<%= Encode.forUriComponent(UNTRUSTED) %>&order=1#top"> Encode REST URL parameters<a href="/page/<%= Encode.forUriComponent(UNTRUSTED) %>"> Handling a Full Untrusted URLWhen handling a full URL with the OWASP Java encoder, first verify the URL is a legal URL. String url = validateURL(untrustedInput); Then encode the URL as an HTML attribute when outputting to the page. Note the linkable text needs to be encoded in a different context. <a href="<%= Encode.forHtmlAttribute(untrustedUrl) %>"> <%= Encode.forHtmlContent(untrustedLinkName) %> </a> To use in a JSP with EL<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@taglib prefix="e" uri="https://www.owasp.org/index.php/OWASP_Java_Encoder_Project" %>
<html>
<head>
<title><e:forHtml value="${param.title}" /></title>
</head>
<body>
<h1>${e:forHtml(param.data)}</h1>
</body>
</html>
Other contexts can be found in the org.owasp.Encode class methods, including XML contexts and more. Numbers don’t need encoding since they cannot cause XSS. There are no numbers that will break out of a javascript context. If (and only if) ‘javaNumber’ is a numeric type (primitive or box wrapper), just use: var javaScriptNumber = <%= javaNumber %>; This is true even for the special cases of java.lang.Double.POSITIVE_INFINITY, NEGATIVE_INFINITY, NaN, and java.lang.Float equivalents. On the other hand, if ‘javaNumber’ is some user provided data that is NOT a numeric type, then you should either (1) convert it to a number on the java side, or (2) encode it to a string and handle it on the javascript side. E.g. <% // option (1) String javaNumber = (untrusted data); Double actualNumber = Double.parseDouble(javaNumber); // don’t forget to catch NumberFormatException %> <script> var jsNumber = <%= actualNumber %>; </script> -- OR -- <% // option (2)
String javaNumber = (untrusted data);
%>
<script>
var jsNumber = parseInt("<%=Encode.forJavaScript(javaNumber)%>");
</script>
The OWASP Java Encoder version 1.2.2 is now available in central! OWASP Encoder at Maven Central. CoreDirect Download: encoder-1.2.2.jar Maven<dependency> <groupId>org.owasp.encoder</groupId> <artifactId>encoder</artifactId> <version>1.2.2</version> </dependency> JSP Tag LibraryDirect Download: encoder-jsp-1.2.2.jar Maven<dependency> <groupId>org.owasp.encoder</groupId> <artifactId>encoder-jsp</artifactId> <version>1.2.2</version> </dependency> The following describes the Grave Accent XSS issue with unpatched versions of Internet Explorer. Thank you to Rafay Baloch for bringing this to our attention and to Jeff Ichnowski for the workaround. IntroductionThe grave accent (`), ASCII 96, hex 60 (wikipedia) is subject to a critical flaw in unpatched Internet Explorer. There is no possible encoding of the character that can avoid the issue. For a more in depth presentation on the issue discussed herein, please see Mario Heidrech's presentation. BackgroundIn Internet Explorer, the grave accent is usable as an HTML attribute quotation character, equivalent to single and double quotes. Specifically, IE treats the following as equivalent: <input value="this is the value"> <input value=`this is the value`> It is an IE extension, is not in HTML specifications (HTML4, HTML5), and is probably not well supported in other browsers. The IssueThe following HTML snippet, demonstrates the cross-site scripting vulnerability related to grave accents on unpatched Internet Explorer: <div id=a><input value="``onmouseover=alert(1)"></div> <div id=b></div> <script>b.innerHTML=a.innerHTML</script> When this snippet is run in Internet Explorer the following steps happen:
<input value=``onmouseover=alert(1)>
<input value="" onmouseover="alert(1)"> The XSS issue arises from IE returning a value from innerHTML that it does not parse back into the original DOM. Patched version of IE fix this issue by returning the XSS value as a double-quoted attribute. The issue is complicated by the fact that no possible encoding of the grave accent can avoid this issue. When... <input value="``onmouseover=alert(1)"> ...is the input, "a.innerHTML" returns the same XSS vector as it does without the encoding. Recommend SolutionOur recommended workaround is to update any JavaScript based innerHTML read to replace the accent grave with a numeric entity encoded form: "`". As an example, the following change to the XSS vulnerable code above fixes the issue: <script>a.innerHTML=b.innerHTML.replace(/`/g, "`");</script> This can be done in any library code that reads the innerHTML. To follow how this addresses the issue, the innerHTML from step 2 of the issue is converted to: <input value=``onmouseover=alert(1)> Since the browser will no longer see the grave accents as an empty attribute, it will convert the input back to a copy of its original DOM. Other Possible SolutionsAs there is no encoding option available, the following options are available to web application authors:
OWASP Java Encoder Library Related ChangesThe OWASP Java Encoder Library at its core is intended to be a XSS safe _encoding_ library. The grave accent is a legitimate and frequently used character, that cannot be encoded to avoid this bug in unpatched versions of IE. With enough user feedback, we may update the library to include one of the following options: (1) alternate, drop-in build that filters grave accents, with unchanged API, (2) new filtering methods. Several users of the Java Encoder have asked how to properly use the OWASP Java Encoder in combination with template literals. The best way to encode template literal variables is to first escape the untrusted data in a JavaScript variable and then place that variable in the template literal. var user = "<%= Encode.forJavaScript(user) %>";
`Hello ${user}, here is your total: ${total}`
Another method is to properly escape the variable in-line. `Hello ${"<%= Encode.forJavaScript(user) $>"}, here is your total ${total}`
2017-2018 Roadmap
Main
Creating a HTML PolicyYou can view a few basic prepackaged policies for links, tables, integers, images and more here: https://github.com/OWASP/java-html-sanitizer/blob/master/src/main/java/org/owasp/html/Sanitizers.java. PolicyFactory policy = Sanitizers.FORMATTING.and(Sanitizers.LINKS); String safeHTML = policy.sanitize(untrustedHTML); There tests illustrate how to configure your own policy here: https://github.com/OWASP/java-html-sanitizer/blob/master/src/test/java/org/owasp/html/HtmlPolicyBuilderTest.java PolicyFactory policy = new HtmlPolicyBuilder()
.allowElements("a")
.allowUrlProtocols("https")
.allowAttributes("href").onElements("a")
.requireRelNofollowOnLinks()
.build();
String safeHTML = policy.sanitize(untrustedHTML);
... or you can write custom policies ... PolicyFactory policy = new HtmlPolicyBuilder()
.allowElements("p")
.allowElements(
new ElementPolicy() {
public String apply(String elementName, List<String> attrs) {
attrs.add("class");
attrs.add("header-" + elementName);
return "div";
}
}, "h1", "h2", "h3", "h4", "h5", "h6"))
.build();
String safeHTML = policy.sanitize(untrustedHTML);
Please note that the elements "a", "font", "img", "input" and "span" need to be explicitly whitelisted using the `allowWithoutAttributes()` method if you want them to be allowed through the filter when these elements do not include any attributes. You can also use the default "ebay" and "slashdot" policies. The Slashdot policy (defined here https://github.com/OWASP/java-html-sanitizer/blob/master/src/main/java/org/owasp/html/examples/SlashdotPolicyExample.java) allows the following tags ("a", "p", "div", "i", "b", "em", "blockquote", "tt", "strong"n "br", "ul", "ol", "li") and only certain attributes. This policy also allows for the custom slashdot tags, "quote" and "ecode". CSS SanitizationCSS sanitization is challenging. We disallow position:sticky and position:fixed so that client code can use a position:relative;overflow:hidden to contain self-styling sanitized snippets. Embedders of sanitized content do have to consistently do that and make sure that contributed content is clearly demarcated. Most CSS attacks require a payload to specify selectors which the sanitizer should not allow. Unproxied images do allow tracking and, by positioning below the fold, can track whether a user scrolls down. Embedders do need to use URL rewriting if they allow background styling and use sensible Referrer-Policy and related headers. That said, even if care is taken, CSS has a large attack surface, so not using it puts you in a safer place. Inline/Embedded ImagesInline images use the data URI scheme to embed images directly within web pages. The following describes how to allow inline images in an HTML Sanitizer policy. 1) Add the "data" protocol do your whitelist. See: https://static.javadoc.io/com.googlecode.owasp-java-html-sanitizer/owasp-java-html-sanitizer/20160628.1/org/owasp/html/HtmlPolicyBuilder.html#allowUrlProtocols .allowUrlProtocols("data")
2) You can then allow an attribute with an extra check thus .allowAttributes("src")
.matching(...)
.onElements("img")
3) There are a number of things you can do in the matching part such as allow the following instead of just allowing data. data:image/... 4) Since allowUrlProtocols("data") allows data URLs anywhere data URLs are allowed, you might want to also add a matcher to any other URL attributes that reject anything with a colon that does not start with http: or https: or mailto: .allowAttributes("href")
.matching(...)
.onElements("a")
QuestionsHow was this project tested? How is this project deployed? Roadmap
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Java Project | The OWASP Java Project's goal is to enable Java and J2EE developers to build secure applications efficiently. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Java XML Templates Project | JXT is a fast and secure XHTML-compliant template language that runs on a model similar to JSP. JXT provides automatic context-aware encoding of data to make it easy to avoid OWASP Top Ten Project #2 web-application security risks Cross-site Scripting.
By providing automatic context aware escaping, JXT relieves the developer of having to think through the various contexts and appropriate escaping method required--allowing them to focus on coding the application. It also helps make the application more robust--it is easy to forget an escape after late night coding sessions after long hours. An additional benefit, perhaps not obvious at first, is that the automatic escaping provides for shorter syntax, and thus more readable code. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP JBroFuzz Project | JBroFuzz is a stateless web application fuzzer for requests being made over HTTP and/or HTTPS. Its purpose is to provide a single, portable application that offers stable web protocol fuzzing capabilities. As a tool, it emerged from the needs of penetration testing. | |||||||||||||||||||||||||||||||||||||||||||||||||
| JSReg | JSReg is a Javascript sandbox which converts code using regular expressions.
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Mantra - Security Framework | Mantra is a security framework which can be very helpful in performing all the five phases of attacks including reconnaissance, scanning and enumeration, gaining access, escalation of privileges,maintaining access, and covering tracks. Apart from that it also contains a set of tools targeted for web developers and code debuggers which makes it handy for both offensive security and defensive security related tasks. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Mobile Security Project | Our primary focus is at the application layer. While we take into consideration the underlying mobile platform and carrier inherent risks when threat modeling and building controls, we are targeting the areas that the average developer can make a difference. Additionally, we focus not only on the mobile applications deployed to end user devices, but also on the broader server-side infrastructure which the mobile apps communicate with. We focus heavily on the integration between the mobile application, remote authentication services, and cloud platform-specific features. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Mobile Security Project - Mobile Threat Model | ||||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP ModSecurity Core Rule Set Project | ModSecurity is an Apache web server module that provides a web application firewall engine. The ModSecurity Rules Language engine is extrememly flexible and robust and has been referred to as the "Swiss Army Knife of web application firewalls." While this is certainly true, it doesn't do much implicitly on its own and requires rules to tell it what to do. In order to enable users to take full advantage of ModSecurity out of the box, we have developed the Core Rule Set (CRS) which provides critical protections against attacks across most every web architecture.
Unlike intrusion detection and prevention systems, which rely on signatures specific to known vulnerabilities, the CRS is based on generic rules which focus on attack payload identification in order to provide protection from zero day and unknown vulnerabilities often found in web applications, which are in most cases custom coded. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Myth Breakers Project | Similar to http://dsc.discovery.com/tv/mythbusters but for appsec, urban legends and assumptions regarding appsec will be tested and there'll be a set of examples that will prove the correctness/incorrectness of a statement related to the question. Every question will be answered in the mailing list and further, a page on the OWASP site will be created to report the results. Also anyone will be able to use the contents of the page/ml in OWASP conferences to spread the verb about what's an urban legend and what's not”. | |||||||||||||||||||||||||||||||||||||||||||||||||
| Opa | Usher in a new generation of web development tools and methodologies. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP O2 Platform Project | Collection of Open Source modules that help Web Application Security Professionals to maximize their efforts and quickly obtain high visibility into an application's security profile.
NOTE: most of the O2 Platform content is still on the external website | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Portuguese Language Project | This project aims to coordinate and push foward the iniciatives developed to translate OWASP materials to Portuguese. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Secure Coding Practices - Quick Reference Guide | This document provides a quick high level reference for secure coding practices. It is technology agnostic and defines a set of general software security coding practices, in a checklist format, that can be integrated into the development lifecycle. Implementation of these practices will mitigate most common software vulnerabilities. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Secure Password Project | The majority of the world's authentication systems rely on a single-factor authentication mechanism: the password. A simple internet search yields thousands of pages dedicated to the topic of creating a secure password, but almost all of them are inherently flawed in that they recommend using either joining pieces of known information to compile a secure password or variations of character conversion schemes on commonly known words and phrases. The inherent problem with this approach is that if the pieces are known, then it is fairly trivial to compute the variations that compile the whole password.
This project will have a two pronged approach designed to put more nails in the single-factor method of authentication.
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Secure the Flag Competition Project | This project aims to create a different type of competition that encourages secure coding rather than hacking skills.
We've all heard of capture the flag competitions, Secure The Flag (STF) is different. STF is a developer focused competition where teams compete to develop the most secure application based on a series of software requirements. Some requirements are just there to set boundaries and standardize the game, some requirements are critical elements and MUST be implemented, other elements are optional and can get you bonus points, but be careful, bonus features are more risky! Teams will receive the requirements, along with a pre-configured VM (LAMP) several days before the competition to allow ample time to design and implement their systems. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Secure Web Application Framework Manifesto | The Secure Web Application Framework Manifesto is a document detailing a specific set of security requirements for developers of web application frameworks to adhere to. The goal is to help develop more secure applications from the start. The manifesto centers around the following beliefs:
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Security Baseline Project | This projects aims to benchmark the security of various enterprise security products/services against OWASP Top 10 risks. Comprehensive assessing security of enterprise products/services, the OWASP Security Baseline initiative will (eventually) lead to vendor-independent security certified solutions. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Software Security Assurance Process | To outlines mandatory and recommended processes and practices to manage risks associated with applications. Software Security is equally dependent on people, processes and technology. The effectiveness of the OWASP Software Security Process is continuously measured and is improved through feedback, threat landscape changes, availability of new concepts and tools. Should be the framework to map Requirements, Dev and Testing guidelines for example. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Threat Modelling Project |
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Uniform Reporting Guidelines | This project will complement the OWASP Testing Guide as well as the OWASP RFP Template. This is going to be a reporting template for vulnerability findings which will be free, base on industry best practices and hopefully will become the defacto standard. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Watcher Project | Watcher is a runtime passive-analysis tool for HTTP-based Web applications. Being passive means it won't damage production systems, it's completely safe to use in Cloud computing, shared hosting, and dedicated hosting environments. Watcher detects Web-application security issues as well as operational configuration issues. Watcher provides pen-testers hot-spot detection for vulnerabilities, developers quick sanity checks, and auditors PCI compliance auditing. It looks for issues related to mashups, user-controlled payloads (potential XSS), cookies, comments, HTTP headers, SSL, Flash, Silverlight, referrer leaks, information disclosure, Unicode, and more.
Major Features:
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Web Application Security Accessibility Project | The practice points out to the fact that a seemingly secure web application does, in reality, protect interests of only a specific group of users. Interests of a great number of users are protected only partially or by no means. This project will focus extensively on the issue of web application security accessibility. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Web Browser Testing System Project | WBTS was built to quickly automate and test various browser and user-agents for security issues. It contains all the necessary services required for testing a browser. The following services are included: DNS, HTTP(S), Logging Services and support for VirtualHosts. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Web Testing Environment Project | ||||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP WebScarab NG Project | *WebScarab NG is a robust tool that assists the user in penetration test. This is a complete rewrite of the old WebScarab application, with a special focus on making the application more user-friendly. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP X5s Project | Active XSS testing and input/output encoding detection
x5s is a Fiddleraddon which aims to assist penetration testers in finding cross-site scripting vulnerabilities. This is not a point and shoot tool, it requires some understanding of how encoding issues lead to XSS, and it requires manual driving. It's main goal is to help you identify the hotspots where XSS might occur by:
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Browser Security Project | ||||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Development Guide | The Development Guide provides practical guidance and includes J2EE, ASP.NET, and PHP code samples. The Development Guide covers an extensive array of application-level security issues, from SQL injection through modern concerns such as phishing, credit card handling, session fixation, cross-site request forgeries, compliance, and privacy issues. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Related Commercial Services | *Controlled environment for commercial providers of ‘OWASP Related’ services to be exposed to the OWASP community Promote the development of professional services around OWASP,
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP RFP-Criteria | Purpose of this project is to simply provide an objective list and a aggregate set of questions from companies to utilize when they issue a RFPs for web application security. | |||||||||||||||||||||||||||||||||||||||||||||||||
| Security Ecosystem Project | Nobody (and no company) can build secure software by themselves. We have seen that vulnerability research can help to drive security forward in companies, but it’s a painful process. We envision a partnership between technology platform vendors and a thriving ecosystem focused on the security of their technology. The ecosystem will include researchers (both builders and breakers), tools, libraries, guidelines, awareness materials, standards, education, conferences, forums, feeds, announcements, and probably more. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Student Chapters Program | ||||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Testing Project | *The OWASP Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues. | |||||||||||||||||||||||||||||||||||||||||||||||||
