OWASP - User contributions [en]

Category:OWASP AntiSamy Project

2017-09-25T14:50:54Z

Arshan: no quickdownload available

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP AntiSamy Project==

OWASP AntiSamy is a library for HTML and CSS encoding.

==Introduction==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) of Contrast Security with help from Jason Li (jason.li [at the] owasp.org) of Aspect Security (http://www.aspectsecurity.com/).

==Description==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take care of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is AntiSamy ==

OWASP AntiSamy provides:

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== Presentations ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - by Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - by Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - by Jason Li - AntiSamy project contributor

From Shmoocon 2009 (Washington, DC): [http://www.shmoocon.org/2009/slides/OWASP%20Winter%202009%20Shmoocon%20-%20Anti%20Samy.pptx AntiSamy - Picking a Fight with XSS (pptx)] - by Arshan Dabirsiaghi - AntiSamy project lead

== Project Leader ==

[mailto:arshan.dabirsiaghi@gmail.com Arshan Dabirsiaghi]

== Related Projects ==

== Ohloh ==

* https://www.ohloh.net/p/owaspantisamy

| valign="top" style="padding-left:25px;width:200px;" |

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= How do I get started? =

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-tinymce-X.X.X.xml
#* antisamy-slashdot-X.X.X.xml
#* antisamy-ebay-X.X.X.xml
#* antisamy-myspace-X.X.X.xml
#* antisamy-anythinggoes-X.X.X.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see [[the .NET page]].

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package '''antisamy-X.X.X-src.jar'''. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's [[an example POM for including AntiSamy]]. If you want a jar file, then download the '''antisamy-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option, ''only available for versions before 1.2,'' is to download '''antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues. ''This option is no longer available after version 1.2.''

You must also download required dependencies, which are documented in the '''Developer Guide.pdf''' file.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) was, at the time this project was born, arguably the most popular social networking site today. Users were allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace was using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace was _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 5 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

= Acknowledgements =
== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com].

=== Issue tracking ===

Visit the [https://github.com/nahsra/antisamy/issues GitHub issue tracker].

==Sponsors==
The AntiSamy project is sponsored by [http://www.contrastsecurity.com/ Contrast Security].

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]].

= Road Map =
This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

=Project About=
== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

__NOTOC__ <headertabs />

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

{{OWASP Builders}}

Category:OWASP AntiSamy Project

2017-09-25T14:43:24Z

Arshan: /* Introduction */

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP AntiSamy Project==

OWASP AntiSamy is a library for HTML and CSS encoding.

==Introduction==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) of Contrast Security with help from Jason Li (jason.li [at the] owasp.org) of Aspect Security (http://www.aspectsecurity.com/).

==Description==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take care of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is AntiSamy ==

OWASP AntiSamy provides:

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== Presentations ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - by Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - by Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - by Jason Li - AntiSamy project contributor

From Shmoocon 2009 (Washington, DC): [http://www.shmoocon.org/2009/slides/OWASP%20Winter%202009%20Shmoocon%20-%20Anti%20Samy.pptx AntiSamy - Picking a Fight with XSS (pptx)] - by Arshan Dabirsiaghi - AntiSamy project lead

== Project Leader ==

[mailto:arshan.dabirsiaghi@gmail.com Arshan Dabirsiaghi]

== Related Projects ==

== Ohloh ==

* https://www.ohloh.net/p/owaspantisamy

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

https://code.google.com/p/owaspantisamy/downloads/list

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= How do I get started? =

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-tinymce-X.X.X.xml
#* antisamy-slashdot-X.X.X.xml
#* antisamy-ebay-X.X.X.xml
#* antisamy-myspace-X.X.X.xml
#* antisamy-anythinggoes-X.X.X.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see [[the .NET page]].

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package '''antisamy-X.X.X-src.jar'''. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's [[an example POM for including AntiSamy]]. If you want a jar file, then download the '''antisamy-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option, ''only available for versions before 1.2,'' is to download '''antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues. ''This option is no longer available after version 1.2.''

You must also download required dependencies, which are documented in the '''Developer Guide.pdf''' file.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) was, at the time this project was born, arguably the most popular social networking site today. Users were allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace was using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace was _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 5 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

= Acknowledgements =
== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com].

=== Issue tracking ===

Visit the [https://github.com/nahsra/antisamy/issues GitHub issue tracker].

==Sponsors==
The AntiSamy project is sponsored by [http://www.contrastsecurity.com/ Contrast Security].

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]].

= Road Map =
This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

=Project About=
== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

__NOTOC__ <headertabs />

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

{{OWASP Builders}}

Category:OWASP AntiSamy Project

2017-09-25T14:42:50Z

Arshan: made it a little more up to date!

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP AntiSamy Project==

OWASP AntiSamy is a library for HTML and CSS encoding.

==Introduction==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (jason.li [at the] owasp.org), both of Aspect Security (http://www.aspectsecurity.com/).

==Description==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take care of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is AntiSamy ==

OWASP AntiSamy provides:

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== Presentations ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - by Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - by Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - by Jason Li - AntiSamy project contributor

From Shmoocon 2009 (Washington, DC): [http://www.shmoocon.org/2009/slides/OWASP%20Winter%202009%20Shmoocon%20-%20Anti%20Samy.pptx AntiSamy - Picking a Fight with XSS (pptx)] - by Arshan Dabirsiaghi - AntiSamy project lead

== Project Leader ==

[mailto:arshan.dabirsiaghi@gmail.com Arshan Dabirsiaghi]

== Related Projects ==

== Ohloh ==

* https://www.ohloh.net/p/owaspantisamy

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

https://code.google.com/p/owaspantisamy/downloads/list

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= How do I get started? =

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-tinymce-X.X.X.xml
#* antisamy-slashdot-X.X.X.xml
#* antisamy-ebay-X.X.X.xml
#* antisamy-myspace-X.X.X.xml
#* antisamy-anythinggoes-X.X.X.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see [[the .NET page]].

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package '''antisamy-X.X.X-src.jar'''. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's [[an example POM for including AntiSamy]]. If you want a jar file, then download the '''antisamy-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option, ''only available for versions before 1.2,'' is to download '''antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues. ''This option is no longer available after version 1.2.''

You must also download required dependencies, which are documented in the '''Developer Guide.pdf''' file.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) was, at the time this project was born, arguably the most popular social networking site today. Users were allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace was using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace was _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 5 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

= Acknowledgements =
== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com].

=== Issue tracking ===

Visit the [https://github.com/nahsra/antisamy/issues GitHub issue tracker].

==Sponsors==
The AntiSamy project is sponsored by [http://www.contrastsecurity.com/ Contrast Security].

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]].

= Road Map =
This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

=Project About=
== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

__NOTOC__ <headertabs />

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

{{OWASP Builders}}

Category:OWASP AntiSamy Project

2017-09-25T14:41:15Z

Arshan:

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP AntiSamy Project==

OWASP AntiSamy is a library for HTML and CSS encoding.

==Introduction==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (jason.li [at the] owasp.org), both of Aspect Security (http://www.aspectsecurity.com/).

==Description==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take care of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is AntiSamy ==

OWASP AntiSamy provides:

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== Presentations ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - by Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - by Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - by Jason Li - AntiSamy project contributor

From Shmoocon 2009 (Washington, DC): [http://www.shmoocon.org/2009/slides/OWASP%20Winter%202009%20Shmoocon%20-%20Anti%20Samy.pptx AntiSamy - Picking a Fight with XSS (pptx)] - by Arshan Dabirsiaghi - AntiSamy project lead

== Project Leader ==

[mailto:arshan.dabirsiaghi@gmail.com Arshan Dabirsiaghi]

== Related Projects ==

== Ohloh ==

* https://www.ohloh.net/p/owaspantisamy

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

https://code.google.com/p/owaspantisamy/downloads/list

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= How do I get started? =

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-tinymce-X.X.X.xml
#* antisamy-slashdot-X.X.X.xml
#* antisamy-ebay-X.X.X.xml
#* antisamy-myspace-X.X.X.xml
#* antisamy-anythinggoes-X.X.X.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see [[the .NET page]].

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package '''antisamy-X.X.X-src.jar'''. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's [[an example POM for including AntiSamy]]. If you want a jar file, then download the '''antisamy-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option, ''only available for versions before 1.2,'' is to download '''antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues. ''This option is no longer available after version 1.2.''

You must also download required dependencies, which are documented in the '''Developer Guide.pdf''' file.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) is arguably the most popular social networking site today. Users are allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace is currently using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace is _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 5 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

= Acknowledgements =
== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com].

=== Issue tracking ===

Visit the [https://github.com/nahsra/antisamy/issues GitHub issue tracker].

==Sponsors==
The AntiSamy project is sponsored by [http://www.contrastsecurity.com/ Contrast Security].

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]].

= Road Map =
This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

=Project About=
== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

__NOTOC__ <headertabs />

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

{{OWASP Builders}}

Category:OWASP AntiSamy Project

2017-09-25T00:20:40Z

Arshan: updated long-wrong sponsor info

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP AntiSamy Project==

OWASP AntiSamy is a library for HTML and CSS encoding.

==Introduction==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (jason.li [at the] owasp.org), both of Aspect Security (http://www.aspectsecurity.com/).

==Description==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take care of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is AntiSamy ==

OWASP AntiSamy provides:

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== Presentations ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - by Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - by Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - by Jason Li - AntiSamy project contributor

From Shmoocon 2009 (Washington, DC): [http://www.shmoocon.org/2009/slides/OWASP%20Winter%202009%20Shmoocon%20-%20Anti%20Samy.pptx AntiSamy - Picking a Fight with XSS (pptx)] - by Arshan Dabirsiaghi - AntiSamy project lead

== Project Leader ==

[mailto:arshan.dabirsiaghi@gmail.com Arshan Dabirsiaghi]

== Related Projects ==

== Ohloh ==

* https://www.ohloh.net/p/owaspantisamy

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

https://code.google.com/p/owaspantisamy/downloads/list

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= How do I get started? =

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-tinymce-X.X.X.xml
#* antisamy-slashdot-X.X.X.xml
#* antisamy-ebay-X.X.X.xml
#* antisamy-myspace-X.X.X.xml
#* antisamy-anythinggoes-X.X.X.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see [[the .NET page]].

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package '''antisamy-X.X.X-src.jar'''. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's [[an example POM for including AntiSamy]]. If you want a jar file, then download the '''antisamy-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option, ''only available for versions before 1.2,'' is to download '''antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues. ''This option is no longer available after version 1.2.''

You must also download required dependencies, which are documented in the '''Developer Guide.pdf''' file.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) is arguably the most popular social networking site today. Users are allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace is currently using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace is _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 5 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

= Acknowledgements =
== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com].

=== Issue tracking ===

Visit the [http://code.google.com/p/owaspantisamy/issues/list Google Code issue tracker].

==Sponsors==
The AntiSamy project is sponsored by [http://www.contrastsecurity.com/ Contrast Security].

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]].

= Road Map =
This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

=Project About=
== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

__NOTOC__ <headertabs />

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

{{OWASP Builders}}

Deserialization Cheat Sheet

2015-11-24T18:23:44Z

Arshan:

=Introduction=

This article is focused on providing clear, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> keyword].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
* [http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles AppSecCali 2015 - Marshalling Pickles]
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove Security - Vulnerability Announcement]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Deserialization Cheat Sheet

2015-11-24T18:23:34Z

Arshan:

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> keyword].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
* [http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles AppSecCali 2015 - Marshalling Pickles]
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove Security - Vulnerability Announcement]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Deserialization Cheat Sheet

2015-11-18T16:34:13Z

Arshan: /* Prevent Data Leakage and Trusted Field Clobbering */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> keyword].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
* [http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles AppSecCali 2015 - Marshalling Pickles]
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove Security - Vulnerability Announcement]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T16:10:26Z

Arshan: /* References */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
* [http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles AppSecCali 2015 - Marshalling Pickles]
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove Security - Vulnerability Announcement]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T16:10:15Z

Arshan: /* References */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles AppSecCali 2015 - Marshalling Pickles]
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove Security - Vulnerability Announcement]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T06:12:44Z

Arshan: /* Introduction */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles]
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T06:12:11Z

Arshan: /* Using Alternative Data Formats */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, simple, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles]
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T06:11:35Z

Arshan: /* Harden All java.io.ObjectInputStream Usage with an Agent */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, simple, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating separate objects domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles]
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T06:11:21Z

Arshan: /* Harden All java.io.ObjectInputStream Usage with an Agent */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, simple, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial produ

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating separate objects domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles]
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T05:53:17Z

Arshan: /* Harden All java.io.ObjectInputStream Usage with an Agent */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, simple, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating separate objects domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles]
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T05:39:15Z

Arshan: /* Java */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, simple, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating separate objects domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles]
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T05:38:47Z

Arshan: /* Java */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, simple, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
[https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
[https://github.com/Contrast-Security-OSS/contrast-rO0 by Contrast Security]
[https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating separate objects domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles]
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T04:46:28Z

Arshan: /* Override ObjectInputStream#resolveClass() */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, simple, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.
Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in rO0 and NotSoSerial

===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

==Python==

==Ruby==

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating separate objects domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= References =
* [[Deserialization of untrusted data]]
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles]
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere]

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

<nowiki>[[Category:Cheatsheets]]</nowiki>

Deserialization Cheat Sheet

2015-11-18T03:45:43Z

Arshan: /* Using Alternative Data Formats */

Deserialization Cheat Sheet

2015-11-18T03:45:13Z

Arshan: /* Prevent Data Leakage */

Deserialization Cheat Sheet

2015-11-18T03:44:40Z

Arshan: /* Prevent Deserialization of Domain Objects */

Deserialization Cheat Sheet

2015-11-17T22:33:31Z

Arshan:

Deserialization of untrusted data

2015-11-17T21:54:41Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code, when deserialized.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby (and probably others)
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [https://en.wikipedia.org/wiki/Return-oriented_programming Return-Oriented-Programming] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability ([https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2092 CVE-2011-2092]). You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame object on the target server. The created JFrame object will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends. Researchers have found [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ complex object graphs which, when deserialized, can lead to remote code execution] in most Java software.

The final example is a denial-of-service attack against any Java application that allows deserialization. The HashSet called "root" in the following code sample has members that are recursively linked to each other. When deserializing this "root" object, the JVM will begin creating a recursive object graph. It will never complete, and consume CPU indefinitely.

<pre>
Set root = new HashSet();
Set s1 = root;
Set s2 = new HashSet();
for (int i = 0; i < 100; i++) {
Set t1 = new HashSet();
Set t2 = new HashSet();
t1.add("foo"); // make it not equal to t2
s1.add(t1);
s1.add(t2);
s2.add(t1);
s2.add(t2);
s1 = t1;
s2 = t2;
}
</pre>

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: In your code, override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like [https://github.com/ikkisoft/SerialKiller SerialKiller].
* Implementation: Use a safe replacement for the generic readObject() method as seen [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications here]. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.
* Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0] and [https://github.com/kantega/notsoserial NotSoSerial]

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]
* [https://gist.github.com/coekie/a27cc406fc9f3dc7a70d HashSet Billion-Laughs Style DoS example by Wouter Coekaerts]
* [https://github.com/ikkisoft/SerialKiller Safe ObjectInputStream implementation that allows policy-based deserialization]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0, a Java agent that protects applications from deserialization attacks]
* [https://github.com/kantega/notsoserial NotSoSerial, a Java agent that protects applications from deserialization attacks]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization Cheat Sheet

2015-11-17T21:11:10Z

Arshan:

Deserialization Cheat Sheet

2015-11-17T21:04:11Z

Arshan: Beginning a draft of an safe deserialization page

Deserialization of untrusted data

2015-11-16T21:39:20Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code, when deserialized.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [https://en.wikipedia.org/wiki/Return-oriented_programming Return-Oriented-Programming] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability ([https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2092 CVE-2011-2092]). You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends. Researchers have found [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ complex object graphs which, when deserialized, can lead to remote code execution] in most Java software.

The final example is a denial-of-service attack against any Java application that allows deserialization. The HashSet called "root" in the following code sample has members that are recursively linked to each other. When deserializing this "root" object, the JVM will begin creating a recursive object graph. It will never complete, and eventually throw an exception when memory is fully consumed.

<pre>
Set root = new HashSet();
Set s1 = root;
Set s2 = new HashSet();
for (int i = 0; i < 100; i++) {
Set t1 = new HashSet();
Set t2 = new HashSet();
t1.add("foo"); // make it not equal to t2
s1.add(t1);
s1.add(t2);
s2.add(t1);
s2.add(t2);
s1 = t1;
s2 = t2;
}
</pre>

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: In your code, override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like [https://github.com/ikkisoft/SerialKiller SerialKiller].
* Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0] and [https://github.com/kantega/notsoserial NotSoSerial]

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]
* [https://gist.github.com/coekie/a27cc406fc9f3dc7a70d HashSet Billion-Laughs Style DoS example by Wouter Coekaerts]
* [https://github.com/ikkisoft/SerialKiller Safe ObjectInputStream implementation that allows policy-based deserialization]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0, a Java agent that protects applications from deserialization attacks]
* [https://github.com/kantega/notsoserial NotSoSerial, a Java agent that protects applications from deserialization attacks]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T21:38:36Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code, when deserialized.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [https://en.wikipedia.org/wiki/Return-oriented_programming Return-Oriented-Programming] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability ([https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2092 CVE-2011-2092]). You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends. Researchers have found [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ complex object graphs which, when deserialized, can lead to remote code execution] in most Java software.

The final example is a denial-of-service attack against any Java application that allows deserialization. The HashSet called "root" in the following code sample has members that are recursively linked to each other. When deserializing this "root" object, the JVM will begin creating a recursive object graph. It will never complete, and eventually throw an exception when memory is fully consumed.

<pre>
Set root = new HashSet();
Set s1 = root;
Set s2 = new HashSet();
for (int i = 0; i < 100; i++) {
Set t1 = new HashSet();
Set t2 = new HashSet();
t1.add("foo"); // make it not equal to t2
s1.add(t1);
s1.add(t2);
s2.add(t1);
s2.add(t2);
s1 = t1;
s2 = t2;
}
</pre>

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: In your code, override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like [https://github.com/ikkisoft/SerialKiller SerialKiller].
* Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in rO0 and [https://github.com/kantega/notsoserial NotSoSerial]

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]
* [https://gist.github.com/coekie/a27cc406fc9f3dc7a70d HashSet Billion-Laughs Style DoS example by Wouter Coekaerts]
* [https://github.com/ikkisoft/SerialKiller Safe ObjectInputStream implementation that allows policy-based deserialization]
* [https://github.com/Contrast-Security-OSS/contrast-rO0, a Java agent that protects applications from deserialization attacks]
* [https://github.com/kantega/notsoserial NotSoSerial, a Java agent that protects applications from deserialization attacks]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T21:36:32Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code, when deserialized.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [https://en.wikipedia.org/wiki/Return-oriented_programming Return-Oriented-Programming] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability ([https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2092 CVE-2011-2092]). You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends. Researchers have found [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ complex object graphs which, when deserialized, can lead to remote code execution] in most Java software.

The final example is a denial-of-service attack against any Java application that allows deserialization. The HashSet called "root" in the following code sample has members that are recursively linked to each other. When deserializing this "root" object, the JVM will begin creating a recursive object graph. It will never complete, and eventually throw an exception when memory is fully consumed.

<pre>
Set root = new HashSet();
Set s1 = root;
Set s2 = new HashSet();
for (int i = 0; i < 100; i++) {
Set t1 = new HashSet();
Set t2 = new HashSet();
t1.add("foo"); // make it not equal to t2
s1.add(t1);
s1.add(t2);
s2.add(t1);
s2.add(t2);
s1 = t1;
s2 = t2;
}
</pre>

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: In your code, override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like [https://github.com/ikkisoft/SerialKiller SerialKiller].
* Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in rO0 and

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]
* [https://gist.github.com/coekie/a27cc406fc9f3dc7a70d HashSet Billion-Laughs Style DoS example by Wouter Coekaerts]
* [https://github.com/ikkisoft/SerialKiller Safe ObjectInputStream implementation that allows policy-based deserialization]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T20:47:24Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code, when deserialized.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [https://en.wikipedia.org/wiki/Return-oriented_programming Return-Oriented-Programming] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability ([https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2092 CVE-2011-2092]). You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends. Researchers have found [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ complex object graphs which, when deserialized, can lead to remote code execution] in most Java software.

The final example is a denial-of-service attack against any Java application that allows deserialization. The HashSet called "root" in the following code sample has members that are recursively linked to each other. When deserializing this "root" object, the JVM will begin creating a recursive object graph. It will never complete, and eventually throw an exception when memory is fully consumed.

<pre>
Set root = new HashSet();
Set s1 = root;
Set s2 = new HashSet();
for (int i = 0; i < 100; i++) {
Set t1 = new HashSet();
Set t2 = new HashSet();
t1.add("foo"); // make it not equal to t2
s1.add(t1);
s1.add(t2);
s2.add(t1);
s2.add(t2);
s1 = t1;
s2 = t2;
}
</pre>

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: Override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized.

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]
* [https://gist.github.com/coekie/a27cc406fc9f3dc7a70d HashSet Billion-Laughs Style DoS example by Wouter Coekaerts]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T20:46:50Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data could be used to abuse application logic, deny service, or execute arbitrary code.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [https://en.wikipedia.org/wiki/Return-oriented_programming Return-Oriented-Programming] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability ([https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2092 CVE-2011-2092]). You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends. Researchers have found [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ complex object graphs which, when deserialized, can lead to remote code execution] in most Java software.

The final example is a denial-of-service attack against any Java application that allows deserialization. The HashSet called "root" in the following code sample has members that are recursively linked to each other. When deserializing this "root" object, the JVM will begin creating a recursive object graph. It will never complete, and eventually throw an exception when memory is fully consumed.

<pre>
Set root = new HashSet();
Set s1 = root;
Set s2 = new HashSet();
for (int i = 0; i < 100; i++) {
Set t1 = new HashSet();
Set t2 = new HashSet();
t1.add("foo"); // make it not equal to t2
s1.add(t1);
s1.add(t2);
s2.add(t1);
s2.add(t2);
s1 = t1;
s2 = t2;
}
</pre>

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: Override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized.

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]
* [https://gist.github.com/coekie/a27cc406fc9f3dc7a70d HashSet Billion-Laughs Style DoS example by Wouter Coekaerts]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T20:45:22Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data could be used to abuse application logic, deny service, or execute arbitrary code.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [https://en.wikipedia.org/wiki/Return-oriented_programming Return-Oriented-Programming] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability ([https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2092 CVE-2011-2092]). You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends. Researchers have found [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ complex object graphs which, when deserialized, can lead to remote code execution] in most Java software.

The final example is a denial-of-service attack against any Java application that allows deserialization. The HashSet called "root" in the following code sample has members that are recursively linked to each other. When deserializing this "root" object, the JVM will begin creating a recursive object graph. It will never complete, and eventually throw an exception when memory is fully consumed.

<pre>
Set root = new HashSet();
Set s1 = root;
Set s2 = new HashSet();
for (int i = 0; i < 100; i++) {
Set t1 = new HashSet();
Set t2 = new HashSet();
t1.add("foo"); // make it not equal to t2
s1.add(t1);
s1.add(t2);
s2.add(t1);
s2.add(t2);
s1 = t1;
s2 = t2;
}
</pre>

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: Override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized.

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T20:10:56Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data could be used to abuse application logic, deny service, or execute arbitrary code.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [https://en.wikipedia.org/wiki/Return-oriented_programming Return-Oriented-Programming] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability. You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends.

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: Override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized.

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T20:10:00Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data could be used to abuse application logic, deny service, or execute arbitrary code.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [https://en.wikipedia.org/wiki/Return-oriented_programming|Return-Oriented-Programming] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability. You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends.

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: Override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized.

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T20:09:08Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data could be used to abuse application logic, deny service, or execute arbitrary code.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [[https://en.wikipedia.org/wiki/Return-oriented_programming|Return-Oriented-Programming]] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability. You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends.

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: Override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized.

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T20:01:53Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data could be used to abuse application logic, deny service, or execute arbitrary code.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [[https://en.wikipedia.org/wiki/Return-oriented_programming|Return-Oriented-Programming]] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability. You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends.

==Related [[Controls]]==

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.
* Implementation: Override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized.

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove vulnerability announcement]
* [http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution JFrame DoS example by Wouter Coekaerts]

[[Category:Input Validation Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

Deserialization of untrusted data

2015-11-16T19:27:29Z

Arshan:

Deserialization of untrusted data

2015-11-16T19:06:56Z

Arshan:

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Data which is untrusted cannot be trusted to be well formed. Malformed data could be used to abuse application logic, deny service, or execute arbitrary code.

'''Consequences'''

* Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
* Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
* Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

'''Exposure period'''

* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
* Implementation: Not using the protection accessor functions of an object can cause data integrity problems
* Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
* Implementation: Not making fields transient can often may cause data confidentiality problems.

'''Platform'''

* Languages: C, C++, Java, Python, Ruby
* Operating platforms: Any

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

==Risk Factors==

* Does the deserialization take place before authentication?
* Does the deserialization limit which types can be deserialized?
* Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [[https://en.wikipedia.org/wiki/Return-oriented_programming|Return-Oriented-Programming]] attacks.

==Examples==

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability. You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

<pre>
[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
public var title:String = "Gotcha!";
public var defaultCloseOperation:int = 3;
public var visible:Boolean = true;
}
</pre>

The next example is one that is much more likely to be seen in custom code. It reads an object from an untrusted source, and then casts it to an AcmeObject.

<pre>
InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();
</pre>

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring.

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Control 1]]
* [[Control 2]]
* Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
* Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
* Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
* Implementation: Explicitly define final readObject() to prevent deserialization.

An example of this is:

<pre>
private final void readObject(ObjectInputStream in)
throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}
</pre>

* Implementation: Make fields transient to protect them from deserialization.

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
[[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere|FoxGlove vulnerability announcement]]
[[http://wouter.coekaerts.be/2011/amf-arbitrary-code-execution|JFrame DoS example by Wouter Coekaerts]]
[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Snippet]]
[[Category:Java]]

2014 BASC Presentations

2014-10-16T14:18:10Z

Arshan:

{{2014_BASC:Header_Template | Presentations}}

__FORCETOC__
We would like to thank our speakers for donating their time and effort to help make this conference successful.

{{2014_BASC:Presentaton_Info_Template|AppSec: How It Fits into Digital Security|Jared DeMott| | | }}
Securing code is important. But history has shown us that
we can never be certain that our code is 100% perfect. This
becomes particularly true in rapidly evolving environments.
As an industry we need to take a broader look. What security
features are provided by the hardware, OS, language, compiler,
and even application type? Join us bright and early as Dr.
DeMott kicks off the 2014 Boston Application Security Conference
with a Keynote you won’t forget.

{{2014_BASC:Presentaton_Info_Template|Code Assisted PenTest for Mobile Applications|Dinesh Shetty| | | }}

The presentation focuses on problems of following bad Mobile development practice. During this
session, you will learn how to perform a Code Assisted PenTest on Mobile applications and uncover
some well-known and some other not so well known security issues. It is far easy to gain a practical
knowledge of security vulnerabilities than it is to read about them. Watch as Dinesh walks you through
custom created demo applications and source code review tools, to catch security flaws noted in the
various hand-held devices. Expect to see a lot of demos, tools, hacking and a lot of fun.

{{2014_BASC:Presentaton_Info_Template|Finding and Exploiting Access Control Vulnerabilities in Graphical User Interfaces|Collin Mulliner| | | }}

Graphical user interfaces (GUIs) contain a number of common visual
elements or widgets such as labels, text fields, buttons, and lists.
GUIs typically provide the ability to set attributes on these widgets to
control their visibility, enabled status, and whether they are writable.
While these attributes are extremely useful to provide visual cues to
users to guide them through an application's GUI, they can also be
misused for purposes they were not intended. In particular, in the
context of GUI-based applications that include multiple privilege levels
within the application, GUI element attributes are often misused as a
mechanism for enforcing access control policies.

In this session, we introduce GEMs, or instances of GUI element misuse,
as a novel class of access control vulnerabilities in GUI-based
applications. We present a classification of different GEMs that can
arise through misuse of widget attributes, and describe a general
algorithm for identifying and confirming the presence of GEMs in
vulnerable applications. We then present GEM Miner, an implementation of
our GEM analysis for the Windows platform. We evaluate GEM Miner using
real-world GUI-based applications that target the small business and
enterprise markets, and demonstrate the efficacy of our analysis by
finding numerous previously unknown access control vulnerabilities in
these applications.

{{2014_BASC:Presentaton_Info_Template|How a Hacker Views Your Web Site|Patrick Laverty| | | }}

As defenders, we have to be right 100% of the time where an attacker only needs to be right once. The attack surface of a modern web site is incredibly large and we need to be aware of all of it. Additionally, individual attacks may not always be effective but sometimes using them together can gain the desired effect. In this talk, we’ll take a look at the whole attack surface for a typical web site and the various ways that an attacker will use to compromise a site.

{{2014_BASC:Presentaton_Info_Template|The Intersection of Application Architecture and Security Architecture|Walt Williams| | | }}

This presentation will look at the relationship between security architecture and application architecture, specifically on the impact on application security from recent proposed changes to the Clark-Wilson integrity model. I'll explore those changes in depth, discuss the implications for application design. I'll also discuss the implications of these changes to distributed application architectures such as service oriented architectures and other distributed models.

This presentation will be based upon my recent book: Security for Service Oriented Architectures, CRC press, and 10 years of experience working with application security architecture in various corporations.

{{2014_BASC:Presentaton_Info_Template|Lean Security for Small or Medium Sized Business|Anson Gomes and Jeremy Spencer| | | }}

For a small or medium sized business (SMB) the fallout from a security or privacy incident can be at best a PR nightmare. At their worst it can cause irrecoverable damage and end your business by impacting sales or ad revenue. Your user base may take a hit. You may need to draft a blog post or email your customers describing the incident and asking them to change passwords. A key culprit is budget constraints – as a SMB you are allocating resources to innovating, creating, and improving your product. Security, while important, isn't always the primary objective.

Our talk will introduce a simple framework for SMBs to focus their security efforts. We will then discuss a common scenario applicable to most SMBs that employs our framework; and leverages it to introduce cheap and effective security mechanisms that provide prevention, limitation, detection, and response capabilities. The key take away will be the thought process and sample techniques that can enable a SMB to take their rag-tag security outfit and turn it into a business enabler.

{{2014_BASC:Presentaton_Info_Template|Mobile First AppSec: Evolving AppSec for Mobile Applications|Sagar Dongre| | | }}

Development teams are embracing Mobile First Development. They are building native iOS and Android
mobile apps, some are using PhoneGap, and others are using Appcelerator. Evolving AppSec from web
applications to include mobile is where Mobile First AppSec comes in. Mobile First AppSec describes
what application security teams must consider for successfully testing mobile applications. The heart of
Mobile First AppSec is driving the security testing based on the mobile application’s architecture.
This talk discusses the popular mobile application architectures and how the architecture drives risk. The
talk then relates the different application architectures and development frameworks to differences in
their threat model and the consequences on security tests and testing techniques.

{{2014_BASC:Presentaton_Info_Template|Open Source Vulnerability Response|EMC Product Security Response Center| | | }}

Like all software vendors, EMC faces challenges when it comes to managing the response to security vulnerabilities reported on open source embedded components. We will share our experiences by taking OpenSSL Heartbleed and the Bash Bug ‘ShellShock’ as examples and walk through the various challenges we encountered while dealing with it and the processes we built to overcome some of those problems.

{{2014_BASC:Presentaton_Info_Template|Securing The Android Apps On Your Wrist and Face|Jack Mannino and Geller Bedoya| | | }}

Android Wear and Google Glass introduce new ways of interacting with our apps and receiving timely, contextual information from the world around us. Smartphones and tablets are becoming the central point for sending and receiving data from wearables and sensors. Building apps for a wearable world introduces new risks as well as shifts the responsibilities for implementing security controls to other layers.

Many of the same issues we’re familiar with from past Android experiences are still relevant, while some issues are less impactful or not (currently) possible within existing wearables. At the same time, extending the app’s trust boundaries introduces new points of exposure for developers to be aware of in order to proactively defend against attacks. We want to highlight these areas, which developers may not be aware of when adding a wearable component to an existing app.

In this presentation, we will explore how Android Wear and Glass work underneath the hood. We will examine their methods of communication, data replication, and persistence options. We will examine how they fit into the Android development ecosystem and the new risks to privacy and security that need to be considered. Our goal isn’t to deter developers from building wearable apps, but to enable them to make strong security decisions throughout development.

{{2014_BASC:Presentaton_Info_Template|Securing Native Big Data Deployments|Steve Markey| | | }}

This session will provide thought leadership and use cases on securing Big Data technologies
through stateless tokenization. We will cover: an overview of what native Big Data consists of,
Big Data architectures, stateless tokenization use, and finally how to implement and secure Big
Data architectures through stateless tokenization deployments.

Specific focal points include:
* What Big Data is and how it is used
* An overview of Big Data architectures in the enterprise
* What stateless tokenization is and how it is used
* Secure Big Data deployments through stateless tokenization

{{2014_BASC:Presentaton_Info_Template|Using the OCTAVE Allegro Framework to Model Application Risks and Countermeasures|George Ehrhorn| | | }}

Effective Risk Assessment is an incredible tool available to the Information Security professional. A defensible risk assessment ensures that you’ll analyze the most risky aspects of your most risky applications. It lets you develop countermeasures that have the biggest impact. In a real world scenario a properly conducted risk assessment can help you work in the most efficient way. This talk is about how MathWorks uses the OCTAVE Allegro Framework to model application risks and develop countermeasures.

{{2014_BASC:Presentaton_Info_Template|Why is CSP Failing? Trends and Challenges in CSP Adoption|Michael Weissbacher| | | }}

Content Security Policy (CSP) has been proposed as a principled and
robust browser security mechanism against content injection attacks such
as XSS. When configured correctly, CSP renders malicious code injection
and data exfiltration exceedingly difficult for attackers. However,
despite the promise of these security benefits and being implemented in
almost all major browsers, CSP adoption is minuscule-our measurements
show that CSP is deployed in enforcement mode on only 1% of the Alexa
Top 100.

In this paper, we present the results of a long-term study to determine
challenges in CSP deployments that can prevent wide adoption. We
performed weekly crawls of the Alexa Top 1M to measure adoption of web
security headers, and find that CSP both significantly lags other
security headers, and that the policies in use are often ineffective at
actually preventing content injection. In addition, we evaluate the
feasibility of deploying CSP from the perspective of a
security-conscious website operator. We used an incremental deployment
approach through CSP's report-only mode on four websites, collecting
over 10M reports. Furthermore, we used semi-automated policy generation
through web application crawling on a set of popular websites. We found
both that automated methods do not suffice and that significant barriers
exist to producing accurate results.

Finally, based on our observations, we suggest several improvements to
CSP that could help to ease its adoption by the web community.

{{2014_BASC:Presentaton_Info_Template|Why Your AppSec Experts Are Killing You|Jeff Williams| | | }}

Software development has been transformed by practices like Continuous Integration and Continuous Delivery, while application security has remained trapped in expert-based waterfall mode. In this talk, Jeff will show you how you can evolve into a “Continuous Application Security” organization that generates assurance automatically across an entire application security portfolio. Jeff will show you how to bootstrap the “sensor-model-dashboard” feedback loop that makes real time, continuous application security possible. He will demonstrate the approach with a new *free* tool called Contrast for Eclipse that brings the power of instrumentation-based application security testing directly into the popular IDE. Check out [https://www.youtube.com/watch?v=4B-HgsT_J_M “Application Security at DevOps Speed and Portfolio Scale”] for some background.

{{2014_BASC:Footer_Template | Presentations}}

GSoC2012 Ideas

2012-03-01T19:47:16Z

Arshan: adding antisamy to list of projects

==Guidelines==
===Information for Students===
The ideas below were contributed by OWASP project leaders and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the corresponding project leaders and find out more about the particular suggestion you're looking at.
Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.

===Adding a Proposal===

'''Project:'''

'''Brief explanation:'''

'''Expected results:'''

'''Knowledge Prerequisite:'''

'''Mentor:'''

'''Ideas'''
How to find ideas? Obvious sources of projects are the OWASP project wiki, bugs database, and project mailing lists.

=== Generic Sample Proposal===

'''Accepted for GSoC 2011'''

'''Brief explanation:'''

KDE has developed a number of very interesting and powerful technologies, libraries and components but there is no easy way to show them to other people.

'''Expected results:'''

Something like Qt Demo but with KDE technologies.

'''Knowledge prerequisite:'''

C++ is the main language of KDE, therefore the demo should be in C++. The more you know about C++, Qt, KDE and scripting (for Kross and KDE bindings demos), the better.
This idea encompasses so much different stuff the student is not expected to know everything before he starts coding (but will certainly know a lot when he's done!).

'''Skill level:''' medium

'''Mentor:''' Pau Garcia i Quiles as general mentor and someone to ask for directions. Specific help for each technology will probably require help from its developers.

==OWASP Project Requests==

=== ZAP Proxy ===

The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.

It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.

ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

'''Website:''' https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

'''Mailing List:''' http://groups.google.com/group/zaproxy-develop

====Project 001 - Compare crawling sessions for authentication issues ====

'''Brief explanation:''' Develop a ZAP session crawler to be able to compare two crawling sessions of two logged in users and see what URLs or Actions could be performed from the other session.

'''Expected results:'''

ZAP will be able to recognise when requests are associated with different sessions.

ZAP should allow the user to view the crawled URLs for each session independantly, and show which URLs are unique to each session.

It should also be able to check if any of the 'unique' pages can in fact be accessed by the other session.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of crawlers and/or aplication security would be useful, but not essential.

'''Mentors:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

====Project 002 - Dynamically Configurable actions ====

'''Brief explanation:'''

ZAP provides various mechanisms which allow HTTP requests and responses to be changed dynamically. So (for example) a string in an HTTP request can automatically be changed to another string.

It also supports a scripting interface, which is very powerful but at the moment difficult to use.

This project would introduce something inbetween thess 2 options - a powerful way of defining (potentially) complex rules using a wizard based interface.

The challenge will be to make it as usable as possible while still providing a wide range of functionality.

'''Expected results:'''

This component would provide a set of highly configurable 'actions' which the user would see up via a wizard.

So they would initially define when the action applies, based on things like regex matching on request elements. And they should be able to define multiple criteria with ANDs and ORs.

Then they would define the actions, which could include:
* Changing the request (adding, removing or replacing strings)
* Raising alerts
* Breaking (to replace existing break points)
* Running custom scripts (which could do pretty much anything)
They would then be able to switch the actions on and off from the full list of defined actions using checkboxes

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

====Project 003 - Extend Web API to cover all of the ZAP functionality ====

'''Brief explanation:'''

ZAP provides a REST based API which can be used to control core aspects of the functionality provided by ZAP.

This project would extend that API to cover all/most of the ZAP functionality.

'''Expected results:''' Comprehensive Web API that will cover all of the ZAP Proxy functionality.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

====Project 004 - Closer integration with OWASP AJAX ====

'''Brief explanation:'''

ZAP provides a basic spider that can be used to explore an application, however it is very limited, especially when used with AJAX based applications.

The OWASP AJAX crawling tool (https://www.owasp.org/index.php/OWASP_AJAX_Crawling_Tool) is specifically designed to crawl AJAX applications and can already use ZAP as a proxy.

This project would develop a ZAP plugin which integrates ZAP with the OWASP AJAX crawling Tool.

'''Expected results:'''

A new ZAP plugin would be produced which allows ZAP to crawl AJAX applications using the OWASP AJAX crawling tool.

The plugin would allow the 2 tools to be tightly integrated, while still allowing them to work completely independently.

'''Knowledge Prerequisite:'''

Both ZAP and the AJAX tool are written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of crawlers and/or aplication security would be useful, but not essential.

'''Mentor:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP AJAX Tool Project Leader

=== ESAPI Swingset Interactive ===

The ESAPI Swingset Interactive is a web application which demonstrates common security vulnerabilities and asks users to secure the application against these vulnerabilities using the ESAPI library. 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.

'''Website:''' https://www.owasp.org/index.php/Projects/OWASP_ESAPI_Swingset_Interactive_Project

'''Mailing List:''' http://lists.owasp.org/pipermail/owasp-esapi-swingset/

====Project 001 - Implement a solid Authenticator class ====

'''Brief explanation:'''

Provide Swingset Interactive with a simple but fully functional implementation of the ESAPI Authenticator Interface.

'''Expected results:'''

Swingset Interactive comes with a rudimentary implementation of the ESAPI Authenticator Interface, a FileBasedAuthenticator. This implementation needs to be fixed or replaced in order to allow users of the Swingset Interactive application all of the ESAPI Authenticator methods, including registration, login, a "remember me" feature and a persistence beyond server restart.

'''Knowledge Prerequisite:'''

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 002 - Upgrade to ESAPI 2.0.x ====

'''Brief explanation:'''

Adapt Swingset Interactive to work with ESAPI 2.0.x. libraries.

'''Expected results:'''

Make the current Swingset Interactive application compatible with ESAPI 2.0.x. Swingset Interactive currently comes with ESAPI 1.4.Various changes and improvements were made with ESAPI 2.0.x and it is generally recommended not to use 1.4 any more for Java EE Projects.

'''Knowledge Prerequisite:'''

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 003 - Improve the Swingset look and feel ====

'''Brief explanation:'''

Various minor bug fixes and improvements.

'''Expected results:'''

Fix and solve a number of documented bug fixes and improvement suggestions for the Swingset Interactive and bring in your own improvement suggestions.

'''Knowledge Prerequisite:'''

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 004 - Platform-independent Swingset Interactive ====

'''Brief explanation:'''

Adapt Swingset Interactive to work with any OS.

'''Expected results:'''

Swingset Interactive currently runs only under Windows. Modify the Eclipse project and installation scripts to be easily installed on any OS that runs Eclipse.

'''Knowledge Prerequisite:'''

Good knowledge of Java, Apache Tomcat and a broad knowledge of various Operating Systems are required.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 005 - Mavenize the Swingset ====

'''Brief explanation:'''

Create a new Swingset Interactive Maven Archetype.

'''Expected results:'''

Offer the Swingset Interactive as a Maven Archetype.

'''Knowledge Prerequisite:'''

Good knowledge of Java, and Maven are required.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

=== AntiSamy ===

The AntiSamy project provides a Java library for developers to accept innocent HTML markup without exposing themselves to possible cross-site scripting (XSS) vulnerabilities.

'''Website:''' https://www.owasp.org/index.php/AntiSamy

'''Mailing List:''' https://lists.owasp.org/mailman/listinfo/owasp-antisamy

====Project 001 - Add a Functional Testing Suite ====

'''Brief explanation:'''

Create a set of positive test cases designed to generate assurance that AntiSamy correctly processes inert HTML.

'''Expected results:'''

As of today, AntiSamy has a large set of test cases that prove that AntiSamy is resistant to a number of known attacks. There are also test cases that make sure it doesn't crash when given bad data. There are very few test cases that ensure that it properly handles good HTML. A set of test cases that confirm how expected good data is processed by AntiSamy generates a lot of assurance that it is functional as well as secure.

'''Knowledge Prerequisite:'''

Comfort with Java, Maven, SVN and JUnit are required.

'''Mentor:''' Arshan Dabirsiaghi - OWASP AntiSamy Project Leader

====Project 002 - Various Bug Fixes ====

'''Brief explanation:'''

There are around 30 open defects from the issue tracker.

'''Expected results:'''

A set of patches that address defects or implement features from the accepted issues in the issue tracker.

'''Knowledge Prerequisite:'''

Comfort with Java, Maven, SVN and JUnit are required.

'''Mentor:''' Arshan Dabirsiaghi - OWASP AntiSamy Project Leader

Category:OWASP AntiSamy Project

2011-03-10T07:00:05Z

Arshan: /* Who are you? */

== What is it? ==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take care of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

== Who are you? ==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (li.jason.c [at the] gmail.com), both of Aspect Security (http://www.aspectsecurity.com/).

== What's the difference between AntiSamy Java, .NET, etc.? ==

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== How do I get started? ==

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-slashdot.xml
#* antisamy-ebay.xml
#* antisamy-myspace.xml
#* antisamy-anythinggoes.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see the .NET page.

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's an example POM for including AntiSamy. If you want a jar file, then '''download the antisamy-bin-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option versions before 1.2 is '''downloading antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues.

For convenience, the download page also contains the necessary libraries for running AntiSamy in '''antisamy-required-libs.zip'''.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) is arguably the most popular social networking site today. Users are allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace is currently using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace is _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 5 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

== Project roadmap ==

This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

== Presentations on AntiSamy ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - by Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - by Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - by Jason Li - AntiSamy project contributor

From Shmoocon 2009 (Washington, DC): [http://www.shmoocon.org/2009/slides/OWASP%20Winter%202009%20Shmoocon%20-%20Anti%20Samy.pptx AntiSamy - Picking a Fight with XSS (pptx)] - by Arshan Dabirsiaghi - AntiSamy project lead

== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com].

=== Issue tracking ===

Visit the [http://code.google.com/p/owaspantisamy/issues/list Google Code issue tracker].

== Sponsors ==

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]]

== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

CSRFGuard 3 Installation

2011-01-04T18:56:38Z

Arshan: adding a filter-mapping

= Overview =

The purpose of this article is to provide guidance around the installation of OWASP CSRFGuard within a JavaEE web application. Installation of OWASP CSRFGuard 3 is very straight forward requiring three simple steps. First, you must copy the Owasp.CsrfGuard.jar file to your application's classpath. After copying over the OWASP CSRFGuard library, declare and map the CsrfGuardFilter in your application's web.xml deployment descriptor. This instructs the application server to initialize the OWASP CSRFGuard Filter protecting those resources that match the Filter mapping. Finally, customize the Owasp.CsrfGuard.properties file as you see fit. You'll need to make sure you tell CsrfGuardFilter the location of your CSRFGuard properties file via a JavaEE Filter init-param directive. Please refer to the following sub-sections for more detailed information on each of the aforementioned installation steps.

= Copy Owasp.CsrfGuard.jar to Classpath =

The first thing you need to do is copy the Owasp.CsrfGuard.jar library into your classpath. The most common classpath location to place Owasp.CsrfGuard.jar is within the lib directory of the web application's WEB-INF folder. OWASP CSRFGuard 3 has no additional dependencies outside of the traditional JavaEE runtime environment.

= Declare and Map CsrfGuardFilter in web.xml =

After placing Owasp.CsrfGuard.jar in your application's classpath, you'll need to declare and map the CsrfGuardFilter in web.xml. All CSRF token verification logic is encompassed within CsrfGuard integrated via the stand-alone filter CsrfGuardFilter. The following web.xml snippet was extracted from the [http://code.google.com/p/owaspcsrfguard/source/browse/#svn/trunk/main/Owasp.CsrfGuard.Test Owasp.CsrfGuard.Test] web application:

<filter>
<filter-name>CSRFGuard</filter-name>
<filter-class>org.owasp.csrfguard.CsrfGuardFilter</filter-class>
<init-param>
<param-name>config</param-name>
<param-value>WEB-INF/Owasp.CsrfGuard.properties</param-value>
</init-param>
<init-param>
<param-name>print-config</param-name>
<param-value>true</param-value>
</init-param>
</filter>

We create a filter with the name of CSRFGuard and specify a classname of org.owasp.csrfguard.CsrfGuardFilter. The filter accepts two initialization parameters: config and print-config. The config parameter is required and specifies the location of the CSRFGuard properties file. CSRFGuard will search for the properties file specified by searching the following locations in order of appearance: the application's classpath, a directory accessible by the container, or an arbitrary absolute path. The print-config parameter is optional and simply instructs CSRFGuard to display the parsed properties to the application server log file.

Afterwards, you have to map the CSRGuard filter to all incoming URLs:

<filter-mapping>
<filter-name>CSRFGuard</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Now that all the incoming URLs are mapped to go through CSRFGuard, its behavior must be defined.

= Configure Owasp.CsrfGuard.properties =

The Owasp.CsrfGuard.properties file controls how OWASP CSRFGuard behaves at runtime. CSRFGuard looks for the file in the following locations in order: application's classpath, servlet context directory, and current directory. You are encouraged to make use of the sample Owasp.CsrfGuard.properties file bundled with CSRFGuard to help kick-start your deployment efforts. There are various properties supported by CSRFGuard. At a minimum, you'll want to configure the new token landing page and the action properties. [[CSRFGuard_3_Configuration | Click here]] for more information regarding the configuration of OWASP CSRFGuard.

[[Category:OWASP CSRFGuard Project]]

Category:OWASP AntiSamy Project

2010-12-06T19:54:24Z

Arshan: /* What is it? */

== What is it? ==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take care of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

== Who are you? ==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (li.jason.c [at the] gmail.com), both of Aspect Security (http://www.aspectsecurity.com/). The problem AntiSamy solves was often described as "impossible" or "impossible to do right". The folks with the AntiSamy project hope to antiquate that idea in a hurry. As of now, there are Java and .NET implementations of AntiSamy, though the framework is implementable in any language. The Java version is callable from ColdFusion.

PHP developers should use [http://htmlpurifier.org/ HTMLPurifier], another free utility similar to AntiSamy.

== What's the difference between AntiSamy Java, .NET, etc.? ==

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== How do I get started? ==

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-slashdot.xml
#* antisamy-ebay.xml
#* antisamy-myspace.xml
#* antisamy-anythinggoes.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see the .NET page.

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's an example POM for including AntiSamy. If you want a jar file, then '''download the antisamy-bin-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option versions before 1.2 is '''downloading antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues.

For convenience, the download page also contains the necessary libraries for running AntiSamy in '''antisamy-required-libs.zip'''.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) is arguably the most popular social networking site today. Users are allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace is currently using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace is _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 5 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

== Project roadmap ==

This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

== Presentations on AntiSamy ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - by Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - by Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - by Jason Li - AntiSamy project contributor

From Shmoocon 2009 (Washington, DC): [http://www.shmoocon.org/2009/slides/OWASP%20Winter%202009%20Shmoocon%20-%20Anti%20Samy.pptx AntiSamy - Picking a Fight with XSS (pptx)] - by Arshan Dabirsiaghi - AntiSamy project lead

== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com].

=== Issue tracking ===

Visit the [http://code.google.com/p/owaspantisamy/issues/list Google Code issue tracker].

== Sponsors ==

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]]

== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

JavaSnoop: How to hack anything written in Java

2010-10-07T19:10:27Z

Arshan: /* The presentation */

[[Image:468x60-banner-2010.gif|link=http://www.owasp.org/index.php?title=OWASP_AppSec_DC_2010]]

[https://guest.cvent.com/EVENTS/Register/IdentityConfirmation.aspx?e=d52c6f5f-d568-4e16-b8e0-b5e2bf87ab3a Registration] | [https://resweb.passkey.com/Resweb.do?mode=welcome_gi_new&groupID=2766908 Hotel] | [http://www.dcconvention.com/ Walter E. Washington Convention Center]
<br>
== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]Anybody who has assessed anything with a thick Java client has probably been frustrated beyond belief and unhappy with their coverage, but that's only because this tool hasn't been released yet. We created a tool that allows you to easily jump into any JVM on your machine, and tamper with class bytecode, method parameters, return values - without requiring any pesky original source code, or the most elusive artifact - skill!

What happens when that applet you want to hack uses serialized objects over a custom encryption scheme, and you have 40 hours to break it? Theoretically, you know that's not good enough, but who cares about "theoretically"? JavaSnoop will allow you to intercept calls inside the JVM for tampering with data before it gets to the network, while its still in object form! What happens when that fancy desktop tool you have has an expired license? JavaSnoop will allow you to make that isLicensed() check return the value you want, instead of the value you didn't pay for.

All this in a nice, portable GUI tool. I can't wait to enable you!

== The speaker ==

Speaker bio will be posted shortly.

[[Category:AppSec_DC_2010_Presentations]] [[Category:OWASP_Conference_Presentations]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2010-09-22T20:12:35Z

Arshan: adding data to rule 5 and a link to how to overcome the url-encoding-but-not-breaking problem

= Introduction =

This article provides a simple positive model for preventing [[XSS]] using output escaping/encoding properly. While there are a huge number of XSS attack vectors, following a few simple rules can completely defend against this serious attack. This article does not explore the technical or business impact of XSS. Suffice it to say that it can lead to an attacker gaining the ability to do anything a victim can do through their browser.

These rules apply to all the different varieties of XSS. Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate escaping on the server-side. The use of an escaping/encoding library like the one in [[ESAPI]] is strongly recommended as there are many special cases. [[DOM Based XSS]] can be addressed by applying these rules on the client on untrusted data.

For a great cheatsheet on the attack vectors related to XSS, please refer to the excellent [http://ha.ckers.org/xss.html XSS Cheat Sheet] by RSnake. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

== Untrusted Data ==

Untrusted data is most often data that comes from the HTTP request, in the form of URL parameters, form fields, headers, or cookies. But data that comes from databases, web services, and other sources is frequently untrusted from a security perspective. That is, it might not have been perfectly validated. The [[Searching for Code in J2EE/Java|OWASP Code Review Guide]] has a decent list of methods that return untrusted data in various languages, but you should be careful about your own methods as well.

Untrusted data should always be treated as though it contains an attack. That means you should not send it '''anywhere''' without taking steps to make sure that any attacks are detected and neutralized. As applications get more and more interconnected, the likelihood of a buried attack being decoded or executed by a downstream interpreter increases rapidly.

Traditionally, [[Data Validation|input validation]] has been the preferred approach for handling untrusted data. However, input validation is not a great solution for injection attacks. First, input validation is typically done when the data is received, before the destination is known. That means that we don't know which characters might be significant in the target interpreter. Second, and possibly even more importantly, applications must allow potentially harmful characters in. For example, should poor Mr. O'Malley be prevented from registering in the database simply because SQL considers ' a special character?

While input validation is important and should always be performed, it is not a complete solution for injection attacks. It's better to think of input validation as [[Defense in depth|defense in depth]] and use '''escaping''' as described below as the primary defense.

== Escaping (aka Output Encoding) ==

"[http://www.w3.org/TR/charmod/#sec-Escaping Escaping]" is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter's parser. There are lots of different types of escaping, sometimes confusingly called output "encoding." Some of these techniques define a special "escape" character, and other techniques have a more sophisticated syntax that involves several characters.

Do not confuse output escaping with the notion of Unicode character [http://www.w3.org/TR/charmod/#sec-Digital encoding], which involves mapping a Unicode character to a sequence of bits. This level of encoding is automatically decoded, and does '''not''' defuse attacks. However, if there are misunderstandings about the intended charset between the server and browser, it may cause unintended characters to be communicated, possibly enabling XSS attacks. This is why it is still important to [http://www.w3.org/TR/charmod/#sec-Encodings specify] the Unicode character encoding (charset), such as UTF-8, for all communications.

Escaping is the primary means to make sure that untrusted data can't be used to convey an injection attack. There is '''no harm''' in escaping data properly - it will still render in the browser properly. Escaping simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.

== Injection Theory ==

[[Injection Flaws|Injection]] is an attack that involves breaking out of a data context and switching into a code context through the use of special characters that are significant in the interpreter being used. A data context is like <div>data context</div>. If the attacker's data gets placed into the data context, they might break out like this <div>data < script>alert("attack")</script> context</div>.

XSS is a form of injection where the interpreter is the browser and attacks are buried in an HTML document. HTML is easily the worst mashup of code and data of all time, as there are so many possible places to put code and so many different valid encodings. HTML is particularly difficult because it is not only hierarchical, but also contains many different parsers (XML, HTML, JavaScript, VBScript, CSS, URL, etc...).

To really understand what's going on with XSS, you have to consider injection into the hierarchical structure of the [http://www.w3schools.com/HTMLDOM/default.asp HTML DOM]. Given a place to insert data into an HTML document (that is, a place where a developer has allowed untrusted data to be included in the DOM), there are two ways to inject code:

;Injecting UP:The most common way is to close the current context and start a new code context. For example, this is what you do when you close an HTML attribute with a "> and start a new <script> tag. This attack closes the original context (going up in the hierarchy) and then starts a new tag that will allow script code to execute. Remember that you may be able to skip many layers up in the hierarchy when trying to break out of your current context. For example, a </script> tag may be able to terminate a script block even if it is injected inside a quoted string inside a method call inside the script. This happens because the HTML parser runs before the JavaScript parser.

;Injecting DOWN:The less common way to perform XSS injection is to introduce a code subcontext without closing the current context. For example, if the attacker is able to change <img src="...UNTRUSTED DATA HERE..." /> into < img src="javascript:alert(document.cookie)" /> they do not have to break out of the HTML attribute context. Instead, they introduce a subcontext that allows scripting within the src attribute (in this case a javascript url). Another example is the expression() functionality in CSS properties. Even though you may not be able to escape a quoted CSS property to inject up, you may be able to introduce something like xss:expression(document.write(document.cookie)) without ever leaving the current context.

There's also the possibility of injecting directly in the current context. For example, if you take untrusted input and put it directly into a JavaScript context. While insane, accepting code from an attacker is more common than you might think in modern applications. Generally it is impossible to secure untrusted code with escaping (or anything else). If you do this, your application is just a conduit for attacker code to get running in your users' browsers.

The rules in this document have been designed to prevent both UP and DOWN varieties of XSS injection. To prevent injecting up, you must escape the characters that would allow you to close the current context and start a new one. To prevent attacks that jump up several levels in the DOM hierarchy, you must also escape all the characters that are significant in all enclosing contexts. To prevent injecting down, you must escape any characters that can be used to introduce a new sub-context within the current context.

== A Positive XSS Prevention Model ==

This article treats an HTML page like a template, with slots where a developer is allowed to put untrusted data. These slots cover the vast majority of the common places where a developer might want to put untrusted data. Putting untrusted data in other places in the HTML is not allowed. This is a "whitelist" model, that denies everything that is not specifically allowed.

Given the way browsers parse HTML, each of the different types of slots has slightly different security rules. When you put untrusted data into these slots, you need to take certain steps to make sure that the data does not break out of that slot into a context that allows code execution. In a way, this approach treats an HTML document like a parameterized database query - the data is kept in specific places and is isolated from code contexts with escaping.

This document sets out the most common types of slots and the rules for putting untrusted data into them safely. Based on the various specifications, known XSS vectors, and a great deal of manual testing with all the popular browsers, we have determined that the rule proposed here are safe.

The slots are defined and a few examples of each are provided. Developers SHOULD NOT put data into any other slots without a very careful analysis to ensure that what they are doing is safe. Browser parsing is extremely tricky and many innocuous looking characters can be significant in the right context.

== Why Can't I Just HTML Entity Encode Untrusted Data? ==

HTML entity encoding is okay for untrusted data that you put in the body of the HTML document, such as inside a <div> tag. It even sort of works for untrusted data that goes into attributes, particularly if you're religious about using quotes around your attributes. But HTML entity encoding doesn't work if you're putting untrusted data inside a <script> tag anywhere, or an event handler attribute like onmouseover, or inside CSS, or in a URL. So even if you use an HTML entity encoding method everywhere, you are still most likely vulnerable to XSS. '''You MUST use the escape syntax for the part of the HTML document you're putting untrusted data into.''' That's what the rules below are all about.

== You Need a Security Encoding Library ==

Writing these encoders is not tremendously difficult, but there are quite a few hidden pitfalls. For example, you might be tempted to use some of the escaping shortcuts like \" in JavaScript. However, these values are dangerous and may be misinterpreted by the nested parsers in the browser. You might also forget to escape the escape character, which attackers can use to neutralize your attempts to be safe. OWASP recommends using a security-focused encoding library to make sure these rules are properly implemented.

The OWASP [[ESAPI]] project has created an escaping library in a variety of languages including Java, .NET, PHP, Classic ASP, Cold Fusion, Python, and Haskell. The ESAPI library can be used for escaping as described here and also for decoding (aka canonicalization), which is critical for input validation. Microsoft provides an encoding library named [http://www.codeplex.com/AntiXSS AntiXSS].

= XSS Prevention Rules =

The following rules are intended to prevent all XSS in your application. While these rules do not allow absolute freedom in putting untrusted data into an HTML document, they should cover the vast majority of common use cases. You do not have to allow '''all''' the rules in your organization. Many organizations may find that '''allowing only Rule #1 and Rule #2 are sufficient for their needs'''. Please add a note to the discussion page if there is an additional context that is often required and can be secured with escaping.

Do NOT simply escape the list of example characters provided in the various rules. It is NOT sufficient to escape only that list. Blacklist approaches are quite fragile. The whitelist rules here have been carefully designed to provide protection even against future vulnerabilities introduced by browser changes.

== RULE #0 - Never Insert Untrusted Data Except in Allowed Locations ==

The first rule is to '''deny all''' - don't put untrusted data into your HTML document unless it is within one of the slots defined in Rule #1 through Rule #5. The reason for Rule #0 is that there are so many strange contexts within HTML that the list of escaping rules gets very complicated. We can't think of any good reason to put untrusted data in these contexts.

<script>'''...NEVER PUT UNTRUSTED DATA HERE...'''</script> directly in a script

 inside an HTML comment

<div '''...NEVER PUT UNTRUSTED DATA HERE...'''=test /> in an attribute name

<'''...NEVER PUT UNTRUSTED DATA HERE...''' href="/test" /> in a tag name

Most importantly, never accept actual JavaScript code from an untrusted source and then run it. For example, a parameter named "callback" that contains a JavaScript code snippet. No amount of escaping can fix that.

== RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content ==

Rule #1 is for when you want to put untrusted data directly into the HTML body somewhere. This includes inside normal tags like div, p, b, td, etc. Most web frameworks have a method for HTML escaping for the characters detailed below. However, this is '''absolutely not sufficient for other HTML contexts.''' You need to implement the other rules detailed here as well.

<body>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''</body>

<div>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''</div>

any other normal HTML elements

Escape the following characters with HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. Using hex entities is recommended in the spec. In addition to the 5 characters significant in XML (&, <, >, ", '), the forward slash is included as it helps to end an HTML entity.

& --> &amp;
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27; ' is not recommended
/ --> &#x2F; forward slash is included as it helps end an HTML entity

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/HTMLEntityCodec.java ESAPI reference implementation] of HTML entity escaping and unescaping.

String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );

== RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes ==

Rule #2 is for putting untrusted data into typical attribute values like width, name, value, etc. This should not be used for complex attributes like href, src, style, or any of the event handlers like onmouseover. It is extremely important that event handler attributes should follow Rule #3 for HTML JavaScript Data Values.

<div attr='''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''>content</div> inside UNquoted attribute

<div attr=''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''>content</div> inside single quoted attribute

<div attr="'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''">content</div> inside double quoted attribute

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of the attribute. The reason this rule is so broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |.

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/HTMLEntityCodec.java ESAPI reference implementation] of HTML entity escaping and unescaping.

String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) );

== RULE #3 - JavaScript Escape Before Inserting Untrusted Data into HTML JavaScript Data Values ==

Rule #3 concerns the JavaScript event handlers that are specified on various HTML elements. The only safe place to put untrusted data into these event handlers as a quoted "data value." Including untrusted data inside any other code block is quite dangerous, as it is very easy to switch into an execution context, so use with caution.

<script>alert(''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''')</script> inside a quoted string

<script>x=''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''</script> one side of a quoted expression

<div onmouseover="x=''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''"</div> inside quoted event handler

Please note there are some JavaScript functions that can never safely untrusted data as input - <b>EVEN IF JAVASCRIPT ESCAPED</b>!

For example:
<script>
window.setInterval(''''...EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED HERE...'''');
</script>

Except for alphanumeric characters, escape all characters less than 256 with the \xHH format to prevent switching out of the data value into the script context or into another attribute. Do not use any escaping shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs first. If an event handler is quoted, breaking out requires the corresponding quote. The reason this rule is so broad is that developers frequently leave event handler attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and |. Also, a </script> closing tag will close a script block even though it is inside a quoted string because the HTML parser runs before the JavaScript parser.

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/JavaScriptCodec.java ESAPI reference implementation] of JavaScript escaping and unescaping.

String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );

== RULE #4 - CSS Escape Before Inserting Untrusted Data into HTML Style Property Values ==

Rule #4 is for when you want to put untrusted data into a stylesheet or a style tag. CSS is surprisingly powerful, and can be used for numerous attacks. Therefore, it's important that you only use untrusted data in a property '''value''' and not into other places in style data. You should stay away from putting untrusted data into complex properties like url, behavior, and custom (-moz-binding). You should also not put untrusted data into IE’s expression property value which allows JavaScript.

<style>selector { property : '''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''; } </style> property value<br/>
<style>selector { property : "'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''"; } </style> property value<br/>
<span style=property : '''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''';>text</style> property value<br/>
<span style=property : "'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''";>text</style> property value

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the \HH escaping format. Do not use any escaping shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs first. Prevent switching out of the property value and into another property or attribute. Also prevent switching into an expression or other property value that allows scripting. If attribute is quoted, breaking out requires the corresponding quote. All attributes should be quoted but your encoding should be strong enough to prevent XSS when untrusted data is placed in unquoted contexts. Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and |. Also, the </style> tag is also likely to close the style block even though it is inside a quoted string because the HTML parser runs before the JavaScript parser. Please note that we recommend aggressive CSS encoding to prevent XSS attacks for both quoted and unquoted attributes.

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/CSSCodec.java ESAPI reference implementation] of CSS escaping and unescaping.

String safe = ESAPI.encoder().encodeForCSS( request.getParameter( "input" ) );

== RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values ==

Rule #5 is for when you want to put untrusted data into HTTP GET parameter value.

<a href="http://www.somesite.com?test='''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE..."'''>link</a >

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the %HH escaping format. Including untrusted data in data: URLs should not be allowed as there is no good way to disable attacks with escaping to prevent switching out of the URL. All attributes should be quoted. Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and |. Note that entity encoding is useless in this context.

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/PercentCodec.java ESAPI reference implementation] of URL escaping and unescaping.

String safe = ESAPI.encoder().encodeForURL( request.getParameter( "input" ) );

WARNING: Do not encode complete or relative URL's with URL encoding! URL's should be encoded based on the context of display like any other piece of data. For example, user driven URL's in HREF links should be attribute encoded. Also, encoding complete URLs may cause them to be requested in an encoded form, which could have undesirable consequences.

If untrusted input is meant to be placed into href, src or other URL-based attributes, it should be validated to make sure it does not point to an unexpected protocol. The OWASP AntiSamy project uses a [http://code.google.com/p/owaspantisamy/source/browse/trunk/Java/current/antisamy-project/antisamy-sample-configs/src/main/resources/antisamy.xml#56 regular expression] to validate a fully-qualified URL does not execute any code and is safe to display to the user.

== RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way ==

import org.owasp.validator.html.*;
Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function

== RULE #7 - Prevent DOM-based XSS ==

For details on what DOM-based XSS is, and defenses against this type of XSS flaw, please see the OWASP article on [[DOM_Based_XSS | DOM-based XSS]].

= Encoding Information =
[
http://code.google.com/p/owasp-development-guide/wiki/WebAppSecDesignGuide_D6]

= Additional XSS Defense (HTTPOnly cookie flag)=

Preventing all XSS flaws in an application is hard, as you can see. To help mitigate the impact of an XSS flaw on your site, OWASP also recommends you set the HTTPOnly flag on your session cookie and any custom cookies you have that are not accessed by any Javascript you wrote. This cookie flag is typically on by default in .NET apps, but in other languages you have to set it manually.

For more details on the HTTPOnly cookie flag, including what it does, and how to use it, see the OWASP article on [[HTTPOnly]].

=Related Articles=

'''XSS Attack Cheat Sheet'''

The following article describes how to exploit different kinds of XSS Vulnerabilities that this article was created to help you avoid:

* RSnake: "XSS Cheat Sheet" - http://ha.ckers.org/xss.html

'''Description of XSS Vulnerabilities'''

* OWASP article on [[XSS]] Vulnerabilities

'''How to Review Code for Cross-site scripting Vulnerabilities'''

* [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on [[Reviewing Code for Cross-site scripting]] Vulnerabilities

'''How to Test for Cross-site scripting Vulnerabilities'''

* [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on [[Testing for Cross site scripting]] Vulnerabilities

{{Cheatsheet_Navigation}}

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

AppSec US 2010, CA

2010-07-19T21:21:39Z

Arshan: but most of all SAMMY is not my hero

__NOTOC__

[[Image:Appsec banner.png|661x83px|AppSec USA 2010 Banner]]

==== Welcome ====

{| border="0" align="center" style="" width="100%"
|-
| align="center" style="width: 25%; background: none repeat scroll 0% 0% rgb(240,230,140);" | [http://www.appsecusa.org/travel-and-venue.html Travel and Venue]
| align="center" style="width: 25%; background: none repeat scroll 0% 0% rgb(240,230,140);" | [http://www.appsecusa.org/become-a-sponsor.html Sponsor Information]
| align="center" style="width: 25%; background: none repeat scroll 0% 0% rgb(240,230,140);" | [http://www.appsecusa.org/volunteer-opportunities.html Volunteer Opportunities]
| align="center" style="width: 25%; background: none repeat scroll 0% 0% rgb(255,215,0);" | [http://www.appsecusa.org/register-now.html REGISTER NOW]
|-
| align="left" style="background: none repeat scroll 0% 0% rgb(238, 235, 226); color: black;" colspan="4" |
<br>
For complete information, please visit [http://www.appsecusa.org AppSec US 2010 Website]
<br>
|-
|}

{| style="width: 100%;"
|-
| style="width: 100%; color: rgb(0, 0, 0);" |
{| style="background: none repeat scroll 0% 0% transparent; width: 100%; -moz-background-inline-policy: continuous;"
|-
| style="width: 95%; color: rgb(0, 0, 0);" |
'''Latest Updates:'''

'''Training and conference agenda available'''

'''Register now!''' Early-bird rates extended till July 31.

'''<br>'''

|}



| style="border: 0px solid rgb(204, 204, 204); width: 100%; font-size: 95%; color: rgb(0, 0, 0);" | 
| style="width: 110px; font-size: 95%; color: rgb(0, 0, 0);" |
|}



==== Training September 7th & 8th ====

{| border="0" align="center" style="width: 80%;"
|-
! align="center" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" | T1. Web Security Testing - 2-Days - $1350
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | This course is a deep dive into the world of web application security testing. It is designed to walk testers through every step of web application penetration testing, arming them with the knowledge and tools they will need to begin conducting their own security testing. The course will teach the participants how to think like a security engineer by creating and executing a security test plan. Participants will be exposed to common web application vulnerabilities, testing techniques and tools by a professional security tester.
The course includes a guided penetration test in which the students will execute security test with the help of the instructor.

|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Instructor: Joe Basirico, Security Innovation
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | [[Learn More About the Web Security Testing Class]]
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | [http://www.appsecusa.org/register-now.html Click here to register]
|}

{| border="0" align="center" style="width: 80%;"
|-
! align="center" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" | T2. Building Secure Ajax and Web 2.0 Applications - 2-Days - $1350
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | This two-day class will cover common Web 2.0 and AJAX security threats, vulnerabilities, and it will provide specific guidance on how to develop Web 2.0 applications to defend against these threats and vulnerabilities.
Training developers on secure coding practices offers one of highest returns on investment of any security investment by eliminating vulnerabilities at the source. Aspect’s Building Secure Ajax and Web 2.0 Applications Course enables developers to securely utilize Web 2.0 technologies in their web applications without introducing security issues. The course provides detailed examples of ‘what to do’ and ‘what not to do.' The class is lead by an experienced developer and delivered in a very interactive manner. The course will use demonstrations, code examples, and spot-the-bug exercises to get developers engaged in the topic. Developers will leave with an understanding of how Ajax attacks work, the impacts of successful attacks, and what to do to defend against them.

|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Instructor: Dave Wichers: [[Image:100px-Aspect Security Logo.jpg]]
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | [[Learn More about the Building Secure Ajax and Web 2.0 Applications Class]]
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | [http://www.appsecusa.org/register-now.html Click here to register]

|-
! align="center" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" | T3. Assessing and Exploiting Web Applications with Samurai - WTF - 2-Days - $1350
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Summary
Instructor: Justin Serle, InGuardians
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | [http://www.appsecusa.org/register-now.html Click here to register]

|-
! align="center" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" | T4. Application Security Leadership Essentials - 2-Days - $1350
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | In this two-day management session you’ll get an industry perspective of application security, understand the key vulnerabilities to applications, be able to analyze root cause, and provide practical and proven techniques in building out an application security initiative. This course gives executives and managers the education and practical guidance they need to ensure that software projects properly address security. The course is designed to provide a firm understanding of the importance of software security, the critical security activities required within the software development lifecycle, and how to efficiently manage security issues during development and maintenance. This understanding is reinforced through industry awareness, live demonstrations of commonly found application vulnerabilities and workgroup exercises allowing attendees to conduct capability assessments and recommend improvement plans.
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Instructor: Jeff Williams: [[Image:100px-Aspect Security Logo.jpg]]
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | [[Learn More about the Application Security Leadership Essentials Class]]
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | [http://www.appsecusa.org/register-now.html Click here to register]

|-
! align="center" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" | T5. Software Security Remediation: How to Fix Application Vulnerabilities 1-Day - Sept 7th- $675
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Summary
Instructor: Dan Cornell: [[Image:AppSecDC2009-Sponsor-denim.gif]]
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | [http://www.appsecusa.org/register-now.html Click here to register]

|}

{| border="0" align="center" style="width: 80%;"
|-
! align="center" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" | T6. Live CD 1-Day - Sept 8th- $675
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Summary
Instructor: Matt Tesauro: [[Image:TrustwaveLogo.jpg]]
|-
| style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" | [http://www.appsecusa.org/register-now.html Click here to register]

|}

<br>

==== September 9th ====

{| border="0" align="center" style="width: 80%;"
|-
| align="center" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" colspan="4" | '''Conference Day 1 - September 9th, 2010'''
<br>

|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | <br>
| style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Track 1 - Crystal Cove Auditorium
| style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Track 2 - Pacific Ballroom
| style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Track 3 - Doheny Beach
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 07:30-08:30
| align="left" style="width: 80%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Registration and Breakfast + Coffee
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 08:30-08:45
| align="center" style="width: 80%; background: none repeat scroll 0% 0% rgb(242, 242, 242);" colspan="3" | Welcome to OWASP AppSec US, 2010 (Crystal Cove Auditorium)
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 08:45-9:30
| align="center" style="width: 80%; background: none repeat scroll 0% 0% rgb(252, 252, 150);" colspan="3" | Keynote: Jeff Williams (Crystal Cove Auditorium)
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 9:30-10:15
| align="center" style="width: 80%; background: none repeat scroll 0% 0% rgb(252, 252, 150);" colspan="3" | Keynote: Chenxi Wang (Crystal Cove Auditorium)
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:15-10:35
| align="left" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Break - Expo - CTF kick-off (Emerald Bay)
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:35-11:20
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | How I met your Girlfriend, ''Samy Kamkar''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Solving Real-World Problems with an Enterprise Security API (ESAPI), ''Chris Schmidt, ServiceMagic''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Microsoft Security Development Lifecycle for Agile Development, ''Nick Coblentz, AT&T''
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:20-11:30
| align="left" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Break - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:30-12:15
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | State of SL on the Internet - 2010 Survey, Results and Conclusions, ''Ivan Ristic, Qualys''<br>
<br>

| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Into the Rabbit Hole: Execution Flow-based Web Application Testing, ''Rafal Los, Hewlett-Packard''<br>
<br>

| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Threat Modeling Best Practices, Robert Zigweid, IOActive<br>
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 12:15-13:15
| align="left" style="width: 80%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Lunch - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 13:30-14:15
| align="center" style="width: 80%; background: none repeat scroll 0% 0% rgb(252, 252, 150);" colspan="3" | Keynote: Bill Cheswick (Crystal Cove Auditorium)
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 14:15-14:25
| align="left" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Break - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 14:25-15:10
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | P0w3d for Botnet CnC, ''Gunter Ollmann, Damballa''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Cloud Computing, A Weapon of Mass Destruction?, ''David Bryan''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | The Secure Coding Practices Quick Reference Guide, ''Keith Turpin, Boeing''
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:10-15:30
| align="left" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Coffee Break - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:30-16:15
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Smart Phones with Dumb Apps: Threat Modeling for Mobile Applications, ''Dan Cornell, Denim Group''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Assessing, Testing and Validating Flash Content, ''Peleus Uhley, Adobe''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | OWASP State of the Union, ''Tom Brennan, OWASP''
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 16:15-16:25
| align="left" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Break - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 16:25-17:10
| align="center" style="width: 90%; background: none repeat scroll 0% 0% rgb(242, 242, 242);" colspan="3" | Panel Discussion: Security Trends: Jeremiah Grossman, Robert Hansen, TBD...Moderator: Stuart Schwartz
|}

==== September 10th ====

{| border="0" align="center" style="width: 80%;"
|-
| align="center" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" colspan="4" | '''Conference Day 2 - September 10th, 2010'''
<br>

|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | <br>
| style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Track 1 - Crystal Cove Auditorium
| style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Track 2 - Pacific Ballroom
| style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Track 3 - Doheny Beach
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 08:00-09:00
| align="left" style="width: 80%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Coffee - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 09:00-09:15
| align="center" style="width: 80%; background: none repeat scroll 0% 0% rgb(242, 242, 242);" colspan="3" | Announcements (Crystal Cove Auditorium)
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 09:15-10:00
| align="center" style="width: 80%; background: none repeat scroll 0% 0% rgb(252, 252, 150);" colspan="3" | Keynote: David Rice (Crystal Cove Auditorium)
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:00-10:10
| align="left" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Break - Expo - CTF (Emerald Bay)
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:10-10:55
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Security Architecting Applications for the Cloud, ''Alex Stamos, iSEC Partners''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Unraveling Cross-Technology, Cross-Domain Trust Relations, ''Peleus Uhley, Adobe''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Real Time Application Defenses - The Reality of AppSensor & ESAPI, ''Michael Coates, Mozilla,''
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:55-11:15
| align="left" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Break - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:15-12:00
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Reducing Web application Vulnerabilities: Moving from a Test-Dependent to Design-Driven development, ''Ed Adams, Security Innovation''<br>
<br>

| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Session Management Security tips and Tricks, ''Lars Ewe, Cenzic''<br>
<br>

| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | The Dark Side of Twitter: Measuring and Analyzing Malicious Activity on Twitter, ''Paul Judge, David Maynor, and Daniel Peck, Barracuda Labs''<br>
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 12:00-13:15
| align="left" style="width: 80%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Lunch - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 13:14-14:00
| align="center" style="width: 80%; background: none repeat scroll 0% 0% rgb(252, 252, 150);" colspan="3" | Keynote: HD Moore (Crystal Cove Auditorium)
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 14:04-14:50
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Panal Discussion: Vulnerability Lifecycle for Software Vendors, ''Kelly FitzGerald (Symantec), (US CERT), (Cigital), (Tipping Point) Moderator: Edward Bonver''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Agile + Security = FAIL, ''Adrian Lane''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Bug-Alcoholic 2.0 - Untamed World of Web Vulnerabilities, ''Aditya K. Sood, Armorize Technologies''
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 14:50-15:10
| align="left" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Coffee Break - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:10-15:55
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Exploiting Networks through Database Weaknesses, ''Scott Sutherland, NetSPI''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Defining the Identiy Management Framework, ''Richard Tychansky, Jim Molini, Hord Tipton, and Mike Kilroy''<br>
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | ''TBD''
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:55-16:05
| align="left" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Break - Expo - CTF
|-
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 16:05-16:50
| align="center" style="width: 90%; background: none repeat scroll 0% 0% rgb(242, 242, 242);" colspan="3" | Conference Wrap Up: AppSec US 2011 Location Announcement, CTF Results, Prizes
|}

==== Sponsors ====

We are currently soliciting sponsors for the AppSec US 2010 Conference. Please refer to our [http://www.appsecusa.org/become-a-sponsor.html List of Sponsorship Opportunities] (or [http://www.owasp.org/images/b/b3/OWASP_sponsorship_Irvine.pdf PDF]).

Please contact [mailto:kate.hartmann@owasp.org Kate Hartmann] for more information.

Slots are going fast so contact us to sponsor today!

    

{| cellspacing="10" border="0" align="center" style="background: none repeat scroll 0% 0% transparent; -moz-background-inline-policy: continuous; color: white;"
|-
|
== Platinum Sponsors ==

|
| [File:Qualys-468-60.png]
|
|
|-
|  
|-
|
== Gold Sponsors ==

| [[Image:Ibmneg blurgb.jpg]]
| [[Image:Fortify logo AppSec Research 2010.png]]
|
|-
|  
|-
|
== Silver Sponsors ==

| [[Image:AppSecDC2009-Sponsor-fishnet.gif]]
| [[Image:Acunetix logo 200.png]]
| [[Image:Barracuda Color Logo.jpg]]
| [[Image:Cenziclogo.png]]
|-
| [[Image:Cigital-hor-color.JPG|120px]]
| [[Image:Fujitsu-red-opt-b-150x56.gif]]
| [[Image:Netspi_logo.png]]
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|  
|-
|  
|-
|
=== Organizational Sponsors ===

| [[Image:Isc2 logo.gif|120px]]
|
|-
|  
|-
|
=== Reception Sponsors ===

|
|-
|
=== Coffee Sponsors ===

|
|
|}

==== REGISTER NOW ====

Click [http://www.appsecusa.org/register-now.html here]  for registration information.
<br>

[http://www.appsecusa.org/register-now.html http://www.appsecusa.org/register-now.html]

<headertabs />

[[Category:OWASP_AppSec_Conference]] [[Category:OWASP_AppSec_USA]]

Category:OWASP AntiSamy Project

2010-06-12T03:14:27Z

Arshan: /* Emailing the project lead */

== What is it? ==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

== Who are you? ==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (li.jason.c [at the] gmail.com), both of Aspect Security (http://www.aspectsecurity.com/). The problem AntiSamy solves was often described as "impossible" or "impossible to do right". The folks with the AntiSamy project hope to antiquate that idea in a hurry. As of now, there are Java and .NET implementations of AntiSamy, though the framework is implementable in any language. The Java version is callable from ColdFusion.

PHP developers should use [http://htmlpurifier.org/ HTMLPurifier], another free utility similar to AntiSamy.

== What's the difference between AntiSamy Java, .NET, etc.? ==

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== How do I get started? ==

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-slashdot.xml
#* antisamy-ebay.xml
#* antisamy-myspace.xml
#* antisamy-anythinggoes.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see the .NET page.

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's an example POM for including AntiSamy. If you want a jar file, then '''download the antisamy-bin-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option versions before 1.2 is '''downloading antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues.

For convenience, the download page also contains the necessary libraries for running AntiSamy in '''antisamy-required-libs.zip'''.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) is arguably the most popular social networking site today. Users are allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace is currently using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace is _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 4 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

== Project roadmap ==

This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

== Presentations on AntiSamy ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - by Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - by Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - by Jason Li - AntiSamy project contributor

From Shmoocon 2009 (Washington, DC): [http://www.shmoocon.org/2009/slides/OWASP%20Winter%202009%20Shmoocon%20-%20Anti%20Samy.pptx AntiSamy - Picking a Fight with XSS (pptx)] - by Arshan Dabirsiaghi - AntiSamy project lead

== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com].

=== Issue tracking ===

Visit the [http://code.google.com/p/owaspantisamy/issues/list Google Code issue tracker].

== Sponsors ==

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]]

== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

Category:OWASP AntiSamy Project

2010-06-12T03:13:57Z

Arshan: updating to list shmoocon preso

== What is it? ==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

== Who are you? ==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (li.jason.c [at the] gmail.com), both of Aspect Security (http://www.aspectsecurity.com/). The problem AntiSamy solves was often described as "impossible" or "impossible to do right". The folks with the AntiSamy project hope to antiquate that idea in a hurry. As of now, there are Java and .NET implementations of AntiSamy, though the framework is implementable in any language. The Java version is callable from ColdFusion.

PHP developers should use [http://htmlpurifier.org/ HTMLPurifier], another free utility similar to AntiSamy.

== What's the difference between AntiSamy Java, .NET, etc.? ==

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== How do I get started? ==

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-slashdot.xml
#* antisamy-ebay.xml
#* antisamy-myspace.xml
#* antisamy-anythinggoes.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see the .NET page.

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's an example POM for including AntiSamy. If you want a jar file, then '''download the antisamy-bin-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option versions before 1.2 is '''downloading antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues.

For convenience, the download page also contains the necessary libraries for running AntiSamy in '''antisamy-required-libs.zip'''.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) is arguably the most popular social networking site today. Users are allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace is currently using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace is _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 4 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

== Project roadmap ==

This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

== Presentations on AntiSamy ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - by Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - by Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - by Jason Li - AntiSamy project contributor

From Shmoocon 2009 (Washington, DC): [http://www.shmoocon.org/2009/slides/OWASP%20Winter%202009%20Shmoocon%20-%20Anti%20Samy.pptx AntiSamy - Picking a Fight with XSS (pptx)] - by Arshan Dabirsiaghi - AntiSamy project lead

== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com] (s/ at the /@/).

=== Issue tracking ===

Visit the [http://code.google.com/p/owaspantisamy/issues/list Google Code issue tracker].

== Sponsors ==

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]]

== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

Category:OWASP AntiSamy Project

2010-06-12T03:11:17Z

Arshan: making this less wordy, preachy, self-important

== What is it? ==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term "malicious code" in regards to web applications usually mean "JavaScript." Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner. So we take of that too.

Philosophically, AntiSamy is a departure from contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. We get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely pretty bad when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

== Who are you? ==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (li.jason.c [at the] gmail.com), both of Aspect Security (http://www.aspectsecurity.com/). The problem AntiSamy solves was often described as "impossible" or "impossible to do right". The folks with the AntiSamy project hope to antiquate that idea in a hurry. As of now, there are Java and .NET implementations of AntiSamy, though the framework is implementable in any language. The Java version is callable from ColdFusion.

PHP developers should use [http://htmlpurifier.org/ HTMLPurifier], another free utility similar to AntiSamy.

== What's the difference between AntiSamy Java, .NET, etc.? ==

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== How do I get started? ==

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-slashdot.xml
#* antisamy-ebay.xml
#* antisamy-myspace.xml
#* antisamy-anythinggoes.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see the .NET page.

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's an example POM for including AntiSamy. If you want a jar file, then '''download the antisamy-bin-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option versions before 1.2 is '''downloading antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues.

For convenience, the download page also contains the necessary libraries for running AntiSamy in '''antisamy-required-libs.zip'''.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) is arguably the most popular social networking site today. Users are allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace is currently using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace is _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 4 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

== Project roadmap ==

This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

== Presentations on AntiSamy ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - By Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - By Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - By Jason Li - AntiSamy project contributor

== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com] (s/ at the /@/).

=== Issue tracking ===

Visit the [http://code.google.com/p/owaspantisamy/issues/list Google Code issue tracker].

== Sponsors ==

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]]

== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

Category:OWASP AntiSamy Project

2010-06-12T03:08:32Z

Arshan: updating the ports

== What is it? ==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc. that gets persisted on the server. The term malicious code in terms of web applications is usually regarded only as JavaScript. Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner.

Philosophically, AntiSamy is a departure from all contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. So, we get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely ineffective when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

Socioeconomically, AntiSamy is a have-not enabler. Private companies like Google, MySpace, eBay, etc. have come up with proprietary solutions for solving this problem. This introduces two problems. One is that proprietary solutions are not usually all that good, and even if they are, well - naturally they're reluctant to share this hard-earned IP for free. Fortunately, we just don't care. We don't see any reason why only these private companies should have this functionality, so I'm releasing this for free.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

== Who are you? ==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (li.jason.c [at the] gmail.com), both of Aspect Security (http://www.aspectsecurity.com/). The problem AntiSamy solves was often described as "impossible" or "impossible to do right". The folks with the AntiSamy project hope to antiquate that idea in a hurry. As of now, there are Java and .NET implementations of AntiSamy, though the framework is implementable in any language. The Java version is callable from ColdFusion.

PHP developers should use [http://htmlpurifier.org/ HTMLPurifier], another free utility similar to AntiSamy.

== What's the difference between AntiSamy Java, .NET, etc.? ==

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== How do I get started? ==

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-slashdot.xml
#* antisamy-ebay.xml
#* antisamy-myspace.xml
#* antisamy-anythinggoes.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see the .NET page.

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's an example POM for including AntiSamy. If you want a jar file, then '''download the antisamy-bin-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option versions before 1.2 is '''downloading antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues.

For convenience, the download page also contains the necessary libraries for running AntiSamy in '''antisamy-required-libs.zip'''.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) is arguably the most popular social networking site today. Users are allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace is currently using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace is _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 4 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

== Project roadmap ==

This section details the status of the various ports of AntiSamy.

=== Grails ===
Daniel Bower created a [http://www.grails.org/plugin/sanitizer Grails plugin] for AntiSamy.

=== .NET ===
A .NET port of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed by Jerry Hoff.

This port is no longer under active development, and is looking for a few good developers to help make it feature-synchronized with the .NET version. If it doesn't suit your needs, consider Microsoft's [http://blogs.msdn.com/b/securitytools/archive/2009/09/01/html-sanitization-in-anti-xss-library.aspx AntiXSS] library.

=== Python ===
A beta Python version is currently being prototyped by a few different groups. As more information becomes available, we will post it here. If you are interested in helping, please contact the mailing list.

=== PHP ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

== Presentations on AntiSamy ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - By Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - By Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - By Jason Li - AntiSamy project contributor

== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com] (s/ at the /@/).

=== Issue tracking ===

Visit the [http://code.google.com/p/owaspantisamy/issues/list Google Code issue tracker].

== Sponsors ==

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]]

== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

Category:OWASP AntiSamy Project

2010-06-01T16:51:28Z

Arshan: /* Who are you? */

== What is it? ==

The OWASP AntiSamy project is a few things. Technically, it is an API for ensuring user-supplied HTML/CSS is in compliance within an application's rules. Another way of saying that could be: It's an API that helps you make sure that clients don't supply malicious cargo code in the HTML they supply for their profile, comments, etc. that gets persisted on the server. The term malicious code in terms of web applications is usually regarded only as JavaScript. Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where "normal" HTML and CSS can be used in a malicious manner.

Philosophically, AntiSamy is a departure from all contemporary security mechanisms. Generally, the security mechanism and user have a communication that is virtually one way, for good reason. Letting the potential attacker know details about the validation is considered unwise as it allows the attacker to "learn" and "recon" the mechanism for weaknesses. These types of information leaks can also hurt in ways you don't expect. A login mechanism that tells the user, "Username invalid" leaks the fact that a user by that name does not exist. A user could use a dictionary or phone book or both to remotely come up with a list of valid usernames. Using this information, an attacker could launch a brute force attack or massive account lock denial-of-service. So, we get that.

Unfortunately, that's just not very usable in this situation. Typical Internet users are largely ineffective when it comes to writing HTML/CSS, so where do they get their HTML from? Usually they copy it from somewhere out on the web. Simply rejecting their input without any clue as to why is jolting and annoying. Annoyed users go somewhere else to do their social networking.

Socioeconomically, AntiSamy is a have-not enabler. Private companies like Google, MySpace, eBay, etc. have come up with proprietary solutions for solving this problem. This introduces two problems. One is that proprietary solutions are not usually all that good, and even if they are, well - naturally they're reluctant to share this hard-earned IP for free. Fortunately, we just don't care. We don't see any reason why only these private companies should have this functionality, so I'm releasing this for free.

The [[OWASP_Licenses|OWASP licensing policy]] (further explained in the [[Membership|membership FAQ]]) allows OWASP projects to be released under any [http://www.opensource.org/licenses/alphabetical approved open source license]. Under these guidelines, AntiSamy is distributed under a [http://www.opensource.org/licenses/bsd-license.php BSD license].

== Who are you? ==

AntiSamy was originally authored by Arshan Dabirsiaghi (arshan.dabirsiaghi [at the] gmail.com) with help from Jason Li (li.jason.c [at the] gmail.com), both of Aspect Security (http://www.aspectsecurity.com/). The problem AntiSamy solves was often described as "impossible" or "impossible to do right". The folks with the AntiSamy project hope to antiquate that idea in a hurry. As of now, there are Java and .NET implementations of AntiSamy, though the framework is implementable in any language. The Java version is callable from ColdFusion.

PHP developers should use [http://htmlpurifier.org/ HTMLPurifier], another free utility similar to AntiSamy.

== What's the difference between AntiSamy Java, .NET, etc.? ==

[[AntiSamy Version Differences|This page]] shows a big-picture comparison between the versions. Since it's an unfunded open source project, the ports can't be expected to mirror functionality exactly. If there's something a port is missing -- let us know, and we'll try to accommodate, or write a patch!

== How do I get started? ==

There's 4 steps in the process of integrating AntiSamy. Each step is detailed in the next section, but the high level overview follows:
# Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]
# Choose one of the standard policy files that matches as close to the functionality you need:
#* antisamy-slashdot.xml
#* antisamy-ebay.xml
#* antisamy-myspace.xml
#* antisamy-anythinggoes.xml
# Tailor the policy file according to your site's rules
# Call the API from the code

=== Stage 1 - Downloading AntiSamy ===

The following instructions are for AntiSamy Java, the main version. For instructions on the .NET version, see the .NET page.

Which package you download depends on what you want to do with AntiSamy. If you'd like to extend it or review the code, download the source package. If you're looking to integrate AntiSamy, you can either download the library or use Maven to include it in your build. If you want to use Maven, here's an example POM for including AntiSamy. If you want a jar file, then '''download the antisamy-bin-X.X.X.jar''' (which, before version 1.2 was confusingly called "antisamy-standalone-X.X.X.jar"), which only contains AntiSamy library. This will be the preferred choice for mature enterprise environments who don't want to be caught in classpath issues which may be introduced by the current version.

The second option versions before 1.2 is '''downloading antisamy-standalone-X.X.X.jar''', which contains not only the AntiSamy code, but all necessary supporting libraries. This should only be used by applications that don't use the libraries AntiSamy ships with as they might introduce classpath and versioning issues.

For convenience, the download page also contains the necessary libraries for running AntiSamy in '''antisamy-required-libs.zip'''.

You can Download AntiSamy from [http://code.google.com/p/owaspantisamy/downloads/list its home on Google Code]

=== Stage 2 - Choosing a base policy file ===

Chances are that your site's use case for AntiSamy is at least roughly comparable to one of the predefined policy files. They each represent a "typical" scenario for allowing users to provide HTML (and possibly CSS) formatting information. Let's look into the different policy files:

1) antisamy-slashdot.xml

Slashdot (http://www.slashdot.org/) is a techie news site that allows users to respond anonymously to news posts with very limited HTML markup. Now Slashdot is not only one of the coolest sites around, it's also one that's been subject to many different successful attacks. Even more unfortunate is the fact that most of the attacks led users to the infamous goatse.cx picture (please don't go look it up). The rules for Slashdot are fairly strict: users can only submit the following HTML tags and no CSS: <b>, <u>, <i>, <a>, <blockquote>.

Accordingly, we've built a policy file that allows fairly similar functionality. All text-formatting tags that operate directly on the font, color or emphasis have been allowed.

2) antisamy-ebay.xml

eBay (http://www.ebay.com/) is the most popular online auction site in the universe, as far as I can tell. It is a public site so anyone is allowed to post listings with rich HTML content. It's not surprising that given the attractiveness of eBay as a target that it has been subject to a few complex XSS attacks. Listings are allowed to contain much more rich content than, say, Slashdot- so it's attack surface is considerably larger. The following tags appear to be accepted by eBay (they don't publish rules): <a>,...

3) antisamy-myspace.xml

MySpace (http://www.myspace.com/) is arguably the most popular social networking site today. Users are allowed to submit pretty much all HTML and CSS they want - as long as it doesn't contain JavaScript. MySpace is currently using a word blacklist to validate users' HTML, which is why they were subject to the infamous Samy worm (http://namb.la/). The Samy worm, which used fragmentation attacks combined with a word that should have been blacklisted (eval) - was the inspiration for the project.

4) antisamy-anythinggoes.xml

I don't know of a possible use case for this policy file. If you wanted to allow every single valid HTML and CSS element (but without JavaScript or blatant CSS-related phishing attacks), you can use this policy file. Not even MySpace is _this_ crazy. However, it does serve as a good reference because it contains base rules for every element, so you can use it as a knowledge base when using tailoring the other policy files.

=== Stage 3 - Tailoring the policy file ===

Smaller organizations may want to deploy AntiSamy in a default configuration, but it's equally likely that a site may want to have strict, business-driven rules for what users can allow. The discussion that decides the tailoring should also consider attack surface - which grows in relative proportion to the policy file.

You may also want to enable/modify some "directives", which are basically advanced user options. [[AntiSamy Directives|This page]] tells you what the directives are and which versions support them.

=== Stage 4 - Calling the AntiSamy API ===

Using AntiSamy is abnormally easy. Here is an example of invoking AntiSamy with a policy file:

<code><pre>import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
</pre></code>

There are a few ways to create a Policy object. The <code>getInstance()</code> method can take any of the following:
* a String filename
* a File object
* an InputStream

Policy files can also be referenced by filename by passing a second argument to the <code>AntiSamy:scan()</code> method as the following examples show.:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);</pre></code>

Finally, policy files can also be referenced by File objects directly in the second parameter:

<code><pre>AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));</pre></code>

=== Stage 4 - Analyzing CleanResults ===

The CleanResults object provides a lot of useful stuff.

<code>getErrorMessages()</code> - a list of <code>String</code> error messages

<code>getCleanHTML()</code> - the clean, safe HTML output

<code>getCleanXMLDocumentFragment()</code> - the clean, safe <code>XMLDocumentFragment</code> which is reflected in <code>getCleanHTML()</code>

<code>getScanTime()</code> - returns the scan time in seconds

== Project roadmap ==

This is a labor of love, so the upgrade process may be achingly slow at times. This section details port roadmaps.

=== .NET version ===
The .NET version of AntiSamy is available now at the [[:Category:OWASP AntiSamy Project .NET|OWASP AntiSamy .NET]] page. The project was funded by a Summer of Code 2008 grant and was developed primarily by Jerry Hoff with oversight from Arshan Dabirsiaghi.

=== Python version ===
A beta Python version is currently being prototyped. As more information becomes available, we will post it here. If you are interesting in helping, please email me (arshan.dabirsiaghi [at the] gmail.com).

=== PHP version (no plans) ===
Although a PHP version was initially planned, we now suggest [http://htmlpurifier.org HTMLPurifier] for safe rich input validation for PHP applications.

== Presentations on AntiSamy ==

From OWASP & WASC AppSec U.S. 2007 Conference (San Jose, CA): [http://www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt AntiSamy - Picking a Fight with XSS (ppt)] - By Arshan Dabirsiaghi - AntiSamy project lead

From OWASP AppSec Europe 2008 (Ghent, Belgium): [http://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt The OWASP AntiSamy project (ppt)] - By Jason Li - AntiSamy project contributor

From OWASP AppSec India 2008 (Delhi, India): [https://www.owasp.org/images/9/9d/AppSecIN08-ValidatingRichUserContent.ppt Validating Rich User Content (ppt)] - By Jason Li - AntiSamy project contributor

== Contacting us ==
There are two ways of getting information on AntiSamy. The mailing list, and contacting the project lead directly.

=== OWASP AntiSamy mailing list ===
The first is the mailing list which is located at https://lists.owasp.org/mailman/listinfo/owasp-antisamy. The list was previously private and the archives have been cleared with the release of version 1.0. We encourage all prospective and current users and bored attackers to join in the conversation. We're happy to brainstorm attack scenarios, discuss regular expressions and help with integration.

=== Emailing the project lead ===

For content which is not appropriate for the public mailing list, you can alternatively contact the project lead, Arshan Dabirsiaghi, at [arshan.dabirsiaghi] at [aspectsecurity.com] (s/ at the /@/).

=== Issue tracking ===

Visit the [http://code.google.com/p/owaspantisamy/issues/list Google Code issue tracker].

== Sponsors ==

The initial Java project was sponsored by the [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]]. The .NET project was sponsored by the [[OWASP Summer of Code 2008]]

== Project's Assessment ==

This project was assessed by [[:User:Jeff Williams|Jeff Williams]] and his evaluation can be seen [http://spreadsheets.google.com/ccc?key=pAX6n7m2zaTW-JtGBqixbTw '''here'''].

[[Category:OWASP Project|AntiSamy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]