OWASP - User contributions [en]

Regular expression Denial of Service - ReDoS

2012-11-09T18:30:09Z

Ebing: /* The problematic Regex naïve algorithm */

{{template: Attack}} 
[[Category:OWASP ASDR Project]]

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

==Introduction==
The '''Regular expression Denial of Service (ReDoS)''' is a [[Denial of Service]] attack, that exploits the fact that most Regular Expression implementations may reach extreme situations that cause them to work very slowly (exponentially related to input size). An attacker can then cause a program using a Regular Expression to enter these extreme situations and then hang for a very long time.

==Description==
===The problematic Regex naïve algorithm===
The Regular Expression naïve algorithm builds a [http://en.wikipedia.org/wiki/Nondeterministic_finite_state_machine Nondeterministic Finite Automaton (NFA)], which is a finite state machine where for each pair of state and input symbol there may be several possible next states. Then the engine starts to make transition until the end of the input. Since there may be several possible next states, a deterministic algorithm is used. This algorithm tries one by one all the possible paths (if needed) until a match is found (or all the paths are tried and fail).

For example, the Regex '''''^(a+)+$''''' is represented by the following NFA:

:::[[File:NFA.png]]

For the input '''''aaaaX''''' there are 16 possible paths in the above graph. But for '''''aaaaaaaaaaaaaaaaX''''' there are 65536 possible paths, and the number is double for each additional '''''a'''''. This is an extreme case where the naïve algorithm is problematic, because it must pass on many many paths, and then fail.

Notice, that not all algorithms are naïve, and actually Regex algorithms can be written in an efficient way. Unfortunately, most Regex engines today try to solve not only "pure" Regexes, but also "expanded" Regexes with "special additions", such as back-references that cannot be always be solved efficiently (see '''Patterns for non-regular languages''' in [http://en.wikipedia.org/wiki/Regular_expression Wiki-Regex] for some more details). So even if the Regex is not "expanded", a naïve algorithm is used.

===Evil Regexes===
A Regex is called "evil" if it can stuck on crafted input.

'''Evil Regex pattern contains''':
* Grouping with repetition
* Inside the repeated group:
** Repetition
** Alternation with overlapping

'''Examples of Evil Patterns''':
* (a+)+
* ([a-zA-Z]+)*
* (a|aa)+
* (a|a?)+
* (.*a){x} | for x > 10

All the above are susceptible to the input '''''aaaaaaaaaaaaaaaaaaaaaaaa!''''' (The minimum input length might change slightly, when using faster or slower machines).

===Attacks===
The attacker might use the above knowledge to look for applications that use Regular Expressions, containing an '''Evil Regex''', and send a well-crafted input, that will hang the system. Alternatively, if a Regex itself is affected by a user input, the attacker can inject an '''Evil Regex''', and make the system vulnerable.

==Risk Factors==
The Web is Regex-Based:

:::[[File:RegexBasedWeb.png]]

In every layer of the WEB there are Regular Expressions, that might contain an '''Evil Regex'''. An attacker can hang a WEB-browser (on a computer or potentially also on a mobile device), hang a Web Application Firewall (WAF), attack a database, and even stack a vulnerable WEB server.

For example, if a programmer uses a Regex to validate the client side of a system, and the Regex contains an '''Evil Regex''', the attacker can assume the same vulnerable Regex is used in the server side, and send a well-crafted input, that stacks the WEB server.

==Examples==
===Vulnerable Regex in online repositories===
1. [http://regexlib.com/REDetails.aspx?regexp_id=1757 ReGexLib,id=1757 (email validation)] - see bold part, which is an '''Evil Regex'''
^([a-zA-Z0-9])'''(([\-.]|[_]+)?([a-zA-Z0-9]+))*'''(@){1}[a-z0-9]+[.]{1}(([a-z]{2,3})|([a-z]{2,3}[.]{1}[a-z]{2,3}))$

Input:
aaaaaaaaaaaaaaaaaaaaaaaa!

2. [[OWASP Validation Regex Repository]], Java Classname - see bold part, which is an '''Evil Regex'''
^'''(([a-z])+.)+'''[A-Z]([a-z])+$

Input:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!

===Web application attack===
* Open a JavaScript
* Find '''Evil Regex'''
* Craft a malicious input for the found Regex
* Submit a valid value via intercepting proxy
* Change the request to contain a malicious input
* You are done!

===ReDoS via Regex Injection===
The following example checks if the username is part of the password entered by the user.
String userName = textBox1.Text;
String password = textBox2.Text;
Regex testPassword = new Regex(userName);
Match match = testPassword.Match(password);
if (match.Success)
{
MessageBox.Show("Do not include name in password.");
}
else
{
MessageBox.Show("Good password.");
}
If an attacker enters ''^(([a-z])+.)+[A-Z]([a-z])+$'' as a username and ''aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!'' as a password, the program will hang.
==Related [[Threat Agents]]==
TBD

==Related [[Attacks]]==
* [[Denial of Service]]

==Related [[Vulnerabilities]]==
* [[:Category: Input Validation Vulnerability]]
* [[:Category: API Abuse]]

==Related [[Controls]]==
* [[Input Validation]]
* [[Output Validation]]
* [[Canonicalization]]

==References ==
* [http://www.cs.rice.edu/~scrosby/hash/slides/USENIX-RegexpWIP.2.ppt Regular Expression Denial Of Service / Crosby&Wallach, Usenix Security 2003]
* [http://www.checkmarx.com/NewsDetails.aspx?id=23&cat=3 Regular expression Denial of Service Revisited, Sep-2009]
* [[Media:20091210_VAC-REGEX_DOS-Adar_Weidman.pdf| VAC Presentation - ReDoS, OWASP-NL Chapter meeting Dec-2009]]
* [[Podcast 56|OWASP podcast about ReDoS]]
* [[OWASP Validation Regex Repository]]
* [http://regexlib.com/ RegExLib]
* Examples of ReDoS in open source applications:
** [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3277 ReDoS in DataVault]
** [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3275 ReDoS in EntLib]
** [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3276 ReDoS in NASD CORE.NET Terelik]

==Credit==
{{Template:Checkmarx}}
[[Category:Attack]]
[[Category:Injection]]

AppSec US 2010, CA

2010-07-20T22:25:35Z

Ebing: Spelling correction

[[Image:Appsec banner.png|468x60px|AppSec USA 2010 Banner]]

==== Welcome ====

{| class="FCK__ShowTableBorders" border="0" width="100%" align="center"
|-
| style="width: 25%; background: rgb(240,230,140)" align="center" | [http://www.appsecusa.org/travel-and-venue.html Travel and Venue]
| style="width: 25%; background: rgb(240,230,140)" align="center" | [http://www.appsecusa.org/become-a-sponsor.html Sponsor Information]
| style="width: 25%; background: rgb(240,230,140)" align="center" | [http://www.appsecusa.org/volunteer-opportunities.html Volunteer Opportunities]
| style="width: 25%; background: rgb(255,215,0)" align="center" | [http://www.appsecusa.org/register-now.html REGISTER NOW]
|-
| style="background: rgb(238,235,226); color: black" colspan="4" align="left" |
 For complete information, please visit [http://www.appsecusa.org AppSec US 2010 Website] 

|}

{| style="width: 100%" class="FCK__ShowTableBorders"
|-
| style="width: 100%; color: rgb(0,0,0)" |
{| style="width: 100%; background: none transparent scroll repeat 0% 0%; -moz-background-inline-policy: continuous" class="FCK__ShowTableBorders"
|-
| style="width: 95%; color: rgb(0,0,0)" |
'''Latest Updates:'''

'''Training and conference agenda available'''

'''Register now!''' Early-bird rates extended till July 31.

''' '''

|}



| style="border-bottom: rgb(204,204,204) 0px solid; border-left: rgb(204,204,204) 0px solid; width: 100%; color: rgb(0,0,0); font-size: 95%; border-top: rgb(204,204,204) 0px solid; border-right: rgb(204,204,204) 0px solid" | 
| style="width: 110px; color: rgb(0,0,0); font-size: 95%" |
|}



==== Training September 7th & 8th ====

{| style="width: 80%" class="FCK__ShowTableBorders" border="0" align="center"
|-
! style="background: rgb(64,88,160); color: white" align="center" | T1. Web Security Testing - 2-Days - $1350
|-
| style="background: rgb(242,242,242)" | This course is a deep dive into the world of web application security testing. It is designed to walk testers through every step of web application penetration testing, arming them with the knowledge and tools they will need to begin conducting their own security testing. The course will teach the participants how to think like a security engineer by creating and executing a security test plan. Participants will be exposed to common web application vulnerabilities, testing techniques and tools by a professional security tester.
The course includes a guided penetration test in which the students will execute security test with the help of the instructor.

|-
| style="background: rgb(242,242,242)" | Instructor: Joe Basirico, Security Innovation
|-
| style="background: rgb(242,242,242)" | [[Learn More About the Web Security Testing Class]]
|-
| style="background: rgb(242,242,242)" | [http://www.appsecusa.org/register-now.html Click here to register]
|}

{| style="width: 80%" class="FCK__ShowTableBorders" border="0" align="center"
|-
! style="background: rgb(64,88,160); color: white" align="center" | T2. Building Secure Ajax and Web 2.0 Applications - 2-Days - $1350
|-
| style="background: rgb(242,242,242)" | This two-day class will cover common Web 2.0 and AJAX security threats, vulnerabilities, and it will provide specific guidance on how to develop Web 2.0 applications to defend against these threats and vulnerabilities.
Training developers on secure coding practices offers one of highest returns on investment of any security investment by eliminating vulnerabilities at the source. Aspect’s Building Secure Ajax and Web 2.0 Applications Course enables developers to securely utilize Web 2.0 technologies in their web applications without introducing security issues. The course provides detailed examples of ‘what to do’ and ‘what not to do.' The class is lead by an experienced developer and delivered in a very interactive manner. The course will use demonstrations, code examples, and spot-the-bug exercises to get developers engaged in the topic. Developers will leave with an understanding of how Ajax attacks work, the impacts of successful attacks, and what to do to defend against them.

|-
| style="background: rgb(242,242,242)" | Instructor: Dave Wichers: [[Image:100px-Aspect Security Logo.jpg]]
|-
| style="background: rgb(242,242,242)" | [[Learn More about the Building Secure Ajax and Web 2.0 Applications Class]]
|-
| style="background: rgb(242,242,242)" | [http://www.appsecusa.org/register-now.html Click here to register]
|-
! style="background: rgb(64,88,160); color: white" align="center" | T3. Assessing and Exploiting Web Applications with Samurai - WTF - 2-Days - $1350
|-
| style="background: rgb(242,242,242)" |
This course will focus on using open source tools to perform web application assessments.  The course will take attendees through the process of application assessment using the open source tools included in the Samurai Web Testing Framework Live CD (Samurai-‐WTF). 

Day one will take students through the steps and open source tools used to assess application for vulnerabilities. 

Day two will focus on the exploitation of web app vulnerabilities, spending half the day on server side attacks and the other half of the day on client side attacks.  The latest tools and techniques will be used throughout the course, including several tools developed by the trainers themselves

|-
| style="background: rgb(242,242,242)" |
Instructor: Jason Searle: InGuardian [[Image:InGuardians.png|36x40px]]

|-
| style="background: rgb(242,242,242)" | [http://www.appsecusa.org/register-now.html Click here to register]
|-
! style="background: rgb(64,88,160); color: white" align="center" | T4. Application Security Leadership Essentials - 2-Days - $1350
|-
| style="background: rgb(242,242,242)" | In this two-day management session you’ll get an industry perspective of application security, understand the key vulnerabilities to applications, be able to analyze root cause, and provide practical and proven techniques in building out an application security initiative. This course gives executives and managers the education and practical guidance they need to ensure that software projects properly address security. The course is designed to provide a firm understanding of the importance of software security, the critical security activities required within the software development lifecycle, and how to efficiently manage security issues during development and maintenance. This understanding is reinforced through industry awareness, live demonstrations of commonly found application vulnerabilities and workgroup exercises allowing attendees to conduct capability assessments and recommend improvement plans.
|-
| style="background: rgb(242,242,242)" | Instructor: Jeff Williams: [[Image:100px-Aspect Security Logo.jpg]]
|-
| style="background: rgb(242,242,242)" | [[Learn More about the Application Security Leadership Essentials Class]]
|-
| style="background: rgb(242,242,242)" | [http://www.appsecusa.org/register-now.html Click here to register]
|-
! style="background: rgb(64,88,160); color: white" align="center" | T5. Software Security Remediation: How to Fix Application Vulnerabilities 1-Day - Sept 7th- $675
|-
| style="background: rgb(242,242,242)" | Summary
Instructor: Dan Cornell: [[Image:AppSecDC2009-Sponsor-denim.gif]]

|-
| style="background: rgb(242,242,242)" | [http://www.appsecusa.org/register-now.html Click here to register]
|}

{| style="width: 80%" class="FCK__ShowTableBorders" border="0" align="center"
|-
! style="background: rgb(64,88,160); color: white" align="center" | T6. Live CD 1-Day - Sept 8th- $675
|-
| style="background: rgb(242,242,242)" | Summary
Instructor: Matt Tesauro: [[Image:TrustwaveLogo.jpg]]

|-
| style="background: rgb(242,242,242)" | [http://www.appsecusa.org/register-now.html Click here to register]
|}

 

==== September 9th ====

{| style="width: 80%" class="FCK__ShowTableBorders" border="0" align="center"
|-
| style="background: rgb(64,88,160); color: white" colspan="4" align="center" | '''Conference Day 1 - September 9th, 2010'''
 

|-
| style="width: 10%; background: rgb(123,138,189)" | 
| style="width: 30%; background: rgb(188,133,122)" | Track 1 - Crystal Cove Auditorium
| style="width: 30%; background: rgb(188,165,122)" | Track 2 - Pacific Ballroom
| style="width: 30%; background: rgb(153,255,153)" | Track 3 - Doheny Beach
|-
| style="width: 10%; background: rgb(123,138,189)" | 07:30-08:30
| style="width: 80%; background: rgb(194,194,194)" colspan="3" align="left" | Registration and Breakfast + Coffee
|-
| style="width: 10%; background: rgb(123,138,189)" | 08:30-08:45
| style="width: 80%; background: rgb(242,242,242)" colspan="3" align="center" | Welcome to OWASP AppSec US, 2010 (Crystal Cove Auditorium)
|-
| style="width: 10%; background: rgb(123,138,189)" | 08:45-9:30
| style="width: 80%; background: rgb(252,252,150)" colspan="3" align="center" | Keynote: Jeff Williams (Crystal Cove Auditorium)
|-
| style="width: 10%; background: rgb(123,138,189)" | 9:30-10:15
| style="width: 80%; background: rgb(252,252,150)" colspan="3" align="center" | Keynote: Chenxi Wang (Crystal Cove Auditorium)
|-
| style="width: 10%; background: rgb(123,138,189)" | 10:15-10:35
| style="width: 90%; background: rgb(194,194,194)" colspan="3" align="left" | Break - Expo - CTF kick-off (Emerald Bay)
|-
| style="width: 10%; background: rgb(123,138,189)" | 10:35-11:20
| style="width: 30%; background: rgb(188,133,122)" align="left" | How I met your Girlfriend, ''Samy Kamkar'' 
| style="width: 30%; background: rgb(188,165,122)" align="left" | Solving Real-World Problems with an Enterprise Security API (ESAPI), ''Chris Schmidt, ServiceMagic'' 
| style="width: 30%; background: rgb(153,255,153)" align="left" | Microsoft Security Development Lifecycle for Agile Development, ''Nick Coblentz, AT&T''
|-
| style="width: 10%; background: rgb(123,138,189)" | 11:20-11:30
| style="width: 90%; background: rgb(194,194,194)" colspan="3" align="left" | Break - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 11:30-12:15
| style="width: 30%; background: rgb(188,133,122)" align="left" | State of SL on the Internet - 2010 Survey, Results and Conclusions, ''Ivan Ristic, Qualys'' 
 

| style="width: 30%; background: rgb(188,165,122)" align="left" | Into the Rabbit Hole: Execution Flow-based Web Application Testing, ''Rafal Los, Hewlett-Packard'' 
 

| style="width: 30%; background: rgb(153,255,153)" align="left" | Threat Modeling Best Practices, Robert Zigweid, IOActive 
|-
| style="width: 10%; background: rgb(123,138,189)" | 12:15-13:15
| style="width: 80%; background: rgb(194,194,194)" colspan="3" align="left" | Lunch - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 13:30-14:15
| style="width: 80%; background: rgb(252,252,150)" colspan="3" align="center" | Keynote: Bill Cheswick (Crystal Cove Auditorium)
|-
| style="width: 10%; background: rgb(123,138,189)" | 14:15-14:25
| style="width: 90%; background: rgb(194,194,194)" colspan="3" align="left" | Break - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 14:25-15:10
| style="width: 30%; background: rgb(188,133,122)" align="left" | P0w3d for Botnet CnC, ''Gunter Ollmann, Damballa'' 
| style="width: 30%; background: rgb(188,165,122)" align="left" | Cloud Computing, A Weapon of Mass Destruction?, ''David Bryan'' 
| style="width: 30%; background: rgb(153,255,153)" align="left" | The Secure Coding Practices Quick Reference Guide, ''Keith Turpin, Boeing''
|-
| style="width: 10%; background: rgb(123,138,189)" | 15:10-15:30
| style="width: 90%; background: rgb(194,194,194)" colspan="3" align="left" | Coffee Break - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 15:30-16:15
| style="width: 30%; background: rgb(188,133,122)" align="left" | Smart Phones with Dumb Apps: Threat Modeling for Mobile Applications, ''Dan Cornell, Denim Group'' 
| style="width: 30%; background: rgb(188,165,122)" align="left" | Assessing, Testing and Validating Flash Content, ''Peleus Uhley, Adobe'' 
| style="width: 30%; background: rgb(153,255,153)" align="left" | OWASP State of the Union, ''Tom Brennan, OWASP''
|-
| style="width: 10%; background: rgb(123,138,189)" | 16:15-16:25
| style="width: 90%; background: rgb(194,194,194)" colspan="3" align="left" | Break - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 16:25-17:10
| style="width: 90%; background: rgb(242,242,242)" colspan="3" align="center" | Panel Discussion: Security Trends: Jeremiah Grossman, Robert Hansen, TBD...Moderator: Stuart Schwartz
|}

==== September 10th ====

{| style="width: 80%" class="FCK__ShowTableBorders" border="0" align="center"
|-
| style="background: rgb(64,88,160); color: white" colspan="4" align="center" | '''Conference Day 2 - September 10th, 2010'''
 

|-
| style="width: 10%; background: rgb(123,138,189)" | 
| style="width: 30%; background: rgb(188,133,122)" | Track 1 - Crystal Cove Auditorium
| style="width: 30%; background: rgb(188,165,122)" | Track 2 - Pacific Ballroom
| style="width: 30%; background: rgb(153,255,153)" | Track 3 - Doheny Beach
|-
| style="width: 10%; background: rgb(123,138,189)" | 08:00-09:00
| style="width: 80%; background: rgb(194,194,194)" colspan="3" align="left" | Coffee - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 09:00-09:15
| style="width: 80%; background: rgb(242,242,242)" colspan="3" align="center" | Announcements (Crystal Cove Auditorium)
|-
| style="width: 10%; background: rgb(123,138,189)" | 09:15-10:00
| style="width: 80%; background: rgb(252,252,150)" colspan="3" align="center" | Keynote: David Rice (Crystal Cove Auditorium)
|-
| style="width: 10%; background: rgb(123,138,189)" | 10:00-10:10
| style="width: 90%; background: rgb(194,194,194)" colspan="3" align="left" | Break - Expo - CTF (Emerald Bay)
|-
| style="width: 10%; background: rgb(123,138,189)" | 10:10-10:55
| style="width: 30%; background: rgb(188,133,122)" align="left" | Security Architecting Applications for the Cloud, ''Alex Stamos, iSEC Partners'' 
| style="width: 30%; background: rgb(188,165,122)" align="left" | Unraveling Cross-Technology, Cross-Domain Trust Relations, ''Peleus Uhley, Adobe'' 
| style="width: 30%; background: rgb(153,255,153)" align="left" | Real Time Application Defenses - The Reality of AppSensor & ESAPI, ''Michael Coates, Mozilla,''
|-
| style="width: 10%; background: rgb(123,138,189)" | 10:55-11:15
| style="width: 90%; background: rgb(194,194,194)" colspan="3" align="left" | Break - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 11:15-12:00
| style="width: 30%; background: rgb(188,133,122)" align="left" | Reducing Web application Vulnerabilities: Moving from a Test-Dependent to Design-Driven development, ''Ed Adams, Security Innovation'' 
 

| style="width: 30%; background: rgb(188,165,122)" align="left" | Session Management Security tips and Tricks, ''Lars Ewe, Cenzic'' 
 

| style="width: 30%; background: rgb(153,255,153)" align="left" | The Dark Side of Twitter: Measuring and Analyzing Malicious Activity on Twitter, ''Paul Judge, David Maynor, and Daniel Peck, Barracuda Labs'' 
|-
| style="width: 10%; background: rgb(123,138,189)" | 12:00-13:15
| style="width: 80%; background: rgb(194,194,194)" colspan="3" align="left" | Lunch - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 13:14-14:00
| style="width: 80%; background: rgb(252,252,150)" colspan="3" align="center" | Keynote: HD Moore (Crystal Cove Auditorium)
|-
| style="width: 10%; background: rgb(123,138,189)" | 14:04-14:50
| style="width: 30%; background: rgb(188,133,122)" align="left" | Panel Discussion: Vulnerability Lifecycle for Software Vendors, ''Kelly FitzGerald (Symantec), (US CERT), (Cigital), (Tipping Point) Moderator: Edward Bonver'' 
| style="width: 30%; background: rgb(188,165,122)" align="left" | Agile + Security = FAIL, ''Adrian Lane'' 
| style="width: 30%; background: rgb(153,255,153)" align="left" | Bug-Alcoholic 2.0 - Untamed World of Web Vulnerabilities, ''Aditya K. Sood, Armorize Technologies''
|-
| style="width: 10%; background: rgb(123,138,189)" | 14:50-15:10
| style="width: 90%; background: rgb(194,194,194)" colspan="3" align="left" | Coffee Break - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 15:10-15:55
| style="width: 30%; background: rgb(188,133,122)" align="left" | Exploiting Networks through Database Weaknesses, ''Scott Sutherland, NetSPI'' 
| style="width: 30%; background: rgb(188,165,122)" align="left" | Defining the Identiy Management Framework, ''Richard Tychansky, Jim Molini, Hord Tipton, and Mike Kilroy'' 
| style="width: 30%; background: rgb(153,255,153)" align="left" | ''TBD''
|-
| style="width: 10%; background: rgb(123,138,189)" | 15:55-16:05
| style="width: 90%; background: rgb(194,194,194)" colspan="3" align="left" | Break - Expo - CTF
|-
| style="width: 10%; background: rgb(123,138,189)" | 16:05-16:50
| style="width: 90%; background: rgb(242,242,242)" colspan="3" align="center" | Conference Wrap Up: AppSec US 2011 Location Announcement, CTF Results, Prizes
|}

 

==== Sponsors ====

We are currently soliciting sponsors for the AppSec US 2010 Conference. Please refer to our [http://www.appsecusa.org/become-a-sponsor.html List of Sponsorship Opportunities] (or [http://www.owasp.org/images/b/b3/OWASP_sponsorship_Irvine.pdf PDF]).

Please contact [mailto:kate.hartmann@owasp.org Kate Hartmann] for more information.

Slots are going fast so contact us to sponsor today!

    

{| style="background: none transparent scroll repeat 0% 0%; color: white; -moz-background-inline-policy: continuous" class="FCK__ShowTableBorders" border="0" cellspacing="10" align="center"
|-
|
== Platinum Sponsors ==

|
| [File:Qualys-468-60.png]
|
|
|-
|  
|-
|
== Gold Sponsors ==

| [[Image:Ibmneg blurgb.jpg]]
| [[Image:Fortify logo AppSec Research 2010.png]]
|
|-
|  
|-
|
== Silver Sponsors ==

| [[Image:AppSecDC2009-Sponsor-fishnet.gif]]
| [[Image:Acunetix logo 200.png]]
| [[Image:Barracuda Color Logo.jpg]]
| [[Image:Cenziclogo.png]]
|-
| [[Image:Cigital-hor-color.JPG|120px]]
| [[Image:Fujitsu-red-opt-b-150x56.gif]]
| [[Image:Netspi logo.png]]
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|  
|-
|  
|-
|
=== Organizational Sponsors ===

| [[Image:Isc2 logo.gif|120px]]
|
|-
|  
|-
|
=== Reception Sponsors ===

|
|-
|
=== Coffee Sponsors ===

|
|
|}

==== REGISTER NOW ====

Click [http://www.appsecusa.org/register-now.html here]  for registration information. 

[http://www.appsecusa.org/register-now.html http://www.appsecusa.org/register-now.html]

<headertabs />

[[Category:OWASP_AppSec_Conference]] [[Category:OWASP_AppSec_USA]]

Top 10 2007-Insecure Direct Object Reference

2007-09-28T23:10:11Z

Ebing: Corrected number from 1.7 billion to 17,000. Cleaned up language.

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Cross Site Request Forgery|useprev=PrevLink|prev=-Malicious File Execution|usemain=MainLink|main=}}

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. An attacker can manipulate direct object references to access other objects without authorization, unless an access control check is in place.

For example, in Internet Banking applications, it is common to use the account number as the primary key. Therefore, it is tempting to use the account number directly in the web interface. Even if the developers have used parameterized SQL queries to prevent SQL injection, if there is no extra check that the user is the account holder and authorized to see the account, an attacker tampering with the account number parameter can see or change '''''all '''''accounts.

This type of attack occurred to the Australian Taxation Office’s ''GST Start Up Assistance'' site in 2000, where a legitimate but hostile user simply changed the ABN (a company tax id) present in the URL. The user farmed around 17,000 company details from the system, and then e-mailed each system. This was a major embarrassment to the Government of the 17,000 companies with details of his attack. This type of vulnerability is very common, but is largely untested in current applications.

== Environments Affected ==

All web application frameworks are vulnerable to attacks on insecure direct object references.

== Vulnerability ==

Many applications expose their internal object references to users. Attackers use parameter tampering to change references and violate the intended but unenforced access control policy. Frequently, these references point to file systems and databases, but any exposed application construct could be vulnerable.

For example, if code allows user input to specify filenames or paths, it may allow attackers to jump out of the application’s directory, and access other resources.

<code><select name="language"><option value="fr">Français</option></select></code>
<code>… </code>
<code>require_once ($_REQUEST['language’]."lang.php");</code>

Such code can be attacked using a string like "../../../../etc/passwd%00" using [http://www.owasp.org/index.php/Data_Validation null byte injection] (see the [http://www.owasp.org/index.php/OWASP_Guide_Project OWASP Guide] for more information) to access any file on the web server’s file system.

Similarly, references to database keys are frequently exposed. An attacker can attack these parameters simply by guessing or searching for another valid key. Often, these are sequential in nature. In the example below, even if an application does not present any links to unauthorized carts, and no SQL injection is possible, an attacker can still change the cartID parameter to whatever cart they want.

<code>int cartID = Integer.parseInt( request.getParameter( "cartID" ) );</code>
<code>String query = "SELECT * FROM table WHERE cartID=" + cartID;</code>

== Verifying Security ==

The goal is to verify that the application does not allow direct object references to be manipulated by an attacker.

Automated approaches: Vulnerability scanning tools will have difficulty identifying which parameters are susceptible to manipulation or whether the manipulation worked. Static analysis tools really cannot know which parameters must have an access control check before use.

Manual approaches: Code review can trace critical parameters and identify whether they are susceptible to manipulation in many cases. Penetration testing can also verify that manipulation is possible. However, both of these techniques are time-consuming and can be spotty.

== Protection ==

The best protection is to avoid exposing direct object references to users by using an index, indirect reference map, or other indirect method that is easy to validate. If a direct object reference must be used, ensure that the user is authorized before using it.

Establishing a standard way of referring to application objects is important:

*'''Avoid exposing your private object references to users''' whenever possible, such as primary keys or filenames
*'''Validate any private object references''' extensively with an "accept known good" approach
*'''Verify authorization to all referenced objects'''
The best solution is to use an index value or a reference map to prevent parameter manipulation attacks.

<code>http://www.example.com/application?file=1</code>
If you must expose direct references to database structures, ensure that SQL statements and other database access methods only allow authorized records to be shown:

<code>int cartID = Integer.parseInt( request.getParameter( "cartID" ) );</code>
<code>User user = (User)request.getSession().getAttribute( "user" );</code>
<code>String query = "SELECT * FROM table WHERE
cartID=" + cartID + " '''AND userID=" + user.getID()''';</code>

== Samples ==

*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0329 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0329]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4369 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4369]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0229 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0229]

== References ==

*CWE: CWE-22 (Path Traversal), CWE-472 (Web Parameter Tampering)
*WASC Threat Classification: [http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml], [http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml]
*OWASP Testing Guide, [http://www.owasp.org/index.php/Testing_for_business_logic http://www.owasp.org/index.php/Testing_for_business_logic]
*OWASP Testing Guide, [http://www.owasp.org/index.php/Testing_for_Directory_Traversal http://www.owasp.org/index.php/Testing_for_Directory_Traversal]
*OWASP, [http://www.owasp.org/index.php/Category:Access_Control_Vulnerability http://www.owasp.org/index.php/Category:Access_Control_Vulnerability]
*GST Assist attack details, [http://www.abc.net.au/7.30/stories/s146760.htm http://www.abc.net.au/7.30/stories/s146760.htm]

{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Cross Site Request Forgery|useprev=PrevLink|prev=-Malicious File Execution|usemain=MainLink|main=}}

Talk:Java Server Faces

2007-06-11T18:30:20Z

Ebing: /* EUxx discussion */

== EUxx discussion ==
I think the blog by EUxx missed some of the details of the implementation. Note that while the MAC and the IV are known, there is still a secret key known to the server used in the MAC that prevents the client from generating a new MAC. This is a fairly common pattern. You can see Inderjeet's response at:
http://weblogs.java.net/blog/inder/archive/2005/05/securing_webapp.html

I think we should either take this section out, or expand on why its an issue.
[[User:Ebing|Ebing]] 14:30, 11 June 2007 (EDT)

Talk:Java Server Faces

2007-06-11T18:23:22Z

Ebing: New page: == EUxx discussion == I think the blog by EUxx missed some of the details of the implementation. Note that while the MAC and the IV are known, there is still a secret key known to the ser...

Java Server Faces

2007-06-11T17:57:31Z

Ebing: /* JSF Standards and roles */ cleanup of language

==Status==
'''Content to be finalised. Needs reviewing'''
==Author==
Sam Reghenzi
==Web security.. before you start ==

This document is about security in web applications developed using the Java Server Faces (JSF) framework. The reader should be aware of the meaning of common terms of both JSF (converters, validators, managed beans) and web security (injection etc.)

==JSF Standards and roles==
JavaServer Faces (JSF) is a Java-based Web application framework that implements the Model-View-Controller pattern and simplifies the development of web interfaces for Java EE applications.

In a standard MVC JSF are meant to provide the V (of view) and part of the C (of Control). JSF components can present almost any basic interface model. The framework also provides part of the Control layer including:
* Navigation Handling
* Error Handling
* Action and event Management
* Input validation
* Value conversion
These elements are defined by the JSF standard (JCP 127) so that any attacker will have knowledge of the architecture and life cycle of a JSF based application. JSF does not implement it's own security model but instead relies on standard JEE security. This means that both application server security model, JAAS or other ACL implementations can be used with the JSF framework without any integration effort. But Access Control is just one part of security - all aspects should be implemented in a secure manner in order to consider the application itself secure.

==Client-side state saving==
A JSF application can save the state of its components in the client response or on the server. Saving state on the client may be required because some users turn off cookies support, but it can increase response times when connections are slow. Saving state on the server may have the disadvantage of high memory consumption for the user, but it does minimize bandwidth requirements.
Since client-side state saving stores data in the client , it should be used wisely, or not used at all. An attacker that can manipulate a user's data could manage a data tampering or worst, a privilege escalation exploit. Unencrypted data is quite easy to manipulate and most of the client-side saved data are serialized Java objects which can contain a wealth of sensitive data. If you plan to use client-side state saving carefully consider which information you decide to store in the POJO/DTO in order to minimise these risks.
==Components==
===Converters===
Converter could be a source of threat since it converts string in Java objects. An attacker could inject malicious code or tampered data to make the converter itself misbehave and expose protected data. The converter system is not insecure by itself, but conversion, since it is a security touch point for business logic and persistent data, should be handled carefully. Input should '''always''' be validated '''after''' being converted. In JSF lingo you should '''always''' have a validator if a conversion occurs. See next section on how to implement a security aware validator.

===Validators===
Validation is your chance to verify that the input is as expected. This means that the input should be validated both from a domain view and from a security view. If input represents a string that in your domain should be from 10 to 254 characters long, the same string should be validated also to prevent SQL Injection and XSS attacks. Since many security checks are done using dictionary algorithms it's useful to have a validator that implements those checks and extends it to implement your domain validator.
For example:

public class TenToHundredsValidator extends SecureValidator() {
public void validate(...) {

super.validate(...); // Do security checks

domainvalidate(....);
}
}

===ManagedBeans===
Managed beans are the gears of JSF based application. Developers can access FacesContext statically and this is potentially dangerous. This is a common short cut for everything in the JSF layer, but manipulating this data could be harmful. Relying on security principals, and software engineering, is always a good approach.
Calls such as:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameter("name")
are dangerous because the whole validation stack is bypassed. You can read parameters but consider them as tainted input. Use Validators described above also if you are not in the validation phase . Validators are also an effective way to refactor your validation code and to prevent code repetition.
FacesContext also allows access to user principal data; this data could be used to verify if the current user can actually execute the business logic in the managed Bean.
This practice should be adopted in favour of rendering or not the commandLinks that lead to the action of the managed Bean. A structured adoption of an execution based security framework , such as ACEGI (see the Appendix), could be a good enforcement of the security of the managed bean.
===Custom components===
If the use of custom components is required in the application, the security depends on how the components are developed. Third party components should be delivered with a security report and support from the specific vendor or community.
If you develop custom components you should be aware of the same old security issues of web development:
* Do not thrust request parameter
* Do not thrust cookies
* Always consider that session could be hijacked
Since the component tree is assembled server side it can be trusted so if your custom component needs to read data from a sibling component it should be considered a safe operation although you will have to make assumptions on element names of the tree.
==Implementations==
Since more than one JSF Implementation exists, bugs of the implementation should be first on the security list.

===MyFaces===
There aren't major or critical security bugs registered in the current stable release of MyFaces (1.1.5). Client state saving is still the weak point and should be used wisely. My Faces comes also with a Security Extension (http://wiki.apache.org/myfaces/SecurityContext) that allows to safely and easily retrieve authenticated user details.

The MyFaces resource filter could be a source of threat. It is designed to expose resources from a jar file and could therefore, be considered, potentially dangerous. Note there aren't any claimed security flaws nor exploits in the resource filter, but the nature of this component makes it a good target for attackers. Since all it has to do is serve data it is recommended that a dispatcher be added to the filter mapping element. This should lower the possibility of an attacker successfully manipulating the server request.
For more information see: http://myfaces.apache.org/tomahawk/extensionsFilter.htm

There is also an easy way to enable encryption when using ''client save state''

<context-param>
<param-name>org.apache.myfaces.secret</param-name>
<param-value>NzY1NDMyMTA=</param-value>
</context-param>

Supported encryption methods are BlowFish, 3DES, AES and are definde bya a context parameter

<context-param>
<param-name>org.apache.myfaces.algorithm</param-name>
<param-value>Blowfish</param-value>
</context-param>

You can find mre info at http://wiki.apache.org/myfaces/Secure_Your_Application

===SUN Reference Implementation===
Quoting from the documentation:
''There are several ways for a web application to store session state on the client tier. One possible solution is to use Cookies to store the state on the client. However, cookies have limitations in size and are not ideal in cases where you want to store session state on the client. The state that needs to be stored on the client is first serialized into a byte array. This byte array is then encrypted using industrial-strength 3DES with cipher-block-chaining (CBC) and an initialization vector. To make the content tamper-resistant, we then create a message authentication code (using SHA1 algorithm) from the encrypted content and the initialization vector. The initialization vector, the message authentication code, and the encrypted content is then combined in a single byte array. Finally, this resulting byte array is converted into a base64 string which is stored in a hidden FORM field on the client.
This solution is secure because it uses a strong crypto algorithm and also uses a MAC for tamper-resistance. We also generate all the random numbers (for example, to generate the initialization vectors and the password) using the cryptographically-secure SecureRandom class. Note that the encryption keys are NEVER sent to the client or sent on the wire. These keys are used only on the server-side to encrypt and decrypt the state. One challenge is to decide what encryption keys to use. The encryption keys should not be known to the client, but still be associated with the client. We solve this problem by generating these keys from a password that is generated randomly and stored in the HttpSession. This strategy for key generation through password is pluggable in our solution and can be changed if needed.''
===EUxx===
http://jroller.com/page/eu stated the following:
''It seems there are few gaps in this claim. Data sent to the client look like this: [MAC][IV][ENCDATA] As you can see, MAC and IV values are known to the client. It means that nothing can stop client from tampering ENCDATA block and then generate a new MAC. This can be improved with using signature based on public key scheme instead of MAC. However that will increase amount of computations for building message data and will require to store public key in HttpSession. Another potential security issue is related to the usage of block cipher. By the nature of Object Serialization Stream Protocol, every encrypted plain text will have common patterns. More over, because client can indirectly control content of the encrypted data by submitting specially crafted requests to the server, that some data from request will be sent back in encrypted form). This can open the door for "known-text" attack and I'm not sure how good "industrial-strength" ciphers against such attacks. Again, this can be improved by generating secure key for every request, but it will create additional troubles on concurrent scenarios and will require that key will be distributed across the cluster on every change. So, I think that above issues has to be investigated more deep and proper security analysis must be done before suggesting any solution that is using some forms of cryptography.''
===ICE Faces===
TODO

==Apendix I==

===ACEGI Integration===

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. If used in combination with jsf, the managed beans could become more "security aware" since acegi do not only perform authentication but also authorization in business layer. Acegi is a convenient way to manage security in all the layers of our application. This is a valuable thing especially when authorization is strongly coupled with business logic (approval work flows etc).

In order to use a custom JSF-Acegi login we have to provide a valid Security Context (''userName'' and ''password'' are properties of the managed bean)

UsernamePasswordAuthenticationToken authReq = new UsernamePasswordAuthenticationToken(userName, password);
Authentication auth = getAuthenticationManager().authenticate(authReq);
SecurityContext secCtx = SecurityContextHolder.getContext();
secCtx.setAuthentication(auth);

We can override the standard ACEGI navigation with custom, logic driven, navigation reading security context and routing the outcome.

More information can be found at http://www.javakaffee.de/blog/2006/07/04/jsfacegi-authentication-with-a-backing-bean/

[[Category:OWASP Java Project]]