OWASP - User contributions [en]

Content Security Policy Cheat Sheet

2015-04-09T19:04:35Z

Nmatatal:

Content Security Policy Cheat Sheet

2015-04-09T19:02:52Z

Nmatatal:

Content Security Policy (CSP) is an important standard by the W3C that is aimed to prevent a broad range of content injection attacks such as cross-site scripting (XSS).

= Introduction =

Content Security Policy (CSP) is an effective "defense in depth" technique to be used against content injection attacks. It is a declarative policy that informs the user agent what are valid sources to load from.

Since, it was introduced in Firefox version 4 by Mozilla, it has been adopted as a standard, and grown in adoption and capabilities.

This document is meant to provide guidance on how to utilize CSP under a variety of situations to address a variety of concerns.

= References =

Specifications of the CSP standard can be found the following locations:
* Latest Revision - https://w3c.github.io/webappsec/specs/content-security-policy/
* Latest Version (CSP2) - http://www.w3.org/TR/CSP2/
* CSP 1.0 - http://www.w3.org/TR/2012/CR-CSP-20121115/

= CSP Basics =

CSP consists of a series of directives. CSP has also evolved over two major revisions. Most browsers support 1.0, and adoption of CSP2 has been incremental.

== HTTP Headers ==

The following are headers for CSP.

* '''Content-Security-Policy''' : W3C Spec standard header. Supported by Firefox 23+, Chrome 25+ and Opera 19+
* '''Content-Security-Policy-Report-Only''' : W3C Spec standard header. Supported by Firefox 23+, Chrome 25+ and Opera 19+, whereby the policy is non-blocking ("fail open") and a report is sent to the URL designated by the '''report-uri''' directive. This is often used as a precursor to utilizing CSP in blocking mode ("fail closed")
* '''DO NOT''' use X-Content-Security-Policy or X-WebKit-CSP. Their implementations are obsolete (since Firefox 23, Chrome 25), limited, inconsistent, and incredibly buggy.

== Directives ==

The following is a listing of directives, and a brief description.

=== CSP 1.0 Spec ===
* '''connect-src''' (d) - restricts which URLs the protected resource can load using script interfaces. (e.g. send() method of an XMLHttpRequest object)
* '''font-src''' (d) - restricts from where the protected resource can load fonts
* '''img-src''' (d) - restricts from where the protected resource can load images
* '''media-src''' (d) - restricts from where the protected resource can load video, audio, and associated text tracks
* '''object-src''' (d) - restricts from where the protected resource can load plugins
* '''script-src''' (d) - restricts which scripts the protected resource can execute. Additional restrictions against, inline scripts, and eval. Additional directives in CSP2 for hash and nonce support
* '''style-src''' (d) - restricts which styles the user may applies to the protected resource. Additional restrictions against inline and eval.
* '''default-src''' - Covers any directive with ''(d)''
* '''frame-src''' - restricts from where the protected resource can embed frames. Note, deprecated in CSP2
* '''report-uri''' - specifies a URL to which the user agent sends reports about policy violation
* '''sandbox''' - specifies an HTML sandbox policy that the user agent applies to the protected resource. Optional in 1.0

=== New in CSP2 ===
* '''form-action''' - retricts which URLs can be used as the action of HTML form elements
* '''frame-ancestors''' - indicates whether the user agent should allow embedding the resource using a frame, iframe, object, embed or applet element, or equivalent functionality in non-HTML resources
* '''plugin-types''' - restricts the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded
* '''base-uri''' - restricts the URLs that can be used to specify the document base URL
* '''child-src''' (d) - governs the creation of nested browsing contexts as well as Worker execution contexts

= CSP Sample Policies =

== Basic CSP Policy ==

This policy will only allow resources from the originating domain for all the default level directives, and will not allow inline scripts/styles to execute. If your application and function with these restrictions, it drastically reduces your attack surface having this policy in place, and will work with most modern browsers.

The most basic policy assumes:
* all resources are hosted by the same domain of the document
* there are no inlines or evals for scripts and style resources

Content-Security-Policy: default-src 'self'

To tighten further, one can do the following:

Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';

This policy allows images, scripts, AJAX, and CSS from the same origin, and does not allow any other resources to load (eg. object, frame, media, etc). (see http://content-security-policy.com/)

== Mixed Content Policy ==

In order to prevent mixed content (resources being loaded over http, from a document loaded over https), one can use the value "https:" as a directive value.

For instance:

Content-Security-Policy: default-src https:; connect-src https:; font-src https: data:; frame-src https:;
img-src https: data:; media-src https:; object-src https:; script-src 'unsafe-inline' 'unsafe-eval' https:;
style-src 'unsafe-inline' https:;

This is what was used at Twitter, Oct 2014. The policy prevents mixed content, allows for scheme "data:" in font-src and img-src, allows for unsafe-inline and unsafe-eval for script-src, and unsafe-inline for style-src. (see: https://twittercommunity.com/t/blocking-mixed-content-with-content-security-policy/26375)

Mixed Content has two categories: Active and Passive. Passive content consists of "resources which cannot directly interact with or modify other resources on a page: images, fonts, audio, and video for example", whereas active content is "content which can in some way directly manipulate the resource with which a user is interacting." (http://www.w3.org/TR/2014/WD-mixed-content-20140722)

Content-Security-Policy: img-src https: data:; font-src https: data:; media-src https:;

This is an example to block only passive mixed content.

Content-Security-Policy: script-src https:; style-src https:; object-src https:; connect-src https:; frame-src https:;

This is an example to block only active mixed content.

= CSP Cheat Sheet - Guide for main technologies =

This section summarizes the implementation and/or support for CSP in different technologies (either acting as Client or Server).
See below the details.

'''Google Chrome'''

Google Chrome based web applications and theme uses a manifest file named manifest.json.
There is a section in the manifest file where the developer can declare the CSP directives.
For further details, please refer to Content Security Police for Google Chrome.

{
''// Required''
"manifest_version": 2,
"name": "My Extension",
"version": "versionString",

''// Recommended''
"default_locale": "en",
"description": "A plain text description",
"icons": {...},

''// Pick one (or none)''
"browser_action": {...},
"page_action": {...},

''// Optional''
"author": ...,
"automation": ...,
"background": {
// Recommended
"persistent": false
},
"background_page": ...,
"chrome_settings_overrides": {...},
"chrome_ui_overrides": {
"bookmarks_ui": {
"remove_bookmark_shortcut": true,
"remove_button": true
}
},
"chrome_url_overrides": {...},
"commands": ...,
"content_pack": ...,
"content_scripts": [{...}],
"content_security_policy": "policyString",
"converted_from_user_script": ...,
"current_locale": ...,
"devtools_page": ...,
"externally_connectable": {
"matches": ["*://*.example.com/*"]
},
"file_browser_handlers": [...],
"homepage_url": "http://path/to/homepage",
"import": ...,
"incognito": "spanning or split",
"input_components": ...,
"key": "publicKey",
"minimum_chrome_version": "versionString",
"nacl_modules": [...],
"oauth2": ...,
"offline_enabled": true,
"omnibox": {
"keyword": "aString"
},
"optional_permissions": ...,
"options_page": "aFile.html",
"options_ui": ...,
"page_actions": ...,
"permissions": [...],
"platforms": ...,
"plugins": [...],
"requirements": {...},
"sandbox": [...],
"script_badge": ...,
"short_name": "Short Name",
"signature": ...,
"spellcheck": ...,
"storage": {
"managed_schema": "schema.json"
},
"system_indicator": ...,
"tts_engine": ...,
"update_url": "http://path/to/updateInfo.xml",
"web_accessible_resources": [...]}

'''Apache'''

It is required to add lines to the httpd.conf configuration file, or inside .htaccess files or virtual host sections.
Also, it is required to enable mod_headers, and after inserting the lines according to your specific needs, restart Apache.
The headers below are good examples to add in the files (change/modify it properly):

Header unset Content-Security-Policy
Header add Content-Security-Policy "default-src 'self'"
Header unset X-Content-Security-Policy
Header add X-Content-Security-Policy "default-src 'self'"
Header unset X-WebKit-CSP Header add X-WebKit-CSP "default-src 'self'"

'''WordPress'''

Most of the configuration can be done in Apache, however, Wordpress has a plugin that allows developers/administrator to set up their own custom policies. The plugin however is not update for 2 years. Use it carefully.
A workaround can be the creation or modification of the file htaccess under wp-admin directory.

An example:

<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self';
img-src 'self' data: http: https: *.gravatar.com;
script-src 'self' 'unsafe-inline' 'unsafe-eval';
style-src 'self' 'unsafe-inline' http: https: fonts.googleapis.com;
font-src 'self' data: http: https: fonts.googleapis.com themes.googleusercontent.com;"
</IfModule>

'''nginx'''

<nowiki>For nginx, it is required to edit the nginx.conf file.

# config to don't allow the browser to render the page inside an frame or iframe

# and avoid clickjacking http://en.wikipedia.org/wiki/Clickjacking

# if you need to allow [i]frames, you can use SAMEORIGIN or even set an uri with ALLOW-FROM uri # https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options
add_header X-Frame-Options SAMEORIGIN;

# when serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: header,

# to disable content-type sniffing on some browsers.

# https://www.owasp.org/index.php/List_of_useful_HTTP_headers

# currently suppoorted in IE > 8 http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx

# http://msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx

# 'soon' on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=471020
add_header X-Content-Type-Options nosniff;

# This header enables the Cross-site scripting (XSS) filter built into most recent web browsers.

# It's usually enabled by default anyway, so the role of this header is to re-enable the filter for

# this particular website if it was disabled by the user.

# https://www.owasp.org/index.php/List_of_useful_HTTP_headers
add_header X-XSS-Protection "1; mode=block";

# with Content Security Policy (CSP) enabled(and a browser that supports it(http://caniuse.com/#feat=contentsecuritypolicy),

# you can tell the browser that it can only download content from the domains you explicitly allow

# http://www.html5rocks.com/en/tutorials/security/content-security-policy/

# https://www.owasp.org/index.php/Content_Security_Policy

# I need to change our application code so we can increase security by disabling 'unsafe-inline' 'unsafe-eval'

# directives for css and js(if you have inline css or js, you will need to keep it too).

# more: http://www.html5rocks.com/en/tutorials/security/content-security-policy/#inline-code-considered-harmful
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://ssl.google-analytics.com https://assets.zendesk.com https://connect.facebook.net; img-src 'self' https://example.com https://example1.com; style-src https://example.com; font-src https://example.com; frame-src https://example.com; object-src 'none'";

server {
listen 443 ssl default deferred;
server_name .forgott.com;

ssl_certificate the_path_of_your_certificate.crt;
ssl_certificate_key the_path_of_your_key.key;</nowiki>

'''Django'''

Django recently introduced a package with a number a collection of models, views and middlewares to aid secure Django based projects.
The installation of this model can be done through from Python packages repository:
pip install django-security
Also, the the latest development version, install from django-security repository on GitHub:
git clone https://github.com/sdelements/django-security.git
cd django-security
sudo python setup.py install
For each Djangon’s application, the settings.py file must be modified.

== INSTALLED_APPS = (
...
'security',
...
)
==

Middleware modules can be added to MIDDLEWARE_CLASSES list in settings file. Particularly, it is our interesting the ContentSecurityPolicyMiddleware. It sends Content Security Policy (CSP) header in HTTP response.:

== MIDDLEWARE_CLASSES = (
...
'security.middleware.DoNotTrackMiddleware',
==

= Authors and Primary Editors =

Neil Mattatall - neil[at]owasp.org<br/>
Denis Mello - ddtaxe

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

AppSec California 2015

2014-09-20T15:22:22Z

Nmatatal:

== Please visit https://2015.appseccalifornia.org/ for up to date info. ==

On January 26-28, 2015, AppSec California, the West Coast’s leading infosec event, will return for the second year in a row to the Annenberg Community Beach House in Santa Monica, California for three days of action-packed presentations and training sessions for IT and IT Security professionals, application developers and software security professionals. This event is a collaborative effort by the Los Angeles, Orange County, San Diego, Santa Barbara, and the Bay Area chapters of the Open Web Application Security Project (OWASP), and will feature many prominent speakers in a truly unique environment. The conference will be three days filled with multiple tracks, great networking, and a full day of hands-on training.
The first round of the call for speakers is currently open and will close on October 31, 2014. To submit a talk proposal, please visit: https://2015.appseccalifornia.org/
AppSec California will feature four outstanding keynote speakers including: Alex Stamos, CISO at Yahoo; John Steven, CTO at Cigital; Charlie Miller, Security Researcher at Twitter; and Katie Moussouris, Chief Policy Officer at HackerOne. Other confirmed speakers include: Parisa Tabriz (Google), Jim Manico (Manicode Security), Adrienne Porter (Google), Aaron Portnoy (Exodus Intelligence), Devdatta Akhawe (Dropbox), Jeff Williams (Contrast Security), Ping Yan (Salesforce), Zach Lanier (Duo Security), James Wickett (Signal Sciences Corp.), Kelly Lum (Tumblr), Ilja van Sprundel (IOActive), Russ Gidein (Attack Research), and Stenoplasma.
“Last year AppSec Cali had nearly 300 top information security attendees from California and across the globe take part in the inaugural event,” said Richard Greenberg, head of the AppSec Cali event. This year we plan to surpass that number, drawing even more senior executives, technical experts, information security practitioners and students to benefit from the information sharing and personal connections the event offers.”
The conference venue sits on 5-acres of oceanfront property with spectacular views of the Pacific Ocean. Attendees will be able to enjoy the various indoor and outdoor spaces, meeting with the leading information security practitioners, researchers, and developers in California.
Who Should Attend AppSec California?
Application Developers
Application Testers and Quality Assurance
Application Project Management and Staff
Chief Information Officers, Chief Information Security Officers, Chief Technology Officers, Deputies, Associates and Staff
Chief Financial Officers, Auditors, and Staff Responsible for IT Security Oversight and Compliance
Security Managers and Staff
Executives, Managers, and Staff Responsible for IT Security Governance
IT Professionals Interesting in Improving IT Security
Various sponsorship opportunities are available to allow all companies to gain exposure for their products and services. For more details on sponsoring this event, please visit:
https://2015.appseccalifornia.org/wp-content/uploads/2014/09/Sponsorship-Opportunities-09-07-2014.pdf
For more general event information, please visit the AppSec California 2015 website:
https://2015.appseccalifornia.org/
About OWASP:
The Open Web Application Security Project (OWASP) is a not-for-profit, worldwide organization focused on improving the security of application software. Its mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of its materials are available under a free and open software license. OWASP is a new kind of organization. Its freedom from commercial pressures allows it to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although it supports the informed use of commercial security technology.

WASPY Awards 2014

2014-08-11T16:33:34Z

Nmatatal:

[[File:WASPY-BANNER-2014.jpg]]

<font size="6">'''Web Application Security People of the Year Awards 2014'''</font>

Every year a group of individuals including researchers, developers, security professionals and others work to ensure the security of web applications. Some of these individuals are featured in news stories or at conferences as recognized experts. But there are many other ‘unsung heroes’ that work every day to improve web application security and yet are rarely recognized.

=='''Timeline'''==

June 10 - Call for Nominees '''Now Open!''' Submit your nominee [http://www.tfaforms.com/284578 here]

June 23 - Reminder Email Will be Sent For Call for Nominees

June 30 - Call for Nominees Closes

July 7 - Announcement of Nominees Per Category

July 15 - Deadline For Profile Picture and Bio to be Submitted

July 31 - Paid Membership Deadline - '''NOT SURE IF YOU ARE A CURRENT MEMBER?'''

August 8 - Voting Opens

August 26 - Voting Closes

August 27 - Announcement of Winners

September 16-19 - Awards Ceremony at AppSecUSA 2014 in Denver, CO

=='''Categories'''==

1. Best Chapter Leader - active chapter leader to be recognized for their contributions to the growth and organization of the chapter.

2. Best Project Leader - active project leader to be recognized for the development of their project.

3. Best Mission Outreach - individual who contributed to the growth of the organization through outreach to the community.

4. Best New Community Supporter "Rookie of the Year" - individual (no requirement to be a leader) who has contributed to any chapter, project, initiative, or other OWASP activity.

5. Best Platform Supporter - (OWASP Staff Vote) individual who positively contributes to the reinforcement of the OWASP platform.

=='''Rules:==

1. Board members can NOT be nominated

2. Paid staff can NOT be nominated

3. Must be a paid member to vote.

4. All nominees will remain anonymous until July 7, 2014

5. Anyone can nominate any individual

6. One person per category may be nominated

=='''Sponsorship Opportunities'''==
The support from our sponsors, is what makes these awards truly successful! To learn more about how you can support these awards please see our [http://owasp.com/images/1/1a/2014_WASPY_Sponsorship_Doc.pdf '''Sponsorship Opportunities'''.]

'''Become involved and support the WASPY Awards today!'''

=='''And the Nominees Are...'''==
'''Categories:'''

*Best Chapter Leader

{| border="1" cellpadding="2"
! scope="col" align="center" width="150" | Name
! scope="col" align="center" width="120" | Chapter
! scope="col" align="center" width="800" | Citation
|-
|align="center"| [https://www.owasp.org/index.php/User:Riotaro_OKADA Riotaro OKADA] & [https://www.owasp.org/index.php/User:Sen_UENO Sen UENO ] Japan Chapter Leaders||align="center"|[https://www.owasp.org/index.php/Japan Japan]||align="center"|"The foundation of the OWASP Japan local chapter, its rapid growth to reaching over 2,000 participants in local chapter meetings in the first 2 years and the massive success of AppSec APAC 2014 in Tokyo would not have been possible without the passion and full commitment to the OWASP cause demonstrated by Rio. He is definitely a role model for the OWASP community, especially in the Asia Pacific region which in general is lacking strong and effective leadership, and there is no doubt in my mind he is the most suited candidate for Best Chapter Leader based on the efforts he's contributed in the past few years as well as the success and results of those efforts."

"He holds local chapter meeting(we call OWASP Night), and every event is full capacity and good topics. And he organized successful event, which is OWASP APAC 2014 in this year."

"Rio has done an amazing job building up our Japan chapters.
Over the last few years with huge community meetings, new chapters in Japan and a lot of community activity.
This is truely outstanding!"

"Sen is OWASP Japan Co-Chapter leader and leading OWASP AppSec APAC."
|-
|align="center"| Adam Brand, Ryan Heiserman, Kristian Erik Hermansen, Neil Matatall, Ron Perris, Adam Robertson [https://www.owasp.org/index.php/Orange_County_Team Orange County Team]||align="center"|[https://www.owasp.org/index.php/Orange_County Orange County]||align="center"|

"• OWASP Orange County Chapter Meetings
• Grew the chapter leadership organization to six chapter leaders from three.
• Increased meeting frequency from bi-yearly to monthly.
• Held 13 meetings in the last twelve months.
• Attracted 140 new attendees to chapter meetings.
• Established a culture of vendor neutrality and speakers selection based on merit

• Organized AppSec California
• 250 Attendees
• 40 Speakers on 3 Tracks

Currently Organizing AppSec California 2015!"
|-
|align="center"| [https://www.owasp.org/index.php/Sebastien_(Seba)_Deleersnyder Sebastien Deleersnyder]||align="center"|[https://www.owasp.org/index.php/ Belgium]||align="center"|"He does a lot of work, not only for the chapter meetings but also for the BeNeLux days. He is very approachable and open for suggestions."
|-
|align="center"| [https://www.owasp.org/index.php/User:Jonathan_Marcil Jonathan Marcil]||align="center"|[https://www.owasp.org/index.php/ Montreal]||align="center"|""I would like to nominate Jonathan for his involvement in:
1) Successfully leading the Montreal Chapter. Even when personally absent and traveling on another continent, Jonathan has remotely managed the overall execution of the local chapter meetings.
2) His valuable contribution to the OWASP Media project, that undoubtedly brings the ""O"" of OWASP to audiences unable to attend meetings
3) Jonathan has contributed and invested efforts on the ""outreach"" objective, announced by the board as a core objective for 2013-2014."
|-
|}

*Best Project Leader
{| border="1" cellpadding="2"
! scope="col" align="center" width="150" | Name
! scope="col" align="center" width="120" | Project
! scope="col" align="center" width="800" | Citation

|-
|align="center"|[https://www.owasp.org/index.php/Jeremy_Long Jeremy Long]||align="center"|[https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check]||align="center"|"Reasons Jeremy Long and his Dependency Check deserve a WASPY award:

- His OWASP Dependency Check is a solution to the problem of third party libraries that needed to be solved.
- Jeremy's work on D.C. is steady. He has put a lot of work into this project
- Jeremy has successfully involved others to help work on the project. It is a model open source project.
- He has been responsive and helpful to questions and created a nice community of users."
|-
|align="center"|[https://www.owasp.org/index.php/User:achim Achim Hoffmann]||align="center"|[https://www.owasp.org/index.php/O-Saft OWASP O-Saft]||align="center"|"Achim is the project leader of O-Saft (https://www.owasp.org/index.php/O-Saft). O-Saft is a tool to analyze the SSL configuration of a web or mail server. It is a tool with a very specific focus, not a swiss army knife but there is a need for exactly this tool. Achim started the development at the beginning of the big SSL-crisis (concerns about weak ciphers, cipher orders, perfect forward secrecy, ). Without a specialized tool it is impossible to find out the SSL behaviour of a given server. Achim's interest was focused on facts only. The outcome of the tool is not a subjective rating, score or grade, only facts about the config. Achim goals were exactness, comprehensiveness and impartiality which he achieved with his project. He was open to suggestions and could win additional highly motivated and skilled contributors. He is not a marketing driven project leader instead of that he gives talks and trainings about SSL and O-Saft (Munich Chapter, OWASP AppSec EU 2014 Cambridge) to share his knowledge.

I would like to nominate Achim for the OWASP Project Leader 2014 because his project fulfills the OWASP mission in a perfect way. It makes the security of SSL servers visible. There is no free available tool beside O-Saft with a comparable comprehensive scope and ability to execute. It is completely free of commercial interests or commercial ""added values"", distributed under a GPL."
|-
|align="center"|[https://www.owasp.org/index.php/User:Tokuji_Akamine Tokuji Akamine]||align="center"|[https://www.owasp.org/index.php/OWASP_XSecurity_Project OWASP XSecurity Project]||align="center"|"The idea(feature) of this security tool is excellent, especially these two points below.
Usually security is difficult and burdensome. But this security tool makes security much easier and less burdensome to iOS app developers.
1. Provide developer friendly security features on top of Xcode to assist developers to learn iOS app security.(Quick Security Help with built-in Security Guidelines)
2. Avoid making vulnerabilities during development.(Real-time Vulnerability Notifications)"

"He provides to assist iOS developers to develop secure iOS apps and a security plugin for Xcode plus clang static analyzer checkers for iOS application development. This plugin will be to reduce the vulnerability made during development by detecting the vulnerability."
|-
|align="center"|[https://www.owasp.org/index.php/Matteo_Meucci Matteo Meucci]||align="center"|[https://www.owasp.org/index.php/OWASP_Testing_Project OWASP Testing Project]||align="center"|"Matteo collaborates in OWASP from 2002.He founded the Italian Chapter in 2005.He candidates for the Autum of Code in 2006 to start a new project regarding the Testing Guide. He leads the OWASP Testing from 2006 (v2) to now with the publishing of Testing Guide v4 in the next weeks. He was capable to attract and manage more than 50 people to create the new Guide. Nowadays the Testing Guide is the most recognized project of OWASP with great contents and high quality delivery."
|-
|align="center"|[https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts]||align="center"|[http://owasp.com/index.php/ZAP OWASP Zed Attack Proxy Project (ZAP)]||align="center"|"He has both humble heart and strong leadership."
|-
|align="center"|[https://www.owasp.org/index.php/John_Melton John Melton]||align="center"|[https://www.owasp.org/index.php/OWASP_AppSensor OWASP AppSensor]||align="center"|"John has working tirelessly, and mostly invisible behind the scenes in developing the OWASP AppSensor project. While others have lead the charge on the OWASP AppSensor documentation project, for the most part, John has been the sole contributor to the OWASP AppSensor source code."
|-
|align="center"|[https://www.owasp.org/index.php/Spyros_Gasteratos Spryos Gasteratos]||align="center"|[https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project OWASP Hackademic Challenges Project]||align="center"|"Spyros has been involved in OWASP since 2010, contributing more and more time as years go by. He began by volunteering for OWASP AppSec Research 2012, where he was in charge for coordinating a team of more than 20 volunteers. For the past 1.5 year he as been co-leading the OWASP Hackademic Challenges Project. During that time he has managed to take the project into the next level both by producing code and by mentoring GSOC students. Spyros has spent a tremendous amount of time in coding, fixing bugs, setting up and maintaining a live version of Hackademic. Undoubtedly, without his efforts the project would have become dormant.Furthermore, he is also helping in other OWASP initiatives, e.g. by participating in the Open Source Showcase, presenting Hackademic and OWASP at the FOSDEM conference in Belgium and by setting up the new ""OWASP Code Wind"" project that aims to bring more student contributions to OWASP."
|-
|}

*Best Mission Outreach
{| border="1" cellpadding="2"
! scope="col" align="center" width="150" | Name
! scope="col" align="center" width="120" |
! scope="col" align="center" width="800" | Citation

|-
|align="center"|[https://www.owasp.org/index.php/Mostafa_Siraj Mostafa Siraj]||align="center"|[https://www.owasp.org/index.php/Cairo Cairo Chapter]||align="center"|"Mostafa did a great job helping our chapter (Cairo Chapter), here are summary of his contribution: - He had a great talk in the latest chapter event, he talk about AppSec US summarizing the conference technical sessions (Mostafa attended the 2013 conference and won the technical competition there), - Mostafa is one of the main members of a small group of AppSec expertise from Cairo chapter, this group is engaged now for preparing security awareness training program for all governmental developers in Egypt, I highly recommend him,"
|-
|align="center"|[https://www.owasp.org/index.php/User:Jonathan_Marcil Jonathan Marcil]||align="center"|[https://www.owasp.org/index.php/OWASP_Media_Project OWASP Media Project]||align="center"|"Because he is helping spread OWASP message through this videos and live streaming events"
|-
|align="center"|[https://www.owasp.org/index.php/AppSecUSA_2013_Team AppSecUSA 2013 Team]||align="center"|[http://2013.appsecusa.org/ AppSecUSA 2013 Team]||align="center"|"AppSec USA 2013 was one of our (if not the) most successful conferences ever. In terms of the sheer number of attendees and high quality talks and organisation, this was indeed an outstanding achievement in mission outreach. I would like to nominate the team for this amazing achievement."
|}

*Best New Community Supporter
{| border="1" cellpadding="2"
! scope="col" align="center" width="150" | Name
! scope="col" align="center" width="120" |
! scope="col" align="center" width="800" | Citation

|-
|align="center"|[https://www.owasp.org/index.php/AppSecAPAC_2014_Team AppSecAPAC 2014 Team]||align="center"|[https://www.owasp.org/index.php/AppSecAsiaPac2014#tab=TEAM AppSec APAC 2014]||align="center"|"Despite it being the first time that AppSec was held in Japan and despite the lack of experience in planning and organizing a large scale international conference, the volunteers on the AppSec APAC 2014 team came together and went above and beyond their responsibilities to make AppSec APAC 2014 in Tokyo a stunning success. It was by far the most successful AppSec in the Asia Pacific region and achieved an unprecedented level of profitability. The vast majority of the sponsors were Japanese companies and many of the attendees were Japanese. The ability to achieve this despite the relatively low level of awareness of the OWASP brand in Japan was definitely due to the hard work and dedication of the AppSec APAC 2014 team who worked around the clock to make the event a success. Considering that there were no applicants to hold AppSec APAC 2015 despite the tremendous success in Tokyo, recognizing the contributions of the AppSec APAC 2015 team would definitely give a strong message motivating the Asia Pacific community and facilitate future OWASP initiatives in the region."

"Surely, potential language barriers were completely broken in the conference. This experience of us will be a good example for OWASP organizers especially in Asia Pacific area."

"2 OWASP ZAP evangelists were born in Japan at the timing of AppSec APAC 2014."
|-
|align="center"|[https://www.owasp.org/index.php/Beth_Ritter-Guth Beth Guth]||align="center"|[https://www.owasp.org/index.php/New_Jersey_South South New Jersey]||align="center"|"She started South New Jersey chapter with energy and enthusiasm bringing together people from builders, breakers and defenders. Self-starter"
|-

File:2014-04 OWASP SoCal - Continuous1.pptx

2014-04-25T19:13:28Z

Nmatatal:

File:CSP-1.1-2014-02-20.pdf

2014-02-24T15:43:18Z

Nmatatal: "How CSP will (maybe) Solve the XSS Problem" presented at OWASP OC on Feb 20, 2014

"How CSP will (maybe) Solve the XSS Problem" presented at OWASP OC on Feb 20, 2014

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-09-15T21:22:04Z

Nmatatal: /* HTML entity encoding */

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

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

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

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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 use 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the context and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this without encoding the data with one of the techniques listed below.'''
</script>

==== JSON entity encoding ====

The rules for JSON encoding can be found in the [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Output_Encoding_Rules_Summary Output Encoding Rules Summary]. Note, this will not allow you to use XSS protection provided by CSP 1.0.

==== HTML entity encoding ====

This technique has the advantage that html entity escaping is widely supported and helps separate data from server side code without crossing any context boundaries. Consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= html_escape(data.to_json) %>
</script>

// external js file
var dataElement = document.getElementById('init_data');
var jsonText = dataElement.textContent || dataElement.innerText // unescapes the content of the span
var initData = JSON.parse(jsonText);

== RULE #4 - CSS Escape And Strictly Validate 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</span> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 will 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 and validation 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! 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, especially Javascript links. URL's should then 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. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer''' - https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

'''Other libraries that provide HTML Sanitization include:'''<br/>

PHP Html Purifier - http://htmlpurifier.org/<br/>
JavaScript/Node.JS Bleach - https://github.com/ecto/bleach<br/>
Python Bleach - https://pypi.python.org/pypi/bleach

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-09-15T21:20:44Z

Nmatatal: /* JSON entity encoding */

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

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

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

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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 use 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the context and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this without encoding the data with one of the techniques listed below.'''
</script>

==== JSON entity encoding ====

The rules for JSON encoding can be found in the [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Output_Encoding_Rules_Summary Output Encoding Rules Summary]. Note, this will not allow you to use XSS protection provided by CSP 1.0.

==== HTML entity encoding ====

Built-in to every framework.

Consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= html_escape(data.to_json) %>
</script>

// external js file
var dataElement = document.getElementById('init_data');
var jsonText = dataElement.textContent || dataElement.innerText // unescapes the content of the span
var initData = JSON.parse(jsonText);

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

== RULE #4 - CSS Escape And Strictly Validate 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</span> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 will 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 and validation 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! 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, especially Javascript links. URL's should then 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. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer''' - https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

'''Other libraries that provide HTML Sanitization include:'''<br/>

PHP Html Purifier - http://htmlpurifier.org/<br/>
JavaScript/Node.JS Bleach - https://github.com/ecto/bleach<br/>
Python Bleach - https://pypi.python.org/pypi/bleach

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-09-15T21:19:52Z

Nmatatal: /* RULE #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse */

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

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

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

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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 use 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the context and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this without encoding the data with one of the techniques listed below.'''
</script>

==== JSON entity encoding ====

An alternative to the technique above is JSON encoding the data. The rules for JSON encoding can be found in the [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Output_Encoding_Rules_Summary Output Encoding Rules Summary].

==== HTML entity encoding ====

Built-in to every framework.

Consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= html_escape(data.to_json) %>
</script>

// external js file
var dataElement = document.getElementById('init_data');
var jsonText = dataElement.textContent || dataElement.innerText // unescapes the content of the span
var initData = JSON.parse(jsonText);

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

== RULE #4 - CSS Escape And Strictly Validate 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</span> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 will 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 and validation 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! 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, especially Javascript links. URL's should then 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. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer''' - https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

'''Other libraries that provide HTML Sanitization include:'''<br/>

PHP Html Purifier - http://htmlpurifier.org/<br/>
JavaScript/Node.JS Bleach - https://github.com/ecto/bleach<br/>
Python Bleach - https://pypi.python.org/pypi/bleach

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-09-15T21:19:17Z

Nmatatal: /* HTML entity encoding */

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

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

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

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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 use 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the context and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this without encoding the data with one of the techniques listed below.'''
</script>

==== HTML entity encoding ====

Built-in to every framework.

Consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= html_escape(data.to_json) %>
</script>

// external js file
var dataElement = document.getElementById('init_data');
var jsonText = dataElement.textContent || dataElement.innerText // unescapes the content of the span
var initData = JSON.parse(jsonText);

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

==== JSON entity encoding ====

An alternative to the technique above is JSON encoding the data. The rules for JSON encoding can be found in the [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Output_Encoding_Rules_Summary Output Encoding Rules Summary].

== RULE #4 - CSS Escape And Strictly Validate 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</span> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 will 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 and validation 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! 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, especially Javascript links. URL's should then 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. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer''' - https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

'''Other libraries that provide HTML Sanitization include:'''<br/>

PHP Html Purifier - http://htmlpurifier.org/<br/>
JavaScript/Node.JS Bleach - https://github.com/ecto/bleach<br/>
Python Bleach - https://pypi.python.org/pypi/bleach

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-09-15T21:18:33Z

Nmatatal: /* RULE #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse */

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

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

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

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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 use 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the context and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this without encoding the data with one of the techniques listed below.'''
</script>

==== HTML entity encoding ====

Built-in to every framework.

Consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= html_escape(data.to_json) %>
</script>

<script>
var dataElement = document.getElementById('init_data');
var jsonText = dataElement.textContent || dataElement.innerText // unescapes the content of the span
var initData = JSON.parse(jsonText);
</script>

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

==== JSON entity encoding ====

An alternative to the technique above is JSON encoding the data. The rules for JSON encoding can be found in the [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Output_Encoding_Rules_Summary Output Encoding Rules Summary].

== RULE #4 - CSS Escape And Strictly Validate 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</span> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 will 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 and validation 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! 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, especially Javascript links. URL's should then 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. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer''' - https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

'''Other libraries that provide HTML Sanitization include:'''<br/>

PHP Html Purifier - http://htmlpurifier.org/<br/>
JavaScript/Node.JS Bleach - https://github.com/ecto/bleach<br/>
Python Bleach - https://pypi.python.org/pypi/bleach

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Projects/OWASP Framework Matrix

2013-09-15T17:09:21Z

Nmatatal:

Note: This page is a template part of the [https://www.owasp.org/index.php/OWASP_Framework_Security_Project OWASP Framework Security Project]. Edit this page [https://www.owasp.org/index.php?title=Projects/OWASP_Framework_Matrix&action=edit here]

{| class="wikitable sortable" border="1"
| align="center" style="background:#f0f0f0;"|'''Framework'''
| align="center" style="background:#f0f0f0;"|'''Security Control'''
| align="center" style="background:#f0f0f0;"|'''Present / Not Present'''
| align="center" style="background:#f0f0f0;"|'''Enabled By Default'''
| align="center" style="background:#f0f0f0;"|'''Link to more info'''
| align="center" style="background:#f0f0f0;"|'''Under Development?'''
| align="center" style="background:#f0f0f0;"|'''Contact Point'''
|-
| || Automatic escaping in templates || || || || ||
|-
| || Prepared statements (including ORM) || || || || ||
|-
| Django||x-frame-options||Present||No||[https://docs.djangoproject.com/en/dev/ref/clickjacking/#setting-x-frame-options-for-all-responses link]||n/a||n/a
|-
| Django||SECURE Cookie Flag||Present||No||[https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SESSION_COOKIE_SECURE link]||n/a||n/a
|-
| Django||HTTPOnly Cookie Flag||?||?||[# link]||?||?
|-
| Rails||Automatic CSRF protection||Present||Yes||[http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf link]||n/a||n/a
|-
| || Offsite redirect detection/prevention || || || || ||
|-
| || javascript: URIs in links || || || || ||
|-
| || Error suppression in production environments || || || || ||
|-
| || Mask sensitive data in logs || || || || ||
|-
| || Encryption abstractions || || || || ||
|-
| || Strict transport security || || || || ||
|-
| || Content security policy || || || || ||
|}

Projects/OWASP Framework Matrix

2013-09-15T17:08:57Z

Nmatatal:

Note: This page is a template part of the [https://www.owasp.org/index.php/OWASP_Framework_Security_Project OWASP Framework Security Project]. Edit this page [https://www.owasp.org/index.php?title=Projects/OWASP_Framework_Matrix&action=edit here]

{| class="wikitable sortable" border="1"
| align="center" style="background:#f0f0f0;"|'''Framework'''
| align="center" style="background:#f0f0f0;"|'''Security Control'''
| align="center" style="background:#f0f0f0;"|'''Present / Not Present'''
| align="center" style="background:#f0f0f0;"|'''Enabled By Default'''
| align="center" style="background:#f0f0f0;"|'''Link to more info'''
| align="center" style="background:#f0f0f0;"|'''Under Development?'''
| align="center" style="background:#f0f0f0;"|'''Contact Point'''
|-
| || Automatic escaping in templates || || || || ||
|-
| || Prepared statements (including ORM) || || || || ||
|-
| Django||x-frame-options||Present||No||[https://docs.djangoproject.com/en/dev/ref/clickjacking/#setting-x-frame-options-for-all-responses link]||n/a||n/a
|-
| Django||SECURE Cookie Flag||Present||No||[https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SESSION_COOKIE_SECURE link]||n/a||n/a
|-
| Django||HTTPOnly Cookie Flag||?||?||[# link]||?||?
|-
| Rails||Automatic CSRF protection||Present||Yes||[http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf link]||n/a||n/a
|-
| || Offsite redirect detection/prevention || || || || ||
|-
| || javascript: URIs in links || || || || ||
|-
| || Error suppression in production environments || || || || ||
|-
| || Mask sensitive data in logs || || || || ||
|-
| || Encryption abstractions || || || || ||
|-
| || Prepared statement support || || || || ||
|-
| || Strict transport security || || || || ||
|-
| || Content security policy || || || || ||
|}

Projects/OWASP Framework Matrix

2013-09-12T04:47:33Z

Nmatatal:

Note: This page is a template part of the [https://www.owasp.org/index.php/OWASP_Framework_Security_Project OWASP Framework Security Project]. Edit this page [https://www.owasp.org/index.php?title=Projects/OWASP_Framework_Matrix&action=edit here]

{| class="wikitable sortable" border="1"
| align="center" style="background:#f0f0f0;"|'''Framework'''
| align="center" style="background:#f0f0f0;"|'''Security Control'''
| align="center" style="background:#f0f0f0;"|'''Present / Not Present'''
| align="center" style="background:#f0f0f0;"|'''Enabled By Default'''
| align="center" style="background:#f0f0f0;"|'''Link to more info'''
| align="center" style="background:#f0f0f0;"|'''Under Development?'''
| align="center" style="background:#f0f0f0;"|'''Contact Point'''
|-
| Django||x-frame-options||Present||No||[https://docs.djangoproject.com/en/dev/ref/clickjacking/#setting-x-frame-options-for-all-responses link]||n/a||n/a
|-
| Django||SECURE Cookie Flag||Present||No||[https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SESSION_COOKIE_SECURE link]||n/a||n/a
|-
| Django||HTTPOnly Cookie Flag||?||?||[# link]||?||?
|-
| Rails||Automatic CSRF protection||Present||Yes||[http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf link]||n/a||n/a
|}

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-08-29T19:29:49Z

Nmatatal: /* RULE #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse */

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

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

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

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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 use 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the context and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this.'''
</script>

Instead, consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= data.to_json %> <-- data is HTML escaped, or at least json entity escaped -->
</script>

<script>
var dataElement = document.getElementById('init_data');
var jsonText = dataElement.textContent || dataElement.innerText // unescapes the content of the span
var initData = JSON.parse(jsonText);
</script>

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

== RULE #4 - CSS Escape And Strictly Validate 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</span> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 will 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 and validation 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! 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, especially Javascript links. URL's should then 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. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer''' - https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

'''Other libraries that provide HTML Sanitization include:'''<br/>

PHP Html Purifier - http://htmlpurifier.org/<br/>
JavaScript/Node.JS Bleach - https://github.com/ecto/bleach<br/>
Python Bleach - https://pypi.python.org/pypi/bleach

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Orange County

2013-06-14T23:13:20Z

Nmatatal:

{{Chapter Template|chaptername=Orange County|extra=Lead by [mailto:ron.perris@whitehatsec.com Ron Perris]

|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Orange_County|emailarchives=http://lists.owasp.org/pipermail/owasp-Orange_County}}
The chapter leader is [mailto:ron.perris@whitehatsec.com Ron Perris].

== We are on '''Meetup'''! ==
Join us and RSVP to our meeting there <br>
http://www.meetup.com/OWASP-OC

== Sponsor ==
HP Enterprise Security

==Future Meetings ==

==== May 21th 2013====

'''Topic: Top Ten Web Defenses'''<br>
'''Presenter: Jim Manico<br>'''
'''Summary:''' <br>
Title: Top Ten Web Defenses

We cannot “firewall” or “patch” our way to secure websites. In the past, security professionals thought firewalls, Secure Sockets Layer (SSL), patching, and privacy policies were enough. Today, however, these methods are outdated and ineffective, as attacks on prominent, well-protected websites are occurring every day. Citigroup, PBS, Sega, Nintendo, Gawker, AT&T, the CIA, the US Senate, NASA, Nasdaq, the NYSE, Zynga, and thousands of others have something in common – all have had websites compromised in the last year. No company or industry is immune. Programmers need to learn to build websites differently. This talk will review the top coding techniques developers need to master in order to build a low-risk, high-security web application.

BIO: Jim Manico is the VP of Security Architecture for WhiteHat
Security, a web security firm. He authors and delivers developer
security awareness training for WhiteHat Security and has a background as a software developer and architect. Jim is also a global board member for the OWASP foundation. He manages and participates in several OWASP projects, including the OWASP cheat sheet series and the OWASP podcast series.<br>

Where: Crescent Solutions
17871 Mitchell N # 100, Irvine, CA<br>

Schedule:<br>
6:00 - 6:30: Introduction and networking<br>
6:30 - 7:30: Presentation
<br>

'''RSVP here http://www.meetup.com/OWASP-OC'''
<br><br>

==== July 18th 2013====

'''Topic: TBD'''<br>
'''Presenter:TBD<br>'''
'''Summary:''' <br>
Where: Crescent Solutions
17871 Mitchell N # 100, Irvine, CA<br>

Schedule:<br>
6:00 - 6:30: Introduction and networking<br>
6:30 - 7:30: Presentation
<br>

'''RSVP here http://www.meetup.com/OWASP-OC'''
<br><br>

===Previous Meetings===

==== January 17th 2013====

'''Topic: Putting your robots to work: security automation at Twitter'''<br>
'''Presenter: Neil Matatall and Justin Collins<br>'''
'''Summary:''' <br>
"With daily code releases and a growing infrastructure, manually reviewing code changes and protecting against security regressions quickly becomes impractical. Even when using security tools, whether commercial or open source, the difficult work of integrating them into the development and security cycles remains. We need to use an automated approach to push these tools as close to when the code is written as possible, allowing us to prevent potential vulnerabilities before they are shipped. We worked with development, operations, and release teams to create a targeted suite of tools focused on specific security concerns that are effective and don’t introduce any noise. This presentation will give an overview of what we’ve done over the past year, what we have learned along the way, and will provide advice for anyone else going down this road as well as the philosophy that guided us along the way."<br>

Where: Crescent Solutions
17871 Mitchell N # 100, Irvine, CA<br>

Schedule:<br>
6:00 - 6:30: Introduction and networking<br>
6:30 - 7:30: Presentation
<br>

'''RSVP here http://www.meetup.com/OWASP-OC'''
<br><br>

==== OWASP LA Event: Security Summit: April 25, 2012, 3:00PM - 8PM ====

(Note different time and location)<br>

'''Jerry Hoff VP, Static Code Analysis Division at WhiteHat Security, will be speaking about Webgoat. Shakeel Tufail, Federal Practice Director for HP Enterprise Security Solutions, will be speaking on securing software. Noa Bar Yosef, Senior Security Strategist at Imperva, will be speaking on "De-Anonymizing Anonymous". A concluding panel, moderated by Richard Greenberg, Information Security Officer for LA County Public Health, will have the speakers joined by Adnan Masood, a Software Engineer and Architect.

==== March 28th 2012 7PM ====

When: March 28th 7pm

Where: Irvine - 5151 California Ave, Irvine, CA 92617

Loose Schedule:
7:00 - 7:30: Introduction and networking
7:30 - 8:30: Presentation

===="WebGoat.NET"====

Abstract:
Jerry Hoff, the project leader of the OWASP Appsec Tutorial Series, and VP of the Static Code Analysis Division at WhiteHat Security, will be discussing his newest OWASP project, WebGoat.NET. For many years, the Java version of WebGoat has been available as a fantastic tool for learning application security from the Java perspective. Jerry has now created a parallel tool for ASP.NET developers to learn about application security. Jerry will be discussing how this tool can be used in a learning environment, and other issues related to application security education.

====Speaker Bio:====
Jerry Hoff is vice president of the Static Code Analysis division at WhiteHat Security. In this role, he oversees the development of WhiteHats cloud-based static application security testing (SAST) service. Prior to WhiteHat, Mr. Hoff was co-founder and managing partner ofInfrared Security, a leading application security professional services firm. Mr. Hoff is an experienced application security consultant with years of professional development and training delivery. He is also the lead of the OWASP AppSec Tutorial Series.

==== September 14th 2011 7PM ====

When: Wednesday September 17th 7pm
Where: TBD (Irvine)
http://www.meetup.com/ocrails/events/30043551/

Loose Schedule:
7:00 - 7:30: Introduction and networking
7:30 - 8:00: Brakeman with Justin Collins
8:00 - 8:15: Lightning Rounds
8:15 - 8:30: Brakeman Demo

Brakeman with Justin Collins:
While the popular Ruby on Rails web framework provides built-in protection
for many security vulnerabilities, it is still possible to misuse these
features or introduce other vulnerabilities to an application. Brakeman is a static code analysis tool designed specifically to find vulnerabilities and configuration issues in Ruby on Rails applications. Since it works at the source code level, Brakeman can be used at any point in development without the need for deploying the full application stack. To make it even simpler,
Brakeman can be integrated with Hudson/Jenkins to provide automatic monitoring of Brakeman results as code is committed. This talk will discuss how to use Brakeman and how it can help you create safer Rails applications.

Lightning Rounds:

Neil Matatall: Friendly_id + ancsetry

Drew Deponte: Guard, spork, BDD

==== June 29th 2011 7PM ====

[[http://owaspoc.eventbrite.com/ Registration Link]]

'''When''': Wednesday june 29th, 2011 7pm

'''Where: HireRight Offices'''
5151 California Avenue
Irvine, CA 92617

'''Pizza and refreshments will be provided by the sponsors of this meeting.
'''

===== Meeting Sponsors =====

Food and refreshments:
[[File:AppSecDC2010-Sponsor-trustwave.gif]]

Meeting location:
[[File:Hireright.png]]

===== Presentation Topic: =====
Featuring analysis of more than 220 data breach investigations and more than 2,300 penetration tests conducted by Trustwave's SpiderLabs, the Global Security Report 2011 identifies the top vulnerabilities business encountered in 2010 as well as a list of strategic initiatives to help your business improve its overall security.

The data gathered from these engagements is substantial and comprehensive. This presentation will be a summary of the results of the analysis of the data gathered during 2010. The results will be presented both technical and business impact analysis.

===== Charles Henderson, Director of Application Security Services of SpiderLabs at Trustwave =====

Henderson began his career in computer security in 1993, specializing in penetration testing as well as security and vulnerability research. As Director of Application Security Services at SpiderLabs, he leads the team responsible for Application Penetration Testing, Code Review, Secure Development Training, and other elite application security consulting services.

Prior to joining SpiderLabs, Henderson ran his own boutique application
security testing firm. Henderson’s firm provided offensive security services to a wide variety of clients in the United States and Europe.

Henderson speaks frequently at major industry events and conferences, including BlackHat, DEF CON, AppSec US, AppSec EU, SOURCE, and the International Association of Financial Crime Investigators convention.

====January 28th, 2011====

'''Registration link: [https://www.regonline.com/owasp_oc_jan]'''

'''Time:''' 1 PM - 5PM

'''Location: '''

[http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=5151+California+Ave&sll=33.621597,-117.740797&sspn=0.010489,0.019011&ie=UTF8&hq=&hnear=5151+California+Ave,+Irvine,+Orange,+California+92617&z=16&iwloc=A Hireright]

5151 California Ave

Irvine, California 92617

United States.

'''Topics:''' Threat Modeling, Application Security

'''Food:''' Provided

Speakers:

'''Samy Kamkar'''

Online Privacy and the Evercookie

Bio:

Samy Kamkar has lectured on computer security issues in over a dozen
countries, and his work has been featured on the front page of the New
York Times. As a grey-hat hacker, he makes and breaks computer
security for tech companies. In addition to his independent security
research, he co-founded Fonality, an IP PBX company.

'''Jim Manico'''

Back to Basics: Defensive Coding Principles for Web Development 101

The application security community is in deep need of prescriptive
solutions for developers. This talk will review the world of Web
Application Security from a "builder" point of view, focusing on
critical controls that all developers must master if they wish to build
low risk web applications today.

Bio:

Jim Manico is the chair of the OWASP Connections committee where he
focuses on producing and hosting the OWASP Podcast. Jim also is a
co-manager of the OWASP ESAPI Open Source project. Professionally, Jim
is an independent application security architect specializing in the
construction of low-risk web applications. Jim is also an application
security educator and assessment specialist.

'''Edward Bonver'''
Talk Title:

Threat Modeling at Symantec
[[File:OWASP-WWW-2011-Edward-Bonver-Threat-Modelint-at-Symantec.pptx]]

Abstract:

Threat Modeling is one of the most important security activities that a development/QA team needs to perform as part of a Security Development Lifecycle. This activity allows the team to build a complete security profile of the system being built. Threat Modeling is not always easy to get going for a team that has little or no security experience. In this presentation we’ll take a look at why Threat Modeling is so important; we’ll explore the process behind it, and how the process is being implemented and followed across Symantec.

Bio:

Edward Bonver is a principal software engineer on the product security team under the Office of the CTO at Symantec Corporation. In this capacity, Edward is responsible for working with software developers and quality assurance (QA) professionals across Symantec to continuously enhance the company’s software security practices through the adoption of methodologies, procedures and tools for secure coding and security testing. Within Symantec, Edward teaches secure coding and security testing classes for Symantec engineers, and also leads the company’s QA Security Task Force, which he founded. Prior to joining Symantec, Edward held software engineering and QA roles at Digital Equipment Corporation, Nbase and Zuma Networks.

Edward is a Certified Information Systems Security Professional (CISSP) and a Certified Secure Software Lifecycle Professional (CSSLP). He holds a master’s degree in computer science from California State University, Northridge, and a bachelor’s degree in computer science from Rochester Institute of Technology. Edward is a Ph.D. student at NOVA Southeastern University.

====Thursday, January 21st 2010====

Time: 7:30
Location: We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building. http://www.oit.uci.edu/computing/labs/training.html Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdfBD

For those who would like to avoid paying for parking, you can park in the University Center and take the campus shuttle: http://www.shuttle.uci.edu/maincampus/index.php

The shuttle runs until 10:45PM. The shuttle costs $1 per ride, but fees are rarely collected ;)

Title: Do VLANs allow for good application security?

Virtual Local Area Networks (VLANs) are not a new concept, and can help
any organization better control network access. I will present some of
the previous issues identified, what was the root cause, and how these
have been fixed in current technology. In addition we will talk about
how this can help to enhance security in your environment, and what
controls must be in place in order to implement such an environment. We
will also touch on how this can complicate your application environment,
but improve overall security.

I will touch on the controls that need to be reviewed and audited when
working with VMware, VLANs, and web applications, to ensure that these
networks are secure, and what to look for to potentially pass audit
criteria. I will also talk about where and how these controls have been
implemented in order to protect thousands of users while accessing one
of the most hostile networks in the world.

David M. N. Bryan
Senior Security Consultant

David has over 9+ years of computer security experience including,
consulting, engineering and administration. He has performed security
assessment projects for health care, nuclear, manufacturing,
pharmaceutical, banking and educational sectors. As an active
participant in the information security community, he volunteers at
DEFCON where he designs and implements the Firewall and Network for what
is said to be the most hostile network environment in the world.

He is also an active participant in the local Minneapolis security
groups both as a board member of OWASP MSP and DC612. His roots and
experience come from working for a large enterprise banks, designing and
managing enterprise security systems. In the more recent years he has
been working as an Information Security Consultant to review the
security and architecture of information computing environments.

====Thursday December 17th 2009====

7:30 PM, UC Irvine Campus, Room AIRB 1020

We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building.
http://www.oit.uci.edu/computing/labs/training.html
Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf

'''Abstract'''

'''Title: Pulling the Plug: Security Risks in the Next Generation of Offline Web Applications'''

As the line between desktop and web applications becomes increasingly blurry in a web 2.0 world, browser functionality is being pushed well beyond what it was originally intended for. Persistent client side storage has become a requirement for web applications if they are to be available both online and off. This need is being filled by a variety of technologies such as [http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage Gears (formerly Google Gears) and the Database Storage] functionality included in the emerging [http://dev.w3.org/html5/spec/Overview.html HTML 5 specification]. While all such technologies offer great promise, it is clear that the vast majority of developers simply do not understand their security implications.

Researching a variety of currently deployed implementations of these technologies has revealed a broad scope of vulnerabilities with frightening implications. Now attackers can target victims not just once, but every time they visit a site as the victim now carries and stores the attack with them. Imagine a scenario whereby updated confidential information is forwarded to an attacker every time a victim interacts with a given we application. The attacker no longer needs to worry about timing their attacks to ensure that the victim is authenticated as the victim attacks himself! Limited storage? Cookies that expire? Not a problem when entire databases are accessible with virtually unlimited storage and an infinite lifespan. Think these attacks are theoretical? Think again. In this talk we dive into these technologies and break down the risk posed by them when not properly understood. We will then detail a variety of real-world vulnerabilities that have been uncovered, including a new class of cross-site scripting and client-side SQL injection.

'''Bio'''

'''Michael Sutton'''
'''Vice President, Security Research – Zscaler'''

Michael Sutton has spent more than a decade in the security industry conducting leading-edge research, building teams of world-class researchers and educating others on a variety of security topics. As VP of Security Research, Michael heads Zscaler Labs, the research and development arm of the company. Zscaler Labs is responsible for researching emerging topics in web security and developing innovative security controls, which leverage the Zscaler in-the-cloud model. The team is comprised of researchers with a wealth of experience in the security industry.

Prior to joining Zscaler, Michael was the Security Evangelist for SPI Dynamics where, as an industry expert, he was responsible for researching, publishing and presenting on various security issues. In 2007, SPI Dynamics was acquired by Hewlett-Packard. Previously, Michael was a Research Director at iDefense where he led iDefense Labs, a team responsible for discovering and researching security vulnerabilities in a variety of technologies. iDefense was acquired by VeriSign in 2005. Michael is a frequent speaker at major information security conferences; he is regularly quoted by the media on various information security topics, has authored numerous articles and is the co-author of Fuzzing: Brute Force Vulnerability Discovery, an Addison-Wesley publication.

====Thursday, November 19th 2009====

When: November 19th 2009, 7:30PM
Where: Gina's Pizza, Irvine
Topics: Facebook privacy, web application firewalls, penetration testing, the reluctance for hackers to execute attacks, and random new technology. Announced OWASP OC/LAs intention to submit a proposal for AppSec 2010.

====Wednesday, October 14th 2009====

Separate meetings will be held for OWASP OC and OWASP@UCI (student group).

When: Wednesday 10/14 7:30PM
Where: Steelhead Brewery
Topics: News, Ideas, Chit-chat

This is a restaurant/bar with plenty of seating, but room for a projector is out of the question so this would be an informal round table discussion.

I have a presentation I'm working on regarding WAFs and Vulnerability Assessment Tools. If it pleases the group, I'd love to go over the presentation and discuss everyone's experiences. Also, it's a great way to get feedback :)

Neil

I'm open to suggestions of any kind: location, time, topics, etc

====Thursday, September 17th, 2009 7:30PM ====
'''Location:''' UC Irvine
Building: Calit2 building,building number 325 in quadrant H8 on the [http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf UC Irvine Map]
Room: 3008

Parking will be $7.
Please park in the [http://maps.google.com/maps?li=d&hl=en&f=d&iwstate1=dir:to&daddr=Parking+Structure+for+CalIT2%4033.643082,+-117.837593&geocode=CSJ9b4xJxrzxFUpaAQId5_D5-A&iwloc=1&dq=calit2,+uc+irvine,+ca&cid=33643082,-117837593,16505793731713499531&ei=v3bvSabfO6LejAOR2pjgAQ Anteater Parking Structure]

I can only unofficially say that if you park in the nearby shopping centers and walk, you may be able to park for free.

* <b>The Rise of Threat Analysis and the Fall of Compliance, Policies, and Standards in mitigating Web Application Security Risks</b>

====Apr 30, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Our fourth OC OWASP meeting will be an informal, roundtable discussion of current application security issues. Feel free to bring some ideas, code, slides, etc to contribute to the discussion. Hope to see everyone there!

====Feb 19, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Come talk application security at the third OWASP OC meeting. We'll discuss current application security topics and chapter issues over pizza. We have a room booked for 15-20 people so we'll be able to rant without disturbing the patrons :) See you there! [https://www.owasp.org/images/5/58/Cloud_Computing_Security.pdf Presentation Slides]

====Dec 17, 2008 6PM - 9PM====
Microsoft Campus
Room MPR1, 3 Park Plaza, Suite 1600, Irvine, CA, 92614

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=microsoft,+Irvine,+CA,+92614&sll=33.678479,-117.838368&sspn=0.009892,0.022745&g=3+Park+Plaza,+Irvine,+CA,+92614&ie=UTF8&ei=sCFJSfKPEo3UNc2ZmCc&cd=1&cid=33728042,-117783305,17507068988286890825&li=lmd&ll=33.731835,-117.78142&spn=0.039545,0.090981&z=14&iwloc=A Google Map]

This meeting will be a roundtable discussion of application security news, plus a few OWASP-themed challenges with prizes. Pizza will be provided and we'll head to the Yard House after the meeting.

====Aug 27, 2008, 7 PM - 9 PM====
Penny Saver

603 Valencia, Brea, CA 92822

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=603+valencia,+Brea,+CA+92822&sll=33.911348,-117.851629&sspn=0.009865,0.022745&ie=UTF8&ll=33.909478,-117.852917&spn=0.009866,0.022745&z=16&iwloc=addr Google Map]

Come meet up with web security professionals, have some pizza, and offer your thoughts for the direction of the OC chapter at our inaugural meeting! We are looking for speakers and venue sponsors for the next meeting. If you are interested, please contact the chapter leaders. Everyone is welcome to join us at our chapter meetings.

[[Category:OWASP Chapter]]

= Orange County OWASP Board Members =

*<b>Orange County President</b> [mailto:ron.perris@whitehatsec.com Ron Perris]
*<b>Orange County Vice-President</b> Jerry Craft, [mailto:shong.chong@owasp.org Shong Chong]
*<b>Orange County Treasurer:</b> [mailto: TBD]
*<b>Orange County Recording Secretary:</b> [mailto: TBD]
*<b>Orange County Board Member</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]

[[Category:California]]

Ruby on Rails Cheatsheet

2013-03-29T16:47:59Z

Nmatatal: /* Redirects and Forwards */

DRAFT CHEAT SHEET - WORK IN PROGRESS

= Introduction =

This ''Cheatsheet'' intends to provide quick basic Ruby on Rails security tips for developers. It complements, augments or emphasizes points brought up in the [http://guides.rubyonrails.org/security.html rails security guide] from rails core.

The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.

= Items =
== Command Injection ==

Ruby offers a function called “eval” which will dynamically build new Ruby code based on Strings. It also has a number of ways to call system commands.

eval("ruby code here")
System("os command here")
`ls -al /` (backticks contain os command)
Kernel.exec("os command here")

While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application. Usually, its just a bad idea. If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible. The Ruby Security Reviewer's Guide has a [http://code.google.com/p/ruby-security/wiki/Guide#Good_ol%27_shell_injection section on injection] and there are a number of OWASP references for it, starting at the top: [https://www.owasp.org/index.php/Command_Injection Command Injection].

== SQL Injection ==

Ruby on Rails is often used with an ORM called ActiveRecord, though it is flexible and can be used with other data sources. Typically very simple Rails applications use methods on the Rails models to query data. Many use cases protect for SQL Injection out of the box. However, it is possible to write code that allows for SQL Injection.

Here is an example (Rails 2.X style):

@projects = Project.find(:all, :conditions => “name like #{params[:name]}”)

A Rails 3.X example:

name = params[:name]
@projects = Project.where(“name like ‘“ + name + “‘“);

In both of these cases, the statement is injectable because the name parameter is not escaped.

Here is the idiom for building this kind of statement:

@projects = Project.find(:all, :conditions => [ “name like ?”, “#{params[:name]}”] )

An AREL based solution:

@projects = Project.where("name like ?", "%#{params[:name]}%")

Use caution not to build SQL statements based on user controlled input. A list of more realistic and detailed examples is here: [http://rails-sqli.org rails-sqli.org]. OWASP has extensive information about [https://www.owasp.org/index.php/SQL_Injection SQL Injection].

== Cross-site Scripting (XSS) ==

By default, in Rails 3.0 protection against XSS comes as the default behavior. When string data is shown in views, it is escaped prior to being sent back to the browser. This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing. In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).

<%= raw @product.name %>
<%= @product.name.html_safe %> These are examples of how NOT to do it!
<%= content_tag @product.name %>

Unfortunately, any field that uses raw like this will be a potential XSS target. Note that there are also widespread misunderstandings about html_safe. [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail. Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.

If you must accept HTML content from users, consider a markup language for rich text in an application (Examples include: markdown and textile) and disallow HTML tags. This helps ensures that the input accepted doesn’t include HTML content that could be malicious. If you cannot restrict your users from entering HTML, consider implementing content security policy to disallow the execution of any javascript. And finally, consider using the #sanitize method that let's you whitelist allowed tags. Be careful, this method has been shown to be flawed numerous times and will never be a complete solution.

An often overlooked XSS attack vector is the href value of a link:

<%= link_to “Personal Website”, @user.website %>

If @user.website contains a link that starts with “javascript:”, the content will execute when a user clicks the generated link:

<a href=”javascript:alert(‘Haxored’)”>Personal Website</a>

OWASP provides more general information about XSS in a top level page: [https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29 OWASP Cross Site Scripting].

== Sessions ==

By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.

The best practice is to use a database based session, which thankfully is very easy with Rails:

Project::Application.config.session_store :active_record_store

There is an [https://www.owasp.org/index.php/Session_Management_Cheat_Sheet OWASP Session Management Cheat Sheet].

== Authentication ==

Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication. To enable authentication with Devise, one simply has to put the following in a controller:

class ProjectController < ApplicationController
before_filter :authenticate_user

As with other methods, this supports exceptions. Note that by default Devise only requires 6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb

config.password_length = 8..128

There are several possible ways to enforce complexity. One is to put a Validator in the user model.

validate :password_complexity
def password_complexity
if password.present? and not password.match(/\A(?=.*[a-z])(?=.*[A-Z])(?=.*\d).+\z/)
errors.add :password, "must include at least one lowercase letter, one uppercase letter, and one digit"
end
end

There is an [https://www.owasp.org/index.php/Authentication_Cheat_Sheet OWASP Authentication Cheat Sheet].

== Insecure Direct Object Reference or Forceful Browsing ==

By default, Ruby on Rails apps use a RESTful uri structure. That means that paths are often intuitive and guessable. To protect against a user trying to access or modify data that belongs to another user, it is important to specifically control actions. Out of the gate on a vanilla Rails application, there is no such built in protection. It is possible to do this by hand at the controller level.

It is also possible, and probably recommended, to consider resource-based access control libraries such as [https://github.com/ryanb/cancan cancan] to do this. This ensures that all operations on a database object are authorized by the business logic of the application.

More general information about this class of vulnerability is in the [https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References OWASP Top 10 Page].

== CSRF (Cross Site Request Forgery) ==

Ruby on Rails has specific, built in support for CSRF tokens. To enable it, or ensure that it is enabled, find the base ApplicationController and look for a directive such as the following:

class ApplicationController < ActionController::Base
protect_from_forgery

Note that the syntax for this type of control includes a way to add exceptions. Exceptions may be useful for API’s or other reasons - but should be reviewed and consciously included. In the example below, the Rails ProjectController will not provide CSRF protection for the show method.

class ProjectController < ApplicationController
protect_from_forgery :except => :show

Also note that by default Rails does not provide CSRF protection for any HTTP GET request.

There is a top level OWASP page for [https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29 CSRF].

== Mass Assignment and Strong Parameters ==

Although the major issue with Mass Assignment has been fixed by default in base Rails specifically when generating new projects, it still applies to older and upgraded projects so it is important to understand the issue and to ensure that only attributes that are intended to be modifiable are exposed.

When working with a model, the attributes on the model will not be accessible to forms being posted unless a programmer explicitly indicates that:

class Project < ActiveRecord::Base
attr_accessible :name, :admin
end

With the admin attribute accessible based on the example above, the following could work:

curl -d “project[name]=triage&project[admin]=1” host:port/projects

Review accessible attributes to ensure that they should be accessible. If you are working in Rails < 3.2.3 you should ensure that your attributes are whitelisted with the following:

config.active_record.whitelist_attributes = true

In Rails 4.0 strong parameters will be the recommended approach for handling attribute visibility. It is also possible to use the strong_parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications.

== Redirects and Forwards ==

Web applications often require the ability to dynamically redirect users based on client-supplied data. To clarify, dynamic redirection usually entails the client including a URL in a parameter within a request to the application. Once received by the application, the user is redirected to the URL specified in the request. For example:

http://www.example.com/redirect?url=http://www.example_commerce_site.com/checkout

The above request would redirect the user to http://www.example.com/checkout. The security concern associated with this functionality is leveraging an organization’s trusted brand to phish users and trick them into visiting a malicious site, in our example, “badhacker.com”. Example:

http://www.example.com/redirect?url=http://badhacker.com

The most basic, but restrictive protection is to use the :only_path option. Setting this to true will essentially strip out any host information.

redirect_to params[:url], :only_path => true

If matching user input against a list of approved sites or TLDs against regular expression is a must, it makes sense to leverage a library such as URI.parse() to obtain the host and then take the host value and match it against regular expression patterns. Those regular expressions must, at a minimum, have anchors or there is a greater chance of an attacker bypassing the validation routine.

Example:

require ‘uri’
host = URI.parse(“#{params[:url]}”).host
validation_routine(host) if host # no validation is needed if we are just using a path, as this will lead to your applications
def validation_routine(host)
# Validation routine where we use \A and \z as anchors *not* ^ and $
# you could also check the host value against a whitelist
end

The obvious fix for this type of vulnerability is to restrict to specific Top-Level Domains (TLDs), statically define specific sites, or map a key to it’s value. Example:

ACCEPTABLE_URLS = {
‘our_app_1’ => “https://www.example_commerce_site.com/checkout”,
‘our_app_2’ => “https://www.example_user_site.com/change_settings”
}

http://www.example.com/redirect?url=our_app_1

def redirect
url = ACCEPTABLE_URLS[“#{params[:url]}”]
redirect_to url if url
end

There is a more general OWASP resource about [https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet Unvalidated Redirects and Forwards].

== Dynamic Render Paths ==

In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.

Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.

== Cross Origin Resource Sharing ==

Occasionally, a need arises to share resources with another domain. For example, a file-upload function that sends data via an AJAX request to another domain. In these cases, the same-origin rules followed by web browsers must be bent. Modern browsers, in compliance with HTML5 standards, will allow this to occur but in order to do this; a couple precautions must be taken.

When using a nonstandard HTTP construct, such as an atypical Content-Type header, for example, the following applies:

The receiving site should whitelist only those domains allowed to make such requests as well as set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain. Next, a second request, a POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.

When standard HTTP constructs are used:

The request is sent and the browser, upon receiving a response, inspects the response headers in order to determine if the response can and should be processed.

Note: Do NOT do use the wildcard in the access control header as it allows communication with any site.
Access-Control-Allow-Origin: * (Bad example)

Whitelist in Rails:

Gemfile
gem 'rack-cors', :require => 'rack/cors'

config/application.rb
module Sample
class Application < Rails::Application
config.middleware.use Rack::Cors do
allow do
origins 'someserver.example.com'
resource %r{/users/\d+.json},
:headers => ['Origin', 'Accept', 'Content-Type'],
:methods => [:post, :get]
end
end
end
end

== Security-related headers ==

To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter).

response.headers['X-header-name'] = 'value'

'''Rails 4''' provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases. Note: this does not account for content security policy.

ActionDispatch::Response.default_headers = {
'X-Frame-Options' => 'DENY',
'X-Content-Type-Options' => 'nosniff',
'X-XSS-Protection' => '1;'
}

Strict transport security is a special case, it is set in an environment file (e.g. production.rb)

config.force_ssl = true

For those not on the edge, there is a library ([https://github.com/twitter/secureheaders secure_headers]) for the same behavior with content security policy abstraction provided. It will automatically apply logic based on the user agent to produce a concise set of headers.

== Business Logic Bugs ==

Any application in any technology can contain business logic errors that result in security bugs. Business logic bugs are difficult to impossible to detect using automated tools. The best ways to prevent business logic security bugs are to do code review, pair program and write unit tests.

== Attack Surface ==

Generally speaking, Rails avoids open redirect and path traversal types of vulnerabilities because of its /config/routes.rb file which dictates what URL’s should be accessible and handled by which controllers. The routes file is a great place to look when thinking about the scope of the attack surface. An example might be as follows:

match ':controller(/:action(/:id(.:format)))' # this is an example of what NOT to do

In this case, this route allows any public method on any controller to be called as an action. As a developer, you want to make sure that users can only reach the controller methods intended and in the way intended.

== Sensitive Files ==

Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.

/config/database.yml - May contain production credentials.
/config/initializers/secret_token.rb - Contains a secret used to hash session cookie.
/db/seeds.rb - May contain seed data including bootstrap admin user.
/db/development.sqlite3 - May contain real data.

== Encryption ==

Rails uses OS encryption. Generally speaking, it is always a bad idea to write your own encryption.

Devise by default uses bcrypt for password hashing, which is an appropriate solution. Typically, the following config causes the 10 stretches for production: /config/initializers/devise.rb

config.stretches = Rails.env.test? ? 1 : 10

= Updating Rails and Having a Process for Updating Dependencies =

In early 2013, a number of critical vulnerabilities were identified in the Rails Framework. Organizations that had fallen behind current versions had more trouble updating and harder decisions along the way, including patching the source code for the framework itself.

An additional concern with Ruby applications in general is that most libraries (gems) are not signed by their authors. It is literally impossible to build a Rails based project with libraries that come from trusted sources. One good practice might be to audit the gems you are using.

In general, it is important to have a process for updating dependencies. An example process might define three mechanisms for triggering an update of response:
* Every month/quarter dependencies in general are updated.
* Every week important security vulnerabilities are taken into account and potentially trigger an update.
* In EXCEPTIONAL conditions, emergency updates may need to be applied.

= Tools =

Use [http://brakemanscanner.org/ brakeman], an open source code analysis tool for Rails applications, to identify many potential issues. It will not necessarily produce comprehensive security findings, but it can find easily exposed issues. A great way to see potential issues in Rails is to review the brakeman documentation of warning types.

There are emerging tools that can be used to track security issues in dependency sets, like https://gemcanary.com/ and https://gemnasium.com/.

Another area of tooling is the security testing tool [http://gauntlt.org Gauntlt] which is built on cucumber and uses gherkin syntax to define attack files.

= Authors and Primary Editors =
Matt Konda - mkonda [at] jemurai.com<br/>
Neil Matatall neil [at] matatall.com<br/>
Ken Johnson cktricky [at] gmail.com<br/>
Justin Collins justin [at] presidentbeef.com<br/>
Jon Rose - jrose400 [at] gmail.com<br/>
Lance Vaughn - lance [at] cabforward.com<br/>
Jon Claudius - jonathan.claudius [at] gmail.com<br/>
Jim Manico jim [at] owasp.org<br/>
Aaron Bedra aaron [at] aaronbedra.com<br/>

= Related Articles and References =

* [http://guides.rubyonrails.org/security.html The Official Rails Security Guide]
* [https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Rails_Security_Guide_V2 OWASP Ruby on Rails Security Guide]
* [http://code.google.com/p/ruby-security/wiki/Guide The Ruby Security Reviewers Guide]
* [https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security The Ruby on Rails Security Mailing List]
* [http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/ Rails Insecure Defaults]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Ruby on Rails Cheatsheet

2013-03-29T16:44:39Z

Nmatatal: /* Redirects and Forwards */

DRAFT CHEAT SHEET - WORK IN PROGRESS

= Introduction =

This ''Cheatsheet'' intends to provide quick basic Ruby on Rails security tips for developers. It complements, augments or emphasizes points brought up in the [http://guides.rubyonrails.org/security.html rails security guide] from rails core.

The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.

= Items =
== Command Injection ==

Ruby offers a function called “eval” which will dynamically build new Ruby code based on Strings. It also has a number of ways to call system commands.

eval("ruby code here")
System("os command here")
`ls -al /` (backticks contain os command)
Kernel.exec("os command here")

While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application. Usually, its just a bad idea. If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible. The Ruby Security Reviewer's Guide has a [http://code.google.com/p/ruby-security/wiki/Guide#Good_ol%27_shell_injection section on injection] and there are a number of OWASP references for it, starting at the top: [https://www.owasp.org/index.php/Command_Injection Command Injection].

== SQL Injection ==

Ruby on Rails is often used with an ORM called ActiveRecord, though it is flexible and can be used with other data sources. Typically very simple Rails applications use methods on the Rails models to query data. Many use cases protect for SQL Injection out of the box. However, it is possible to write code that allows for SQL Injection.

Here is an example (Rails 2.X style):

@projects = Project.find(:all, :conditions => “name like #{params[:name]}”)

A Rails 3.X example:

name = params[:name]
@projects = Project.where(“name like ‘“ + name + “‘“);

In both of these cases, the statement is injectable because the name parameter is not escaped.

Here is the idiom for building this kind of statement:

@projects = Project.find(:all, :conditions => [ “name like ?”, “#{params[:name]}”] )

An AREL based solution:

@projects = Project.where("name like ?", "%#{params[:name]}%")

Use caution not to build SQL statements based on user controlled input. A list of more realistic and detailed examples is here: [http://rails-sqli.org rails-sqli.org]. OWASP has extensive information about [https://www.owasp.org/index.php/SQL_Injection SQL Injection].

== Cross-site Scripting (XSS) ==

By default, in Rails 3.0 protection against XSS comes as the default behavior. When string data is shown in views, it is escaped prior to being sent back to the browser. This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing. In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).

<%= raw @product.name %>
<%= @product.name.html_safe %> These are examples of how NOT to do it!
<%= content_tag @product.name %>

Unfortunately, any field that uses raw like this will be a potential XSS target. Note that there are also widespread misunderstandings about html_safe. [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail. Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.

If you must accept HTML content from users, consider a markup language for rich text in an application (Examples include: markdown and textile) and disallow HTML tags. This helps ensures that the input accepted doesn’t include HTML content that could be malicious. If you cannot restrict your users from entering HTML, consider implementing content security policy to disallow the execution of any javascript. And finally, consider using the #sanitize method that let's you whitelist allowed tags. Be careful, this method has been shown to be flawed numerous times and will never be a complete solution.

An often overlooked XSS attack vector is the href value of a link:

<%= link_to “Personal Website”, @user.website %>

If @user.website contains a link that starts with “javascript:”, the content will execute when a user clicks the generated link:

<a href=”javascript:alert(‘Haxored’)”>Personal Website</a>

OWASP provides more general information about XSS in a top level page: [https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29 OWASP Cross Site Scripting].

== Sessions ==

By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.

The best practice is to use a database based session, which thankfully is very easy with Rails:

Project::Application.config.session_store :active_record_store

There is an [https://www.owasp.org/index.php/Session_Management_Cheat_Sheet OWASP Session Management Cheat Sheet].

== Authentication ==

Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication. To enable authentication with Devise, one simply has to put the following in a controller:

class ProjectController < ApplicationController
before_filter :authenticate_user

As with other methods, this supports exceptions. Note that by default Devise only requires 6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb

config.password_length = 8..128

There are several possible ways to enforce complexity. One is to put a Validator in the user model.

validate :password_complexity
def password_complexity
if password.present? and not password.match(/\A(?=.*[a-z])(?=.*[A-Z])(?=.*\d).+\z/)
errors.add :password, "must include at least one lowercase letter, one uppercase letter, and one digit"
end
end

There is an [https://www.owasp.org/index.php/Authentication_Cheat_Sheet OWASP Authentication Cheat Sheet].

== Insecure Direct Object Reference or Forceful Browsing ==

By default, Ruby on Rails apps use a RESTful uri structure. That means that paths are often intuitive and guessable. To protect against a user trying to access or modify data that belongs to another user, it is important to specifically control actions. Out of the gate on a vanilla Rails application, there is no such built in protection. It is possible to do this by hand at the controller level.

It is also possible, and probably recommended, to consider resource-based access control libraries such as [https://github.com/ryanb/cancan cancan] to do this. This ensures that all operations on a database object are authorized by the business logic of the application.

More general information about this class of vulnerability is in the [https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References OWASP Top 10 Page].

== CSRF (Cross Site Request Forgery) ==

Ruby on Rails has specific, built in support for CSRF tokens. To enable it, or ensure that it is enabled, find the base ApplicationController and look for a directive such as the following:

class ApplicationController < ActionController::Base
protect_from_forgery

Note that the syntax for this type of control includes a way to add exceptions. Exceptions may be useful for API’s or other reasons - but should be reviewed and consciously included. In the example below, the Rails ProjectController will not provide CSRF protection for the show method.

class ProjectController < ApplicationController
protect_from_forgery :except => :show

Also note that by default Rails does not provide CSRF protection for any HTTP GET request.

There is a top level OWASP page for [https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29 CSRF].

== Mass Assignment and Strong Parameters ==

Although the major issue with Mass Assignment has been fixed by default in base Rails specifically when generating new projects, it still applies to older and upgraded projects so it is important to understand the issue and to ensure that only attributes that are intended to be modifiable are exposed.

When working with a model, the attributes on the model will not be accessible to forms being posted unless a programmer explicitly indicates that:

class Project < ActiveRecord::Base
attr_accessible :name, :admin
end

With the admin attribute accessible based on the example above, the following could work:

curl -d “project[name]=triage&project[admin]=1” host:port/projects

Review accessible attributes to ensure that they should be accessible. If you are working in Rails < 3.2.3 you should ensure that your attributes are whitelisted with the following:

config.active_record.whitelist_attributes = true

In Rails 4.0 strong parameters will be the recommended approach for handling attribute visibility. It is also possible to use the strong_parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications.

== Redirects and Forwards ==

Web applications often require the ability to dynamically redirect users based on client-supplied data. To clarify, dynamic redirection usually entails the client including a URL in a parameter within a request to the application. Once received by the application, the user is redirected to the URL specified in the request. For example:

http://www.example.com/redirect?url=http://www.example_commerce_site.com/checkout

The above request would redirect the user to http://www.example.com/checkout. The security concern associated with this functionality is leveraging an organization’s trusted brand to phish users and trick them into visiting a malicious site, in our example, “badhacker.com”. Example:

http://www.example.com/redirect?url=http://badhacker.com

If matching user input against a list of approved sites or TLDs against regular expression is a must, it makes sense to leverage a library such as URI.parse() to obtain the host and then take the host value and match it against regular expression patterns. Those regular expressions must, at a minimum, have anchors or there is a greater chance of an attacker bypassing the validation routine.

Example:

require ‘uri’
host = URI.parse(“#{params[:url]}”).host
validation_routine(host) if host # no validation is needed if we are just using a path, as this will lead to your applications
def validation_routine(host)
# Validation routine where we use \A and \z as anchors *not* ^ and $
# you could also check the host value against a whitelist
end

The obvious fix for this type of vulnerability is to restrict to specific Top-Level Domains (TLDs), statically define specific sites, or map a key to it’s value. Example:

ACCEPTABLE_URLS = {
‘our_app_1’ => “https://www.example_commerce_site.com/checkout”,
‘our_app_2’ => “https://www.example_user_site.com/change_settings”
}

http://www.example.com/redirect?url=our_app_1

def redirect
url = ACCEPTABLE_URLS[“#{params[:url]}”]
redirect_to url if url
end

There is a more general OWASP resource about [https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet Unvalidated Redirects and Forwards].

== Dynamic Render Paths ==

In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.

Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.

== Cross Origin Resource Sharing ==

Occasionally, a need arises to share resources with another domain. For example, a file-upload function that sends data via an AJAX request to another domain. In these cases, the same-origin rules followed by web browsers must be bent. Modern browsers, in compliance with HTML5 standards, will allow this to occur but in order to do this; a couple precautions must be taken.

When using a nonstandard HTTP construct, such as an atypical Content-Type header, for example, the following applies:

The receiving site should whitelist only those domains allowed to make such requests as well as set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain. Next, a second request, a POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.

When standard HTTP constructs are used:

The request is sent and the browser, upon receiving a response, inspects the response headers in order to determine if the response can and should be processed.

Note: Do NOT do use the wildcard in the access control header as it allows communication with any site.
Access-Control-Allow-Origin: * (Bad example)

Whitelist in Rails:

Gemfile
gem 'rack-cors', :require => 'rack/cors'

config/application.rb
module Sample
class Application < Rails::Application
config.middleware.use Rack::Cors do
allow do
origins 'someserver.example.com'
resource %r{/users/\d+.json},
:headers => ['Origin', 'Accept', 'Content-Type'],
:methods => [:post, :get]
end
end
end
end

== Security-related headers ==

To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter).

response.headers['X-header-name'] = 'value'

'''Rails 4''' provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases. Note: this does not account for content security policy.

ActionDispatch::Response.default_headers = {
'X-Frame-Options' => 'DENY',
'X-Content-Type-Options' => 'nosniff',
'X-XSS-Protection' => '1;'
}

Strict transport security is a special case, it is set in an environment file (e.g. production.rb)

config.force_ssl = true

For those not on the edge, there is a library ([https://github.com/twitter/secureheaders secure_headers]) for the same behavior with content security policy abstraction provided. It will automatically apply logic based on the user agent to produce a concise set of headers.

== Business Logic Bugs ==

Any application in any technology can contain business logic errors that result in security bugs. Business logic bugs are difficult to impossible to detect using automated tools. The best ways to prevent business logic security bugs are to do code review, pair program and write unit tests.

== Attack Surface ==

Generally speaking, Rails avoids open redirect and path traversal types of vulnerabilities because of its /config/routes.rb file which dictates what URL’s should be accessible and handled by which controllers. The routes file is a great place to look when thinking about the scope of the attack surface. An example might be as follows:

match ':controller(/:action(/:id(.:format)))' # this is an example of what NOT to do

In this case, this route allows any public method on any controller to be called as an action. As a developer, you want to make sure that users can only reach the controller methods intended and in the way intended.

== Sensitive Files ==

Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.

/config/database.yml - May contain production credentials.
/config/initializers/secret_token.rb - Contains a secret used to hash session cookie.
/db/seeds.rb - May contain seed data including bootstrap admin user.
/db/development.sqlite3 - May contain real data.

== Encryption ==

Rails uses OS encryption. Generally speaking, it is always a bad idea to write your own encryption.

Devise by default uses bcrypt for password hashing, which is an appropriate solution. Typically, the following config causes the 10 stretches for production: /config/initializers/devise.rb

config.stretches = Rails.env.test? ? 1 : 10

= Updating Rails and Having a Process for Updating Dependencies =

In early 2013, a number of critical vulnerabilities were identified in the Rails Framework. Organizations that had fallen behind current versions had more trouble updating and harder decisions along the way, including patching the source code for the framework itself.

An additional concern with Ruby applications in general is that most libraries (gems) are not signed by their authors. It is literally impossible to build a Rails based project with libraries that come from trusted sources. One good practice might be to audit the gems you are using.

In general, it is important to have a process for updating dependencies. An example process might define three mechanisms for triggering an update of response:
* Every month/quarter dependencies in general are updated.
* Every week important security vulnerabilities are taken into account and potentially trigger an update.
* In EXCEPTIONAL conditions, emergency updates may need to be applied.

= Tools =

Use [http://brakemanscanner.org/ brakeman], an open source code analysis tool for Rails applications, to identify many potential issues. It will not necessarily produce comprehensive security findings, but it can find easily exposed issues. A great way to see potential issues in Rails is to review the brakeman documentation of warning types.

There are emerging tools that can be used to track security issues in dependency sets, like https://gemcanary.com/ and https://gemnasium.com/.

Another area of tooling is the security testing tool [http://gauntlt.org Gauntlt] which is built on cucumber and uses gherkin syntax to define attack files.

= Authors and Primary Editors =
Matt Konda - mkonda [at] jemurai.com<br/>
Neil Matatall neil [at] matatall.com<br/>
Ken Johnson cktricky [at] gmail.com<br/>
Justin Collins justin [at] presidentbeef.com<br/>
Jon Rose - jrose400 [at] gmail.com<br/>
Lance Vaughn - lance [at] cabforward.com<br/>
Jon Claudius - jonathan.claudius [at] gmail.com<br/>
Jim Manico jim [at] owasp.org<br/>
Aaron Bedra aaron [at] aaronbedra.com<br/>

= Related Articles and References =

* [http://guides.rubyonrails.org/security.html The Official Rails Security Guide]
* [https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Rails_Security_Guide_V2 OWASP Ruby on Rails Security Guide]
* [http://code.google.com/p/ruby-security/wiki/Guide The Ruby Security Reviewers Guide]
* [https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security The Ruby on Rails Security Mailing List]
* [http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/ Rails Insecure Defaults]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Unvalidated Redirects and Forwards Cheat Sheet

2013-03-20T17:10:43Z

Nmatatal: /* Dangerous URL Redirect Example 1 */

= Introduction =

Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.

= Safe URL Redirects =

When we want to redirect a user automatically to another page (without an action of the visitor such as clicking on a hyperlink) you might implement a code such as the following:

PHP
<?php
/* Redirect browser */
header("Location: http://www.mysite.com/");
?>

ASP.NET
Response.Redirect("~/folder/Login.aspx")

Rails
redirect_to login_path

In the examples above, the URL is being explicitly declared in the code and cannot be manipulated by an attacker.

= Dangerous URL Redirects =

The following examples demonstrate unsafe redirect and forward code.

== Dangerous URL Redirect Example 1 ==

The following PHP code obtains a URL from the query string and then redirects the user to that URL.

$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

A similar example of C# .NET Vulnerable Code:

string url = request.QueryString["url"];
Response.Redirect(url);

And in rails:
redirect_to params[:url]

The above code is vulnerable to an attack if no validation or extra method controls are applied to verify the certainty of the URL. This vulnerability could be used as part of a phishing scam by redirecting users to a malicious site. If no validation is applied, a malicious user could create a hyperlink to redirect your users to an unvalidated malicious website, for example:

http://example.com/example.php?url=http://malicious.example.com

The user sees the link directing to the original trusted site (example.com) and does not realize the redirection that could take place

== Dangerous URL Redirect Example 2 ==

ASP.NET MVC 1 & 2 websites are particularly vulnerable to open redirection attacks. In order to avoid this vulnerability, you need to apply MVC 3.

The code for the LogOn action in an ASP.NET MVC 2 application is shown below. After a successful login, the controller returns a redirect to the returnUrl. You can see that no validation is being performed against the returnUrl parameter.

Listing 1 – ASP.NET MVC 2 LogOn action in AccountController.cs

[HttpPost]
public ActionResult LogOn(LogOnModel model, string returnUrl)
{
if (ModelState.IsValid)
{
if (MembershipService.ValidateUser(model.UserName, model.Password))
{
FormsService.SignIn(model.UserName, model.RememberMe);
if (!String.IsNullOrEmpty(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Index", "Home");
}
}
else
{
ModelState.AddModelError("", "The user name or password provided is incorrect.");
}
}

// If we got this far, something failed, redisplay form
return View(model);
}

== Dangerous Forward Example ==

When applications allow user input to forward requests between different parts of the site, the application must check that the user is authorized to access the url, perform the functions it provides, and it is an appropriate url request. If the application fails to perform these checks, an attacker crafted URL may pass the application’s access control check and then forward the attacker to an administrative function that is not normally permitted.

http://www.example.com/function.jsp?fwd=admin.jsp

The following code is a Java servlet that will receive a GET request with a url parameter in the request to redirect the browser to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and send a response to redirect the browser to the url address.

public class RedirectServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String query = request.getQueryString();
if (query.contains("url")) {
String url = request.getParameter("url");
response.sendRedirect(url);
}
}
}

= Preventing Unvalidated Redirects and Forwards =

Safe use of redirects and forwards can be done in a number of ways:

* Simply avoid using redirects and forwards.
* If used, do not allow the url as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
* If user input can’t be avoided, ensure that the supplied <strong>value</strong> is valid, appropriate for the application, and is <strong>authorized</strong> for the user.
* It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
* Sanitize input by creating a list of trusted URL's (lists of hosts or a regex).
* Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.

= References =

# OWASP Article on Open Redirects https://www.owasp.org/index.php/Open_redirect
# CWE Entry 601 on Open Redirects http://cwe.mitre.org/data/definitions/601.html
# WASC Article on URL Redirector Abuse http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse
# Google blog article on the dangers of open redirects http://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your-site-being.html
# Preventing Open Redirection Attacks (C#) http://www.asp.net/mvc/tutorials/security/preventing-open-redirection-attacks

= Authors and Primary Editors =

Susanna Bezold - susanna.bezold[at]owasp.org<br/>
Johanna Curiel - johanna.curiel[at]owasp.org<br/>
Jim Manico - jim[at]owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Unvalidated Redirects and Forwards Cheat Sheet

2013-03-20T17:10:07Z

Nmatatal:

= Introduction =

Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.

= Safe URL Redirects =

When we want to redirect a user automatically to another page (without an action of the visitor such as clicking on a hyperlink) you might implement a code such as the following:

PHP
<?php
/* Redirect browser */
header("Location: http://www.mysite.com/");
?>

ASP.NET
Response.Redirect("~/folder/Login.aspx")

Rails
redirect_to login_path

In the examples above, the URL is being explicitly declared in the code and cannot be manipulated by an attacker.

= Dangerous URL Redirects =

The following examples demonstrate unsafe redirect and forward code.

== Dangerous URL Redirect Example 1 ==

The following PHP code obtains a URL from the query string and then redirects the user to that URL.

$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

A similar example of C# .NET Vulnerable Code:

string url = request.QueryString["url"];
Response.Redirect(url);

And in ruby:
redirect_to params[:url]

The above code is vulnerable to an attack if no validation or extra method controls are applied to verify the certainty of the URL. This vulnerability could be used as part of a phishing scam by redirecting users to a malicious site. If no validation is applied, a malicious user could create a hyperlink to redirect your users to an unvalidated malicious website, for example:

http://example.com/example.php?url=http://malicious.example.com

The user sees the link directing to the original trusted site (example.com) and does not realize the redirection that could take place

== Dangerous URL Redirect Example 2 ==

ASP.NET MVC 1 & 2 websites are particularly vulnerable to open redirection attacks. In order to avoid this vulnerability, you need to apply MVC 3.

The code for the LogOn action in an ASP.NET MVC 2 application is shown below. After a successful login, the controller returns a redirect to the returnUrl. You can see that no validation is being performed against the returnUrl parameter.

Listing 1 – ASP.NET MVC 2 LogOn action in AccountController.cs

[HttpPost]
public ActionResult LogOn(LogOnModel model, string returnUrl)
{
if (ModelState.IsValid)
{
if (MembershipService.ValidateUser(model.UserName, model.Password))
{
FormsService.SignIn(model.UserName, model.RememberMe);
if (!String.IsNullOrEmpty(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Index", "Home");
}
}
else
{
ModelState.AddModelError("", "The user name or password provided is incorrect.");
}
}

// If we got this far, something failed, redisplay form
return View(model);
}

== Dangerous Forward Example ==

When applications allow user input to forward requests between different parts of the site, the application must check that the user is authorized to access the url, perform the functions it provides, and it is an appropriate url request. If the application fails to perform these checks, an attacker crafted URL may pass the application’s access control check and then forward the attacker to an administrative function that is not normally permitted.

http://www.example.com/function.jsp?fwd=admin.jsp

The following code is a Java servlet that will receive a GET request with a url parameter in the request to redirect the browser to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and send a response to redirect the browser to the url address.

public class RedirectServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String query = request.getQueryString();
if (query.contains("url")) {
String url = request.getParameter("url");
response.sendRedirect(url);
}
}
}

= Preventing Unvalidated Redirects and Forwards =

Safe use of redirects and forwards can be done in a number of ways:

* Simply avoid using redirects and forwards.
* If used, do not allow the url as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
* If user input can’t be avoided, ensure that the supplied <strong>value</strong> is valid, appropriate for the application, and is <strong>authorized</strong> for the user.
* It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
* Sanitize input by creating a list of trusted URL's (lists of hosts or a regex).
* Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.

= References =

# OWASP Article on Open Redirects https://www.owasp.org/index.php/Open_redirect
# CWE Entry 601 on Open Redirects http://cwe.mitre.org/data/definitions/601.html
# WASC Article on URL Redirector Abuse http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse
# Google blog article on the dangers of open redirects http://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your-site-being.html
# Preventing Open Redirection Attacks (C#) http://www.asp.net/mvc/tutorials/security/preventing-open-redirection-attacks

= Authors and Primary Editors =

Susanna Bezold - susanna.bezold[at]owasp.org<br/>
Johanna Curiel - johanna.curiel[at]owasp.org<br/>
Jim Manico - jim[at]owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Ruby on Rails Cheatsheet

2013-03-18T18:48:55Z

Nmatatal: /* Cross-site Scripting (XSS) */

DRAFT CHEAT SHEET - WORK IN PROGRESS

= Introduction =

This article intends to provide quick basic Ruby on Rails security tips for developers. The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.

= Items =
== Command Injection ==

Ruby offers a function called “eval” which will dynamically build new Ruby code based on Strings. It also has a number of ways to call system commands.

eval("ruby code here")
System("os command here")
`ls -al /` (backticks contain os command)
Kernel.exec("os command here")

While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application. Usually, its just a bad idea. If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible.

== SQL Injection ==

Ruby on Rails is often used with an ORM called ActiveRecord, though it is flexible and can be used with other data sources. Typically very simple Rails applications use methods on the Rails models to query data. Many use cases protect for SQL Injection out of the box. However, it is possible to write code that allows for SQL Injection.

Here is an example (Rails 2.X style):

@projects = Project.find(:all, :conditions => “name like #{params[:name]}”)

A Rails 3.X example:

name = params[:name]
@projects = Project.where(“name like ‘“ + name + “‘“);

In both of these cases, the statement is injectable because the name parameter is not escaped.

Here is the idiom for building this kind of statement:

@projects = Project.find(:all, :conditions => [ “name like ?”, “#{params[:name]}”] )

An AREL based solution:

@projects = Project.where("name like ?", "%#{params[:name]}%")

Use caution not to build SQL statements based on user controlled input. A list of more realistic and detailed examples is here: [http://rails-sqli.org rails-sqli.org].

== Cross-site Scripting (XSS) ==

By default, in Rails 3.0 protection against XSS comes as the default behavior. When string data is shown in views, it is escaped prior to being sent back to the browser. This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing. In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).

<%= raw @product.name %>
<%= @product.name.html_safe %> These are examples of how NOT to do it!
<%= content_tag @product.name %>

Unfortunately, any field that uses raw like this will be a potential XSS target. Note that there are also widespread misunderstandings about html_safe. [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail. Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.

If you must accept HTML content from users, consider a markup language for rich text in an application (Examples include: markdown and textile) and disallow HTML tags. This helps ensures that the input accepted doesn’t include HTML content that could be malicious. If you cannot restrict your users from entering HTML, consider implementing content security policy to disallow the execution of any javascript. And finally, consider using the #sanitize method that let's you whitelist allowed tags. Be careful, this method has been shown to be flawed numerous times and will never be a complete solution.

An often overlooked XSS attack vector is the href value of a link:

<%= link_to “Personal Website”, @user.website %>

If @user.website contains a link that starts with “javascript:”, the content will execute when a user clicks the generated link:

<a href=”javascript:alert(‘Haxored’)”>Personal Website</a>

== Sessions ==

By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.

The best practice is to use a database based session, which thankfully is very easy with Rails:

Project::Application.config.session_store :active_record_store

== Authentication ==

Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication. To enable authentication with Devise, one simply has to put the following in a controller:

class ProjectController < ApplicationController
before_filter :authenticate_user

As with other methods, this supports exceptions. Note that by default Devise only requires 6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb

config.password_length = 8..128

There are several possible ways to enforce complexity. One is to put a Validator in the user model.

validate :password_complexity
def password_complexity
if password.present? and not password.match(/\A(?=.*[a-z])(?=.*[A-Z])(?=.*\d).+\z/)
errors.add :password, "must include at least one lowercase letter, one uppercase letter, and one digit"
end
end

== Insecure Direct Object Reference or Forceful Browsing ==

By default, Ruby on Rails apps use a RESTful uri structure. That means that paths are often intuitive and guessable. To protect against a user trying to access or modify data that belongs to another user, it is important to specifically control actions. Out of the gate on a vanilla Rails application, there is no such built in protection. It is possible to do this by hand at the controller level.

It is also possible, and probably recommended, to consider resource-based access control libraries such as [https://github.com/ryanb/cancan cancan] to do this. This ensures that all operations on a database object are authorized by the business logic of the application.

== CSRF (Cross Site Request Forgery) ==

Ruby on Rails has specific, built in support for CSRF tokens. To enable it, or ensure that it is enabled, find the base ApplicationController and look for a directive such as the following:

class ApplicationController < ActionController::Base
protect_from_forgery

Note that the syntax for this type of control includes a way to add exceptions. Exceptions may be useful for API’s or other reasons - but should be reviewed and consciously included. In the example below, the Rails ProjectController will not provide CSRF protection for the show method.

class ProjectController < ApplicationController
protect_from_forgery :except => :show

Also note that by default Rails does not provide CSRF protection for any HTTP GET request.

== Mass Assignment and Strong Parameters ==

Although the major issue with Mass Assignment has been fixed by default in base Rails specifically when generating new projects, it still applies to older and upgraded projects so it is important to understand the issue and to ensure that only attributes that are intended to be modifiable are exposed.

When working with a model, the attributes on the model will not be accessible to forms being posted unless a programmer explicitly indicates that:

class Project < ActiveRecord::Base
attr_accessible :name, :admin
end

With the admin attribute accessible based on the example above, the following could work:

curl -d “project[name]=triage&project[admin]=1” host:port/projects

Review accessible attributes to ensure that they should be accessible. If you are working in Rails < 3.2.3 you should ensure that your attributes are whitelisted with the following:

config.active_record.whitelist_attributes = true

In Rails 4.0 strong parameters will be the recommended approach for handling attribute visibility. It is also possible to use the strong_parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications.

== Redirects and Forwards ==

Web applications often require the ability to dynamically redirect users based on client-supplied data. To clarify, dynamic redirection usually entails the client including a URL in a parameter within a request to the application. Once received by the application, the user is redirected to the URL specified in the request. For example:

http://www.example.com/redirect?url=http://www.example_commerce_site.com/checkout

The above request would redirect the user to http://www.example.com/checkout. The security concern associated with this functionality is leveraging an organization’s trusted brand to phish users and trick them into visiting a malicious site, in our example, “badhacker.com”. Example:

http://www.example.com/redirect?url=http://badhacker.com

The obvious fix for this type of vulnerability is to restrict to specific Top-Level Domains (TLDs), statically define specific sites, or map a key to it’s value. Example:

ACCEPTABLE_URLS = {
‘our_app_1’ => “https://www.example_commerce_site.com/checkout”,
‘our_app_2’ => “https://www.example_user_site.com/change_settings”
}

http://www.example.com/redirect?url=our_app_1

def redirect
url = ACCEPTABLE_URLS[“#{params[:url]}”]
redirect_to url if url
end

If matching user input against a list of approved sites or TLDs against regular expression is a must, it makes sense to leverage a library such as URI.parse() to obtain the host and then take the host value and match it against regular expression patterns. Those regular expressions must, at a minimum, have anchors or there is a greater chance of an attacker bypassing the validation routine.

Example:

require ‘uri’
host = URI.parse(“#{params[:url]}”).host
validation_routine(host) if host
def validation_routine(host)
# Validation routine where we use \A and \z as anchors *not* ^ and $
end

== Dynamic Render Paths ==

In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.

Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.

== Cross Origin Resource Sharing ==

Occasionally, a need arises to share resources with another domain. For example, a file-upload function that sends data via an AJAX request to another domain. In these cases, the same-origin rules followed by web browsers must be bent. Modern browsers, in compliance with HTML5 standards, will allow this to occur but in order to do this; a couple precautions must be taken.

When using a nonstandard HTTP construct, such as an atypical Content-Type header, for example, the following applies:

The receiving site should whitelist only those domains allowed to make such requests as well as set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain. Next, a second request, a POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.

When standard HTTP constructs are used:

The request is sent and the browser, upon receiving a response, inspects the response headers in order to determine if the response can and should be processed.

Note: Do NOT do use the wildcard in the access control header as it allows communication with any site.
Access-Control-Allow-Origin: * (Bad example)

Whitelist in Rails:

Gemfile
gem 'rack-cors', :require => 'rack/cors'

config/application.rb
module Sample
class Application < Rails::Application
config.middleware.use Rack::Cors do
allow do
origins 'someserver.example.com'
resource %r{/users/\d+.json},
:headers => ['Origin', 'Accept', 'Content-Type'],
:methods => [:post, :get]
end
end
end
end

== Security-related headers ==

To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter).

response.headers['X-header-name'] = 'value'

'''Rails 4''' provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases. Note: this does not account for content security policy.

ActionDispatch::Response.default_headers = {
'X-Frame-Options' => 'DENY',
'X-Content-Type-Options' => 'nosniff',
'X-XSS-Protection' => '1;'
}

Strict transport security is a special case, it is set in an environment file (e.g. production.rb)

config.force_ssl = true

For those not on the edge, there is a library ([https://github.com/twitter/secureheaders secure_headers]) for the same behavior with content security policy abstraction provided. It will automatically apply logic based on the user agent to produce a concise set of headers.

== Business Logic Bugs ==

Any application in any technology can contain business logic errors that result in security bugs. Business logic bugs are difficult to impossible to detect using automated tools. The best ways to prevent business logic security bugs are to do code review, pair program and write unit tests.

== Attack Surface ==

Generally speaking, Rails avoids open redirect and path traversal types of vulnerabilities because of its /config/routes.rb file which dictates what URL’s should be accessible and handled by which controllers. The routes file is a great place to look when thinking about the scope of the attack surface. An example might be as follows:

match ':controller(/:action(/:id(.:format)))' # this is an example of what NOT to do

In this case, this route allows any public method on any controller to be called as an action. As a developer, you want to make sure that users can only reach the controller methods intended and in the way intended.

== Sensitive Files ==

Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.

/config/database.yml - May contain production credentials.
/config/initializers/secret_token.rb - Contains a secret used to hash session cookie.
/db/seeds.rb - May contain seed data including bootstrap admin user.
/db/development.sqlite3 - May contain real data.

== Encryption ==

Rails uses OS encryption. Generally speaking, it is always a bad idea to write your own encryption.

Devise by default uses bcrypt for password hashing, which is an appropriate solution. Typically, the following config causes the 10 stretches for production: /config/initializers/devise.rb

config.stretches = Rails.env.test? ? 1 : 10

= Updating Rails and Having a Process for Updating Dependencies =

In early 2013, a number of critical vulnerabilities were identified in the Rails Framework. Organizations that had fallen behind current versions had more trouble updating and harder decisions along the way, including patching the source code for the framework itself.

An additional concern with Ruby applications in general is that most libraries (gems) are not signed by their authors. It is literally impossible to build a Rails based project with libraries that come from trusted sources. One good practice might be to audit the gems you are using.

In general, it is important to have a process for updating dependencies. An example process might define three mechanisms for triggering an update of response:
* Every month/quarter dependencies in general are updated.
* Every week important security vulnerabilities are taken into account and potentially trigger an update.
* In EXCEPTIONAL conditions, emergency updates may need to be applied.

= Tools =

Use [http://brakemanscanner.org/ brakeman], an open source code analysis tool for Rails applications, to identify many potential issues. It will not necessarily produce comprehensive security findings, but it can find easily exposed issues. A great way to see potential issues in Rails is to review the brakeman documentation of warning types.

There are emerging tools that can be used to track security issues in dependency sets, like [http://sourceninja.com SourceNinja].

Another area of tooling is the security testing tool [http://gauntlt.org Gauntlt] which is built on cucumber and uses gherkin syntax to define attack files.

= Authors and Primary Editors =
Matt Konda - mkonda [at] jemurai.com<br/>
Neil Matatall neil [at] matatall.com<br/>
Ken Johnson cktricky [at] gmail.com<br/>
Justin Collins justin [at] presidentbeef.com<br/>
Jon Rose - jrose400 [at] gmail.com<br/>
Lance Vaughn - lance [at] cabforward.com<br/>
Jon Claudius - jonathan.claudius [at] gmail.com<br/>
Jim Manico jim [at] owasp.org<br/>
Aaron Bedra aaron [at] aaronbedra.com<br/>

= Related Articles and References =

* [http://guides.rubyonrails.org/security.html The Official Rails Security Guide]
* [https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Rails_Security_Guide_V2 OWASP Ruby on Rails Security Guide]
* [http://code.google.com/p/ruby-security/wiki/Guide The Ruby Security Reviewers Guide]
* [https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security The Ruby on Rails Security Mailing List]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Ruby on Rails Cheatsheet

2013-02-14T17:59:50Z

Nmatatal: /* Attack Surface */

DRAFT CHEAT SHEET - WORK IN PROGRESS

= Introduction =

This article intends to provide quick basic Ruby on Rails security tips for developers. The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.

= Items =
== Command Injection ==

Ruby offers a function called “eval” which will dynamically build new Ruby code based on Strings. It also has a number of ways to call system commands.

eval("ruby code here")
System("os command here")
`ls -al /` (backticks contain os command)
Kernel.exec("os command here")

While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application. Usually, its just a bad idea. If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible.

== SQL Injection ==

Ruby on Rails is often used with an ORM called ActiveRecord, though it is flexible and can be used with other data sources. Typically very simple Rails applications use methods on the Rails models to query data. Many use cases protect for SQL Injection out of the box. However, it is possible to write code that allows for SQL Injection.

Here is an example (Rails 2.X style):

@projects = Project.find(:all, :conditions => “name like #{params[:name]}”)

A Rails 3.X example:

name = params[:name]
@projects = Project.where(“name like ‘“ + name + “‘“);

In both of these cases, the statement is injectable because the name parameter is not escaped.

Here is the idiom for building this kind of statement:

@projects = Project.find(:all, :conditions => [ “name like ?”, “#{params[:name]}”] )

An AREL based solution:

@projects = Project.where("name like ?", "%#{params[:name]}%")

Use caution not to build SQL statements based on user controlled input. A list of more realistic and detailed examples is here: [http://rails-sqli.org rails-sqli.org].

== Cross-site Scripting (XSS) ==

By default, in Rails 3.0 protection against XSS comes as the default behavior. When string data is shown in views, it is escaped prior to being sent back to the browser. This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing. In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).

<%= raw @product.name %>
<%= @product.name.html_safe %> These are examples of how NOT to do it!
<%= content_tag @product.name %>

Unfortunately, any field that uses raw like this will be a potential XSS target. Note that there are also widespread misunderstandings about html_safe. [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail. Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.

One way to manage cases like this is to use a Rails provided helper method called sanitize:

<%= sanitize @project.name, :tags => %w(h1 h2 h3 h4 h5), :attributes => %() %>

This eliminates tags other than <nowiki><h1>, <h2>, <h3>, <h4>, <h5></nowiki>. It also disallows attributes on those tags. Note that it is critical to understand the tags you enable here. <nowiki><img></nowiki> may seem like an innocuous tag, but through various attributes on <nowiki><img/></nowiki> that are scriptable such as onError=””. Only by sanitizing only innocuous tags can XSS be prevented.

A more attractive alternative to using sanitize and real HTML content is to use an alternative markup language for rich text in an application (Examples include: markdown and textile) and disallow HTML tags. This ensures that the input accepted doesn’t include HTML content that could be malicious.

An often overlooked XSS attack vector is the href value of a link:

<%= link_to “Personal Website”, @user.website %>

If @user.website contains a link that starts with “javascript:”, the content will execute when a user clicks the generated link:

<a href=”javascript:alert(‘Haxored’)”>Personal Website</a>

== Sessions ==

By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.

The best practice is to use a database based session, which thankfully is very easy with Rails:

Project::Application.config.session_store :active_record_store

== Authentication ==

Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication. To enable authentication with Devise, one simply has to put the following in a controller:

class ProjectController < ApplicationController
before_filter :authenticate_user

As with other methods, this supports exceptions. Note that by default Devise only requires 6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb

config.password_length = 8..128

There are several possible ways to enforce complexity. One is to put a Validator in the user model.

validate :password_complexity
def password_complexity
if password.present? and not password.match(/\A(?=.*[a-z])(?=.*[A-Z])(?=.*\d).+\z/)
errors.add :password, "must include at least one lowercase letter, one uppercase letter, and one digit"
end
end

== Insecure Direct Object Reference or Forceful Browsing ==

By default, Ruby on Rails apps use a RESTful uri structure. That means that paths are often intuitive and guessable. To protect against a user trying to access or modify data that belongs to another user, it is important to specifically control actions. Out of the gate on a vanilla Rails application, there is no such built in protection. It is possible to do this by hand at the controller level.

It is also possible, and probably recommended, to consider resource-based access control libraries such as [https://github.com/ryanb/cancan cancan] to do this. This ensures that all operations on a database object are authorized by the business logic of the application.

== CSRF (Cross Site Request Forgery) ==

Ruby on Rails has specific, built in support for CSRF tokens. To enable it, or ensure that it is enabled, find the base ApplicationController and look for a directive such as the following:

class ApplicationController < ActionController::Base
protect_from_forgery

Note that the syntax for this type of control includes a way to add exceptions. Exceptions may be useful for API’s or other reasons - but should be reviewed and consciously included. In the example below, the Rails ProjectController will not provide CSRF protection for the show method.

class ProjectController < ApplicationController
protect_from_forgery :except => :show

Also note that by default Rails does not provide CSRF protection for any HTTP GET request.

== Mass Assignment and Strong Parameters ==

Although the major issue with Mass Assignment has been fixed by default in base Rails specifically when generating new projects, it still applies to older and upgraded projects so it is important to understand the issue and to ensure that only attributes that are intended to be modifiable are exposed.

When working with a model, the attributes on the model will not be accessible to forms being posted unless a programmer explicitly indicates that:

class Project < ActiveRecord::Base
attr_accessible :name, :admin
end

With the admin attribute accessible based on the example above, the following could work:

curl -d “project[name]=triage&project[admin]=1” host:port/projects

Review accessible attributes to ensure that they should be accessible. If you are working in Rails < 3.2.3 you should ensure that your attributes are whitelisted with the following:

config.active_record.whitelist_attributes = true

In Rails 4.0 strong parameters will be the recommended approach for handling attribute visibility. It is also possible to use the strong_parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications.

== Redirects and Forwards ==

Web applications often require the ability to dynamically redirect users based on client-supplied data. To clarify, dynamic redirection usually entails the client including a URL in a parameter within a request to the application. Once received by the application, the user is redirected to the URL specified in the request. For example:

http://www.example.com/redirect?url=http://www.example_commerce_site.com/checkout

The above request would redirect the user to http://www.example.com/checkout. The security concern associated with this functionality is leveraging an organization’s trusted brand to phish users and trick them into visiting a malicious site, in our example, “badhacker.com”. Example:

http://www.example.com/redirect?url=http://badhacker.com

The obvious fix for this type of vulnerability is to restrict to specific Top-Level Domains (TLDs), statically define specific sites, or map a key to it’s value. Example:

ACCEPTABLE_URLS = {
‘our_app_1’ => “https://www.example_commerce_site.com/checkout”,
‘our_app_2’ => “https://www.example_user_site.com/change_settings”
}

http://www.example.com/redirect?url=our_app_1

def redirect
url = ACCEPTABLE_URLS[“#{params[:url]}”]
redirect_to url if url
end

If matching user input against a list of approved sites or TLDs against regular expression is a must, it makes sense to leverage a library such as URI.parse() to obtain the host and then take the host value and match it against regular expression patterns. Those regular expressions must, at a minimum, have anchors or there is a greater chance of an attacker bypassing the validation routine.

Example:

require ‘uri’
host = URI.parse(“#{params[:url]}”).host
validation_routine(host) if host
def validation_routine(host)
# Validation routine where we use \A and \z as anchors *not* ^ and $
end

== Dynamic Render Paths ==

In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.

Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.

== Cross Origin Resource Sharing ==

Occasionally, a need arises to share resources with another domain. For example, a file-upload function that sends data via an AJAX request to another domain. In these cases, the same-origin rules followed by web browsers must be bent. Modern browsers, in compliance with HTML5 standards, will allow this to occur but in order to do this; a couple precautions must be taken.

When using a nonstandard HTTP construct, such as an atypical Content-Type header, for example, the following applies:

The receiving site should whitelist only those domains allowed to make such requests as well as set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain. Next, a second request, a POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.

When standard HTTP constructs are used:

The request is sent and the browser, upon receiving a response, inspects the response headers in order to determine if the response can and should be processed.

Note: Do NOT do use the wildcard in the access control header as it allows communication with any site.
Access-Control-Allow-Origin: * (Bad example)

Whitelist in Rails:

Gemfile
gem 'rack-cors', :require => 'rack/cors'

config/application.rb
module Sample
class Application < Rails::Application
config.middleware.use Rack::Cors do
allow do
origins 'someserver.example.com'
resource %r{/users/\d+.json},
:headers => ['Origin', 'Accept', 'Content-Type'],
:methods => [:post, :get]
end
end
end
end

== Security-related headers ==

To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter).

response.headers['X-header-name'] = 'value'

'''Rails 4''' provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases. Note: this does not account for content security policy.

ActionDispatch::Response.default_headers = {
'X-Frame-Options' => 'DENY',
'X-Content-Type-Options' => 'nosniff',
'X-XSS-Protection' => '1;'
}

Strict transport security is a special case, it is set in an environment file (e.g. production.rb)

config.force_ssl = true

For those not on the edge, there is a library ([https://github.com/twitter/secureheaders secure_headers]) for the same behavior with content security policy abstraction provided. It will automatically apply logic based on the user agent to produce a concise set of headers.

== Business Logic Bugs ==

Any application in any technology can contain business logic errors that result in security bugs. Business logic bugs are difficult to impossible to detect using automated tools. The best ways to prevent business logic security bugs are to do code review, pair program and write unit tests.

== Attack Surface ==

Generally speaking, Rails avoids open redirect and path traversal types of vulnerabilities because of its /config/routes.rb file which dictates what URL’s should be accessible and handled by which controllers. The routes file is a great place to look when thinking about the scope of the attack surface. An example might be as follows:

match ':controller(/:action(/:id(.:format)))' # this is an example of what NOT to do

In this case, this route allows any public method on any controller to be called as an action. As a developer, you want to make sure that users can only reach the controller methods intended and in the way intended.

== Sensitive Files ==

Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.

/config/database.yml - May contain production credentials.
/config/initializers/secret_token.rb - Contains a secret used to hash session cookie.
/db/seeds.rb - May contain seed data including bootstrap admin user.
/db/development.sqlite3 - May contain real data.

== Encryption ==

Rails uses OS encryption. Generally speaking, it is always a bad idea to write your own encryption.

Devise by default uses bcrypt for password hashing, which is an appropriate solution. Typically, the following config causes the 10 stretches for production: /config/initializers/devise.rb

config.stretches = Rails.env.test? ? 1 : 10

= Updating Rails and Having a Process for Updating Dependencies =

In early 2013, a number of critical vulnerabilities were identified in the Rails Framework. Organizations that had fallen behind current versions had more trouble updating and harder decisions along the way, including patching the source code for the framework itself.

An additional concern with Ruby applications in general is that most libraries (gems) are not signed by their authors. It is literally impossible to build a Rails based project with libraries that come from trusted sources. One good practice might be to audit the gems you are using.

In general, it is important to have a process for updating dependencies. An example process might define three mechanisms for triggering an update of response:
* Every month/quarter dependencies in general are updated.
* Every week important security vulnerabilities are taken into account and potentially trigger an update.
* In EXCEPTIONAL conditions, emergency updates may need to be applied.

= Tools =

Use [http://brakemanscanner.org/ brakeman], an open source code analysis tool for Rails applications, to identify many potential issues. It will not necessarily produce comprehensive security findings, but it can find easily exposed issues. A great way to see potential issues in Rails is to review the brakeman documentation of warning types.

There are emerging tools that can be used to track security issues in dependency sets, like [http://sourceninja.com SourceNinja].

= Authors and Primary Editors =
Matt Konda - mkonda [at] jemurai.com<br/>
Neil Matatall neil [at] matatall.com<br/>
Ken Johnson cktricky [at] gmail.com<br/>
Justin Collins justin [at] presidentbeef.com<br/>
Jon Rose - jrose [at] crowdsecurify.com<br/>
Lance Vaughn - lance [at] cabforward.com<br/>
Jon Claudius - jonathan.claudius [at] gmail.com<br/>
Jim Manico jim [at] owasp.org<br/>
Aaron Bedra aaron [at] aaronbedra.com<br/>

= Related Articles and References =

* [http://guides.rubyonrails.org/security.html The Official Rails Security Guide]
* [https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Rails_Security_Guide_V2 OWASP Ruby on Rails Security Guide]
* [http://code.google.com/p/ruby-security/wiki/Guide The Ruby Security Reviewers Guide]
* [https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security The Ruby on Rails Security Mailing List]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Ruby on Rails Cheatsheet

2013-02-14T17:55:50Z

Nmatatal: /* Security-related headers */

DRAFT CHEAT SHEET - WORK IN PROGRESS

= Introduction =

This article intends to provide quick basic Ruby on Rails security tips for developers. The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.

= Items =
== Command Injection ==

Ruby offers a function called “eval” which will dynamically build new Ruby code based on Strings. It also has a number of ways to call system commands.

eval("ruby code here")
System("os command here")
`ls -al /` (backticks contain os command)
Kernel.exec("os command here")

While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application. Usually, its just a bad idea. If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible.

== SQL Injection ==

Ruby on Rails is often used with an ORM called ActiveRecord, though it is flexible and can be used with other data sources. Typically very simple Rails applications use methods on the Rails models to query data. Many use cases protect for SQL Injection out of the box. However, it is possible to write code that allows for SQL Injection.

Here is an example (Rails 2.X style):

@projects = Project.find(:all, :conditions => “name like #{params[:name]}”)

A Rails 3.X example:

name = params[:name]
@projects = Project.where(“name like ‘“ + name + “‘“);

In both of these cases, the statement is injectable because the name parameter is not escaped.

Here is the idiom for building this kind of statement:

@projects = Project.find(:all, :conditions => [ “name like ?”, “#{params[:name]}”] )

An AREL based solution:

@projects = Project.where("name like ?", "%#{params[:name]}%")

Use caution not to build SQL statements based on user controlled input. A list of more realistic and detailed examples is here: [http://rails-sqli.org rails-sqli.org].

== Cross-site Scripting (XSS) ==

By default, in Rails 3.0 protection against XSS comes as the default behavior. When string data is shown in views, it is escaped prior to being sent back to the browser. This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing. In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).

<%= raw @product.name %>
<%= @product.name.html_safe %> These are examples of how NOT to do it!
<%= content_tag @product.name %>

Unfortunately, any field that uses raw like this will be a potential XSS target. Note that there are also widespread misunderstandings about html_safe. [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail. Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.

One way to manage cases like this is to use a Rails provided helper method called sanitize:

<%= sanitize @project.name, :tags => %w(h1 h2 h3 h4 h5), :attributes => %() %>

This eliminates tags other than <nowiki><h1>, <h2>, <h3>, <h4>, <h5></nowiki>. It also disallows attributes on those tags. Note that it is critical to understand the tags you enable here. <nowiki><img></nowiki> may seem like an innocuous tag, but through various attributes on <nowiki><img/></nowiki> that are scriptable such as onError=””. Only by sanitizing only innocuous tags can XSS be prevented.

A more attractive alternative to using sanitize and real HTML content is to use an alternative markup language for rich text in an application (Examples include: markdown and textile) and disallow HTML tags. This ensures that the input accepted doesn’t include HTML content that could be malicious.

An often overlooked XSS attack vector is the href value of a link:

<%= link_to “Personal Website”, @user.website %>

If @user.website contains a link that starts with “javascript:”, the content will execute when a user clicks the generated link:

<a href=”javascript:alert(‘Haxored’)”>Personal Website</a>

== Sessions ==

By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.

The best practice is to use a database based session, which thankfully is very easy with Rails:

Project::Application.config.session_store :active_record_store

== Authentication ==

Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication. To enable authentication with Devise, one simply has to put the following in a controller:

class ProjectController < ApplicationController
before_filter :authenticate_user

As with other methods, this supports exceptions. Note that by default Devise only requires 6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb

config.password_length = 8..128

There are several possible ways to enforce complexity. One is to put a Validator in the user model.

validate :password_complexity
def password_complexity
if password.present? and not password.match(/\A(?=.*[a-z])(?=.*[A-Z])(?=.*\d).+\z/)
errors.add :password, "must include at least one lowercase letter, one uppercase letter, and one digit"
end
end

== Insecure Direct Object Reference or Forceful Browsing ==

By default, Ruby on Rails apps use a RESTful uri structure. That means that paths are often intuitive and guessable. To protect against a user trying to access or modify data that belongs to another user, it is important to specifically control actions. Out of the gate on a vanilla Rails application, there is no such built in protection. It is possible to do this by hand at the controller level.

It is also possible, and probably recommended, to consider resource-based access control libraries such as [https://github.com/ryanb/cancan cancan] to do this. This ensures that all operations on a database object are authorized by the business logic of the application.

== CSRF (Cross Site Request Forgery) ==

Ruby on Rails has specific, built in support for CSRF tokens. To enable it, or ensure that it is enabled, find the base ApplicationController and look for a directive such as the following:

class ApplicationController < ActionController::Base
protect_from_forgery

Note that the syntax for this type of control includes a way to add exceptions. Exceptions may be useful for API’s or other reasons - but should be reviewed and consciously included. In the example below, the Rails ProjectController will not provide CSRF protection for the show method.

class ProjectController < ApplicationController
protect_from_forgery :except => :show

Also note that by default Rails does not provide CSRF protection for any HTTP GET request.

== Mass Assignment and Strong Parameters ==

Although the major issue with Mass Assignment has been fixed by default in base Rails specifically when generating new projects, it still applies to older and upgraded projects so it is important to understand the issue and to ensure that only attributes that are intended to be modifiable are exposed.

When working with a model, the attributes on the model will not be accessible to forms being posted unless a programmer explicitly indicates that:

class Project < ActiveRecord::Base
attr_accessible :name, :admin
end

With the admin attribute accessible based on the example above, the following could work:

curl -d “project[name]=triage&project[admin]=1” host:port/projects

Review accessible attributes to ensure that they should be accessible. If you are working in Rails < 3.2.3 you should ensure that your attributes are whitelisted with the following:

config.active_record.whitelist_attributes = true

In Rails 4.0 strong parameters will be the recommended approach for handling attribute visibility. It is also possible to use the strong_parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications.

== Redirects and Forwards ==

Web applications often require the ability to dynamically redirect users based on client-supplied data. To clarify, dynamic redirection usually entails the client including a URL in a parameter within a request to the application. Once received by the application, the user is redirected to the URL specified in the request. For example:

http://www.example.com/redirect?url=http://www.example_commerce_site.com/checkout

The above request would redirect the user to http://www.example.com/checkout. The security concern associated with this functionality is leveraging an organization’s trusted brand to phish users and trick them into visiting a malicious site, in our example, “badhacker.com”. Example:

http://www.example.com/redirect?url=http://badhacker.com

The obvious fix for this type of vulnerability is to restrict to specific Top-Level Domains (TLDs), statically define specific sites, or map a key to it’s value. Example:

ACCEPTABLE_URLS = {
‘our_app_1’ => “https://www.example_commerce_site.com/checkout”,
‘our_app_2’ => “https://www.example_user_site.com/change_settings”
}

http://www.example.com/redirect?url=our_app_1

def redirect
url = ACCEPTABLE_URLS[“#{params[:url]}”]
redirect_to url if url
end

If matching user input against a list of approved sites or TLDs against regular expression is a must, it makes sense to leverage a library such as URI.parse() to obtain the host and then take the host value and match it against regular expression patterns. Those regular expressions must, at a minimum, have anchors or there is a greater chance of an attacker bypassing the validation routine.

Example:

require ‘uri’
host = URI.parse(“#{params[:url]}”).host
validation_routine(host) if host
def validation_routine(host)
# Validation routine where we use \A and \z as anchors *not* ^ and $
end

== Dynamic Render Paths ==

In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.

Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.

== Cross Origin Resource Sharing ==

Occasionally, a need arises to share resources with another domain. For example, a file-upload function that sends data via an AJAX request to another domain. In these cases, the same-origin rules followed by web browsers must be bent. Modern browsers, in compliance with HTML5 standards, will allow this to occur but in order to do this; a couple precautions must be taken.

When using a nonstandard HTTP construct, such as an atypical Content-Type header, for example, the following applies:

The receiving site should whitelist only those domains allowed to make such requests as well as set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain. Next, a second request, a POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.

When standard HTTP constructs are used:

The request is sent and the browser, upon receiving a response, inspects the response headers in order to determine if the response can and should be processed.

Note: Do NOT do use the wildcard in the access control header as it allows communication with any site.
Access-Control-Allow-Origin: * (Bad example)

Whitelist in Rails:

Gemfile
gem 'rack-cors', :require => 'rack/cors'

config/application.rb
module Sample
class Application < Rails::Application
config.middleware.use Rack::Cors do
allow do
origins 'someserver.example.com'
resource %r{/users/\d+.json},
:headers => ['Origin', 'Accept', 'Content-Type'],
:methods => [:post, :get]
end
end
end
end

== Security-related headers ==

To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter).

response.headers['X-header-name'] = 'value'

'''Rails 4''' provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases. Note: this does not account for content security policy.

ActionDispatch::Response.default_headers = {
'X-Frame-Options' => 'DENY',
'X-Content-Type-Options' => 'nosniff',
'X-XSS-Protection' => '1;'
}

Strict transport security is a special case, it is set in an environment file (e.g. production.rb)

config.force_ssl = true

For those not on the edge, there is a library ([https://github.com/twitter/secureheaders secure_headers]) for the same behavior with content security policy abstraction provided. It will automatically apply logic based on the user agent to produce a concise set of headers.

== Business Logic Bugs ==

Any application in any technology can contain business logic errors that result in security bugs. Business logic bugs are difficult to impossible to detect using automated tools. The best ways to prevent business logic security bugs are to do code review, pair program and write unit tests.

== Attack Surface ==

Generally speaking, Rails avoids open redirect and path traversal types of vulnerabilities because of its /config/routes.rb file which dictates what URL’s should be accessible and handled by which controllers. The routes file is a great place to look when thinking about the scope of the attack surface. An example might be as follows:

match ':controller(/:action(/:id(.:format)))'

In this case, this route allows any public method on any controller to be called as an action. As a developer, you want to make sure that users can only reach the controller methods intended and in the way intended.

== Sensitive Files ==

Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.

/config/database.yml - May contain production credentials.
/config/initializers/secret_token.rb - Contains a secret used to hash session cookie.
/db/seeds.rb - May contain seed data including bootstrap admin user.
/db/development.sqlite3 - May contain real data.

== Encryption ==

Rails uses OS encryption. Generally speaking, it is always a bad idea to write your own encryption.

Devise by default uses bcrypt for password hashing, which is an appropriate solution. Typically, the following config causes the 10 stretches for production: /config/initializers/devise.rb

config.stretches = Rails.env.test? ? 1 : 10

= Updating Rails and Having a Process for Updating Dependencies =

In early 2013, a number of critical vulnerabilities were identified in the Rails Framework. Organizations that had fallen behind current versions had more trouble updating and harder decisions along the way, including patching the source code for the framework itself.

An additional concern with Ruby applications in general is that most libraries (gems) are not signed by their authors. It is literally impossible to build a Rails based project with libraries that come from trusted sources. One good practice might be to audit the gems you are using.

In general, it is important to have a process for updating dependencies. An example process might define three mechanisms for triggering an update of response:
* Every month/quarter dependencies in general are updated.
* Every week important security vulnerabilities are taken into account and potentially trigger an update.
* In EXCEPTIONAL conditions, emergency updates may need to be applied.

= Tools =

Use [http://brakemanscanner.org/ brakeman], an open source code analysis tool for Rails applications, to identify many potential issues. It will not necessarily produce comprehensive security findings, but it can find easily exposed issues. A great way to see potential issues in Rails is to review the brakeman documentation of warning types.

There are emerging tools that can be used to track security issues in dependency sets, like [http://sourceninja.com SourceNinja].

= Authors and Primary Editors =
Matt Konda - mkonda [at] jemurai.com<br/>
Neil Matatall neil [at] matatall.com<br/>
Ken Johnson cktricky [at] gmail.com<br/>
Justin Collins justin [at] presidentbeef.com<br/>
Jon Rose - jrose [at] crowdsecurify.com<br/>
Lance Vaughn - lance [at] cabforward.com<br/>
Jon Claudius - jonathan.claudius [at] gmail.com<br/>
Jim Manico jim [at] owasp.org<br/>
Aaron Bedra aaron [at] aaronbedra.com<br/>

= Related Articles and References =

* [http://guides.rubyonrails.org/security.html The Official Rails Security Guide]
* [https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Rails_Security_Guide_V2 OWASP Ruby on Rails Security Guide]
* [http://code.google.com/p/ruby-security/wiki/Guide The Ruby Security Reviewers Guide]
* [https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security The Ruby on Rails Security Mailing List]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Ruby on Rails Cheatsheet

2013-02-14T17:55:06Z

Nmatatal:

DRAFT CHEAT SHEET - WORK IN PROGRESS

= Introduction =

This article intends to provide quick basic Ruby on Rails security tips for developers. The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.

= Items =
== Command Injection ==

Ruby offers a function called “eval” which will dynamically build new Ruby code based on Strings. It also has a number of ways to call system commands.

eval("ruby code here")
System("os command here")
`ls -al /` (backticks contain os command)
Kernel.exec("os command here")

While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application. Usually, its just a bad idea. If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible.

== SQL Injection ==

Ruby on Rails is often used with an ORM called ActiveRecord, though it is flexible and can be used with other data sources. Typically very simple Rails applications use methods on the Rails models to query data. Many use cases protect for SQL Injection out of the box. However, it is possible to write code that allows for SQL Injection.

Here is an example (Rails 2.X style):

@projects = Project.find(:all, :conditions => “name like #{params[:name]}”)

A Rails 3.X example:

name = params[:name]
@projects = Project.where(“name like ‘“ + name + “‘“);

In both of these cases, the statement is injectable because the name parameter is not escaped.

Here is the idiom for building this kind of statement:

@projects = Project.find(:all, :conditions => [ “name like ?”, “#{params[:name]}”] )

An AREL based solution:

@projects = Project.where("name like ?", "%#{params[:name]}%")

Use caution not to build SQL statements based on user controlled input. A list of more realistic and detailed examples is here: [http://rails-sqli.org rails-sqli.org].

== Cross-site Scripting (XSS) ==

By default, in Rails 3.0 protection against XSS comes as the default behavior. When string data is shown in views, it is escaped prior to being sent back to the browser. This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing. In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).

<%= raw @product.name %>
<%= @product.name.html_safe %> These are examples of how NOT to do it!
<%= content_tag @product.name %>

Unfortunately, any field that uses raw like this will be a potential XSS target. Note that there are also widespread misunderstandings about html_safe. [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail. Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.

One way to manage cases like this is to use a Rails provided helper method called sanitize:

<%= sanitize @project.name, :tags => %w(h1 h2 h3 h4 h5), :attributes => %() %>

This eliminates tags other than <nowiki><h1>, <h2>, <h3>, <h4>, <h5></nowiki>. It also disallows attributes on those tags. Note that it is critical to understand the tags you enable here. <nowiki><img></nowiki> may seem like an innocuous tag, but through various attributes on <nowiki><img/></nowiki> that are scriptable such as onError=””. Only by sanitizing only innocuous tags can XSS be prevented.

A more attractive alternative to using sanitize and real HTML content is to use an alternative markup language for rich text in an application (Examples include: markdown and textile) and disallow HTML tags. This ensures that the input accepted doesn’t include HTML content that could be malicious.

An often overlooked XSS attack vector is the href value of a link:

<%= link_to “Personal Website”, @user.website %>

If @user.website contains a link that starts with “javascript:”, the content will execute when a user clicks the generated link:

<a href=”javascript:alert(‘Haxored’)”>Personal Website</a>

== Sessions ==

By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.

The best practice is to use a database based session, which thankfully is very easy with Rails:

Project::Application.config.session_store :active_record_store

== Authentication ==

Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication. To enable authentication with Devise, one simply has to put the following in a controller:

class ProjectController < ApplicationController
before_filter :authenticate_user

As with other methods, this supports exceptions. Note that by default Devise only requires 6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb

config.password_length = 8..128

There are several possible ways to enforce complexity. One is to put a Validator in the user model.

validate :password_complexity
def password_complexity
if password.present? and not password.match(/\A(?=.*[a-z])(?=.*[A-Z])(?=.*\d).+\z/)
errors.add :password, "must include at least one lowercase letter, one uppercase letter, and one digit"
end
end

== Insecure Direct Object Reference or Forceful Browsing ==

By default, Ruby on Rails apps use a RESTful uri structure. That means that paths are often intuitive and guessable. To protect against a user trying to access or modify data that belongs to another user, it is important to specifically control actions. Out of the gate on a vanilla Rails application, there is no such built in protection. It is possible to do this by hand at the controller level.

It is also possible, and probably recommended, to consider resource-based access control libraries such as [https://github.com/ryanb/cancan cancan] to do this. This ensures that all operations on a database object are authorized by the business logic of the application.

== CSRF (Cross Site Request Forgery) ==

Ruby on Rails has specific, built in support for CSRF tokens. To enable it, or ensure that it is enabled, find the base ApplicationController and look for a directive such as the following:

class ApplicationController < ActionController::Base
protect_from_forgery

Note that the syntax for this type of control includes a way to add exceptions. Exceptions may be useful for API’s or other reasons - but should be reviewed and consciously included. In the example below, the Rails ProjectController will not provide CSRF protection for the show method.

class ProjectController < ApplicationController
protect_from_forgery :except => :show

Also note that by default Rails does not provide CSRF protection for any HTTP GET request.

== Mass Assignment and Strong Parameters ==

Although the major issue with Mass Assignment has been fixed by default in base Rails specifically when generating new projects, it still applies to older and upgraded projects so it is important to understand the issue and to ensure that only attributes that are intended to be modifiable are exposed.

When working with a model, the attributes on the model will not be accessible to forms being posted unless a programmer explicitly indicates that:

class Project < ActiveRecord::Base
attr_accessible :name, :admin
end

With the admin attribute accessible based on the example above, the following could work:

curl -d “project[name]=triage&project[admin]=1” host:port/projects

Review accessible attributes to ensure that they should be accessible. If you are working in Rails < 3.2.3 you should ensure that your attributes are whitelisted with the following:

config.active_record.whitelist_attributes = true

In Rails 4.0 strong parameters will be the recommended approach for handling attribute visibility. It is also possible to use the strong_parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications.

== Redirects and Forwards ==

Web applications often require the ability to dynamically redirect users based on client-supplied data. To clarify, dynamic redirection usually entails the client including a URL in a parameter within a request to the application. Once received by the application, the user is redirected to the URL specified in the request. For example:

http://www.example.com/redirect?url=http://www.example_commerce_site.com/checkout

The above request would redirect the user to http://www.example.com/checkout. The security concern associated with this functionality is leveraging an organization’s trusted brand to phish users and trick them into visiting a malicious site, in our example, “badhacker.com”. Example:

http://www.example.com/redirect?url=http://badhacker.com

The obvious fix for this type of vulnerability is to restrict to specific Top-Level Domains (TLDs), statically define specific sites, or map a key to it’s value. Example:

ACCEPTABLE_URLS = {
‘our_app_1’ => “https://www.example_commerce_site.com/checkout”,
‘our_app_2’ => “https://www.example_user_site.com/change_settings”
}

http://www.example.com/redirect?url=our_app_1

def redirect
url = ACCEPTABLE_URLS[“#{params[:url]}”]
redirect_to url if url
end

If matching user input against a list of approved sites or TLDs against regular expression is a must, it makes sense to leverage a library such as URI.parse() to obtain the host and then take the host value and match it against regular expression patterns. Those regular expressions must, at a minimum, have anchors or there is a greater chance of an attacker bypassing the validation routine.

Example:

require ‘uri’
host = URI.parse(“#{params[:url]}”).host
validation_routine(host) if host
def validation_routine(host)
# Validation routine where we use \A and \z as anchors *not* ^ and $
end

== Dynamic Render Paths ==

In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.

Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.

== Cross Origin Resource Sharing ==

Occasionally, a need arises to share resources with another domain. For example, a file-upload function that sends data via an AJAX request to another domain. In these cases, the same-origin rules followed by web browsers must be bent. Modern browsers, in compliance with HTML5 standards, will allow this to occur but in order to do this; a couple precautions must be taken.

When using a nonstandard HTTP construct, such as an atypical Content-Type header, for example, the following applies:

The receiving site should whitelist only those domains allowed to make such requests as well as set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain. Next, a second request, a POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.

When standard HTTP constructs are used:

The request is sent and the browser, upon receiving a response, inspects the response headers in order to determine if the response can and should be processed.

Note: Do NOT do use the wildcard in the access control header as it allows communication with any site.
Access-Control-Allow-Origin: * (Bad example)

Whitelist in Rails:

Gemfile
gem 'rack-cors', :require => 'rack/cors'

config/application.rb
module Sample
class Application < Rails::Application
config.middleware.use Rack::Cors do
allow do
origins 'someserver.example.com'
resource %r{/users/\d+.json},
:headers => ['Origin', 'Accept', 'Content-Type'],
:methods => [:post, :get]
end
end
end
end

== Security-related headers ==

To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter.

response.headers['X-header-name'] = 'value'

'''Rails 4''' provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases. Note: this does not account for content security policy.

ActionDispatch::Response.default_headers = {
'X-Frame-Options' => 'DENY',
'X-Content-Type-Options' => 'nosniff',
'X-XSS-Protection' => '1;'
}

Strict transport security is a special case, it is set in an environment file (e.g. production.rb)

config.force_ssl = true

For those not on the edge, there is a library ([https://github.com/twitter/secureheaders secure_headers]) for the same behavior with content security policy abstraction provided. It will automatically apply logic based on the user agent to produce a concise set of headers.

== Business Logic Bugs ==

Any application in any technology can contain business logic errors that result in security bugs. Business logic bugs are difficult to impossible to detect using automated tools. The best ways to prevent business logic security bugs are to do code review, pair program and write unit tests.

== Attack Surface ==

Generally speaking, Rails avoids open redirect and path traversal types of vulnerabilities because of its /config/routes.rb file which dictates what URL’s should be accessible and handled by which controllers. The routes file is a great place to look when thinking about the scope of the attack surface. An example might be as follows:

match ':controller(/:action(/:id(.:format)))'

In this case, this route allows any public method on any controller to be called as an action. As a developer, you want to make sure that users can only reach the controller methods intended and in the way intended.

== Sensitive Files ==

Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.

/config/database.yml - May contain production credentials.
/config/initializers/secret_token.rb - Contains a secret used to hash session cookie.
/db/seeds.rb - May contain seed data including bootstrap admin user.
/db/development.sqlite3 - May contain real data.

== Encryption ==

Rails uses OS encryption. Generally speaking, it is always a bad idea to write your own encryption.

Devise by default uses bcrypt for password hashing, which is an appropriate solution. Typically, the following config causes the 10 stretches for production: /config/initializers/devise.rb

config.stretches = Rails.env.test? ? 1 : 10

= Updating Rails and Having a Process for Updating Dependencies =

In early 2013, a number of critical vulnerabilities were identified in the Rails Framework. Organizations that had fallen behind current versions had more trouble updating and harder decisions along the way, including patching the source code for the framework itself.

An additional concern with Ruby applications in general is that most libraries (gems) are not signed by their authors. It is literally impossible to build a Rails based project with libraries that come from trusted sources. One good practice might be to audit the gems you are using.

In general, it is important to have a process for updating dependencies. An example process might define three mechanisms for triggering an update of response:
* Every month/quarter dependencies in general are updated.
* Every week important security vulnerabilities are taken into account and potentially trigger an update.
* In EXCEPTIONAL conditions, emergency updates may need to be applied.

= Tools =

Use [http://brakemanscanner.org/ brakeman], an open source code analysis tool for Rails applications, to identify many potential issues. It will not necessarily produce comprehensive security findings, but it can find easily exposed issues. A great way to see potential issues in Rails is to review the brakeman documentation of warning types.

There are emerging tools that can be used to track security issues in dependency sets, like [http://sourceninja.com SourceNinja].

= Authors and Primary Editors =
Matt Konda - mkonda [at] jemurai.com<br/>
Neil Matatall neil [at] matatall.com<br/>
Ken Johnson cktricky [at] gmail.com<br/>
Justin Collins justin [at] presidentbeef.com<br/>
Jon Rose - jrose [at] crowdsecurify.com<br/>
Lance Vaughn - lance [at] cabforward.com<br/>
Jon Claudius - jonathan.claudius [at] gmail.com<br/>
Jim Manico jim [at] owasp.org<br/>
Aaron Bedra aaron [at] aaronbedra.com<br/>

= Related Articles and References =

* [http://guides.rubyonrails.org/security.html The Official Rails Security Guide]
* [https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Rails_Security_Guide_V2 OWASP Ruby on Rails Security Guide]
* [http://code.google.com/p/ruby-security/wiki/Guide The Ruby Security Reviewers Guide]
* [https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security The Ruby on Rails Security Mailing List]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Ruby on Rails Cheatsheet

2013-02-14T17:40:37Z

Nmatatal: /* Insecure Direct Object Reference or Forceful Browsing */

DRAFT CHEAT SHEET - WORK IN PROGRESS

= Introduction =

This article intends to provide quick basic Ruby on Rails security tips for developers. The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.

= Items =
== Command Injection ==

Ruby offers a function called “eval” which will dynamically build new Ruby code based on Strings. It also has a number of ways to call system commands.

eval("ruby code here")
System("os command here")
`ls -al /` (backticks contain os command)
Kernel.exec("os command here")

While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application. Usually, its just a bad idea. If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible.

== SQL Injection ==

Ruby on Rails is often used with an ORM called ActiveRecord, though it is flexible and can be used with other data sources. Typically very simple Rails applications use methods on the Rails models to query data. Many use cases protect for SQL Injection out of the box. However, it is possible to write code that allows for SQL Injection.

Here is an example (Rails 2.X style):

@projects = Project.find(:all, :conditions => “name like #{params[:name]}”)

A Rails 3.X example:

name = params[:name]
@projects = Project.where(“name like ‘“ + name + “‘“);

In both of these cases, the statement is injectable because the name parameter is not escaped.

Here is the idiom for building this kind of statement:

@projects = Project.find(:all, :conditions => [ “name like ?”, “#{params[:name]}”] )

An AREL based solution:

@projects = Project.where("name like ?", "%#{params[:name]}%")

Use caution not to build SQL statements based on user controlled input. A list of more realistic and detailed examples is here: [http://rails-sqli.org rails-sqli.org].

== Cross-site Scripting (XSS) ==

By default, in Rails 3.0 protection against XSS comes as the default behavior. When string data is shown in views, it is escaped prior to being sent back to the browser. This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing. In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).

<%= raw @product.name %>
<%= @product.name.html_safe %> These are examples of how NOT to do it!
<%= content_tag @product.name %>

Unfortunately, any field that uses raw like this will be a potential XSS target. Note that there are also widespread misunderstandings about html_safe. [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail. Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.

One way to manage cases like this is to use a Rails provided helper method called sanitize:

<%= sanitize @project.name, :tags => %w(h1 h2 h3 h4 h5), :attributes => %() %>

This eliminates tags other than <nowiki><h1>, <h2>, <h3>, <h4>, <h5></nowiki>. It also disallows attributes on those tags. Note that it is critical to understand the tags you enable here. <nowiki><img></nowiki> may seem like an innocuous tag, but through various attributes on <nowiki><img/></nowiki> that are scriptable such as onError=””. Only by sanitizing only innocuous tags can XSS be prevented.

A more attractive alternative to using sanitize and real HTML content is to use an alternative markup language for rich text in an application (Examples include: markdown and textile) and disallow HTML tags. This ensures that the input accepted doesn’t include HTML content that could be malicious.

An often overlooked XSS attack vector is the href value of a link:

<%= link_to “Personal Website”, @user.website %>

If @user.website contains a link that starts with “javascript:”, the content will execute when a user clicks the generated link:

<a href=”javascript:alert(‘Haxored’)”>Personal Website</a>

== Sessions ==

By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.

The best practice is to use a database based session, which thankfully is very easy with Rails:

Project::Application.config.session_store :active_record_store

== Authentication ==

Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication. To enable authentication with Devise, one simply has to put the following in a controller:

class ProjectController < ApplicationController
before_filter :authenticate_user

As with other methods, this supports exceptions. Note that by default Devise only requires 6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb

config.password_length = 8..128

There are several possible ways to enforce complexity. One is to put a Validator in the user model.

validate :password_complexity
def password_complexity
if password.present? and not password.match(/\A(?=.*[a-z])(?=.*[A-Z])(?=.*\d).+\z/)
errors.add :password, "must include at least one lowercase letter, one uppercase letter, and one digit"
end
end

== Insecure Direct Object Reference or Forceful Browsing ==

By default, Ruby on Rails apps use a RESTful uri structure. That means that paths are often intuitive and guessable. To protect against a user trying to access or modify data that belongs to another user, it is important to specifically control actions. Out of the gate on a vanilla Rails application, there is no such built in protection. It is possible to do this by hand at the controller level.

It is also possible, and probably recommended, to consider resource-based access control libraries such as [https://github.com/ryanb/cancan cancan] to do this. This ensures that all operations on a database object are authorized by the business logic of the application.

== CSRF (Cross Site Request Forgery) ==

Ruby on Rails has specific, built in support for CSRF tokens. To enable it, or ensure that it is enabled, find the base ApplicationController and look for a directive such as the following:

class ApplicationController < ActionController::Base
protect_from_forgery

Note that the syntax for this type of control includes a way to add exceptions. Exceptions may be useful for API’s or other reasons - but should be reviewed and consciously included. In the example below, the Rails ProjectController will not provide CSRF protection for the show method.

class ProjectController < ApplicationController
protect_from_forgery :except => :show

Also note that by default Rails does not provide CSRF protection for any HTTP GET request.

== Mass Assignment and Strong Parameters ==

Although the major issue with Mass Assignment has been fixed by default in base Rails specifically when generating new projects, it still applies to older and upgraded projects so it is important to understand the issue and to ensure that only attributes that are intended to be modifiable are exposed.

When working with a model, the attributes on the model will not be accessible to forms being posted unless a programmer explicitly indicates that:

class Project < ActiveRecord::Base
attr_accessible :name, :admin
end

With the admin attribute accessible based on the example above, the following could work:

curl -d “project[name]=triage&project[admin]=1” host:port/projects

Review accessible attributes to ensure that they should be accessible. If you are working in Rails < 3.2.3 you should ensure that your attributes are whitelisted with the following:

config.active_record.whitelist_attributes = true

In Rails 4.0 strong parameters will be the recommended approach for handling attribute visibility. It is also possible to use the strong_parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications.

== Redirects and Forwards ==

Web applications often require the ability to dynamically redirect users based on client-supplied data. To clarify, dynamic redirection usually entails the client including a URL in a parameter within a request to the application. Once received by the application, the user is redirected to the URL specified in the request. For example:

http://www.example.com/redirect?url=http://www.example_commerce_site.com/checkout

The above request would redirect the user to http://www.example.com/checkout. The security concern associated with this functionality is leveraging an organization’s trusted brand to phish users and trick them into visiting a malicious site, in our example, “badhacker.com”. Example:

http://www.example.com/redirect?url=http://badhacker.com

The obvious fix for this type of vulnerability is to restrict to specific Top-Level Domains (TLDs), statically define specific sites, or map a key to it’s value. Example:

ACCEPTABLE_URLS = {
‘our_app_1’ => “https://www.example_commerce_site.com/checkout”,
‘our_app_2’ => “https://www.example_user_site.com/change_settings”
}

http://www.example.com/redirect?url=our_app_1

def redirect
url = ACCEPTABLE_URLS[“#{params[:url]}”]
redirect_to url if url
end

If matching user input against a list of approved sites or TLDs against regular expression is a must, it makes sense to leverage a library such as URI.parse() to obtain the host and then take the host value and match it against regular expression patterns. Those regular expressions must, at a minimum, have anchors or there is a greater chance of an attacker bypassing the validation routine.

Example:

require ‘uri’
host = URI.parse(“#{params[:url]}”).host
validation_routine(host) if host
def validation_routine(host)
# Validation routine where we use \A and \z as anchors *not* ^ and $
end

== Dynamic Render Paths ==

In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.

Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.

== Cross Origin Resource Sharing ==

Occasionally, a need arises to share resources with another domain. For example, a file-upload function that sends data via an AJAX request to another domain. In these cases, the same-origin rules followed by web browsers must be bent. Modern browsers, in compliance with HTML5 standards, will allow this to occur but in order to do this; a couple precautions must be taken.

When using a nonstandard HTTP construct, such as an atypical Content-Type header, for example, the following applies:

The receiving site should whitelist only those domains allowed to make such requests as well as set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain. Next, a second request, a POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.

When standard HTTP constructs are used:

The request is sent and the browser, upon receiving a response, inspects the response headers in order to determine if the response can and should be processed.

Note: Do NOT do use the wildcard in the access control header as it allows communication with any site.
Access-Control-Allow-Origin: * (Bad example)

Whitelist in Rails:

Gemfile
gem 'rack-cors', :require => 'rack/cors'

config/application.rb
module Sample
class Application < Rails::Application
config.middleware.use Rack::Cors do
allow do
origins 'someserver.example.com'
resource %r{/users/\d+.json},
:headers => ['Origin', 'Accept', 'Content-Type'],
:methods => [:post, :get]
end
end
end
end

== Business Logic Bugs ==

Any application in any technology can contain business logic errors that result in security bugs. Business logic bugs are difficult to impossible to detect using automated tools. The best ways to prevent business logic security bugs are to do code review, pair program and write unit tests.

== Attack Surface ==

Generally speaking, Rails avoids open redirect and path traversal types of vulnerabilities because of its /config/routes.rb file which dictates what URL’s should be accessible and handled by which controllers. The routes file is a great place to look when thinking about the scope of the attack surface. An example might be as follows:

match ':controller(/:action(/:id(.:format)))'

In this case, this route allows any public method on any controller to be called as an action. As a developer, you want to make sure that users can only reach the controller methods intended and in the way intended.

== Sensitive Files ==

Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.

/config/database.yml - May contain production credentials.
/config/initializers/secret_token.rb - Contains a secret used to hash session cookie.
/db/seeds.rb - May contain seed data including bootstrap admin user.
/db/development.sqlite3 - May contain real data.

== Encryption ==

Rails uses OS encryption. Generally speaking, it is always a bad idea to write your own encryption.

Devise by default uses bcrypt for password hashing, which is an appropriate solution. Typically, the following config causes the 10 stretches for production: /config/initializers/devise.rb

config.stretches = Rails.env.test? ? 1 : 10

= Updating Rails and Having a Process for Updating Dependencies =

In early 2013, a number of critical vulnerabilities were identified in the Rails Framework. Organizations that had fallen behind current versions had more trouble updating and harder decisions along the way, including patching the source code for the framework itself.

An additional concern with Ruby applications in general is that most libraries (gems) are not signed by their authors. It is literally impossible to build a Rails based project with libraries that come from trusted sources. One good practice might be to audit the gems you are using.

In general, it is important to have a process for updating dependencies. An example process might define three mechanisms for triggering an update of response:
* Every month/quarter dependencies in general are updated.
* Every week important security vulnerabilities are taken into account and potentially trigger an update.
* In EXCEPTIONAL conditions, emergency updates may need to be applied.

= Tools =

Use [http://brakemanscanner.org/ brakeman], an open source code analysis tool for Rails applications, to identify many potential issues. It will not necessarily produce comprehensive security findings, but it can find easily exposed issues. A great way to see potential issues in Rails is to review the brakeman documentation of warning types.

There are emerging tools that can be used to track security issues in dependency sets, like [http://sourceninja.com SourceNinja].

= Authors and Primary Editors =
Matt Konda - mkonda [at] jemurai.com<br/>
Neil Matatall neil [at] matatall.com<br/>
Ken Johnson cktricky [at] gmail.com<br/>
Justin Collins justin [at] presidentbeef.com<br/>
Jon Rose - jrose [at] crowdsecurify.com<br/>
Lance Vaughn - lance [at] cabforward.com<br/>
Jon Claudius - jonathan.claudius [at] gmail.com<br/>
Jim Manico jim [at] owasp.org<br/>
Aaron Bedra aaron [at] aaronbedra.com<br/>

= Related Articles and References =

* [http://guides.rubyonrails.org/security.html The Official Rails Security Guide]
* [https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Rails_Security_Guide_V2 OWASP Ruby on Rails Security Guide]
* [http://code.google.com/p/ruby-security/wiki/Guide The Ruby Security Reviewers Guide]
* [https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security The Ruby on Rails Security Mailing List]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-01-31T21:35:12Z

Nmatatal: /* RULE #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse */

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

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

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

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform. The OWASP [[ESAPI]] project has created an escaping library in a variety of languages including Java, PHP, Classic ASP, Cold Fusion, Python, and Haskell. The OWASP project also provides the [[OWASP Java Encoder Project]] and the [[OWASP Encoding Project]].

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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 use 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this.'''
</script>

Instead, consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= data.to_json %> <-- data is HTML escaped, or at least json entity escaped -->
</script>

<script>
var jsonText = document.getElementById('init_data').innerHTML; // unescapes the content of the span
var initData = JSON.parse(jsonText);
</script>

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

== RULE #4 - CSS Escape And Strictly Validate 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

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 will 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 and validation 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! 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, especially Javascript links. URL's should then 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. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way ==

'''OWASP AntiSamy'''

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

'''OWASP Java HTML Sanitizer'''

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| TODO
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-01-05T01:32:18Z

Nmatatal: /* RULE #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse */

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

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

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

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform. The OWASP [[ESAPI]] project has created an escaping library in a variety of languages including Java, PHP, Classic ASP, Cold Fusion, Python, and Haskell. The OWASP project also provides the [[OWASP Java Encoder Project]] and the [[OWASP Encoding Project]].

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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 use 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this.'''
</script>

Instead, consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<span style="display:none" id="init_data">
<%= data.to_json %> <-- data is HTML escaped -->
</span>

<script>
var jsonText = document.getElementById('init_data').innerHTML; // unescapes the content of the span
var initData = JSON.parse(jsonText);
</script>

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

== RULE #4 - CSS Escape And Strictly Validate 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

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 will 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 and validation 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! 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, especially Javascript links. URL's should then 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. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way ==

'''OWASP AntiSamy'''

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

'''OWASP Java HTML Sanitizer'''

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| TODO
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2012-10-11T00:21:51Z

Nmatatal: /* XSS Prevention Rules */

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

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

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

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform. The OWASP [[ESAPI]] project has created an escaping library in a variety of languages including Java, PHP, Classic ASP, Cold Fusion, Python, and Haskell. The OWASP project also provides the [[OWASP Java Encoder Project]] and the [[OWASP Encoding Project]].

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; 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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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 use 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values. Instead, consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<span style="display:none" id="init_data">
<%= data.to_json %> <-- data is HTML escaped -->
</span>

<script>
var jsonText = document.getElementById('init_data').innerHTML; // unescapes the content of the span
var initData = JSON.parse(jsonText);
</script>

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

== RULE #4 - CSS Escape And Strictly Validate 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

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 will 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 and validation 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! 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, especially Javascript links. URL's should then 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. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way ==

'''OWASP AntiSamy'''

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

'''OWASP Java HTML Sanitizer'''

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| TODO
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Orange County

2012-08-22T17:53:27Z

Nmatatal:

{{Chapter Template|chaptername=Orange County|extra=Lead by [mailto:shong.chong@owasp.org Shong Chong]

<paypal>Orange County</paypal>
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Orange_County|emailarchives=http://lists.owasp.org/pipermail/owasp-Orange_County}}
The chapter leader is [mailto:shong.chong@owasp.org Shong Chong].

Follow OWASP OC on Twitter: https://twitter.com/OWASPOC for the latest news (so I don't spam your inboxes)

== Sponsor ==

[[File:Hireright.png]]

== Local News ==

===Future Meetings ===

===Previous Meetings===

==== OWASP LA Event: Security Summit: April 25, 2012, 3:00PM - 8PM ====

(Note different time and location)<br>

'''Jerry Hoff VP, Static Code Analysis Division at WhiteHat Security, will be speaking about Webgoat. Shakeel Tufail, Federal Practice Director for HP Enterprise Security Solutions, will be speaking on securing software. Noa Bar Yosef, Senior Security Strategist at Imperva, will be speaking on "De-Anonymizing Anonymous". A concluding panel, moderated by Richard Greenberg, Information Security Officer for LA County Public Health, will have the speakers joined by Adnan Masood, a Software Engineer and Architect.

==== March 28th 2012 7PM ====

When: March 28th 7pm

Where: Irvine - 5151 California Ave, Irvine, CA 92617

Loose Schedule:
7:00 - 7:30: Introduction and networking
7:30 - 8:30: Presentation

===="WebGoat.NET"====

Abstract:
Jerry Hoff, the project leader of the OWASP Appsec Tutorial Series, and VP of the Static Code Analysis Division at WhiteHat Security, will be discussing his newest OWASP project, WebGoat.NET. For many years, the Java version of WebGoat has been available as a fantastic tool for learning application security from the Java perspective. Jerry has now created a parallel tool for ASP.NET developers to learn about application security. Jerry will be discussing how this tool can be used in a learning environment, and other issues related to application security education.

====Speaker Bio:====
Jerry Hoff is vice president of the Static Code Analysis division at WhiteHat Security. In this role, he oversees the development of WhiteHats cloud-based static application security testing (SAST) service. Prior to WhiteHat, Mr. Hoff was co-founder and managing partner ofInfrared Security, a leading application security professional services firm. Mr. Hoff is an experienced application security consultant with years of professional development and training delivery. He is also the lead of the OWASP AppSec Tutorial Series.

==== September 14th 2011 7PM ====

When: Wednesday September 17th 7pm
Where: TBD (Irvine)
http://www.meetup.com/ocrails/events/30043551/

Loose Schedule:
7:00 - 7:30: Introduction and networking
7:30 - 8:00: Brakeman with Justin Collins
8:00 - 8:15: Lightning Rounds
8:15 - 8:30: Brakeman Demo

Brakeman with Justin Collins:
While the popular Ruby on Rails web framework provides built-in protection
for many security vulnerabilities, it is still possible to misuse these
features or introduce other vulnerabilities to an application. Brakeman is a static code analysis tool designed specifically to find vulnerabilities and configuration issues in Ruby on Rails applications. Since it works at the source code level, Brakeman can be used at any point in development without the need for deploying the full application stack. To make it even simpler,
Brakeman can be integrated with Hudson/Jenkins to provide automatic monitoring of Brakeman results as code is committed. This talk will discuss how to use Brakeman and how it can help you create safer Rails applications.

Lightning Rounds:

Neil Matatall: Friendly_id + ancsetry

Drew Deponte: Guard, spork, BDD

==== June 29th 2011 7PM ====

[[http://owaspoc.eventbrite.com/ Registration Link]]

'''When''': Wednesday june 29th, 2011 7pm

'''Where: HireRight Offices'''
5151 California Avenue
Irvine, CA 92617

'''Pizza and refreshments will be provided by the sponsors of this meeting.
'''

===== Meeting Sponsors =====

Food and refreshments:
[[File:AppSecDC2010-Sponsor-trustwave.gif]]

Meeting location:
[[File:Hireright.png]]

===== Presentation Topic: =====
Featuring analysis of more than 220 data breach investigations and more than 2,300 penetration tests conducted by Trustwave's SpiderLabs, the Global Security Report 2011 identifies the top vulnerabilities business encountered in 2010 as well as a list of strategic initiatives to help your business improve its overall security.

The data gathered from these engagements is substantial and comprehensive. This presentation will be a summary of the results of the analysis of the data gathered during 2010. The results will be presented both technical and business impact analysis.

===== Charles Henderson, Director of Application Security Services of SpiderLabs at Trustwave =====

Henderson began his career in computer security in 1993, specializing in penetration testing as well as security and vulnerability research. As Director of Application Security Services at SpiderLabs, he leads the team responsible for Application Penetration Testing, Code Review, Secure Development Training, and other elite application security consulting services.

Prior to joining SpiderLabs, Henderson ran his own boutique application
security testing firm. Henderson’s firm provided offensive security services to a wide variety of clients in the United States and Europe.

Henderson speaks frequently at major industry events and conferences, including BlackHat, DEF CON, AppSec US, AppSec EU, SOURCE, and the International Association of Financial Crime Investigators convention.

====January 28th, 2011====

'''Registration link: [https://www.regonline.com/owasp_oc_jan]'''

'''Time:''' 1 PM - 5PM

'''Location: '''

[http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=5151+California+Ave&sll=33.621597,-117.740797&sspn=0.010489,0.019011&ie=UTF8&hq=&hnear=5151+California+Ave,+Irvine,+Orange,+California+92617&z=16&iwloc=A Hireright]

5151 California Ave

Irvine, California 92617

United States.

'''Topics:''' Threat Modeling, Application Security

'''Food:''' Provided

Speakers:

'''Samy Kamkar'''

Online Privacy and the Evercookie

Bio:

Samy Kamkar has lectured on computer security issues in over a dozen
countries, and his work has been featured on the front page of the New
York Times. As a grey-hat hacker, he makes and breaks computer
security for tech companies. In addition to his independent security
research, he co-founded Fonality, an IP PBX company.

'''Jim Manico'''

Back to Basics: Defensive Coding Principles for Web Development 101

The application security community is in deep need of prescriptive
solutions for developers. This talk will review the world of Web
Application Security from a "builder" point of view, focusing on
critical controls that all developers must master if they wish to build
low risk web applications today.

Bio:

Jim Manico is the chair of the OWASP Connections committee where he
focuses on producing and hosting the OWASP Podcast. Jim also is a
co-manager of the OWASP ESAPI Open Source project. Professionally, Jim
is an independent application security architect specializing in the
construction of low-risk web applications. Jim is also an application
security educator and assessment specialist.

'''Edward Bonver'''
Talk Title:

Threat Modeling at Symantec
[[File:OWASP-WWW-2011-Edward-Bonver-Threat-Modelint-at-Symantec.pptx]]

Abstract:

Threat Modeling is one of the most important security activities that a development/QA team needs to perform as part of a Security Development Lifecycle. This activity allows the team to build a complete security profile of the system being built. Threat Modeling is not always easy to get going for a team that has little or no security experience. In this presentation we’ll take a look at why Threat Modeling is so important; we’ll explore the process behind it, and how the process is being implemented and followed across Symantec.

Bio:

Edward Bonver is a principal software engineer on the product security team under the Office of the CTO at Symantec Corporation. In this capacity, Edward is responsible for working with software developers and quality assurance (QA) professionals across Symantec to continuously enhance the company’s software security practices through the adoption of methodologies, procedures and tools for secure coding and security testing. Within Symantec, Edward teaches secure coding and security testing classes for Symantec engineers, and also leads the company’s QA Security Task Force, which he founded. Prior to joining Symantec, Edward held software engineering and QA roles at Digital Equipment Corporation, Nbase and Zuma Networks.

Edward is a Certified Information Systems Security Professional (CISSP) and a Certified Secure Software Lifecycle Professional (CSSLP). He holds a master’s degree in computer science from California State University, Northridge, and a bachelor’s degree in computer science from Rochester Institute of Technology. Edward is a Ph.D. student at NOVA Southeastern University.

====Thursday, January 21st 2010====

Time: 7:30
Location: We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building. http://www.oit.uci.edu/computing/labs/training.html Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdfBD

For those who would like to avoid paying for parking, you can park in the University Center and take the campus shuttle: http://www.shuttle.uci.edu/maincampus/index.php

The shuttle runs until 10:45PM. The shuttle costs $1 per ride, but fees are rarely collected ;)

Title: Do VLANs allow for good application security?

Virtual Local Area Networks (VLANs) are not a new concept, and can help
any organization better control network access. I will present some of
the previous issues identified, what was the root cause, and how these
have been fixed in current technology. In addition we will talk about
how this can help to enhance security in your environment, and what
controls must be in place in order to implement such an environment. We
will also touch on how this can complicate your application environment,
but improve overall security.

I will touch on the controls that need to be reviewed and audited when
working with VMware, VLANs, and web applications, to ensure that these
networks are secure, and what to look for to potentially pass audit
criteria. I will also talk about where and how these controls have been
implemented in order to protect thousands of users while accessing one
of the most hostile networks in the world.

David M. N. Bryan
Senior Security Consultant

David has over 9+ years of computer security experience including,
consulting, engineering and administration. He has performed security
assessment projects for health care, nuclear, manufacturing,
pharmaceutical, banking and educational sectors. As an active
participant in the information security community, he volunteers at
DEFCON where he designs and implements the Firewall and Network for what
is said to be the most hostile network environment in the world.

He is also an active participant in the local Minneapolis security
groups both as a board member of OWASP MSP and DC612. His roots and
experience come from working for a large enterprise banks, designing and
managing enterprise security systems. In the more recent years he has
been working as an Information Security Consultant to review the
security and architecture of information computing environments.

====Thursday December 17th 2009====

7:30 PM, UC Irvine Campus, Room AIRB 1020

We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building.
http://www.oit.uci.edu/computing/labs/training.html
Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf

'''Abstract'''

'''Title: Pulling the Plug: Security Risks in the Next Generation of Offline Web Applications'''

As the line between desktop and web applications becomes increasingly blurry in a web 2.0 world, browser functionality is being pushed well beyond what it was originally intended for. Persistent client side storage has become a requirement for web applications if they are to be available both online and off. This need is being filled by a variety of technologies such as [http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage Gears (formerly Google Gears) and the Database Storage] functionality included in the emerging [http://dev.w3.org/html5/spec/Overview.html HTML 5 specification]. While all such technologies offer great promise, it is clear that the vast majority of developers simply do not understand their security implications.

Researching a variety of currently deployed implementations of these technologies has revealed a broad scope of vulnerabilities with frightening implications. Now attackers can target victims not just once, but every time they visit a site as the victim now carries and stores the attack with them. Imagine a scenario whereby updated confidential information is forwarded to an attacker every time a victim interacts with a given we application. The attacker no longer needs to worry about timing their attacks to ensure that the victim is authenticated as the victim attacks himself! Limited storage? Cookies that expire? Not a problem when entire databases are accessible with virtually unlimited storage and an infinite lifespan. Think these attacks are theoretical? Think again. In this talk we dive into these technologies and break down the risk posed by them when not properly understood. We will then detail a variety of real-world vulnerabilities that have been uncovered, including a new class of cross-site scripting and client-side SQL injection.

'''Bio'''

'''Michael Sutton'''
'''Vice President, Security Research – Zscaler'''

Michael Sutton has spent more than a decade in the security industry conducting leading-edge research, building teams of world-class researchers and educating others on a variety of security topics. As VP of Security Research, Michael heads Zscaler Labs, the research and development arm of the company. Zscaler Labs is responsible for researching emerging topics in web security and developing innovative security controls, which leverage the Zscaler in-the-cloud model. The team is comprised of researchers with a wealth of experience in the security industry.

Prior to joining Zscaler, Michael was the Security Evangelist for SPI Dynamics where, as an industry expert, he was responsible for researching, publishing and presenting on various security issues. In 2007, SPI Dynamics was acquired by Hewlett-Packard. Previously, Michael was a Research Director at iDefense where he led iDefense Labs, a team responsible for discovering and researching security vulnerabilities in a variety of technologies. iDefense was acquired by VeriSign in 2005. Michael is a frequent speaker at major information security conferences; he is regularly quoted by the media on various information security topics, has authored numerous articles and is the co-author of Fuzzing: Brute Force Vulnerability Discovery, an Addison-Wesley publication.

====Thursday, November 19th 2009====

When: November 19th 2009, 7:30PM
Where: Gina's Pizza, Irvine
Topics: Facebook privacy, web application firewalls, penetration testing, the reluctance for hackers to execute attacks, and random new technology. Announced OWASP OC/LAs intention to submit a proposal for AppSec 2010.

====Wednesday, October 14th 2009====

Separate meetings will be held for OWASP OC and OWASP@UCI (student group).

When: Wednesday 10/14 7:30PM
Where: Steelhead Brewery
Topics: News, Ideas, Chit-chat

This is a restaurant/bar with plenty of seating, but room for a projector is out of the question so this would be an informal round table discussion.

I have a presentation I'm working on regarding WAFs and Vulnerability Assessment Tools. If it pleases the group, I'd love to go over the presentation and discuss everyone's experiences. Also, it's a great way to get feedback :)

Neil

I'm open to suggestions of any kind: location, time, topics, etc

====Thursday, September 17th, 2009 7:30PM ====
'''Location:''' UC Irvine
Building: Calit2 building,building number 325 in quadrant H8 on the [http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf UC Irvine Map]
Room: 3008

Parking will be $7.
Please park in the [http://maps.google.com/maps?li=d&hl=en&f=d&iwstate1=dir:to&daddr=Parking+Structure+for+CalIT2%4033.643082,+-117.837593&geocode=CSJ9b4xJxrzxFUpaAQId5_D5-A&iwloc=1&dq=calit2,+uc+irvine,+ca&cid=33643082,-117837593,16505793731713499531&ei=v3bvSabfO6LejAOR2pjgAQ Anteater Parking Structure]

I can only unofficially say that if you park in the nearby shopping centers and walk, you may be able to park for free.

* <b>The Rise of Threat Analysis and the Fall of Compliance, Policies, and Standards in mitigating Web Application Security Risks</b>

====Apr 30, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Our fourth OC OWASP meeting will be an informal, roundtable discussion of current application security issues. Feel free to bring some ideas, code, slides, etc to contribute to the discussion. Hope to see everyone there!

====Feb 19, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Come talk application security at the third OWASP OC meeting. We'll discuss current application security topics and chapter issues over pizza. We have a room booked for 15-20 people so we'll be able to rant without disturbing the patrons :) See you there! [https://www.owasp.org/images/5/58/Cloud_Computing_Security.pdf Presentation Slides]

====Dec 17, 2008 6PM - 9PM====
Microsoft Campus
Room MPR1, 3 Park Plaza, Suite 1600, Irvine, CA, 92614

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=microsoft,+Irvine,+CA,+92614&sll=33.678479,-117.838368&sspn=0.009892,0.022745&g=3+Park+Plaza,+Irvine,+CA,+92614&ie=UTF8&ei=sCFJSfKPEo3UNc2ZmCc&cd=1&cid=33728042,-117783305,17507068988286890825&li=lmd&ll=33.731835,-117.78142&spn=0.039545,0.090981&z=14&iwloc=A Google Map]

This meeting will be a roundtable discussion of application security news, plus a few OWASP-themed challenges with prizes. Pizza will be provided and we'll head to the Yard House after the meeting.

====Aug 27, 2008, 7 PM - 9 PM====
Penny Saver

603 Valencia, Brea, CA 92822

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=603+valencia,+Brea,+CA+92822&sll=33.911348,-117.851629&sspn=0.009865,0.022745&ie=UTF8&ll=33.909478,-117.852917&spn=0.009866,0.022745&z=16&iwloc=addr Google Map]

Come meet up with web security professionals, have some pizza, and offer your thoughts for the direction of the OC chapter at our inaugural meeting! We are looking for speakers and venue sponsors for the next meeting. If you are interested, please contact the chapter leaders. Everyone is welcome to join us at our chapter meetings.

[[Category:OWASP Chapter]]

= Orange County OWASP Board Members =

*<b>Orange County Co-President</b> [mailto:neil@owasp.org Neil Matatall]
*<b>Orange County Co-President</b> Shong Chong
*<b>Orange County Co-President</b> Rob LaViolette
*<b>Orange County Treasurer:</b> [mailto: TBD]
*<b>Orange County Recording Secretary:</b> [mailto: TBD]
*<b>Orange County Board Member</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]

[[Category:California]]

Orange County

2012-08-22T17:51:01Z

Nmatatal:

{{Chapter Template|chaptername=Orange County|extra=Lead by the co-presidents [mailto:neil@owasp.org Neil Matatall], [mailto:roblav@owasp.org Rob LaViolette] and [mailto:shong.chong@owasp.org Shong Chong]

<paypal>Orange County</paypal>
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Orange_County|emailarchives=http://lists.owasp.org/pipermail/owasp-Orange_County}}
The chapter leader is [mailto:shong.chong@owasp.org Shong Chong].

Follow OWASP OC on Twitter: https://twitter.com/OWASPOC for the latest news (so I don't spam your inboxes)

== Sponsor ==

[[File:Hireright.png]]

== Local News ==

===Future Meetings ===

===Previous Meetings===

==== OWASP LA Event: Security Summit: April 25, 2012, 3:00PM - 8PM ====

(Note different time and location)<br>

'''Jerry Hoff VP, Static Code Analysis Division at WhiteHat Security, will be speaking about Webgoat. Shakeel Tufail, Federal Practice Director for HP Enterprise Security Solutions, will be speaking on securing software. Noa Bar Yosef, Senior Security Strategist at Imperva, will be speaking on "De-Anonymizing Anonymous". A concluding panel, moderated by Richard Greenberg, Information Security Officer for LA County Public Health, will have the speakers joined by Adnan Masood, a Software Engineer and Architect.

==== March 28th 2012 7PM ====

When: March 28th 7pm

Where: Irvine - 5151 California Ave, Irvine, CA 92617

Loose Schedule:
7:00 - 7:30: Introduction and networking
7:30 - 8:30: Presentation

===="WebGoat.NET"====

Abstract:
Jerry Hoff, the project leader of the OWASP Appsec Tutorial Series, and VP of the Static Code Analysis Division at WhiteHat Security, will be discussing his newest OWASP project, WebGoat.NET. For many years, the Java version of WebGoat has been available as a fantastic tool for learning application security from the Java perspective. Jerry has now created a parallel tool for ASP.NET developers to learn about application security. Jerry will be discussing how this tool can be used in a learning environment, and other issues related to application security education.

====Speaker Bio:====
Jerry Hoff is vice president of the Static Code Analysis division at WhiteHat Security. In this role, he oversees the development of WhiteHats cloud-based static application security testing (SAST) service. Prior to WhiteHat, Mr. Hoff was co-founder and managing partner ofInfrared Security, a leading application security professional services firm. Mr. Hoff is an experienced application security consultant with years of professional development and training delivery. He is also the lead of the OWASP AppSec Tutorial Series.

==== September 14th 2011 7PM ====

When: Wednesday September 17th 7pm
Where: TBD (Irvine)
http://www.meetup.com/ocrails/events/30043551/

Loose Schedule:
7:00 - 7:30: Introduction and networking
7:30 - 8:00: Brakeman with Justin Collins
8:00 - 8:15: Lightning Rounds
8:15 - 8:30: Brakeman Demo

Brakeman with Justin Collins:
While the popular Ruby on Rails web framework provides built-in protection
for many security vulnerabilities, it is still possible to misuse these
features or introduce other vulnerabilities to an application. Brakeman is a static code analysis tool designed specifically to find vulnerabilities and configuration issues in Ruby on Rails applications. Since it works at the source code level, Brakeman can be used at any point in development without the need for deploying the full application stack. To make it even simpler,
Brakeman can be integrated with Hudson/Jenkins to provide automatic monitoring of Brakeman results as code is committed. This talk will discuss how to use Brakeman and how it can help you create safer Rails applications.

Lightning Rounds:

Neil Matatall: Friendly_id + ancsetry

Drew Deponte: Guard, spork, BDD

==== June 29th 2011 7PM ====

[[http://owaspoc.eventbrite.com/ Registration Link]]

'''When''': Wednesday june 29th, 2011 7pm

'''Where: HireRight Offices'''
5151 California Avenue
Irvine, CA 92617

'''Pizza and refreshments will be provided by the sponsors of this meeting.
'''

===== Meeting Sponsors =====

Food and refreshments:
[[File:AppSecDC2010-Sponsor-trustwave.gif]]

Meeting location:
[[File:Hireright.png]]

===== Presentation Topic: =====
Featuring analysis of more than 220 data breach investigations and more than 2,300 penetration tests conducted by Trustwave's SpiderLabs, the Global Security Report 2011 identifies the top vulnerabilities business encountered in 2010 as well as a list of strategic initiatives to help your business improve its overall security.

The data gathered from these engagements is substantial and comprehensive. This presentation will be a summary of the results of the analysis of the data gathered during 2010. The results will be presented both technical and business impact analysis.

===== Charles Henderson, Director of Application Security Services of SpiderLabs at Trustwave =====

Henderson began his career in computer security in 1993, specializing in penetration testing as well as security and vulnerability research. As Director of Application Security Services at SpiderLabs, he leads the team responsible for Application Penetration Testing, Code Review, Secure Development Training, and other elite application security consulting services.

Prior to joining SpiderLabs, Henderson ran his own boutique application
security testing firm. Henderson’s firm provided offensive security services to a wide variety of clients in the United States and Europe.

Henderson speaks frequently at major industry events and conferences, including BlackHat, DEF CON, AppSec US, AppSec EU, SOURCE, and the International Association of Financial Crime Investigators convention.

====January 28th, 2011====

'''Registration link: [https://www.regonline.com/owasp_oc_jan]'''

'''Time:''' 1 PM - 5PM

'''Location: '''

[http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=5151+California+Ave&sll=33.621597,-117.740797&sspn=0.010489,0.019011&ie=UTF8&hq=&hnear=5151+California+Ave,+Irvine,+Orange,+California+92617&z=16&iwloc=A Hireright]

5151 California Ave

Irvine, California 92617

United States.

'''Topics:''' Threat Modeling, Application Security

'''Food:''' Provided

Speakers:

'''Samy Kamkar'''

Online Privacy and the Evercookie

Bio:

Samy Kamkar has lectured on computer security issues in over a dozen
countries, and his work has been featured on the front page of the New
York Times. As a grey-hat hacker, he makes and breaks computer
security for tech companies. In addition to his independent security
research, he co-founded Fonality, an IP PBX company.

'''Jim Manico'''

Back to Basics: Defensive Coding Principles for Web Development 101

The application security community is in deep need of prescriptive
solutions for developers. This talk will review the world of Web
Application Security from a "builder" point of view, focusing on
critical controls that all developers must master if they wish to build
low risk web applications today.

Bio:

Jim Manico is the chair of the OWASP Connections committee where he
focuses on producing and hosting the OWASP Podcast. Jim also is a
co-manager of the OWASP ESAPI Open Source project. Professionally, Jim
is an independent application security architect specializing in the
construction of low-risk web applications. Jim is also an application
security educator and assessment specialist.

'''Edward Bonver'''
Talk Title:

Threat Modeling at Symantec
[[File:OWASP-WWW-2011-Edward-Bonver-Threat-Modelint-at-Symantec.pptx]]

Abstract:

Threat Modeling is one of the most important security activities that a development/QA team needs to perform as part of a Security Development Lifecycle. This activity allows the team to build a complete security profile of the system being built. Threat Modeling is not always easy to get going for a team that has little or no security experience. In this presentation we’ll take a look at why Threat Modeling is so important; we’ll explore the process behind it, and how the process is being implemented and followed across Symantec.

Bio:

Edward Bonver is a principal software engineer on the product security team under the Office of the CTO at Symantec Corporation. In this capacity, Edward is responsible for working with software developers and quality assurance (QA) professionals across Symantec to continuously enhance the company’s software security practices through the adoption of methodologies, procedures and tools for secure coding and security testing. Within Symantec, Edward teaches secure coding and security testing classes for Symantec engineers, and also leads the company’s QA Security Task Force, which he founded. Prior to joining Symantec, Edward held software engineering and QA roles at Digital Equipment Corporation, Nbase and Zuma Networks.

Edward is a Certified Information Systems Security Professional (CISSP) and a Certified Secure Software Lifecycle Professional (CSSLP). He holds a master’s degree in computer science from California State University, Northridge, and a bachelor’s degree in computer science from Rochester Institute of Technology. Edward is a Ph.D. student at NOVA Southeastern University.

====Thursday, January 21st 2010====

Time: 7:30
Location: We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building. http://www.oit.uci.edu/computing/labs/training.html Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdfBD

For those who would like to avoid paying for parking, you can park in the University Center and take the campus shuttle: http://www.shuttle.uci.edu/maincampus/index.php

The shuttle runs until 10:45PM. The shuttle costs $1 per ride, but fees are rarely collected ;)

Title: Do VLANs allow for good application security?

Virtual Local Area Networks (VLANs) are not a new concept, and can help
any organization better control network access. I will present some of
the previous issues identified, what was the root cause, and how these
have been fixed in current technology. In addition we will talk about
how this can help to enhance security in your environment, and what
controls must be in place in order to implement such an environment. We
will also touch on how this can complicate your application environment,
but improve overall security.

I will touch on the controls that need to be reviewed and audited when
working with VMware, VLANs, and web applications, to ensure that these
networks are secure, and what to look for to potentially pass audit
criteria. I will also talk about where and how these controls have been
implemented in order to protect thousands of users while accessing one
of the most hostile networks in the world.

David M. N. Bryan
Senior Security Consultant

David has over 9+ years of computer security experience including,
consulting, engineering and administration. He has performed security
assessment projects for health care, nuclear, manufacturing,
pharmaceutical, banking and educational sectors. As an active
participant in the information security community, he volunteers at
DEFCON where he designs and implements the Firewall and Network for what
is said to be the most hostile network environment in the world.

He is also an active participant in the local Minneapolis security
groups both as a board member of OWASP MSP and DC612. His roots and
experience come from working for a large enterprise banks, designing and
managing enterprise security systems. In the more recent years he has
been working as an Information Security Consultant to review the
security and architecture of information computing environments.

====Thursday December 17th 2009====

7:30 PM, UC Irvine Campus, Room AIRB 1020

We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building.
http://www.oit.uci.edu/computing/labs/training.html
Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf

'''Abstract'''

'''Title: Pulling the Plug: Security Risks in the Next Generation of Offline Web Applications'''

As the line between desktop and web applications becomes increasingly blurry in a web 2.0 world, browser functionality is being pushed well beyond what it was originally intended for. Persistent client side storage has become a requirement for web applications if they are to be available both online and off. This need is being filled by a variety of technologies such as [http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage Gears (formerly Google Gears) and the Database Storage] functionality included in the emerging [http://dev.w3.org/html5/spec/Overview.html HTML 5 specification]. While all such technologies offer great promise, it is clear that the vast majority of developers simply do not understand their security implications.

Researching a variety of currently deployed implementations of these technologies has revealed a broad scope of vulnerabilities with frightening implications. Now attackers can target victims not just once, but every time they visit a site as the victim now carries and stores the attack with them. Imagine a scenario whereby updated confidential information is forwarded to an attacker every time a victim interacts with a given we application. The attacker no longer needs to worry about timing their attacks to ensure that the victim is authenticated as the victim attacks himself! Limited storage? Cookies that expire? Not a problem when entire databases are accessible with virtually unlimited storage and an infinite lifespan. Think these attacks are theoretical? Think again. In this talk we dive into these technologies and break down the risk posed by them when not properly understood. We will then detail a variety of real-world vulnerabilities that have been uncovered, including a new class of cross-site scripting and client-side SQL injection.

'''Bio'''

'''Michael Sutton'''
'''Vice President, Security Research – Zscaler'''

Michael Sutton has spent more than a decade in the security industry conducting leading-edge research, building teams of world-class researchers and educating others on a variety of security topics. As VP of Security Research, Michael heads Zscaler Labs, the research and development arm of the company. Zscaler Labs is responsible for researching emerging topics in web security and developing innovative security controls, which leverage the Zscaler in-the-cloud model. The team is comprised of researchers with a wealth of experience in the security industry.

Prior to joining Zscaler, Michael was the Security Evangelist for SPI Dynamics where, as an industry expert, he was responsible for researching, publishing and presenting on various security issues. In 2007, SPI Dynamics was acquired by Hewlett-Packard. Previously, Michael was a Research Director at iDefense where he led iDefense Labs, a team responsible for discovering and researching security vulnerabilities in a variety of technologies. iDefense was acquired by VeriSign in 2005. Michael is a frequent speaker at major information security conferences; he is regularly quoted by the media on various information security topics, has authored numerous articles and is the co-author of Fuzzing: Brute Force Vulnerability Discovery, an Addison-Wesley publication.

====Thursday, November 19th 2009====

When: November 19th 2009, 7:30PM
Where: Gina's Pizza, Irvine
Topics: Facebook privacy, web application firewalls, penetration testing, the reluctance for hackers to execute attacks, and random new technology. Announced OWASP OC/LAs intention to submit a proposal for AppSec 2010.

====Wednesday, October 14th 2009====

Separate meetings will be held for OWASP OC and OWASP@UCI (student group).

When: Wednesday 10/14 7:30PM
Where: Steelhead Brewery
Topics: News, Ideas, Chit-chat

This is a restaurant/bar with plenty of seating, but room for a projector is out of the question so this would be an informal round table discussion.

I have a presentation I'm working on regarding WAFs and Vulnerability Assessment Tools. If it pleases the group, I'd love to go over the presentation and discuss everyone's experiences. Also, it's a great way to get feedback :)

Neil

I'm open to suggestions of any kind: location, time, topics, etc

====Thursday, September 17th, 2009 7:30PM ====
'''Location:''' UC Irvine
Building: Calit2 building,building number 325 in quadrant H8 on the [http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf UC Irvine Map]
Room: 3008

Parking will be $7.
Please park in the [http://maps.google.com/maps?li=d&hl=en&f=d&iwstate1=dir:to&daddr=Parking+Structure+for+CalIT2%4033.643082,+-117.837593&geocode=CSJ9b4xJxrzxFUpaAQId5_D5-A&iwloc=1&dq=calit2,+uc+irvine,+ca&cid=33643082,-117837593,16505793731713499531&ei=v3bvSabfO6LejAOR2pjgAQ Anteater Parking Structure]

I can only unofficially say that if you park in the nearby shopping centers and walk, you may be able to park for free.

* <b>The Rise of Threat Analysis and the Fall of Compliance, Policies, and Standards in mitigating Web Application Security Risks</b>

====Apr 30, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Our fourth OC OWASP meeting will be an informal, roundtable discussion of current application security issues. Feel free to bring some ideas, code, slides, etc to contribute to the discussion. Hope to see everyone there!

====Feb 19, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Come talk application security at the third OWASP OC meeting. We'll discuss current application security topics and chapter issues over pizza. We have a room booked for 15-20 people so we'll be able to rant without disturbing the patrons :) See you there! [https://www.owasp.org/images/5/58/Cloud_Computing_Security.pdf Presentation Slides]

====Dec 17, 2008 6PM - 9PM====
Microsoft Campus
Room MPR1, 3 Park Plaza, Suite 1600, Irvine, CA, 92614

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=microsoft,+Irvine,+CA,+92614&sll=33.678479,-117.838368&sspn=0.009892,0.022745&g=3+Park+Plaza,+Irvine,+CA,+92614&ie=UTF8&ei=sCFJSfKPEo3UNc2ZmCc&cd=1&cid=33728042,-117783305,17507068988286890825&li=lmd&ll=33.731835,-117.78142&spn=0.039545,0.090981&z=14&iwloc=A Google Map]

This meeting will be a roundtable discussion of application security news, plus a few OWASP-themed challenges with prizes. Pizza will be provided and we'll head to the Yard House after the meeting.

====Aug 27, 2008, 7 PM - 9 PM====
Penny Saver

603 Valencia, Brea, CA 92822

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=603+valencia,+Brea,+CA+92822&sll=33.911348,-117.851629&sspn=0.009865,0.022745&ie=UTF8&ll=33.909478,-117.852917&spn=0.009866,0.022745&z=16&iwloc=addr Google Map]

Come meet up with web security professionals, have some pizza, and offer your thoughts for the direction of the OC chapter at our inaugural meeting! We are looking for speakers and venue sponsors for the next meeting. If you are interested, please contact the chapter leaders. Everyone is welcome to join us at our chapter meetings.

[[Category:OWASP Chapter]]

= Orange County OWASP Board Members =

*<b>Orange County Co-President</b> [mailto:neil@owasp.org Neil Matatall]
*<b>Orange County Co-President</b> Shong Chong
*<b>Orange County Co-President</b> Rob LaViolette
*<b>Orange County Treasurer:</b> [mailto: TBD]
*<b>Orange County Recording Secretary:</b> [mailto: TBD]
*<b>Orange County Board Member</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]

[[Category:California]]

Orange County

2012-04-13T21:29:57Z

Nmatatal: /* Local News */

{{Chapter Template|chaptername=Orange County|extra=Lead by the co-presidents [mailto:neil@owasp.org Neil Matatall], [mailto:roblav@owasp.org Rob LaViolette] and [mailto:shong.chong@owasp.org Shong Chong]

<paypal>Orange County</paypal>
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Orange_County|emailarchives=http://lists.owasp.org/pipermail/owasp-Orange_County}}
The chapter leaders are [mailto:neil@owasp.org Neil Matatall], Rob LaViolette, and Shong Chong.

Follow OWASP OC on Twitter: https://twitter.com/OWASPOC for the latest news (so I don't spam your inboxes)

== Sponsor ==

[[File:Hireright.png]]

== Local News ==

===Future Meetings ===

==== OWASP LA Event: Security Summit: April 25, 2012, 3:00PM - 8PM ====

(Note different time and location)<br>

'''Jerry Hoff VP, Static Code Analysis Division at WhiteHat Security, will be speaking about Webgoat. Shakeel Tufail, Federal Practice Director for HP Enterprise Security Solutions, will be speaking on securing software. Noa Bar Yosef, Senior Security Strategist at Imperva, will be speaking on "De-Anonymizing Anonymous". A concluding panel, moderated by Richard Greenberg, Information Security Officer for LA County Public Health, will have the speakers joined by Adnan Masood, a Software Engineer and Architect.

''Food and drinks will follow''.'''


<b>
Location:

Four Points by Sheraton Los Angeles </b>

5990 Green Valley Cir

Culver City, CA 90230

(310) 641-7740

RSVP at http://www.meetup.com/OWASP-Los-Angeles/

<br>

==== March 28th 2012 7PM ====

When: March 28th 7pm

Where: Irvine - 5151 California Ave, Irvine, CA 92617

Loose Schedule:
7:00 - 7:30: Introduction and networking
7:30 - 8:30: Presentation

===="WebGoat.NET"====

Abstract:
Jerry Hoff, the project leader of the OWASP Appsec Tutorial Series, and VP of the Static Code Analysis Division at WhiteHat Security, will be discussing his newest OWASP project, WebGoat.NET. For many years, the Java version of WebGoat has been available as a fantastic tool for learning application security from the Java perspective. Jerry has now created a parallel tool for ASP.NET developers to learn about application security. Jerry will be discussing how this tool can be used in a learning environment, and other issues related to application security education.

====Speaker Bio:====
Jerry Hoff is vice president of the Static Code Analysis division at WhiteHat Security. In this role, he oversees the development of WhiteHats cloud-based static application security testing (SAST) service. Prior to WhiteHat, Mr. Hoff was co-founder and managing partner ofInfrared Security, a leading application security professional services firm. Mr. Hoff is an experienced application security consultant with years of professional development and training delivery. He is also the lead of the OWASP AppSec Tutorial Series.

You: ???

===Previous Meetings===

==== September 14th 2011 7PM ====

When: Wednesday September 17th 7pm
Where: TBD (Irvine)
http://www.meetup.com/ocrails/events/30043551/

Loose Schedule:
7:00 - 7:30: Introduction and networking
7:30 - 8:00: Brakeman with Justin Collins
8:00 - 8:15: Lightning Rounds
8:15 - 8:30: Brakeman Demo

Brakeman with Justin Collins:
While the popular Ruby on Rails web framework provides built-in protection
for many security vulnerabilities, it is still possible to misuse these
features or introduce other vulnerabilities to an application. Brakeman is a static code analysis tool designed specifically to find vulnerabilities and configuration issues in Ruby on Rails applications. Since it works at the source code level, Brakeman can be used at any point in development without the need for deploying the full application stack. To make it even simpler,
Brakeman can be integrated with Hudson/Jenkins to provide automatic monitoring of Brakeman results as code is committed. This talk will discuss how to use Brakeman and how it can help you create safer Rails applications.

Lightning Rounds:

Neil Matatall: Friendly_id + ancsetry

Drew Deponte: Guard, spork, BDD

==== June 29th 2011 7PM ====

[[http://owaspoc.eventbrite.com/ Registration Link]]

'''When''': Wednesday june 29th, 2011 7pm

'''Where: HireRight Offices'''
5151 California Avenue
Irvine, CA 92617

'''Pizza and refreshments will be provided by the sponsors of this meeting.
'''

===== Meeting Sponsors =====

Food and refreshments:
[[File:AppSecDC2010-Sponsor-trustwave.gif]]

Meeting location:
[[File:Hireright.png]]

===== Presentation Topic: =====
Featuring analysis of more than 220 data breach investigations and more than 2,300 penetration tests conducted by Trustwave's SpiderLabs, the Global Security Report 2011 identifies the top vulnerabilities business encountered in 2010 as well as a list of strategic initiatives to help your business improve its overall security.

The data gathered from these engagements is substantial and comprehensive. This presentation will be a summary of the results of the analysis of the data gathered during 2010. The results will be presented both technical and business impact analysis.

===== Charles Henderson, Director of Application Security Services of SpiderLabs at Trustwave =====

Henderson began his career in computer security in 1993, specializing in penetration testing as well as security and vulnerability research. As Director of Application Security Services at SpiderLabs, he leads the team responsible for Application Penetration Testing, Code Review, Secure Development Training, and other elite application security consulting services.

Prior to joining SpiderLabs, Henderson ran his own boutique application
security testing firm. Henderson’s firm provided offensive security services to a wide variety of clients in the United States and Europe.

Henderson speaks frequently at major industry events and conferences, including BlackHat, DEF CON, AppSec US, AppSec EU, SOURCE, and the International Association of Financial Crime Investigators convention.

====January 28th, 2011====

'''Registration link: [https://www.regonline.com/owasp_oc_jan]'''

'''Time:''' 1 PM - 5PM

'''Location: '''

[http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=5151+California+Ave&sll=33.621597,-117.740797&sspn=0.010489,0.019011&ie=UTF8&hq=&hnear=5151+California+Ave,+Irvine,+Orange,+California+92617&z=16&iwloc=A Hireright]

5151 California Ave

Irvine, California 92617

United States.

'''Topics:''' Threat Modeling, Application Security

'''Food:''' Provided

Speakers:

'''Samy Kamkar'''

Online Privacy and the Evercookie

Bio:

Samy Kamkar has lectured on computer security issues in over a dozen
countries, and his work has been featured on the front page of the New
York Times. As a grey-hat hacker, he makes and breaks computer
security for tech companies. In addition to his independent security
research, he co-founded Fonality, an IP PBX company.

'''Jim Manico'''

Back to Basics: Defensive Coding Principles for Web Development 101

The application security community is in deep need of prescriptive
solutions for developers. This talk will review the world of Web
Application Security from a "builder" point of view, focusing on
critical controls that all developers must master if they wish to build
low risk web applications today.

Bio:

Jim Manico is the chair of the OWASP Connections committee where he
focuses on producing and hosting the OWASP Podcast. Jim also is a
co-manager of the OWASP ESAPI Open Source project. Professionally, Jim
is an independent application security architect specializing in the
construction of low-risk web applications. Jim is also an application
security educator and assessment specialist.

'''Edward Bonver'''
Talk Title:

Threat Modeling at Symantec
[[File:OWASP-WWW-2011-Edward-Bonver-Threat-Modelint-at-Symantec.pptx]]

Abstract:

Threat Modeling is one of the most important security activities that a development/QA team needs to perform as part of a Security Development Lifecycle. This activity allows the team to build a complete security profile of the system being built. Threat Modeling is not always easy to get going for a team that has little or no security experience. In this presentation we’ll take a look at why Threat Modeling is so important; we’ll explore the process behind it, and how the process is being implemented and followed across Symantec.

Bio:

Edward Bonver is a principal software engineer on the product security team under the Office of the CTO at Symantec Corporation. In this capacity, Edward is responsible for working with software developers and quality assurance (QA) professionals across Symantec to continuously enhance the company’s software security practices through the adoption of methodologies, procedures and tools for secure coding and security testing. Within Symantec, Edward teaches secure coding and security testing classes for Symantec engineers, and also leads the company’s QA Security Task Force, which he founded. Prior to joining Symantec, Edward held software engineering and QA roles at Digital Equipment Corporation, Nbase and Zuma Networks.

Edward is a Certified Information Systems Security Professional (CISSP) and a Certified Secure Software Lifecycle Professional (CSSLP). He holds a master’s degree in computer science from California State University, Northridge, and a bachelor’s degree in computer science from Rochester Institute of Technology. Edward is a Ph.D. student at NOVA Southeastern University.

====Thursday, January 21st 2010====

Time: 7:30
Location: We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building. http://www.oit.uci.edu/computing/labs/training.html Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdfBD

For those who would like to avoid paying for parking, you can park in the University Center and take the campus shuttle: http://www.shuttle.uci.edu/maincampus/index.php

The shuttle runs until 10:45PM. The shuttle costs $1 per ride, but fees are rarely collected ;)

Title: Do VLANs allow for good application security?

Virtual Local Area Networks (VLANs) are not a new concept, and can help
any organization better control network access. I will present some of
the previous issues identified, what was the root cause, and how these
have been fixed in current technology. In addition we will talk about
how this can help to enhance security in your environment, and what
controls must be in place in order to implement such an environment. We
will also touch on how this can complicate your application environment,
but improve overall security.

I will touch on the controls that need to be reviewed and audited when
working with VMware, VLANs, and web applications, to ensure that these
networks are secure, and what to look for to potentially pass audit
criteria. I will also talk about where and how these controls have been
implemented in order to protect thousands of users while accessing one
of the most hostile networks in the world.

David M. N. Bryan
Senior Security Consultant

David has over 9+ years of computer security experience including,
consulting, engineering and administration. He has performed security
assessment projects for health care, nuclear, manufacturing,
pharmaceutical, banking and educational sectors. As an active
participant in the information security community, he volunteers at
DEFCON where he designs and implements the Firewall and Network for what
is said to be the most hostile network environment in the world.

He is also an active participant in the local Minneapolis security
groups both as a board member of OWASP MSP and DC612. His roots and
experience come from working for a large enterprise banks, designing and
managing enterprise security systems. In the more recent years he has
been working as an Information Security Consultant to review the
security and architecture of information computing environments.

====Thursday December 17th 2009====

7:30 PM, UC Irvine Campus, Room AIRB 1020

We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building.
http://www.oit.uci.edu/computing/labs/training.html
Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf

'''Abstract'''

'''Title: Pulling the Plug: Security Risks in the Next Generation of Offline Web Applications'''

As the line between desktop and web applications becomes increasingly blurry in a web 2.0 world, browser functionality is being pushed well beyond what it was originally intended for. Persistent client side storage has become a requirement for web applications if they are to be available both online and off. This need is being filled by a variety of technologies such as [http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage Gears (formerly Google Gears) and the Database Storage] functionality included in the emerging [http://dev.w3.org/html5/spec/Overview.html HTML 5 specification]. While all such technologies offer great promise, it is clear that the vast majority of developers simply do not understand their security implications.

Researching a variety of currently deployed implementations of these technologies has revealed a broad scope of vulnerabilities with frightening implications. Now attackers can target victims not just once, but every time they visit a site as the victim now carries and stores the attack with them. Imagine a scenario whereby updated confidential information is forwarded to an attacker every time a victim interacts with a given we application. The attacker no longer needs to worry about timing their attacks to ensure that the victim is authenticated as the victim attacks himself! Limited storage? Cookies that expire? Not a problem when entire databases are accessible with virtually unlimited storage and an infinite lifespan. Think these attacks are theoretical? Think again. In this talk we dive into these technologies and break down the risk posed by them when not properly understood. We will then detail a variety of real-world vulnerabilities that have been uncovered, including a new class of cross-site scripting and client-side SQL injection.

'''Bio'''

'''Michael Sutton'''
'''Vice President, Security Research – Zscaler'''

Michael Sutton has spent more than a decade in the security industry conducting leading-edge research, building teams of world-class researchers and educating others on a variety of security topics. As VP of Security Research, Michael heads Zscaler Labs, the research and development arm of the company. Zscaler Labs is responsible for researching emerging topics in web security and developing innovative security controls, which leverage the Zscaler in-the-cloud model. The team is comprised of researchers with a wealth of experience in the security industry.

Prior to joining Zscaler, Michael was the Security Evangelist for SPI Dynamics where, as an industry expert, he was responsible for researching, publishing and presenting on various security issues. In 2007, SPI Dynamics was acquired by Hewlett-Packard. Previously, Michael was a Research Director at iDefense where he led iDefense Labs, a team responsible for discovering and researching security vulnerabilities in a variety of technologies. iDefense was acquired by VeriSign in 2005. Michael is a frequent speaker at major information security conferences; he is regularly quoted by the media on various information security topics, has authored numerous articles and is the co-author of Fuzzing: Brute Force Vulnerability Discovery, an Addison-Wesley publication.

====Thursday, November 19th 2009====

When: November 19th 2009, 7:30PM
Where: Gina's Pizza, Irvine
Topics: Facebook privacy, web application firewalls, penetration testing, the reluctance for hackers to execute attacks, and random new technology. Announced OWASP OC/LAs intention to submit a proposal for AppSec 2010.

====Wednesday, October 14th 2009====

Separate meetings will be held for OWASP OC and OWASP@UCI (student group).

When: Wednesday 10/14 7:30PM
Where: Steelhead Brewery
Topics: News, Ideas, Chit-chat

This is a restaurant/bar with plenty of seating, but room for a projector is out of the question so this would be an informal round table discussion.

I have a presentation I'm working on regarding WAFs and Vulnerability Assessment Tools. If it pleases the group, I'd love to go over the presentation and discuss everyone's experiences. Also, it's a great way to get feedback :)

Neil

I'm open to suggestions of any kind: location, time, topics, etc

====Thursday, September 17th, 2009 7:30PM ====
'''Location:''' UC Irvine
Building: Calit2 building,building number 325 in quadrant H8 on the [http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf UC Irvine Map]
Room: 3008

Parking will be $7.
Please park in the [http://maps.google.com/maps?li=d&hl=en&f=d&iwstate1=dir:to&daddr=Parking+Structure+for+CalIT2%4033.643082,+-117.837593&geocode=CSJ9b4xJxrzxFUpaAQId5_D5-A&iwloc=1&dq=calit2,+uc+irvine,+ca&cid=33643082,-117837593,16505793731713499531&ei=v3bvSabfO6LejAOR2pjgAQ Anteater Parking Structure]

I can only unofficially say that if you park in the nearby shopping centers and walk, you may be able to park for free.

* <b>The Rise of Threat Analysis and the Fall of Compliance, Policies, and Standards in mitigating Web Application Security Risks</b>

====Apr 30, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Our fourth OC OWASP meeting will be an informal, roundtable discussion of current application security issues. Feel free to bring some ideas, code, slides, etc to contribute to the discussion. Hope to see everyone there!

====Feb 19, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Come talk application security at the third OWASP OC meeting. We'll discuss current application security topics and chapter issues over pizza. We have a room booked for 15-20 people so we'll be able to rant without disturbing the patrons :) See you there! [https://www.owasp.org/images/5/58/Cloud_Computing_Security.pdf Presentation Slides]

====Dec 17, 2008 6PM - 9PM====
Microsoft Campus
Room MPR1, 3 Park Plaza, Suite 1600, Irvine, CA, 92614

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=microsoft,+Irvine,+CA,+92614&sll=33.678479,-117.838368&sspn=0.009892,0.022745&g=3+Park+Plaza,+Irvine,+CA,+92614&ie=UTF8&ei=sCFJSfKPEo3UNc2ZmCc&cd=1&cid=33728042,-117783305,17507068988286890825&li=lmd&ll=33.731835,-117.78142&spn=0.039545,0.090981&z=14&iwloc=A Google Map]

This meeting will be a roundtable discussion of application security news, plus a few OWASP-themed challenges with prizes. Pizza will be provided and we'll head to the Yard House after the meeting.

====Aug 27, 2008, 7 PM - 9 PM====
Penny Saver

603 Valencia, Brea, CA 92822

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=603+valencia,+Brea,+CA+92822&sll=33.911348,-117.851629&sspn=0.009865,0.022745&ie=UTF8&ll=33.909478,-117.852917&spn=0.009866,0.022745&z=16&iwloc=addr Google Map]

Come meet up with web security professionals, have some pizza, and offer your thoughts for the direction of the OC chapter at our inaugural meeting! We are looking for speakers and venue sponsors for the next meeting. If you are interested, please contact the chapter leaders. Everyone is welcome to join us at our chapter meetings.

[[Category:OWASP Chapter]]

= Orange County OWASP Board Members =

*<b>Orange County Co-President</b> [mailto:neil@owasp.org Neil Matatall]
*<b>Orange County Co-President</b> Shong Chong
*<b>Orange County Co-President</b> Rob LaViolette
*<b>Orange County Treasurer:</b> [mailto: TBD]
*<b>Orange County Recording Secretary:</b> [mailto: TBD]
*<b>Orange County Board Member</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]

[[Category:California]]

Abridged SQL Injection Prevention Cheat Sheet

2011-11-18T22:20:16Z

Nmatatal:

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

SQL Injection is one of the most damaging web vulnerabilities. It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or facilitate command injection. This cheat sheet is a derivative work of the [[SQL Injection Prevention Cheat Sheet]].

= Parametrized Query Examples =

SQL Injection is best prevented through the use of [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29 ''parametrized queries'']. The following chart demonstrates, with real-world code samples, how to build parametrized queries in most of the common web languages.

{| class="wikitable nowraplinks"
|-
! Language - Library
! Parametrized Query
|-
| Java - Standard
|
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );
|-
| Java - Hibernate
|
Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);
|-
| .NET/C#
|
String query = "SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}
|-
| ASP.NET
|
string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";
'''SqlCommand command = new SqlCommand(sql);'''
'''command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));'''
command.Parameters["@CustomerId"].Value = 1;
|-
| Ruby - ActiveRecord
|
'''# Create'''
Project.create!(:name => 'owasp')
'''# Read'''
Project.all(:conditions => "name = ?", name)
Project.all(:conditions => { :name => name })
Project.where("name = :name", :name => name)
'''# Update'''
project.update_attributes(:name => 'owasp')
'''# Delete'''
Project.delete(:name => 'name')
|-
| Ruby
|
insert_new_user = db.prepare "INSERT INTO users (name, age, gender) VALUES (?, ? ,?)"
insert_new_user.execute 'aizatto', '20', 'male'
|-
| PHP - PDO
|
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
'''$stmt->bindParam(':name', $name);'''
'''$stmt->bindParam(':value', $value);'''
|-
| Cold Fusion
|
<cfquery name = "getFirst" dataSource = "cfsnippets">
'''SELECT * FROM #strDatabasePrefix#_courses WHERE intCourseID ='''
'''<cfqueryparam value = #intCourseID# CFSQLType = "CF_SQL_INTEGER">'''
</cfquery>
|-
| Perl - DBI
|
my $sql = "INSERT INTO foo (bar, baz) VALUES ( ?, ? )";
'''my $sth = $dbh->prepare( $sql );'''
'''$sth->execute( $bar, $baz );'''
|}

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim [at] owasp.org

[[Category:Cheatsheets]]

Abridged SQL Injection Prevention Cheat Sheet

2011-11-18T22:04:18Z

Nmatatal: /* Parametrized Query Examples */

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

SQL Injection is one of the most damaging web vulnerabilities. It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or facilitate command injection. This cheat sheet is a derivative work of the [[SQL Injection Prevention Cheat Sheet]].

= Parametrized Query Examples =

SQL Injection is best prevented through the use of [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29 ''parametrized queries'']. The following chart demonstrates, with real-world code samples, how to build parametrized queries in most of the common web languages.

{| class="wikitable nowraplinks"
|-
! Language - Library
! Parametrized Query
|-
| Java - Standard
|
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );
|-
| Java - Hibernate
|
Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);
|-
| .NET/C#
|
String query = "SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}
|-
| ASP.NET
|
string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";
'''SqlCommand command = new SqlCommand(sql);'''
'''command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));'''
command.Parameters["@CustomerId"].Value = 1;
|-
| Ruby - ActiveRecord
|
'''# Create'''
Project.create!(:name => 'owasp')
'''# Read'''
Project.all(:conditions => "name = ?", name)
Project.all(:conditions => { :name => name })
Project.where("name = :name", :name => name)
'''# Update'''
project.update_attributes(:name => 'owasp')
'''# Delete'''
Project.delete(:name => 'name')
|-
| PHP - PDO
|
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
'''$stmt->bindParam(':name', $name);'''
'''$stmt->bindParam(':value', $value);'''
|-
| Cold Fusion
|
<cfquery name = "getFirst" dataSource = "cfsnippets">
'''SELECT * FROM #strDatabasePrefix#_courses WHERE intCourseID ='''
'''<cfqueryparam value = #intCourseID# CFSQLType = "CF_SQL_INTEGER">'''
</cfquery>
|-
| Perl - DBI
|
my $sql = "INSERT INTO foo (bar, baz) VALUES ( ?, ? )";
'''my $sth = $dbh->prepare( $sql );'''
'''$sth->execute( $bar, $baz );'''
|}

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim [at] owasp.org

[[Category:Cheatsheets]]

Abridged SQL Injection Prevention Cheat Sheet

2011-11-18T21:46:15Z

Nmatatal:

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

SQL Injection is one of the most damaging web vulnerabilities. It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or facilitate command injection. This cheat sheet is a derivative work of the [[SQL Injection Prevention Cheat Sheet]].

= Parametrized Query Examples =

SQL Injection is best prevented through the use of [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29 ''parametrized queries'']. The following chart demonstrates, with real-world code samples, how to build parametrized queries in most of the common web languages.

{| class="wikitable nowraplinks"
|-
! Language - Library
! Parametrized Query
|-
| Java - Standard
|
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );
|-
| Java - Hibernate
|
Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);
|-
| .NET/C#
|
String query = "SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}
|-
| ASP.NET
|
string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";
'''SqlCommand command = new SqlCommand(sql);'''
'''command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));'''
command.Parameters["@CustomerId"].Value = 1;
|-
| Ruby - ActiveRecord
|
'''# Create'''
'''Project.create!(:name => 'owasp')'''
'''# Read'''
'''Project.all(:conditions => "name = ?", name)'''
'''Project.all(:conditions => { :name => name })'''
'''Project.where("name = :name", :name => name)'''
'''# Update'''
'''project.update_attributes(:name => 'owasp')'''
'''# Delete'''
'''Project.delete(:name => 'name')'''
|-
| PHP - PDO
|
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
'''$stmt->bindParam(':name', $name);'''
'''$stmt->bindParam(':value', $value);'''
|-
| Cold Fusion
|
<cfquery name = "getFirst" dataSource = "cfsnippets">
'''SELECT * FROM #strDatabasePrefix#_courses WHERE intCourseID ='''
'''<cfqueryparam value = #intCourseID# CFSQLType = "CF_SQL_INTEGER">'''
</cfquery>
|-
| Perl - DBI
|
my $sql = "INSERT INTO foo (bar, baz) VALUES ( ?, ? )";
'''my $sth = $dbh->prepare( $sql );'''
'''$sth->execute( $bar, $baz );'''
|}

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim [at] owasp.org

[[Category:Cheatsheets]]

Abridged SQL Injection Prevention Cheat Sheet

2011-11-18T21:40:08Z

Nmatatal: /* Parametrized Query Examples */

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

SQL Injection is one of the most damaging web vulnerabilities. It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or facilitate command injection. This cheat sheet is a derivative work of the [[SQL Injection Prevention Cheat Sheet]].

= Parametrized Query Examples =

SQL Injection is best prevented through the use of [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29 ''parametrized queries'']. The following chart demonstrates, with real-world code samples, how to build parametrized queries in most of the common web languages.

{| class="wikitable nowraplinks"
|-
! Language - Library
! Parametrized Query
|-
| Java - Standard
|
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );
|-
| Java - Hibernate
|
Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);
|-
| .NET/C#
|
String query = "SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}
|-
| ASP.NET
|
string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";
'''SqlCommand command = new SqlCommand(sql);'''
'''command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));'''
command.Parameters["@CustomerId"].Value = 1;
|-
| Ruby - ActiveRecord
|
'''Project.all(:conditions => "name = ?", name)'''
'''Project.all(:conditions => { :name => name })'''
'''Project.where("name = :name", :name => name)'''
|-
| PHP - PDO
|
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
'''$stmt->bindParam(':name', $name);'''
'''$stmt->bindParam(':value', $value);'''
|-
| Cold Fusion
|
<cfquery name = "getFirst" dataSource = "cfsnippets">
'''SELECT * FROM #strDatabasePrefix#_courses WHERE intCourseID ='''
'''<cfqueryparam value = #intCourseID# CFSQLType = "CF_SQL_INTEGER">'''
</cfquery>
|-
| Perl - DBI
|
my $sql = "INSERT INTO foo (bar, baz) VALUES ( ?, ? )";
'''my $sth = $dbh->prepare( $sql );'''
'''$sth->execute( $bar, $baz );'''
|}

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim [at] owasp.org

[[Category:Cheatsheets]]

Abridged SQL Injection Prevention Cheat Sheet

2011-11-18T21:39:16Z

Nmatatal: /* Parametrized Query Examples */

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

SQL Injection is one of the most damaging web vulnerabilities. It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or facilitate command injection. This cheat sheet is a derivative work of the [[SQL Injection Prevention Cheat Sheet]].

= Parametrized Query Examples =

SQL Injection is best prevented through the use of [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29 ''parametrized queries'']. The following chart demonstrates, with real-world code samples, how to build parametrized queries in most of the common web languages.

{| class="wikitable nowraplinks"
|-
! Language - Library
! Parametrized Query
|-
| Java - Standard
|
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );
|-
| Java - Hibernate
|
Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);
|-
| .NET/C#
|
String query = "SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}
|-
| ASP.NET
|
string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";
'''SqlCommand command = new SqlCommand(sql);'''
'''command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));'''
command.Parameters["@CustomerId"].Value = 1;
|-
| Ruby
|
'''Project.all(:conditions => "name = ?", name)'''
'''Project.all(:conditions => { :name => name })'''
|-
| PHP - PDO
|
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
'''$stmt->bindParam(':name', $name);'''
'''$stmt->bindParam(':value', $value);'''
|-
| Cold Fusion
|
<cfquery name = "getFirst" dataSource = "cfsnippets">
'''SELECT * FROM #strDatabasePrefix#_courses WHERE intCourseID ='''
'''<cfqueryparam value = #intCourseID# CFSQLType = "CF_SQL_INTEGER">'''
</cfquery>
|-
| Perl - DBI
|
my $sql = "INSERT INTO foo (bar, baz) VALUES ( ?, ? )";
'''my $sth = $dbh->prepare( $sql );'''
'''$sth->execute( $bar, $baz );'''
|}

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim [at] owasp.org

[[Category:Cheatsheets]]

Projects/OWASP Passw3rd Project/Releases/Current

2011-11-02T18:20:38Z

Nmatatal: Redirected page to Projects/OWASP Passw3rd Project/Releases/passw3rd-0.1.0

#REDIRECT [[Projects/OWASP Passw3rd Project/Releases/passw3rd-0.1.0]]

Projects/OWASP Passw3rd Project/Releases/Current

2011-11-02T18:19:35Z

Nmatatal: Redirected page to Https://www.owasp.org/index.php/Projects/OWASP Passw3rd Project/Releases/passw3rd-0.1.0

#REDIRECT [[https://www.owasp.org/index.php/Projects/OWASP_Passw3rd_Project/Releases/passw3rd-0.1.0]]

Projects/OWASP Passw3rd Project/Releases/passw3rd-0.1.0

2011-11-02T18:18:46Z

Nmatatal: Created page with "{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude> | project_name = Passw3rd | project_home_page = https://www.owasp.org/index.php/OWASP_Passw3rd_..."

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = Passw3rd
| project_home_page = https://www.owasp.org/index.php/OWASP_Passw3rd_Project

| release_name = passw3rd-0.1.0
| release_date = Nov 1, 2011
| release_description = AES 256 by default, support URIs, production level code (hopefully)
| release_license = MIT
| release_download_link = https://rubygems.org/gems/passw3rd/versions/0.1.0

| leader_name[1] = Neil Matatall
| leader_email[1] = neil@owasp.org
| leader_username[1] = nmatatal

| contributor_name[1] = Neil Matatall
| contributor_email[1] = neil@owasp.org
| contributor_username[1] = nmatatal

| contributor_name[2] = Edward Bonver
| contributor_name[3] = Ben Duoung

| release_notes = https://github.com/oreoshake/passw3rd/commit/4ff412fe03c201ca86bb76466a7e095870d19973

| links_url[1] = https://github.com/oreoshake/passw3rd
| links_name[1] = Github page
}}

Projects/OWASP Passw3rd Project

2011-11-02T18:11:38Z

Nmatatal:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP Passw3rd Project
| project_home_page = OWASP Passw3rd Project
| project_description = Store passwords in encrypted files with an easy to use command line interface, and utilities to use the passwords in code. In its simplest form, the keys are generated per environment with OS access controls while the password files are stored in SCM.

| project_license = MIT

| leader_name1 = Neil Matatall
| leader_email1 = neil@owasp.org
| leader_username1 = nmatatal

| contributor_name[1-10] = Brendon Murphey
| contributor_email[1-10] =
| contributor_username[1-10] =

| pamphlet_link = https://www.owasp.org/images/8/86/Passw3rd-Pamphlet.pptx

| presentation_link = https://www.owasp.org/images/f/f7/Passw3rd.pptx

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-passw3rd-project

| project_road_map = https://www.owasp.org/index.php/OWASP_Passw3rd_Project/Roadmap

| links_url1 = https://github.com/oreoshake/passw3rd
| links_name1 = Passw3rd @ Github

| links_url4 = http://rubygems.org/gems/passw3rd
| links_name4 = Passw3rd @ Ruby Gems

| links_url3 = https://github.com/bemurphy
| links_name3 = Brendon Murphey's Github Page
| links_url2 = http://www.youtube.com/watch?v=BzbiSPOJUxc&feature=channel_video_title
| links_name2 = OC Rails Passw3rd Presentation on youtube
| links_url[5-10] =
| links_name[5-10] =

| release_1 = password-0.0.5
| release_2 = passw3rd-0.1.0
| release_3 =
| release_4 =


| project_about_page = Projects/OWASP Passw3rd Project

}}

File:Passw3rd.pptx

2011-11-02T18:10:26Z

Nmatatal:

Projects/OWASP Passw3rd Project

2011-10-26T07:54:36Z

Nmatatal:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP Passw3rd Project
| project_home_page = OWASP Passw3rd Project
| project_description = Store passwords in encrypted files with an easy to use command line interface, and utilities to use the passwords in code. In its simplest form, the keys are generated per environment with OS access controls while the password files are stored in SCM.

| project_license = MIT

| leader_name1 = Neil Matatall
| leader_email1 = neil@owasp.org
| leader_username1 = nmatatal

| contributor_name[1-10] = Brendon Murphey
| contributor_email[1-10] =
| contributor_username[1-10] =

| pamphlet_link =

| presentation_link = https://www.owasp.org/images/8/86/Passw3rd-Pamphlet.pptx

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-passw3rd-project

| project_road_map = https://www.owasp.org/index.php/OWASP_Passw3rd_Project/Roadmap

| links_url1 = https://github.com/oreoshake/passw3rd
| links_name1 = Passw3rd @ Github

| links_url4 = http://rubygems.org/gems/passw3rd
| links_name4 = Passw3rd @ Ruby Gems

| links_url3 = https://github.com/bemurphy
| links_name3 = Brendon Murphey's Github Page
| links_url2 = http://www.youtube.com/watch?v=BzbiSPOJUxc&feature=channel_video_title
| links_name2 = OC Rails Passw3rd Presentation on youtube
| links_url[5-10] =
| links_name[5-10] =

| release_1 = password-0.0.5
| release_2 =
| release_3 =
| release_4 =


| project_about_page = Projects/OWASP Passw3rd Project

}}

Projects/OWASP Passw3rd Project

2011-10-26T07:53:43Z

Nmatatal:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP Passw3rd Project
| project_home_page = OWASP Passw3rd Project
| project_description = Store passwords in encrypted files with an easy to use command line interface, and utilities to use the passwords in code. In its simplest form, the keys are generated per environment with OS access controls while the password files are stored in SCM.

| project_license = MIT

| leader_name1 = Neil Matatall
| leader_email1 = neil@owasp.org
| leader_username1 = nmatatal

| contributor_name[1-10] = Brendon Murphey
| contributor_email[1-10] =
| contributor_username[1-10] =

| pamphlet_link =

| presentation_link = https://www.owasp.org/images/8/86/Passw3rd-Pamphlet.pptx

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-passw3rd-project

| project_road_map = https://www.owasp.org/index.php/OWASP_Passw3rd_Project/Roadmap

| links_url1 = https://github.com/oreoshake/passw3rd
| links_name1 = Passw3rd @ Github

| links_url2 = http://rubygems.org/gems/passw3rd
| links_name2 = Passw3rd @ Ruby Gems

| links_url3 = https://github.com/bemurphy
| links_name3 = Brendon Murphey's Github Page
| links_url4 = http://www.youtube.com/watch?v=BzbiSPOJUxc&feature=channel_video_title
| links_name4 = Github Presentation on youtube
| links_url[5-10] =
| links_name[5-10] =

| release_1 = password-0.0.5
| release_2 =
| release_3 =
| release_4 =


| project_about_page = Projects/OWASP Passw3rd Project

}}

Projects/OWASP Passw3rd Project

2011-10-26T07:52:29Z

Nmatatal:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP Passw3rd Project
| project_home_page = OWASP Passw3rd Project
| project_description = Store passwords in encrypted files with an easy to use command line interface, and utilities to use the passwords in code. In its simplest form, the keys are generated per environment with OS access controls while the password files are stored in SCM.

| project_license = MIT

| leader_name1 = Neil Matatall
| leader_email1 = neil@owasp.org
| leader_username1 = nmatatal

| contributor_name[1-10] = Brendon Murphey
| contributor_email[1-10] =
| contributor_username[1-10] =

| pamphlet_link =

| presentation_link = https://www.owasp.org/images/8/86/Passw3rd-Pamphlet.pptx

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-passw3rd-project

| project_road_map = https://www.owasp.org/index.php/OWASP_Passw3rd_Project/Roadmap

| links_url1 = https://github.com/oreoshake/passw3rd
| links_name1 = Passw3rd @ Github

| links_url2 = http://rubygems.org/gems/passw3rd
| links_name2 = Passw3rd @ Ruby Gems

| links_url[3] = https://github.com/bemurphy
| links_name[3] = Brendon Murphey's Github Page
| links_url[4] = http://www.youtube.com/watch?v=BzbiSPOJUxc&feature=channel_video_title
| links_name[4] = Github Presentation on youtube
| links_url[5-10] =
| links_name[5-10] =

| release_1 = password-0.0.5
| release_2 =
| release_3 =
| release_4 =


| project_about_page = Projects/OWASP Passw3rd Project

}}

Projects/OWASP Passw3rd Project

2011-10-13T06:37:18Z

Nmatatal:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP Passw3rd Project
| project_home_page = OWASP Passw3rd Project
| project_description = Store passwords in encrypted files with an easy to use command line interface, and utilities to use the passwords in code. In its simplest form, the keys are generated per environment with OS access controls while the password files are stored in SCM.

| project_license = MIT

| leader_name1 = Neil Matatall
| leader_email1 = neil@owasp.org
| leader_username1 = nmatatal

| contributor_name[1-10] = Brendon Murphey
| contributor_email[1-10] =
| contributor_username[1-10] =

| pamphlet_link =

| presentation_link = https://www.owasp.org/images/8/86/Passw3rd-Pamphlet.pptx

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-passw3rd-project

| project_road_map = https://www.owasp.org/index.php/OWASP_Passw3rd_Project/Roadmap

| links_url1 = https://github.com/oreoshake/passw3rd
| links_name1 = Passw3rd @ Github

| links_url2 = http://rubygems.org/gems/passw3rd
| links_name2 = Passw3rd @ Ruby Gems

| links_url[3] = https://github.com/bemurphy
| links_name[3] = Brendon Murphey's Github Page
| links_url[4-10] =
| links_name[3-10] =

| release_1 = password-0.0.5
| release_2 =
| release_3 =
| release_4 =


| project_about_page = Projects/OWASP Passw3rd Project

}}

Projects/OWASP Passw3rd Project

2011-10-06T17:40:27Z

Nmatatal:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP Passw3rd Project
| project_home_page = OWASP Passw3rd Project
| project_description = Store passwords in encrypted files with an easy to use command line interface, and utilities to use the passwords in code. In its simplest form, the keys are generated per environment with OS access controls while the password files are stored in SCM.

| project_license = MIT

| leader_name1 = Neil Matatall
| leader_email1 = neil@owasp.org
| leader_username1 = nmatatal

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| pamphlet_link =

| presentation_link = https://www.owasp.org/images/8/86/Passw3rd-Pamphlet.pptx

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-passw3rd-project

| project_road_map = https://www.owasp.org/index.php/OWASP_Passw3rd_Project/Roadmap

| links_url1 = https://github.com/oreoshake/passw3rd
| links_name1 = Passw3rd @ Github

| links_url2 = http://rubygems.org/gems/passw3rd
| links_name2 = Passw3rd @ Ruby Gems

| links_url[3-10] =
| links_name[3-10] =

| release_1 = password-0.0.5
| release_2 =
| release_3 =
| release_4 =


| project_about_page = Projects/OWASP Passw3rd Project

}}

File:Passw3rd-Pamphlet.pptx

2011-10-06T17:39:08Z

Nmatatal:

Projects/OWASP Passw3rd Project/Releases/password-0.0.5

2011-10-04T20:16:31Z

Nmatatal:

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = OWASP Passw3rd Project
| project_home_page = OWASP Passw3rd Project

| release_name = password-0.0.5
| release_date = October 2011
| release_description = Working versions of the java and ruby libraries and clients.
| release_license = MIT

| release_download_link =http://rubygems.org/gems/passw3rd

| leader_name1 = Neil Matatall
| leader_email1 = neil@owasp.org
| leader_username1 = nmatatal

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| release_notes =

| links_url1=https://github.com/oreoshake/passw3rd
| links_name1 = Github Repository

| links_url[1-10] =
| links_name[1-10] =
}}

Projects/OWASP Passw3rd Project/Releases/password-0.0.5

2011-10-04T20:15:05Z

Nmatatal:

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = OWASP Passw3rd Project
| project_home_page = OWASP Passw3rd Project

| release_name = password-0.0.9
| release_date = October 2011
| release_description = Working versions of the java and ruby libraries and clients.
| release_license = MIT

| release_download_link =http://rubygems.org/gems/passw3rd

| leader_name1 = Neil Matatall
| leader_email1 = neil@owasp.org
| leader_username1 = nmatatal

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| release_notes =

| links_url1=https://github.com/oreoshake/passw3rd
| links_name1 = Github Repository

| links_url[1-10] =
| links_name[1-10] =
}}

Orange County

2011-09-12T18:52:54Z

Nmatatal: /* Orange County OWASP Board Members */

{{Chapter Template|chaptername=Orange County|extra=Lead by the co-presidents [mailto:neil@owasp.org Neil Matatall], [mailto:roblav@owasp.org Rob LaViolette] and [mailto:shong.chong@owasp.org Shong Chong]

<paypal>Orange County</paypal>
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Orange_County|emailarchives=http://lists.owasp.org/pipermail/owasp-Orange_County}}
The chapter leaders are [mailto:neil@owasp.org Neil Matatall], Rob LaViolette, and Shong Chong.

Follow OWASP OC on Twitter: https://twitter.com/OWASPOC for the latest news (so I don't spam your inboxes)

== Sponsor ==

[[File:Hireright.png]]

== Local News ==

===Future Meetings ===

==== September 14th 2011 7PM ====

When: Wednesday September 17th 7pm
Where: TBD (Irvine)
http://www.meetup.com/ocrails/events/30043551/

Loose Schedule:
7:00 - 7:30: Introduction and networking
7:30 - 8:00: Brakeman with Justin Collins
8:00 - 8:15: Lightning Rounds
8:15 - 8:30: Brakeman Demo

Brakeman with Justin Collins:
While the popular Ruby on Rails web framework provides built-in protection
for many security vulnerabilities, it is still possible to misuse these
features or introduce other vulnerabilities to an application. Brakeman is a static code analysis tool designed specifically to find vulnerabilities and configuration issues in Ruby on Rails applications. Since it works at the source code level, Brakeman can be used at any point in development without the need for deploying the full application stack. To make it even simpler,
Brakeman can be integrated with Hudson/Jenkins to provide automatic monitoring of Brakeman results as code is committed. This talk will discuss how to use Brakeman and how it can help you create safer Rails applications.

Lightning Rounds:

Neil Matatall: Friendly_id + ancsetry

Drew Deponte: Guard, spork, BDD

You: ???

===Previous Meetings===

==== June 29th 2011 7PM ====

[[http://owaspoc.eventbrite.com/ Registration Link]]

'''When''': Wednesday june 29th, 2011 7pm

'''Where: HireRight Offices'''
5151 California Avenue
Irvine, CA 92617

'''Pizza and refreshments will be provided by the sponsors of this meeting.
'''

===== Meeting Sponsors =====

Food and refreshments:
[[File:AppSecDC2010-Sponsor-trustwave.gif]]

Meeting location:
[[File:Hireright.png]]

===== Presentation Topic: =====
Featuring analysis of more than 220 data breach investigations and more than 2,300 penetration tests conducted by Trustwave's SpiderLabs, the Global Security Report 2011 identifies the top vulnerabilities business encountered in 2010 as well as a list of strategic initiatives to help your business improve its overall security.

The data gathered from these engagements is substantial and comprehensive. This presentation will be a summary of the results of the analysis of the data gathered during 2010. The results will be presented both technical and business impact analysis.

===== Charles Henderson, Director of Application Security Services of SpiderLabs at Trustwave =====

Henderson began his career in computer security in 1993, specializing in penetration testing as well as security and vulnerability research. As Director of Application Security Services at SpiderLabs, he leads the team responsible for Application Penetration Testing, Code Review, Secure Development Training, and other elite application security consulting services.

Prior to joining SpiderLabs, Henderson ran his own boutique application
security testing firm. Henderson’s firm provided offensive security services to a wide variety of clients in the United States and Europe.

Henderson speaks frequently at major industry events and conferences, including BlackHat, DEF CON, AppSec US, AppSec EU, SOURCE, and the International Association of Financial Crime Investigators convention.

====January 28th, 2011====

'''Registration link: [https://www.regonline.com/owasp_oc_jan]'''

'''Time:''' 1 PM - 5PM

'''Location: '''

[http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=5151+California+Ave&sll=33.621597,-117.740797&sspn=0.010489,0.019011&ie=UTF8&hq=&hnear=5151+California+Ave,+Irvine,+Orange,+California+92617&z=16&iwloc=A Hireright]

5151 California Ave

Irvine, California 92617

United States.

'''Topics:''' Threat Modeling, Application Security

'''Food:''' Provided

Speakers:

'''Samy Kamkar'''

Online Privacy and the Evercookie

Bio:

Samy Kamkar has lectured on computer security issues in over a dozen
countries, and his work has been featured on the front page of the New
York Times. As a grey-hat hacker, he makes and breaks computer
security for tech companies. In addition to his independent security
research, he co-founded Fonality, an IP PBX company.

'''Jim Manico'''

Back to Basics: Defensive Coding Principles for Web Development 101

The application security community is in deep need of prescriptive
solutions for developers. This talk will review the world of Web
Application Security from a "builder" point of view, focusing on
critical controls that all developers must master if they wish to build
low risk web applications today.

Bio:

Jim Manico is the chair of the OWASP Connections committee where he
focuses on producing and hosting the OWASP Podcast. Jim also is a
co-manager of the OWASP ESAPI Open Source project. Professionally, Jim
is an independent application security architect specializing in the
construction of low-risk web applications. Jim is also an application
security educator and assessment specialist.

'''Edward Bonver'''
Talk Title:

Threat Modeling at Symantec
[[File:OWASP-WWW-2011-Edward-Bonver-Threat-Modelint-at-Symantec.pptx]]

Abstract:

Threat Modeling is one of the most important security activities that a development/QA team needs to perform as part of a Security Development Lifecycle. This activity allows the team to build a complete security profile of the system being built. Threat Modeling is not always easy to get going for a team that has little or no security experience. In this presentation we’ll take a look at why Threat Modeling is so important; we’ll explore the process behind it, and how the process is being implemented and followed across Symantec.

Bio:

Edward Bonver is a principal software engineer on the product security team under the Office of the CTO at Symantec Corporation. In this capacity, Edward is responsible for working with software developers and quality assurance (QA) professionals across Symantec to continuously enhance the company’s software security practices through the adoption of methodologies, procedures and tools for secure coding and security testing. Within Symantec, Edward teaches secure coding and security testing classes for Symantec engineers, and also leads the company’s QA Security Task Force, which he founded. Prior to joining Symantec, Edward held software engineering and QA roles at Digital Equipment Corporation, Nbase and Zuma Networks.

Edward is a Certified Information Systems Security Professional (CISSP) and a Certified Secure Software Lifecycle Professional (CSSLP). He holds a master’s degree in computer science from California State University, Northridge, and a bachelor’s degree in computer science from Rochester Institute of Technology. Edward is a Ph.D. student at NOVA Southeastern University.

====Thursday, January 21st 2010====

Time: 7:30
Location: We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building. http://www.oit.uci.edu/computing/labs/training.html Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdfBD

For those who would like to avoid paying for parking, you can park in the University Center and take the campus shuttle: http://www.shuttle.uci.edu/maincampus/index.php

The shuttle runs until 10:45PM. The shuttle costs $1 per ride, but fees are rarely collected ;)

Title: Do VLANs allow for good application security?

Virtual Local Area Networks (VLANs) are not a new concept, and can help
any organization better control network access. I will present some of
the previous issues identified, what was the root cause, and how these
have been fixed in current technology. In addition we will talk about
how this can help to enhance security in your environment, and what
controls must be in place in order to implement such an environment. We
will also touch on how this can complicate your application environment,
but improve overall security.

I will touch on the controls that need to be reviewed and audited when
working with VMware, VLANs, and web applications, to ensure that these
networks are secure, and what to look for to potentially pass audit
criteria. I will also talk about where and how these controls have been
implemented in order to protect thousands of users while accessing one
of the most hostile networks in the world.

David M. N. Bryan
Senior Security Consultant

David has over 9+ years of computer security experience including,
consulting, engineering and administration. He has performed security
assessment projects for health care, nuclear, manufacturing,
pharmaceutical, banking and educational sectors. As an active
participant in the information security community, he volunteers at
DEFCON where he designs and implements the Firewall and Network for what
is said to be the most hostile network environment in the world.

He is also an active participant in the local Minneapolis security
groups both as a board member of OWASP MSP and DC612. His roots and
experience come from working for a large enterprise banks, designing and
managing enterprise security systems. In the more recent years he has
been working as an Information Security Consultant to review the
security and architecture of information computing environments.

====Thursday December 17th 2009====

7:30 PM, UC Irvine Campus, Room AIRB 1020

We will be meeting in the Anteater Instruction and Research Building on the UC Irvine campus. The building itself is inside of the Anteater Parking Structure at the corner of E. Peltason Dr and Anteater Dr and is room number 1020. Parking is $7 but feel free to park off campus and walk to the building.
http://www.oit.uci.edu/computing/labs/training.html
Buliding #653 in quadrant H9 on the campus map - http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf

'''Abstract'''

'''Title: Pulling the Plug: Security Risks in the Next Generation of Offline Web Applications'''

As the line between desktop and web applications becomes increasingly blurry in a web 2.0 world, browser functionality is being pushed well beyond what it was originally intended for. Persistent client side storage has become a requirement for web applications if they are to be available both online and off. This need is being filled by a variety of technologies such as [http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage Gears (formerly Google Gears) and the Database Storage] functionality included in the emerging [http://dev.w3.org/html5/spec/Overview.html HTML 5 specification]. While all such technologies offer great promise, it is clear that the vast majority of developers simply do not understand their security implications.

Researching a variety of currently deployed implementations of these technologies has revealed a broad scope of vulnerabilities with frightening implications. Now attackers can target victims not just once, but every time they visit a site as the victim now carries and stores the attack with them. Imagine a scenario whereby updated confidential information is forwarded to an attacker every time a victim interacts with a given we application. The attacker no longer needs to worry about timing their attacks to ensure that the victim is authenticated as the victim attacks himself! Limited storage? Cookies that expire? Not a problem when entire databases are accessible with virtually unlimited storage and an infinite lifespan. Think these attacks are theoretical? Think again. In this talk we dive into these technologies and break down the risk posed by them when not properly understood. We will then detail a variety of real-world vulnerabilities that have been uncovered, including a new class of cross-site scripting and client-side SQL injection.

'''Bio'''

'''Michael Sutton'''
'''Vice President, Security Research – Zscaler'''

Michael Sutton has spent more than a decade in the security industry conducting leading-edge research, building teams of world-class researchers and educating others on a variety of security topics. As VP of Security Research, Michael heads Zscaler Labs, the research and development arm of the company. Zscaler Labs is responsible for researching emerging topics in web security and developing innovative security controls, which leverage the Zscaler in-the-cloud model. The team is comprised of researchers with a wealth of experience in the security industry.

Prior to joining Zscaler, Michael was the Security Evangelist for SPI Dynamics where, as an industry expert, he was responsible for researching, publishing and presenting on various security issues. In 2007, SPI Dynamics was acquired by Hewlett-Packard. Previously, Michael was a Research Director at iDefense where he led iDefense Labs, a team responsible for discovering and researching security vulnerabilities in a variety of technologies. iDefense was acquired by VeriSign in 2005. Michael is a frequent speaker at major information security conferences; he is regularly quoted by the media on various information security topics, has authored numerous articles and is the co-author of Fuzzing: Brute Force Vulnerability Discovery, an Addison-Wesley publication.

====Thursday, November 19th 2009====

When: November 19th 2009, 7:30PM
Where: Gina's Pizza, Irvine
Topics: Facebook privacy, web application firewalls, penetration testing, the reluctance for hackers to execute attacks, and random new technology. Announced OWASP OC/LAs intention to submit a proposal for AppSec 2010.

====Wednesday, October 14th 2009====

Separate meetings will be held for OWASP OC and OWASP@UCI (student group).

When: Wednesday 10/14 7:30PM
Where: Steelhead Brewery
Topics: News, Ideas, Chit-chat

This is a restaurant/bar with plenty of seating, but room for a projector is out of the question so this would be an informal round table discussion.

I have a presentation I'm working on regarding WAFs and Vulnerability Assessment Tools. If it pleases the group, I'd love to go over the presentation and discuss everyone's experiences. Also, it's a great way to get feedback :)

Neil

I'm open to suggestions of any kind: location, time, topics, etc

====Thursday, September 17th, 2009 7:30PM ====
'''Location:''' UC Irvine
Building: Calit2 building,building number 325 in quadrant H8 on the [http://today.uci.edu/pdf/UCI_09_map_campus_core.pdf UC Irvine Map]
Room: 3008

Parking will be $7.
Please park in the [http://maps.google.com/maps?li=d&hl=en&f=d&iwstate1=dir:to&daddr=Parking+Structure+for+CalIT2%4033.643082,+-117.837593&geocode=CSJ9b4xJxrzxFUpaAQId5_D5-A&iwloc=1&dq=calit2,+uc+irvine,+ca&cid=33643082,-117837593,16505793731713499531&ei=v3bvSabfO6LejAOR2pjgAQ Anteater Parking Structure]

I can only unofficially say that if you park in the nearby shopping centers and walk, you may be able to park for free.

* <b>The Rise of Threat Analysis and the Fall of Compliance, Policies, and Standards in mitigating Web Application Security Risks</b>

====Apr 30, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Our fourth OC OWASP meeting will be an informal, roundtable discussion of current application security issues. Feel free to bring some ideas, code, slides, etc to contribute to the discussion. Hope to see everyone there!

====Feb 19, 2009 6:30PM-8:30PM====
Brooklyn Pizza Works, 1235 East Imperial Highway, Placentia, CA

[http://maps.google.com/maps?q=1235+East+Imperial+Highway,+placentia,+ca&oe=utf-8&client=firefox-a&ie=UTF8&split=0&gl=us&z=16&iwloc=addr Google Map]

Come talk application security at the third OWASP OC meeting. We'll discuss current application security topics and chapter issues over pizza. We have a room booked for 15-20 people so we'll be able to rant without disturbing the patrons :) See you there! [https://www.owasp.org/images/5/58/Cloud_Computing_Security.pdf Presentation Slides]

====Dec 17, 2008 6PM - 9PM====
Microsoft Campus
Room MPR1, 3 Park Plaza, Suite 1600, Irvine, CA, 92614

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=microsoft,+Irvine,+CA,+92614&sll=33.678479,-117.838368&sspn=0.009892,0.022745&g=3+Park+Plaza,+Irvine,+CA,+92614&ie=UTF8&ei=sCFJSfKPEo3UNc2ZmCc&cd=1&cid=33728042,-117783305,17507068988286890825&li=lmd&ll=33.731835,-117.78142&spn=0.039545,0.090981&z=14&iwloc=A Google Map]

This meeting will be a roundtable discussion of application security news, plus a few OWASP-themed challenges with prizes. Pizza will be provided and we'll head to the Yard House after the meeting.

====Aug 27, 2008, 7 PM - 9 PM====
Penny Saver

603 Valencia, Brea, CA 92822

[http://maps.google.com/maps?f=q&hl=en&geocode=&q=603+valencia,+Brea,+CA+92822&sll=33.911348,-117.851629&sspn=0.009865,0.022745&ie=UTF8&ll=33.909478,-117.852917&spn=0.009866,0.022745&z=16&iwloc=addr Google Map]

Come meet up with web security professionals, have some pizza, and offer your thoughts for the direction of the OC chapter at our inaugural meeting! We are looking for speakers and venue sponsors for the next meeting. If you are interested, please contact the chapter leaders. Everyone is welcome to join us at our chapter meetings.

[[Category:OWASP Chapter]]

= Orange County OWASP Board Members =

*<b>Orange County Co-President</b> [mailto:neil@owasp.org Neil Matatall]
*<b>Orange County Co-President</b> Shong Chong
*<b>Orange County Co-President</b> Rob LaViolette
*<b>Orange County Treasurer:</b> [mailto: TBD]
*<b>Orange County Recording Secretary:</b> [mailto: TBD]
*<b>Orange County Board Member</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]
*<b>Orange County Board Member:</b> [mailto: TBD]

[[Category:California]]