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:

• Security Requirements
• Threat Risk Modeling
• Use and Abuse Cases
• Secure Coding Guideline

• The final goal is to integrate a set of OWASP projects into an Application Security Assessment process in order to define a model which can be used by an organization to provide application security through OWASP standards.

• In 9 years of activities OWASP has become the standard for Web Application Security. We are full of projects that are fantastic resources for developers and testers.
• OWASP SAMM and ASVS address many security management issues.
• What I see is missing now is a kind of guideline the managers should follow to adhere to the OWASP standards. I see that every security manager has different idea about the secure dev and testing (when and how to perform it).
• This project wants to address the Security Manager point of view and tell him what he should do to implement an efficient Application Security Program.
• In this project we will show all the OWASP Guides and tools and will tell why,how and when to use that. We can do that in function of the size of the organization, management roles and objectives. The idea is for example for a Bank Company,OWASP says to perform a OWASP SAMM assessment every year, to per perform Code Review and WAPT to all critical new software, testing every 3 months, etc.. Every activities is linked to an OWASP resource to use.

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.

• Use as a metric - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
• Use as guidance - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
• Use during procurement - Provide a basis for specifying application security verification requirements in contracts.

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.
Detection AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
Response AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
Defending the Application An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

• Main
• RoadMap and Get Involvement
• Education branch of ASIDE: ESIDE
• Main
• Use the Java Encoder Project
• How To Handle Numbers
• Deploy the Java Encoder Project
• Grave Accent Issue
• Encoding and Template Literals
• Roadmap

OWASP ASIDE/ESIDE OWASP ASIDE/ESIDE project consist of two branches, the ASIDE branch that focuses on detecting software vulnerabilities and helping developer write secure code, and the ESIDE branch that focuses on help educating students secure programming knowledge and practices. Details about ESIDE are described [here]. OWASP ASIDE is led by [Mahmoud Mohammadi] and Bill Chu. Other major contributors include Jun Zhu ,Jing Xie, Heather Richter Lipford, Tyler Thomas, John Melton & Will Stranathan. We have presented our talk Using Interactive Static Analysis for Early Detection of Software Vulnerabilities at AppSec USA 2012. You can view and download our presentation here. We have presented our talk Secure Programming Support in IDE at AppSec USA 2011 in Minneapolis. You can view and download our presentation here. Introduction ASIDE is an abbreviation for Application Security plugin for Integrated Development Environment. It is an Eclipse Plugin which is a software tool primarily designed to help developers write more secure code by detecting and identifying potentially vulnerable code and providing informative fixes during the construction of programs in IDEs. Description ASIDE currently has three prototype implementations: ASIDE CodeRefactoring for Education, ASIDE CodeAnnotate which consists of two implementations, ASIDE JavaCodeAnnotate and ASIDE PHPCodeAnnotate. ASIDE CodeRefactoring for Education is an Eclipse plugin that aims to detect root cause of vulnerabilities that are caused by untrusted inputs get in to the application and be consumed without validation, and provide interactive code refactoring support for students and professional developers to learn secure programming practices and write more secure code. ASIDE CodeAnnotate is another Eclipse plugin which deals with a different class of vulnerabilities that are more application logic specific. Specifically, it is aimed at addressing CSRF and broken access control issues while the developers are writing their code. An older version of ASIDE DEMO shows you earlier design and implementation of CodeRefactoring, if you are interested in knowing. You will need Adobe Flash to display it. Research Activities 1. Mahmoud Mohammadi, Bill Chu and Heather Richter Lipford, “POSTER : Using Unit Testing to Detect Sanitization Flaws,” in CCS’15: The 22nd ACM SIGSAC Conference on Computer and Communications Security, 2015, Denver, USA 2. Jun Zhu, Bill Chu, Heather Richter Lipford, Tyler Thomas, Mitigating Access Control Vulnerabilities through Interactive Static Analysis , In Proceedings of the 20th ACM Symposium on Access Control Models and Technologies, June 2015, Vienna, Austria 3. Jun Zhu, Jing Xie, and Bill Chu, Supporting Secure Programming in Web Applications through Interactive Static Analysis, In Journal of Advanced Research, Elsevier, December, 2013. 4. Jing Xie, Heather Richter Lipford, and Bill Chu, Evaluating Interactive Support for Secure Programming, In Proceedings of ACM Conference on Human Factors in Computing Systems (CHI), May 2012, Austin, Texas, USA 5. Jing Xie, Bill Chu, Heather Richter Lipford, and John T. Melton, ASIDE:IDE Support for Web Application Security, In Proceedings of 27th Annual Computer Security Applications Conference (ACSAC), December 5–9, 2011, Orlando, FL, USA 6. Jing Xie, Heather Richter Lipford, and Bill Chu, Why do programmers make security errors?, In Proceedings of IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), September 18–22, 2011, Pittsburgh, PA, USA 7. Jing Xie, Bill Chu, and Heather Richter Lipford Interactive Support for Secure Software Development, In Proceedings of Engineering Secure Software and Systems Third International Symposium (ESSoS), February 2011, Madrid, Spain Relevant Research 8. Heather Richter Lipford, Jing Xie, Bill Chu, etc The Impact of A Structured Application Development Framework on Web Application Security Licensing OWASP ASIDE is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

What is ASIDE/ESIDE? OWASP ASIDE provides: Interactive Static Analysis support to developers in Eclipse IDE (for Java and PHP) to detect and mitigate software vulnerabilities in the code Interactive Secure Programming Education opportunities in IDE for students as well as professional developers to help them write more secure code as well as learn best secure programming practices ESIDE provides: Identification of targeted Java code patterns. Interactive instructional opportunities for students in the IDE. Real-time IDE support for secure code education (Java). p.s. (Details about ESIDE are described [here].) Presentation 1. Our talk Using Interactive Static Analysis for Early Detection of Software Vulnerabilities at AppSec USA 2012. You can view and download our presentation. 2. Our talk Secure Programming Support in IDE at AppSec USA 2011 in Minneapolis. You can view and download our presentation. Project Leaders [Mahmoud Mohammadi], Bill Chu, Jun Zhu Related Projects OWASP_AppSensor_Project Openhub OWASP ASIDE Ohloh

Quick Download Runnable plugins and installation guidelines The recent publicly available ASIDE CodeRefactoring plugin can be downloaded from here. You also need to download the complementary logging facility to make ASIDE work properly. ASIDE CodeRefactoring 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. The recent publicly available ASIDE CodeAnnotate plugin can be downloaded from here. ASIDE CodeAnnotate is built upon Eclipse IDE for Java EE Developers Version 3.5+. To make it work, please place the jar files under the plugins folder of your Eclipse installation directory and then restart your Eclipse. Demo of how to run CodeAnnotate can be viewed from here. New! We recently released a version of ASIDE CodeAnnotate plugin for Eclipse PHP Development Environment. It is built upon Eclipse PDT framework, you can download the plugin here. As it is still in incubator phase at this point, we recommend you to first install the configured Eclipse PHP package we provide on Linux, which can be downloaded here, and then place the jar file under the plugins folder of the Eclipse installation directory, and then restart your Eclipse. Demo of how to run CodeAnnotate can be viewed from here. A good PHP open source project you can try the plugin against is Moodle; Source Code ASIDE Education with CodeRefactoring: https://github.com/JunZhuSecurity/ASIDE-Education ASIDE PHPCodeAnnotate: https://github.com/JunZhuSecurity/ASIDE-PHPCodeAnnotate ASIDE JavaCodeAnnotate: https://github.com/JunZhuSecurity/ASIDE-JavaCodeAnnotate Email List Project Email List: https://lists.owasp.org/mailman/listinfo/owasp-aside-project News and Events [18-19 September 2014] Bill will be hosting a session about ASIDE project at AppSec USA 2014 in Denver! [30 April 2014] ASIDE PHPCodeAnnotate plugin for Eclipse PHP IDE released! [07 December 2013] ASIDE paper titled "Supporting Secure Programming in Web Applications through Interactive Static Analysis" accepted! [10 May 2013] ASIDE Education with CodeRefactoring plugin for Eclipse Java IDE released! [22 October 2012] ASIDE paper titled "Interactive Support for Secure Programming Education" accepted! [September 2012] Bill and Jun delivered ASIDE talk titled "Using Interactive Static Analysis for Early Detection of Software Vulnerabilities" at OWASP AppSec USA in Austin! [8-10 August 2012] Jun gave a poster about ASIDE at USENIX Security 12! [10 May 2012] ASIDE JavaCodeAnnotate plugin for Eclipse Java IDE released! In Print N/A Classifications

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:

• Try ASIDE and email your feedback, comments to the project leaders.
• Do pilot study with ASIDE in your team, and the project leaders would love to collaborate!

ESIDE

The 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].

Introduction

ESIDE (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.

Description

Deployed 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.

Publications

1. 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 Guidelines

The 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 Code

The most recent source code of ESIDE can be accessed via https://github.com/witny23/ESIDE.

Priorities and get involved

As 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!!

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.

• The current release of this project is not suitable for production use

• The application is intended for Java Developers. The goal of the application is to teach developers about the functionality of the ESAPI library and give users a practical understanding of how it can be used to protect web applications against common security vulnerabilities.

1. Remote code execution
2. SQL injection
3. Format string vulnerabilities
4. Cross Site Scripting (XSS)
5. Session hacking
6. Denial of service (DoS) attacks
7. Eavesdropping /Sniffing/ Phishing
8. Identity Spoofing
9. Man-in-the-Middle Attacks
10. Username enumeration
    1. Instrumentation & Audits for:
    2. Critical Business Areas
    3. User Management
    4. Un-usual activities
    5. Interfaces Integrations
11. IIS Tweaks
12. Password Policy

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.

• The Hackademic Challenges project implements realistic scenarios with known vulnerabilities in a safe, controllable environment. Users can attempt to discover and exploit these vulnerabilities in order to learn important concepts of information security through the attacker's perspective.
• They have been especially designed for use in a classroom environment where they have been proved a valuable educational tool. Using hackademic challenges students have the chance to experience application security in a realistic environment, something that triggers their interest and provokes a lot of interesting discussions.
• The Hackademic Challenges are currently used in several Universities and have received very positive feedback from both professors and students.

• Built in Python/Qt + MongoDB.

• • Swing-based UI,
  • Interception capabilities with manual edit,
  • Syntax highlightning (html/form-data/http) based on JFlex,
  • Storage of http traffic into MongoDB database,
  • Interception capabilities of tcp-traffic,
  • Possibilities to intercept in Fully Qualified mode (like all other http-proxies) OR Non-fully qualified mode. The latter means that interception is performed *after* the host has been parsed, thereby enabling the user to submit non-valid http content.
• The primary purpose of the Hatkit Proxy is to create a minimal, lightweight proxy which stores traffic into an offline storage where further analysis can be performed, e.g. all kinds of analysis which is currently implemented by the proxies themselves (webscarab/burp/paros etc).
• Also, since the http traffic is stored in a MongoDB, the traffic is stored at an object-level, retaining the structure of the parsed traffic, which enables a user to perform advanced queries later.
• The proxy should also be a good choice for 'defenders' who wants to (temporarily?) monitor traffic. The proxy itself is, as stated, very lightweight, and the backend MongoDB storage scales very well and should be able to handle extreme amounts of data. This would allow defenders to perform advanced post-mortem or real-time analysis of incoming traffic.
• Built in Java/Swing + MongoDB.

1. REDIRECT [iGoat Tool Project]

{{Template: OWASP Project About/Rows2

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_about_page =Projects/OWASP_iGoat_Project }}

OWASP Java Encoder Project The OWASP Java Encoder is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. This project will help Java web developers defend against Cross Site Scripting! Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts (primarily JavaScript) are injected into otherwise trusted web sites. You can read more about Cross Site Scripting here: Cross-site_Scripting_(XSS). One of the primary defenses to stop Cross Site Scripting is a technique called Contextual Output Encoding. WARNING: Please note that XSS prevention requires other defensive strategies besides encoding! For more information, please read about Cross Site Scripting prevention here: XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet. As of September 16, 2018 there are no security issues submitted against this project! https://github.com/OWASP/owasp-java-encoder/issues. We actively track project issues and seek to remediate any issues that arise. The project owners feel this project is stable and ready for production use and are seeking project status promotion. Introduction Contextual Output Encoding is a computer programming technique necessary to stop Cross Site Scripting. This project is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. It provides numerous encoding functions to help defend against XSS in a variety of different HTML, JavaScript, XML and CSS contexts. Quick Overview The OWASP Java Encoder library is intended for quick contextual encoding with very little overhead, either in performance or usage. To get started, simply add the encoder-1.2.2.jar, import org.owasp.encoder.Encode and start encoding. Please look at the javadoc for Encode to see the variety of contexts for which you can encode. Tag libraries and JSP EL functions can be found in the encoder-jsp-1.2.2.jar. Happy Encoding! Licensing The OWASP Java Encoder is free to use under the New BSD License.

What is this? The OWASP Java Encoder provides: Output Encoding functions to help stop XSS Java 1.5+ standalone library Important Links Java Encoder at GitHub Issue Tracker Mailing List Java Encoder Mailing List Project Leaders Author: Jeff Ichnowski @ Jim Manico @ Jeremy Long @ Related Projects XSS (Cross Site Scripting) Prevention Cheat Sheet OWASP Java HTML Sanitizer Project OWASP JSON Sanitizer OWASP Dependency Check Sourceclear Headlines Google KeyCzar Apache SHIRO

Quick Download encoder-1.2.2.jar encoder-jsp-1.2.2.jar News and Events [14 September 2018] 1.2.2 Released! [19 February 2017] 1.2.1 Released! [11 June 2016] No reported issues and library use is strong! [1 May 2015] Moved to GitHub [12 Apr 2015] 1.2 Released! [10 Apr 2015] GitHub move [1 Feb 2015] Removed ThreadLocal [20 Mar 2014] Doc additions [5 Feb 2014] New Wiki [4 Feb 2014] 1.1.1 Released In Print We will be releasing a user guide soon! Classifications New BSD License

<body><%= Encode.forHtml(UNTRUSTED) %></body>

<textarea name="text"><%= Encode.forHtmlContent(UNTRUSTED) %></textarea>

<input type="text" name="address" value="<%= Encode.forHtmlAttribute(UNTRUSTED) %>" />

<div style="width:<= Encode.forCssString(UNTRUSTED) %>">
<div style="background:<= Encode.forCssUrl(UNTRUSTED) %>">

 <script type="text/javascript">
 var msg = "<%= Encode.forJavaScriptBlock(UNTRUSTED) %>";
 alert(msg);
 </script>

 <button 
 onclick="alert('<%= Encode.forJavaScriptAttribute(UNTRUSTED) %>');">
 click me</button>

<a href="/search?value=<%= Encode.forUriComponent(UNTRUSTED) %>&order=1#top">

<a href="/page/<%= Encode.forUriComponent(UNTRUSTED) %>">

String url = validateURL(untrustedInput);

 <a href="<%= Encode.forHtmlAttribute(untrustedUrl) %>">
 <%= Encode.forHtmlContent(untrustedLinkName) %>
 </a>

<%@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>

var javaScriptNumber = <%= javaNumber %>;

<% // option (1)
String javaNumber = (untrusted data);
Double actualNumber = Double.parseDouble(javaNumber); // don’t forget to catch NumberFormatException
%>
<script>
var jsNumber = <%= actualNumber %>;
</script>

<% // option (2)
String javaNumber = (untrusted data);
%>
<script>
var jsNumber = parseInt("<%=Encode.forJavaScript(javaNumber)%>");
</script>

<dependency>
   <groupId>org.owasp.encoder</groupId>
   <artifactId>encoder</artifactId>
   <version>1.2.2</version>
</dependency>

<dependency>
   <groupId>org.owasp.encoder</groupId>
   <artifactId>encoder-jsp</artifactId>
   <version>1.2.2</version>
</dependency>

<input value="this is the value">
<input value=`this is the value`>

<div id=a><input value="``onmouseover=alert(1)"></div> 
<div id=b></div>
<script>b.innerHTML=a.innerHTML</script>

<input value=``onmouseover=alert(1)>

<input value="" onmouseover="alert(1)">

<input value="``onmouseover=alert(1)">

<script>a.innerHTML=b.innerHTML.replace(/`/g, "`");</script>

<input value=&#96;&#96;onmouseover=alert(1)>

var user = "<%= Encode.forJavaScript(user) %>";
`Hello ${user}, here is your total: ${total}`

`Hello ${"<%= Encode.forJavaScript(user) $>"}, here is your total ${total}`

Main

OWASP HTML Sanitizer Project The OWASP HTML Sanitizer is a fast and easy to configure HTML Sanitizer written in Java which lets you include HTML authored by third-parties in your web application while protecting against XSS. The existing dependencies are on guava and JSR 305. The other jars are only needed by the test suite. The JSR 305 dependency is a compile-only dependency, only needed for annotations. This code was written with security best practices in mind, has an extensive test suite, and has undergone adversarial security review. A great place to get started using the OWASP Java HTML Sanitizer is here: https://github.com/OWASP/java-html-sanitizer/blob/master/docs/getting_started.md. Benefits Very easy to use. It allows for simple programmatic POSITIVE policy configuration (see below). No XML config. Actively maintained by Mike Samuel from Google's AppSec team! Passing 95+% of AntiSamy's unit tests plus many more. This is code from the Caja project that was donated by Google. It is rather high performance and low memory utilization. Java 1.5+ Provides 4X the speed of AntiSamy sanitization in DOM mode and 2X the speed of AntiSamy in SAX mode. Licensing The OWASP HTML Sanitizer is free to use and is dual licensed under the Apache 2 License and the New BSD License.

What is this? The OWASP HTML Sanitizer Projects provides Java based HTML sanitization of untrusted HTML! Code Repo OWASP HTML Sanitizer at GitHub Email List Questions? Please sign up for our Project Support List Project Leaders Author/Project Leader Mike Samuel @ Project Manager Jim Manico @ Related Projects XSS (Cross Site Scripting) Prevention Cheat Sheet OWASP JSON Sanitizer OWASP Java Encoder Project OWASP Dependency Check OWASP AntiSamy Sourceclear Headlines Google KeyCzar Apache SHIRO Ohloh https://www.ohloh.net/p/owasp-java-html-sanitizer

Quick Download OWASP HTML Sanitizer at Maven Central News and Events [20 Feb 2018] Update 20180219.1 addresses iOS/MacOS "text bomb" [3 April 2017] HTML5 Support Update [28 June 2016] v20160628.1 Released [14 Apr 2016] v20160413.1 Released [1 May 2015] Move to GitHub [2 July 2014] v239 Released [3 Mar 2014] v226 Released [5 Feb 2014] New Wiki [4 Sept 2013] v209 Released Change Log For recent release notes, please visit the changelog on GitHub. Classifications Apache 2 License

Creating a HTML Policy

You 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 Sanitization

CSS 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 Images

Inline 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")

Questions

How was this project tested?
This code was written with security best practices in mind, has an extensive test suite, and has undergone adversarial security review.

How is this project deployed?
This project is best deployed through Maven https://github.com/OWASP/java-html-sanitizer/blob/master/docs/getting_started.md

Roadmap

• Maintaining a fully featured HTML sanitizer is a lot of work. We intend to continue to handle community questions and bug reports in a very timely manner.
• There are no plans for major new features other than supporting incoming requests for advanced sanitization such as additional HTML5 support.

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.

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.

NOTE: most of the O2 Platform content is still on the external website
www.o2platform.com

This project will have a two pronged approach designed to put more nails in the single-factor method of authentication.

• First, we will create an interactive portal where penetration testers are able to enter known information about the target. This known information can then be broken down and converted to create a large downloadable dictionary list that has been customized to the target. This list will be added to a comprehensive standard dictionary with the character conversions performed on that as well. The result would be a large list of commonly used passwords, dictionary words, target specific passwords, and various derivitives of each which should cover the vast majority of passwords used today.

• The second prong of our approach will be to capture the results of all data collected into a large database. This data will be hashed with common hashing methods to create what will become the world's largest rainbow tables. A user can provide us with a hash and we can do a lookup against these tables to search for matching entries. The goal here is to put a stop to unsalted password hashes for authentication.

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.

• Frameworks that are ‘secure by default’ will yield a dramatic reduction in the number of common web application security vulnerabilities.
• Application security experts should provide, on a regularly basis, updated guidance to framework developers on how to incorporate mechanisms to avoid newly discovered vulnerabilities.

Major Features:

• Passive detection of security, privacy, and PCI compliance issues in HTTP, HTML, Javascript, CSS, and development frameworks (e.g. ASP.NET, JavaServer);
• Works seamlessly with complex Web 2.0 applications while you drive the Web browser;
• Non-intrusive, will not raise alarms or damage production sites;
• Real-time analysis and reporting - findings are reported as they’re found, exportable to XML, HTML, and Team Foundation Server (TFS);
• Configurable domains with wildcard support;
• Extensible framework for adding new checks.

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:

• Detecting where safe encodings were not applied to emitted user-inputs
• Detecting where Unicode character transformations might bypass security filters
• Detecting where non-shortest UTF-8 encodings might bypass security filters

Review this project. For more details about ZAP see the new ZAP website at zaproxy.org Share this:

Quick Download Download OWASP ZAP! Donate to ZAP News and Events Please see the News and Talks tabs Change Log zaproxy zap-extensions Code Repo zaproxy zap-extensions Email List Questions? Please ask on the ZAP User Group Project Leader Project Leader Simon Bennetts @ Co-Project Leaders Ricardo Pereira @ Rick Mitchell @ Related Projects OWASP WTE OWASP OWTF Open Hub Stats https://www.openhub.net/p/zaproxy Classifications Apache 2 License

• Allow buyers to find the best providers for their needs.