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
Difference between revisions of "OWASP Projects Dashboard 2.0/By Alphabetical Order"
(Created page with "{{:Template:OWASP_Project_About/Columns}} {{:Projects/OWASP Academy Portal Project | OWASP Project About/Rows}} {{:Projects/OWASP Alchemist Project | OWASP Project About/Rows}}...") |
(No difference)
|
Revision as of 16:35, 19 April 2011
| Project | Leader(s) | Contributor(s)
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Alchemist Project | Naveen Rudrappa @ Chandrakanth Reddy Narreddy @ Bishan Singh @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Application Security Assessment Standards Project | Matteo Michelini @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Application Security Program for Manager | Matteo Meucci @ | Marco Morana @ Giorgio Fedon @ Stefano di Paola @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Application Security Skills Assessment | Neil Smithline @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Application Security Verification Standard Project | Sahba Kazerooni @ Daniel Cuthbert @ | Dave Wichers @ Jeff Williams @ Mike Boberski | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP AppSensor Project | Michael Coates @ John Melton @ Colin Watson @ Dennis Groves @ | Ryan Barnett @ Simon Bennetts August Detlefsen Randy Janida Jim Manico @ Giri Nambari Eric Sheridan Kevin Wall Dennis Groves
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 | Dave Wichers (as coproject manager) @ John Wilander (as coproject manager) @ David Lindsay (as technical lead) @ | Isaac Dawson @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Cloud ‐ 10 Project | Vinay Bansal @ Shankar Babu Chebrolu @ Pankaj Telang Ken Huang Ove Hansen | Ludovic Petit @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Code Review Project | Larry Conklin @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Common Numbering Project | Dave Wichers (ASVS) @ | Jeff Williams (ASVS) @ Vishal Garg (Development Guide) @ Eoin Keary (Code Review Guide) @ Matteo Meucci (Testing Guide) @ Keith Turpin (Secure Coding Quick Reference) @ Brad Causey (Global Projects Commitee) @ Rick Mitchell | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP CTF Project | Steven van der Baan @ | Martin Knobloch @ Brad Causey @ Ralf Allar @ Andres Riancho @ Danny Chrastil | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Enterprise Application Security Project | Alexander Polyakov @ | N/A Dmitriy Chastuhin @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP ESAPI Objective - C Project | Deepak Subramanian @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| Owasp Esapi Ruby | Paolo Perego @ | Kuai Hinojosa @ Sal Scotto @ Paco Schiaffella @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP ESAPI Swingset Demo Project | Craig Younkins @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP ESAPI Swingset Interactive Project | Fabio Cerullo @ Cathal Courtney @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Enhancing Security Options Framework (ESOP Framework) | Amber Marfatia @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Exams Project | Jason Taylor @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Forward Exploit Tool Project | Marcos Mateos Garcia @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP German Language Project | Matthias Rohr @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Hackademic Challenges Project | Konstantinos Papapanagiotou @ Spyros Gasteratos @ Andreas Venieris (Core Developer) (Founder) @ | Alex Papanikolaou @ Vasileios Vlachos @ Anastasios Stasinopoulos (Founder) @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Hatkit Datafiddler Project | Martin Holst Swende @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Hatkit Proxy Project | Martin Holst Swende @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| HTMLReg | Gareth Heyes @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP HTTP Post Tool | Tom Brenann @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP JavaScript Sandboxes | Gareth Heyes @ | Eduardo Vela Mario Heiderich
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 | Mirko Richter @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Java XML Templates Project | Jeff Ichnowski @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP JBroFuzz Project | Ranulf Green @ | Yiannis Pavlosoglou @ Markus Miedaner @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| JSReg | Gareth Heyes @ | N/A
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Mantra - Security Framework | Abhi M BalaKrishnan @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Mobile Security Project | Jonathan Carter (Overall Project and iGoat Leader) @ Mike Zusman (Mobile Cheat Sheet Leader) @ Tony DeLaGrange (MobiSec Leader) @ Sarath Geethakumar (Mobile Device Management Leader) @ Tom Eston (Mobile Threat Model Leader) @ Don Williams (Mobile Testing Leader) Jonathan Carter (Mobile Top Ten) @ | Zach Lanier @ Jim Manico @ Ludovic Petit @ Swapnil Deshmukh @ Beau Woods @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP ModSecurity Core Rule Set Project | Chaim Sanders @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Myth Breakers Project | Stefano Di Paola @ Dinis Cruz @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP O2 Platform Project | Dinis Cruz @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Portuguese Language Project | Carlos Serrão @ Marcio Machry @ | Lucas Ferreira @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Secure Coding Practices - Quick Reference Guide | Keith Turpin @ | Dan Kranz Walt Pietrowski Catherine Spencer Caleb McGary @ Jim Manico @ Brad Causey @ Ludovic Petit @ Michael V. Scovetta @ Jason Coleman Tarcizio Vieira Neto | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Secure Password Project | Josh Sokol @ | James Wickett @ Matt Tesauro @ Ben Broussard @ Genung Gregory @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Secure the Flag Competition Project | Mark Bristow @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Secure Web Application Framework Manifesto | Rohit Sethi @ Yuk Fai Chan @ | Tom Aratyn @ Sahba Kazerooni @ Patrick Szeto @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Security Baseline Project | Marian Ventuneac @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Software Security Assurance Process | Mateo Martínez @ | Martin Pellegrino | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Threat Modelling Project | Anurag Agarwal @ | N/A
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Uniform Reporting Guidelines | Vlad Gostomelsky @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Watcher Project | Chris Weber @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Web Application Security Accessibility Project | Petr Závodský @ | Jan Meszáros Tomáš Bakos Jakub Tomšej TEREZA | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Web Browser Testing System Project | Isaac Dawson @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP WebScarab NG Project | Daniel Brzozowski @ | Rogan Dawes (Past Contributor) @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP X5s Project | Chris Weber @ | N/A
| |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Browser Security Project | N/A | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Development Guide | N/A | Andrew van der Stock @ Ken Owen @ | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Related Commercial Services | Eoin Keary @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP RFP-Criteria | Tom Brennan @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| Security Ecosystem Project | Jeff Williams @ | This project is currently seeking volunteers. If you are interested please contact us through the mailing list. | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Student Chapters Program | Mateo Martinez @ Antonios Manaras @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
| OWASP Testing Project | Andrew Muller @ Matteo Meucci @ | N/A | |||||||||||||||||||||||||||||||||||||||||||||||||
