https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Webappsecguy 2026-05-21T08:04:54Z User contributions MediaWiki 1.27.2 https://wiki.owasp.org/index.php?title=File:University_of_British_Columbia_Logo.png&diff=156834 2013-08-15T02:50:26Z

<p>Webappsecguy: Webappsecguy uploaded a new version of &amp;quot;File:University of British Columbia Logo.png&amp;quot;</p> <hr /> <div></div>

Webappsecguy https://wiki.owasp.org/index.php?title=File:Ukl.jpg&diff=156833 2013-08-15T02:50:16Z

<p>Webappsecguy: Webappsecguy uploaded a new version of &amp;quot;File:Ukl.jpg&amp;quot;</p> <hr /> <div></div>

Webappsecguy https://wiki.owasp.org/index.php?title=File:PWC_log_resized.png&diff=156832 2013-08-15T02:50:06Z

<p>Webappsecguy: Webappsecguy uploaded a new version of &amp;quot;File:PWC log resized.png&amp;quot;</p> <hr /> <div></div>

Webappsecguy https://wiki.owasp.org/index.php?title=File:Northumbrialogo.jpg&diff=156831 2013-08-15T02:49:56Z

<p>Webappsecguy: Webappsecguy uploaded a new version of &amp;quot;File:Northumbrialogo.jpg&amp;quot;</p> <hr /> <div></div>

Webappsecguy https://wiki.owasp.org/index.php?title=File:Nlu_logo.png&diff=156830 2013-08-15T02:44:06Z

<p>Webappsecguy: Webappsecguy uploaded a new version of &amp;quot;File:Nlu logo.png&amp;quot;</p> <hr /> <div></div>

Webappsecguy https://wiki.owasp.org/index.php?title=File:Nlu_logo.gif&diff=156829 2013-08-15T02:39:42Z

<p>Webappsecguy: </p> <hr /> <div></div>

Webappsecguy https://wiki.owasp.org/index.php?title=File:TPLOGO_master.jpg&diff=156828 2013-08-15T02:29:28Z

<p>Webappsecguy: Webappsecguy uploaded a new version of &amp;quot;File:TPLOGO master.jpg&amp;quot;</p> <hr /> <div></div>

Webappsecguy https://wiki.owasp.org/index.php?title=Reflected_DOM_Injection&diff=156444 2013-08-05T17:41:43Z

<p>Webappsecguy: Clarity</p> <hr /> <div>Reflected DOM Injection, or ''RDI'', is a form of [[Cross-site_scripting#Stored_and_Reflected_XSS_Attacks|Stored Cross-Site Scripting]].<br /> <br /> The outline of the attack is as follows:<br /> <br /> # Crawler G retrieves data elements from attacker page A and commits the content to persisted storage as G[A] (e.g., a database row).<br /> # End user visits application T. Application T's persisted storage is the set of {G}.<br /> # End user's interaction with application T results in invocation of JavaScript code whereby G[A] is retrieved, and due to a failure neutralize the content in G[A] either prior to its persisted storage or during JavaScript execution at page runtime on the DOM, G[A] is executed as active code instead of being properly interpolated as a scalar-like primitive data value or closure-guarded object data.<br /> <br /> Maturely programmed crawlers often attempt to strip malicious data from crawled resources prior to persistent storage. Additionally, maturely programmed applications often utilize output escaping or JavaScript sandboxing to prevent crawled data from being executed (instead of being safely rendered). Nonetheless, obfuscation of data on a crawled resource may sidestep detection algorithms (although obfuscation may hint at an attempted attack), and reliance strictly on crawler sanitization of crawled resources may result in stored cross-site scripts executing if the target JavaScript context does not actively defend against it. In summary, when the attack is successful, the attack succeeds due to improper [[Data_Validation|data validation]].<br /> <br /> Arshan Dabirsiaghi surmised that vulnerability to this attack would eventually surface in popular search engines during his presentation at [[OWASP_NYC_AppSec_2008_Conference|OWASP NYC AppSec 2008]] and [[OWASP_AppSec_Europe_2008_-_Belgium|AppSec Europe 2008]], ''Next Generation Cross Site Scripting Worms'' (see also ''[https://www.owasp.org/images/1/1b/OWASP-AppSecEU08-Dabirsiaghi.pdf Building and Stopping Next Generation XSS Worms (May 8, 2008)]'', last accessed August 5, 2013). Daniel Chechik and Anat Davidi confirmed Dabirsiaghi's surmisal by demonstrating such vulnerability in the Google Translate web application and Yahoo! cached page results during the DEF CON 21 security conference in their August 2013 ''[https://defcon.org/html/defcon-21/dc-21-speakers.html#Chechik Utilizing Popular Websites for Malicious Purposes Using RDI]'' presentation.<br /> <br /> The [[DOM_based_XSS_Prevention_Cheat_Sheet|DOM-based XSS Prevention Cheat Sheet]] provides guidance on defense against this attack.<br /> <br /> <br /> [[Category:Attack]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Reflected_DOM_Injection&diff=156443 2013-08-05T17:33:17Z

<p>Webappsecguy: Clarification of verbiage</p> <hr /> <div>Reflected DOM Injection, or ''RDI'', is a form of [[Cross-site_scripting#Stored_and_Reflected_XSS_Attacks|Stored Cross-Site Scripting]].<br /> <br /> The outline of the attack is as follows:<br /> <br /> # Crawler G retrieves data elements from attacker page A and commits those contents to persisted storage as G[A] (e.g., a database row).<br /> # End user visits application T. Application T's persisted storage is the set of {G}.<br /> # End user's interaction with application T results in invocation of JavaScript code whereby G[A] is retrieved, and due to a failure neutralize the content in G[A] either prior to its persisted storage or during JavaScript execution from the DOM, G[A] is executed as active code instead of being properly interpolated as scalar-like primitive data value or closure-guarded object data.<br /> <br /> Maturely programmed crawlers often attempt to strip malicious data from crawled resources prior to persistent storage. Additionally, maturely programmed applications often utilize output escaping or JavaScript sandboxing to prevent crawled data from being executed instead of rendered. However, obfuscation of data on a crawled resource may sidestep detection, and reliance strictly on crawler sanitization of crawled resources may result in stored cross-site scripts executing if the target JavaScript context does not actively defend against it. In summary, when the attack is successful, the attack succeeds due to improper [[Data_Validation|data validation]].<br /> <br /> Arshan Dabirsiaghi surmised that vulnerability to this attack would eventually surface in popular search engines during his presentation at [[OWASP_NYC_AppSec_2008_Conference|OWASP NYC AppSec 2008]] and [[OWASP_AppSec_Europe_2008_-_Belgium|AppSec Europe 2008]], ''Next Generation Cross Site Scripting Worms'' (see also ''[https://www.owasp.org/images/1/1b/OWASP-AppSecEU08-Dabirsiaghi.pdf Building and Stopping Next Generation XSS Worms (May 8, 2008)]'', last accessed August 5, 2013). Daniel Chechik and Anat Davidi confirmed Dabirsiaghi's surmisal by demonstrating such vulnerability in the Google Translate web application and Yahoo! cached page results during the DEF CON 21 security conference in their August 2013 ''[https://defcon.org/html/defcon-21/dc-21-speakers.html#Chechik Utilizing Popular Websites for Malicious Purposes Using RDI]'' presentation.<br /> <br /> The [[DOM_based_XSS_Prevention_Cheat_Sheet|DOM-based XSS Prevention Cheat Sheet]] provides guidance on defense against this attack.<br /> <br /> <br /> [[Category:Attack]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Reflected_DOM_Injection&diff=156442 2013-08-05T17:32:28Z

<p>Webappsecguy: Linking to prevention guidance.</p> <hr /> <div>Reflected DOM Injection, or ''RDI'', is a form of [[Cross-site_scripting#Stored_and_Reflected_XSS_Attacks|Stored Cross-Site Scripting]].<br /> <br /> The outline of the attack is as follows:<br /> <br /> # Crawler G retrieves data elements from attacker page A and commits those contents to persisted storage as G[A] (e.g., a database row).<br /> # End user visits application T. Application T's persisted storage is the set of {G}.<br /> # End user's interaction with application T results in invocation of JavaScript code whereby G[A] is retrieved, and due to a failure neutralize the content in G[A] either prior to its persisted storage or during JavaScript execution from the DOM, G[A] is executed as active code instead of being properly interpolated as scalar-like primitive data value or closure-guarded object data.<br /> <br /> Maturely programmed crawlers often attempt to strip malicious data from crawled resources prior to persistent storage. Additionally, maturely programmed applications often utilize output escaping or JavaScript sandboxing to prevent crawled data from being executed instead of rendered. However, obfuscation of data on a crawled resource may sidestep detection, and reliance strictly on crawler sanitization of crawled resources may result in stored cross-site scripts executing if the target JavaScript context does not actively defend against it. In summary, when the attack is successful, the attack succeeds due to improper [[Data_Validation|data validation]].<br /> <br /> Arshan Dabirsiaghi surmised that vulnerability to this attack would eventually surface in popular search engines during his presentation at [[OWASP_NYC_AppSec_2008_Conference|OWASP NYC AppSec 2008]] and [[OWASP_AppSec_Europe_2008_-_Belgium|AppSec Europe 2008]], ''Next Generation Cross Site Scripting Worms'' (see also ''[https://www.owasp.org/images/1/1b/OWASP-AppSecEU08-Dabirsiaghi.pdf Building and Stopping Next Generation XSS Worms (May 8, 2008)]'', last accessed August 5, 2013). Daniel Chechik and Anat Davidi confirmed Dabirsiaghi's surmisal by demonstrating such vulnerability in the Google Translate web application and Yahoo! cached page results during the DEF CON 21 security conference in their August 2013 ''[https://defcon.org/html/defcon-21/dc-21-speakers.html#Chechik Utilizing Popular Websites for Malicious Purposes Using RDI]'' presentation.<br /> <br /> The [[DOM_based_XSS_Prevention_Cheat_Sheet|DOM-based XSS Prevention Cheat Sheet]] provides guidance against this attack.<br /> <br /> <br /> [[Category:Attack]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Reflected_DOM_Injection&diff=156441 2013-08-05T17:27:34Z

<p>Webappsecguy: Cross linking to Data Validation page.</p> <hr /> <div>Reflected DOM Injection, or ''RDI'', is a form of [[Cross-site_scripting#Stored_and_Reflected_XSS_Attacks|Stored Cross-Site Scripting]].<br /> <br /> The outline of the attack is as follows:<br /> <br /> # Crawler G retrieves data elements from attacker page A and commits those contents to persisted storage as G[A] (e.g., a database row).<br /> # End user visits application T. Application T's persisted storage is the set of {G}.<br /> # End user's interaction with application T results in invocation of JavaScript code whereby G[A] is retrieved, and due to a failure neutralize the content in G[A] either prior to its persisted storage or during JavaScript execution from the DOM, G[A] is executed as active code instead of being properly interpolated as scalar-like primitive data value or closure-guarded object data.<br /> <br /> Maturely programmed crawlers often attempt to strip malicious data from crawled resources prior to persistent storage. Additionally, maturely programmed applications often utilize output escaping or JavaScript sandboxing to prevent crawled data from being executed instead of rendered. However, obfuscation of data on a crawled resource may sidestep detection, and reliance strictly on crawler sanitization of crawled resources may result in stored cross-site scripts executing if the target JavaScript context does not actively defend against it. In summary, the attack succeeds due to improper [[Data_Validation|data validation]]<br /> <br /> Arshan Dabirsiaghi surmised that vulnerability to this attack would eventually surface in popular search engines during his presentation at [[OWASP_NYC_AppSec_2008_Conference|OWASP NYC AppSec 2008]] and [[OWASP_AppSec_Europe_2008_-_Belgium|AppSec Europe 2008]], ''Next Generation Cross Site Scripting Worms'' (see also ''[https://www.owasp.org/images/1/1b/OWASP-AppSecEU08-Dabirsiaghi.pdf Building and Stopping Next Generation XSS Worms (May 8, 2008)]'', last accessed August 5, 2013). Daniel Chechik and Anat Davidi confirmed Dabirsiaghi's surmisal by demonstrating such vulnerability in the Google Translate web application and Yahoo! cached page results during the DEF CON 21 security conference in their August 2013 ''[https://defcon.org/html/defcon-21/dc-21-speakers.html#Chechik Utilizing Popular Websites for Malicious Purposes Using RDI]'' presentation.<br /> <br /> <br /> [[Category:Attack]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Reflected_DOM_Injection&diff=156440 2013-08-05T17:16:18Z

<p>Webappsecguy: Citation</p> <hr /> <div>Reflected DOM Injection, or ''RDI'', is a form of [[Cross-site_scripting#Stored_and_Reflected_XSS_Attacks|Stored Cross-Site Scripting]].<br /> <br /> The outline of the attack is as follows:<br /> <br /> # Crawler G retrieves data elements from attacker page A and commits those contents to persisted storage as G[A] (e.g., a database row).<br /> # End user visits application T. Application T's persisted storage is the set of {G}.<br /> # End user's interaction with application T results in invocation of JavaScript code whereby G[A] is retrieved, and due to a failure neutralize the content in G[A] either prior to its persisted storage or during JavaScript execution from the DOM, G[A] is executed as active code instead of being properly interpolated as scalar-like primitive data value or closure-guarded object data.<br /> <br /> Maturely programmed crawlers often attempt to strip malicious data from crawled resources prior to persistent storage. Additionally, maturely programmed applications often utilize output escaping or JavaScript sandboxing to prevent crawled data from being executed instead of rendered. However, obfuscation of data on a crawled resource may sidestep detection, and reliance strictly on crawler sanitization of crawled resources may result in stored cross-site scripts executing if the target JavaScript context does not actively defend against all non-scalar data.<br /> <br /> Arshan Dabirsiaghi surmised that vulnerability to this attack would eventually surface in popular search engines during his presentation at [[OWASP_NYC_AppSec_2008_Conference|OWASP NYC AppSec 2008]] and [[OWASP_AppSec_Europe_2008_-_Belgium|AppSec Europe 2008]], ''Next Generation Cross Site Scripting Worms'' (see also ''[https://www.owasp.org/images/1/1b/OWASP-AppSecEU08-Dabirsiaghi.pdf Building and Stopping Next Generation XSS Worms (May 8, 2008)]'', last accessed August 5, 2013). Daniel Chechik and Anat Davidi confirmed Dabirsiaghi's surmisal by demonstrating such vulnerability in the Google Translate web application and Yahoo! cached page results during the DEF CON 21 security conference in their August 2013 ''[https://defcon.org/html/defcon-21/dc-21-speakers.html#Chechik Utilizing Popular Websites for Malicious Purposes Using RDI]'' presentation.<br /> <br /> <br /> [[Category:Attack]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=RDI&diff=156439 2013-08-05T16:58:36Z

<p>Webappsecguy: Redirected page to Reflected DOM Injection</p> <hr /> <div>#REDIRECT [[Reflected DOM Injection]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Reflected_DOM_Injection&diff=156438 2013-08-05T16:56:51Z

<p>Webappsecguy: Created page with &quot;Reflected DOM Injection, or ''RDI'', is a form of Stored Cross-Site Scripting. The outline of the attack is as follo...&quot;</p> <hr /> <div>Reflected DOM Injection, or ''RDI'', is a form of [[Cross-site_scripting#Stored_and_Reflected_XSS_Attacks|Stored Cross-Site Scripting]].<br /> <br /> The outline of the attack is as follows:<br /> <br /> # Crawler G retrieves data elements from attacker page A and commits those contents to persisted storage as G[A] (e.g., a database row).<br /> # End user visits application T. Application T's persisted storage is the set of {G}.<br /> # End user's interaction with application T results in invocation of JavaScript code whereby G[A] is retrieved, and due to a failure neutralize the content in G[A] either prior to its persisted storage or during JavaScript execution from the DOM, G[A] is executed as active code instead of being properly interpolated as scalar-like primitive data value or closure-guarded object data.<br /> <br /> Maturely programmed crawlers often attempt to strip malicious data from crawled resources prior to persistent storage. Additionally, maturely programmed applications often utilize output escaping or JavaScript sandboxing to prevent crawled data from being executed instead of rendered. However, obfuscation of data on a crawled resource may sidestep detection, and reliance strictly on crawler sanitization of crawled resources may result in stored cross-site scripts executing if the target JavaScript context does not actively defend against all non-scalar data.<br /> <br /> Arshan Dabirsiaghi surmised that vulnerability to this attack would eventually surface in popular search engines during his presentation at [[OWASP_NYC_AppSec_2008_Conference|OWASP NYC AppSec 2008]], ''Next Generation Cross Site Scripting Worms''. Daniel Chechik and Anat Davidi confirmed Dabirsiaghi's surmisal by demonstrating such vulnerability in the Google Translate web application and Yahoo! cached page results during the DEF CON 21 security conference in their August 2013 ''[https://defcon.org/html/defcon-21/dc-21-speakers.html#Chechik Utilizing Popular Websites for Malicious Purposes Using RDI]'' presentation.<br /> <br /> <br /> [[Category:Attack]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Testing_for_Logout_and_Browser_Cache_Management_(OWASP-AT-007)&diff=156412 2013-08-05T00:29:23Z

<p>Webappsecguy: post release notes</p> <hr /> <div>{{Template:OWASP Testing Guide v3}}<br /> <br /> == Brief Summary ==<br /> In this phase, we check that the logout function is properly implemented, and that it is not possible to “reuse” a session after logout. We also check that the application automatically logs out a user when that user has been idle for a certain amount of time, and that no sensitive data remains stored in the browser cache.<br /> &lt;br&gt;<br /> == Description of the Issue == <br /> The end of a web session is usually triggered by one of the following two events:<br /> <br /> * The user logs out<br /> * The user remains idle for a certain amount of time and the application automatically logs him/her out<br /> <br /> Both cases must be implemented carefully, in order to avoid introducing weaknesses that could be exploited by an attacker to gain unauthorized access. More specifically, the logout function must ensure that all session tokens (e.g., cookies) are properly destroyed or made unusable, and that proper controls are enforced at the server side to prevent the reuse of session tokens.<br /> <br /> Note: the most important thing is for the application to invalidate the session on the server side. Generally this means that the code must invoke the appropriate methods, e.g., HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is a nice touch, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.<br /> <br /> If such actions are not properly carried out, an attacker could replay these session tokens in order to “resurrect” the session of a legitimate user and impersonate him/her (this attack is usually known as 'cookie replay'). Of course, a mitigating factor is that the attacker needs to be able to access those tokens (which are stored on the victim's PC), but, in a variety of cases, this may not be impossible or particularly difficult. The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g., webmail, online bank account): when the user has finished using the application and logs out, if the logout process is not properly enforced, the following user could access the same account, for instance, by simply pressing the “back” button of the browser. Another scenario can result from a Cross Site Scripting vulnerability or a connection that is not 100% protected by SSL: a flawed logout function would make stolen cookies useful for a much longer time, making life for the attacker much easier.<br /> The third test of this chapter is aimed to check that the application prevents the browser to cache sensitive data, which again would pose a danger to a user accessing the application from a public computer.<br /> &lt;br&gt;<br /> <br /> == Black Box testing and examples ==<br /> '''Logout function:''' &lt;br&gt;<br /> The first step is to test the presence of the logout function. Check that the application provides a logout button and that this button is present and well visible on all pages that require authentication. A logout button that is not clearly visible, or that is present only on certain pages, poses a security risk, as the user might forget to use it at the end of his/her session.<br /> <br /> The second step consists of checking what happens to the session tokens when the logout function is invoked. For instance, when cookies are used, a proper behavior is to erase all session cookies, by issuing a new Set-Cookie directive that sets their value to a non-valid one (e.g., “NULL” or some equivalent value), and, if the cookie is persistent, setting its expiration date in the past, which tells the browser to discard the cookie. So, if the authentication page originally sets a cookie in the following way:<br /> <br /> &lt;pre&gt;<br /> Set-Cookie: SessionID=sjdhqwoy938eh1q; expires=Sun, 29-Oct-2006 12:20:00 GMT; path=/; domain=victim.com<br /> &lt;/pre&gt;<br /> the logout function should trigger a response somewhat resembling the following:<br /> &lt;pre&gt;<br /> Set-Cookie: SessionID=noauth; expires=Sat, 01-Jan-2000 00:00:00 GMT; path=/; domain=victim.com<br /> &lt;/pre&gt;<br /> The first (and simplest) test at this point consists of logging out and then hitting the 'back' button of the browser, to check whether we are still authenticated. If we are, it means that the logout function has been implemented insecurely, and that the logout function does not destroy the session IDs. This happens sometimes with applications that use non-persistent cookies and that require the user to close his browser in order to effectively erase such cookies from memory. Some of these applications provide a warning to the user, suggesting her to close her browser, but this solution completely relies on the user behavior, and results in a lower level of security compared to destroying the cookies. Other applications might try to close the browser using JavaScript, but that again is a solution that relies on the client behavior, which is intrinsically less secure, since the client browser could be configured to limit the execution of scripts (and, in this case, a configuration that had the goal of increasing security would end up decreasing it). Moreover, the effectiveness of this solution would be dependent on the browser vendor, version, and settings (e.g., the JavaScript code might successfully close an Internet Explorer instance, but fail to close a Firefox one).<br /> <br /> If by pressing the 'back' button we can access previous pages but not access new ones, then we are simply accessing the browser cache. If these pages contain sensitive data, it means that the application did not forbid the browser to cache it (by not setting the Cache-Control header, a different kind of problem that we will analyze later).<br /> <br /> After the “back button” technique has been tried, it's time for something a little more sophisticated: we can re-set the cookie to the original value and check whether we can still access the application in an authenticated fashion. If we can, it means that there is not a server-side mechanism that keeps track of active and non active cookies, but that the correctness of the information stored in the cookie is enough to grant access. To set a cookie to a determined value, we can use WebScarab, and, intercepting one response of the application, insert a Set-Cookie header with our desired values:<br /> &lt;br&gt;&lt;br&gt;<br /> [[image:TestingGuide-LogoutTest-fig1.png]]<br /> &lt;br&gt;&lt;br&gt;<br /> Alternatively, we can install a cookie editor in our browser (e.g., Add N Edit Cookies in Firefox):<br /> &lt;br&gt;&lt;br&gt;<br /> [[image:TestingGuide-LogoutTest-fig2.png]]<br /> &lt;br&gt;&lt;br&gt;<br /> A notable example of a design where there is no control at the server side about cookies that belong to logged-out users is ASP.NET FormsAuthentication class, where the cookie is basically an encrypted and authenticated version of the user credentials, which are decrypted and checked by the server side. While this is very effective in preventing cookie tampering, the fact that the server does not maintain an internal record of the session status means that it is possible to launch a cookie replay attack after the legitimate user has logged out, provided that the cookie has not expired yet (see the references for further detail).<br /> <br /> It should be noted that this test only applies to session cookies, and that a persistent cookie that only stores data about some minor user preferences (e.g., site appearance) and that is not deleted when the user logs out is not to be considered a security risk.<br /> &lt;br&gt;&lt;br&gt;<br /> '''Timeout logout'''&lt;br&gt;<br /> The same approach that we have seen in the previous section can be applied when measuring the timeout logout. The most appropriate logout time should be a right balance between security (shorter logout time) and usability (longer logout time) and heavily depends on the criticality of the data handled by the application. A 60 minute logout time for a public forum can be acceptable, but such a long time would be way too much in a home banking application. In any case, any application that does not enforce a timeout-based logout should be considered not secure, unless such a behavior is addressing a specific functional requirement.<br /> The testing methodology is very similar to the one outlined in the previous section. First, we have to check whether a timeout exists, for instance, by logging in and then killing some time reading some other Testing Guide chapter, waiting for the timeout logout to be triggered. As in the logout function, after the timeout has passed, all session tokens should be destroyed or be unusable. We also need to understand whether the timeout is enforced by the client or by the server (or both). Getting back to our cookie example, if the session cookie is non-persistent (or, more in general, the session token does not store any data about the time), we can be sure that the timeout is enforced by the server. If the session token contains some time related data (e.g., login time, or last access time, or expiration date for a persistent cookie), then we know that the client is involved in the timeout enforcing. In this case, we need to modify the token (if it's not cryptographically protected) and see what happens to our session. For instance, we can set the cookie expiration date far in the future and see whether our session can be prolonged. As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.<br /> &lt;br&gt;&lt;br&gt;'''Cached pages'''&lt;br&gt;<br /> Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored. Therefore, another test that is to be performed is to check that our application does not leak any critical data into the browser cache. In order to do that, we can use WebScarab and search through the server responses that belong to our session, checking that for every page that contains sensitive information the server instructed the browser not to cache any data. Such a directive can be issued in the HTTP response headers (POST RELEASE NOTE: Cache-Control: no-cache, no-store coupled with Expires: 0 and Pragma: no-cache is generally robust although additional flags may be necessary for the Cache-Control header in order to better prevent persistently linked files on the filesystem; these include must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0.)<br /> &lt;pre&gt;<br /> HTTP/1.1:<br /> Cache-Control: no-cache<br /> &lt;/pre&gt;<br /> &lt;pre&gt;<br /> HTTP/1.0:<br /> Pragma: no-cache<br /> Expires: &lt;past date or illegal value (e.g., 0)&gt;<br /> &lt;/pre&gt;<br /> &lt;br&gt;<br /> Alternatively, the same effect can be obtained directly at the HTML level, including in each page that contains sensitive data the following code: (POST RELEASE NOTE: META TAGS ARE COMMONLY INEFFECTIVE.)<br /> &lt;pre&gt;<br /> HTTP/1.1:<br /> &lt;META HTTP-EQUIV=&quot;Cache-Control&quot; CONTENT=&quot;no-cache&quot;&gt;<br /> &lt;/pre&gt;<br /> &lt;pre&gt;<br /> HTTP/1.0: <br /> &lt;META HTTP-EQUIV=&quot;Pragma&quot; CONTENT=&quot;no-cache&quot;&gt;<br /> &lt;META HTTP-EQUIV=”Expires” CONTENT=”Sat, 01-Jan-2000 00:00:00 GMT”&gt;<br /> &lt;/pre&gt;&lt;br&gt;<br /> For instance, if we are testing an e-commerce application, we should look for all pages that contain a credit card number or some other financial information, and check that all those pages enforce the no-cache directive.<br /> On the other hand, if we find pages that contain critical information but that fail to instruct the browser not to cache their content, we know that sensitive information will be stored on the disk, and we can double-check that simply by looking for it in the browser cache. The exact location where that information is stored depends on the client operating system and on the browser that has been used. Here are some examples:<br /> <br /> * Mozilla Firefox:<br /> ** Unix/Linux: ~/.mozilla/firefox/&lt;profile-id&gt;/Cache/<br /> ** Windows: C:\Documents and Settings\&lt;user_name&gt;\Local Settings\Application Data\Mozilla\Firefox\Profiles\&lt;profile-id&gt;\Cache&gt;<br /> <br /> * Internet Explorer:<br /> ** C:\Documents and Settings\&lt;user_name&gt;\Local Settings\Temporary Internet Files&gt;<br /> &lt;br&gt;<br /> <br /> == Gray Box testing and example == <br /> As a general rule, we need to check that:<br /> * The logout function effectively destroys all session token, or at least renders them unusable<br /> * The server performs proper checks on the session state, disallowing an attacker to replay some previous token<br /> * A timeout is enforced and it is properly checked by the server. If the server uses an expiration time that is read from a session token that is sent by the client, the token must be cryptographically protected<br /> &lt;br&gt;<br /> For the secure cache test, the methodology is equivalent to the black box case, as in both scenarios we have full access to the server response headers and to the HTML code.<br /> &lt;br&gt;<br /> <br /> == References ==<br /> '''Whitepapers'''<br /> * ASP.NET Forms Authentication: &quot;Best Practices for Software Developers&quot; - http://www.foundstone.com/resources/whitepapers/ASPNETFormsAuthentication.pdf<br /> * &quot;The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications&quot; - http://support.microsoft.com/default.aspx?scid=kb;en-us;900111<br /> &lt;br&gt;<br /> '''Tools'''<br /> * Add N Edit Cookies (Firefox extension): https://addons.mozilla.org/firefox/573/<br /> &lt;br&gt;</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet&diff=156411 2013-08-05T00:10:40Z

<p>Webappsecguy: clairification.</p> <hr /> <div>= Introduction =<br /> <br /> This article provides a simple model to follow when implementing transport layer protection for an application. Although the concept of SSL is known to many, the actual details and security specific decisions of implementation are often poorly understood and frequently result in insecure deployments. This article establishes clear rules which provide guidance on securely designing and configuring transport layer security for an application. This article is focused on the use of SSL/TLS between a web application and a web browser, but that we also encourage the use of SSL/TLS or other network encryption technologies, such as VPN, on back end and other non-browser based connections.&lt;br&gt; <br /> <br /> == Architectural Decision ==<br /> <br /> An architectural decision must be made to determine the appropriate method to protect data when it is being transmitted. The most common options available to corporations are Virtual Private Networks (VPN) or a SSL/TLS model commonly used by web applications. The selected model is determined by the business needs of the particular organization. For example, a VPN connection may be the best design for a partnership between two companies that includes mutual access to a shared server over a variety of protocols. Conversely, an Internet facing enterprise web application would likely be best served by a SSL/TLS model. <br /> <br /> This cheat sheet will focus on security considerations when the SSL/TLS model is selected. This is a frequently used model for publicly accessible web applications.<br /> <br /> = Providing Transport Layer Protection with SSL/TLS =<br /> <br /> == Benefits ==<br /> <br /> The primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back end and other non-browser based enterprise components. <br /> <br /> The server validation component of TLS provides authentication of the server to the client. If configured to require client side certificates, TLS can also play a role in client authentication to the server. However, in practice client side certificates are not often used in lieu of username and password based authentication models for clients.<br /> <br /> TLS also provides two additional benefits that are commonly overlooked; integrity guarantees and replay prevention. A TLS stream of communication contains built-in controls to prevent tampering with any portion of the encrypted data. In addition, controls are also built-in to prevent a captured stream of TLS data from being replayed at a later time.<br /> <br /> It should be noted that TLS provides the above guarantees to data during transmission. TLS does not offer any of these security benefits to data that is at rest. Therefore appropriate security controls must be added to protect data while at rest within the application or within data stores.<br /> <br /> == Basic Requirements ==<br /> <br /> The basic requirements for using TLS are: access to a Public Key Infrastructure (PKI) in order to obtain certificates, access to a directory or an Online Certificate Status Protocol (OCSP) responder in order to check certificate revocation status, and agreement/ability to support a minimum configuration of protocol versions and protocol options for each version.<br /> <br /> == SSL vs. TLS ==<br /> <br /> The terms, Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. In fact, SSL v3.1 is equivalent to TLS v1.0. However, different versions of SSL and TLS are supported by modern web browsers and by most modern web frameworks and platforms. For the purposes of this cheat sheet we will refer to the technology generically as TLS. Recommendations regarding the use of SSL and TLS protocols, as well as browser support for TLS, can be found in the rule below title [[Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Protocols| &quot;Only Support Strong Protocols&quot;]].<br /> <br /> [[Image:Asvs_cryptomodule.gif|thumb|350px|right|Cryptomodule Parts and Operation]]<br /> <br /> == When to Use a FIPS 140-2 Validated Cryptomodule ==<br /> <br /> If the web application may be the target of determined attackers (a common threat model for Internet accessible applications handling sensitive data), it is strongly advised to use TLS services that are provided by [http://csrc.nist.gov/groups/STM/cmvp/validation.html FIPS 140-2 validated cryptomodules]. <br /> <br /> A cryptomodule, whether it is a software library or a hardware device, basically consists of three parts:<br /> <br /> * Components that implement cryptographic algorithms (symmetric and asymmetric algorithms, hash algorithms, random number generator algorithms, and message authentication code algorithms) <br /> * Components that call and manage cryptographic functions (inputs and outputs include cryptographic keys and so-called critical security parameters) <br /> * A physical container around the components that implement cryptographic algorithms and the components that call and manage cryptographic functions<br /> <br /> The security of a cryptomodule and its services (and the web applications that call the cryptomodule) depend on the correct implementation and integration of each of these three parts. In addition, the cryptomodule must be used and accessed securely. The includes consideration for:<br /> <br /> * Calling and managing cryptographic functions<br /> * Securely Handling inputs and output<br /> * Ensuring the secure construction of the physical container around the components<br /> <br /> In order to leverage the benefits of TLS it is important to use a TLS service (e.g. library, web framework, web application server) which has been FIPS 140-2 validated. In addition, the cryptomodule must be installed, configured and operated in either an approved or an allowed mode to provide a high degree of certainty that the FIPS 140-2 validated cryptomodule is providing the expected security services in the expected manner.<br /> <br /> If the system is legally required to use FIPS 140-2 encryption (e.g., owned or operated by or on behalf of the U.S. Government) then TLS must be used and SSL disabled. Details on why SSL is unacceptable are described in Section 7.1 of [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program].<br /> <br /> Further reading on the use of TLS to protect highly sensitive data against determined attackers can be viewed in [http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf SP800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations]<br /> <br /> == Secure Server Design ==<br /> <br /> === Rule - Use TLS for All Login Pages and All Authenticated Pages ===<br /> <br /> The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the &quot;login landing page&quot;, must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session. <br /> <br /> === Rule - Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data ===<br /> <br /> All networks, both external and internal, which transmit sensitive data must utilize TLS or an equivalent transport layer security mechanism. It is not sufficient to claim that access to the internal network is &quot;restricted to employees&quot;. Numerous recent data compromises have shown that the internal network can be breached by attackers. In these attacks, sniffers have been installed to access unencrypted sensitive data sent on the internal network. <br /> <br /> === Rule - Do Not Provide Non-TLS Pages for Secure Content ===<br /> <br /> All pages which are available over TLS must not be available over a non-TLS connection. A user may inadvertently bookmark or manually type a URL to a HTTP page (e.g. http://example.com/myaccount) within the authenticated portion of the application. If this request is processed by the application then the response, and any sensitive data, would be returned to the user over the clear text HTTP.<br /> <br /> === Rule - REMOVED - Do Not Perform Redirects from Non-TLS Page to TLS Login Page ===<br /> <br /> This recommendation has been removed. Ultimately, the below guidance will only provide user education and cannot provide any technical controls to protect the user against a man-in-the-middle attack. <br /> <br /> --<br /> <br /> A common practice is to redirect users that have requested a non-TLS version of the login page to the TLS version (e.g. http://example.com/login redirects to https://example.com/login). This practice creates an additional attack vector for a man in the middle attack. In addition, redirecting from non-TLS versions to the TLS version reinforces to the user that the practice of requesting the non-TLS page is acceptable and secure.<br /> <br /> In this scenario, the man-in-the-middle attack is used by the attacker to intercept the non-TLS to TLS redirect message. The attacker then injects the HTML of the actual login page and changes the form to post over unencrypted HTTP. This allows the attacker to view the user's credentials as they are transmitted in the clear.<br /> <br /> It is recommended to display a security warning message to the user whenever the non-TLS login page is requested. This security warning should urge the user to always type &quot;HTTPS&quot; into the browser or bookmark the secure login page. This approach will help educate users on the correct and most secure method of accessing the application.<br /> <br /> Currently there are no controls that an application can enforce to entirely mitigate this risk. Ultimately, this issue is the responsibility of the user since the application cannot prevent the user from initially typing [http://owasp.org http://example.com/login] (versus HTTPS). <br /> <br /> Note: [http://www.w3.org/Security/wiki/Strict_Transport_Security Strict Transport Security] will address this issue and will provide a server side control to instruct supporting browsers that the site should only be accessed over HTTPS<br /> <br /> === Rule - Do Not Mix TLS and Non-TLS Content ===<br /> <br /> A page that is available over TLS must be comprised completely of content which is transmitted over TLS. The page must not contain any content that is transmitted over unencrypted HTTP. This includes content from unrelated third party sites. <br /> <br /> An attacker could intercept any of the data transmitted over the unencrypted HTTP and inject malicious content into the user's page. This malicious content would be included in the page even if the overall page is served over TLS. In addition, an attacker could steal the user's session cookie that is transmitted with any non-TLS requests. This is possible if the cookie's 'secure' flag is not set. See the rule 'Use &quot;Secure&quot; Cookie Flag'<br /> <br /> === Rule - Use &quot;Secure&quot; Cookie Flag ===<br /> <br /> The &quot;Secure&quot; flag must be set for all user cookies. Failure to use the &quot;secure&quot; flag enables an attacker to access the session cookie by tricking the user's browser into submitting a request to an unencrypted page on the site. This attack is possible even if the server is not configured to offer HTTP content since the attacker is monitoring the requests and does not care if the server responds with a 404 or doesn't respond at all.<br /> <br /> === Rule - Keep Sensitive Data Out of the URL ===<br /> <br /> Sensitive data must not be transmitted via URL arguments. A more appropriate place is to store sensitive data in a server side repository or within the user's session. When using TLS the URL arguments and values are encrypted during transit. However, there are two methods that the URL arguments and values could be exposed.<br /> <br /> 1. The entire URL is cached within the local user's browser history. This may expose sensitive data to any other user of the workstation.<br /> <br /> 2. The entire URL is exposed if the user clicks on a link to another HTTPS site. This may expose sensitive data within the referral field to the third party site. This exposure occurs in most browsers and will only occur on transitions between two TLS sites. <br /> <br /> For example, a user following a link on [http://owasp.org https://example.com] which leads to [http://owasp.org https://someOtherexample.com] would expose the full URL of [http://owasp.org https://example.com] (including URL arguments) in the referral header (within most browsers). This would not be the case if the user followed a link on [http://owasp.org https://example.com] to [http://owasp.org http://someHTTPexample.com]<br /> <br /> === Rule - Prevent Caching of Sensitive Data ===<br /> <br /> The TLS protocol provides confidentiality only for data in transit but it does not help with potential data leakage issues at the client or intermediary proxies. As a result, it is frequently prudent to instruct these nodes not to cache or persist sensitive data. One option is to add anticaching headers to relevant HTTP responses, (for example, &quot;Cache-Control: no-cache, no-store&quot; and &quot;Expires: 0&quot; for coverage of many modern browsers as of 2013). For compatibility with HTTP/1.0 (i.e., when user agents are really old or the webserver works around quirks by forcing HTTP/1.0) the response should also include the header &quot;Pragma: no-cache&quot;. More information is available in [http://www.ietf.org/rfc/rfc2616.txt HTTP 1.1 RFC 2616], section 14.9.<br /> <br /> === Rule - Use HTTP Strict Transport Security ===<br /> <br /> A new browser security setting called HTTP Strict Transport Security (HSTS) will significantly enhance the implementation of TLS for a domain. HSTS is enabled via a special response header and this instructs [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Browser_Support compatible browsers] to enforce the following security controls:<br /> <br /> * All requests to the domain will be sent over HTTPS<br /> * Any attempts to send an HTTP requests to the domain will be automatically upgraded by the browser to HTTPS before the request is sent<br /> * If a user encounters a bad SSL certificate, the user will receive an error message and will not be allowed to override the warning message<br /> <br /> Additional information on HSTS can be found at [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security https://www.owasp.org/index.php/HTTP_Strict_Transport_Security] and also on the OWASP [http://www.youtube.com/watch?v=zEV3HOuM_Vw&amp;feature=youtube_gdata AppSecTutorial Series - Episode 4]<br /> <br /> === Rule - Prefer Ephemeral Key Exchanges ===<br /> <br /> Ephemeral key exchanges are based on Diffie-Hellman and use per-session, temporary keys during the initial SSL/TLS handshake. They provide perfect forward secrecy (PFS), which means a compromise of the server's long term signing key does not compromise the confidentiality of past session. When the server uses an ephemeral key, the server will sign the temporary key with its long term key (the long term key is the customary key available in its certificate).<br /> <br /> If you have a server farm and are providing forward secrecy, then you might have to disable session resumption. For example, Apache writes the session id's and master secrets to disk so all servers in the farm can participate in resuming a session (there is currently no in-memory mechanism to achieve the sharing). Writing the session id and master secret to disk undermines forward secrecy.<br /> <br /> == Server Certificate and Protocol Configuration ==<br /> <br /> Note: If using a FIPS 140-2 cryptomodule disregard the following rules and defer to the recommended configuration for the particular cryptomodule.<br /> <br /> === Rule - Use an Appropriate Certification Authority for the Application's User Base ===<br /> <br /> An application user must never be presented with a warning that the certificate was signed by an unknown or untrusted authority. The application's user population must have access to the public certificate of the certification authority which issued the server's certificate. For Internet accessible websites, the most effective method of achieving this goal is to purchase the TLS certificate from a recognize certification authority. Popular Internet browsers already contain the public certificates of these recognized certification authorities. <br /> <br /> Internal applications with a limited user population can use an internal certification authority provided its public certificate is securely distributed to all users. However, remember that all certificates issued by this certification authority will be trusted by the users. Therefore, utilize controls to protect the private key and ensure that only authorized individuals have the ability to sign certificates. <br /> <br /> The use of self signed certificates is never acceptable. Self signed certificates negate the benefit of end-point authentication and also significantly decrease the ability for an individual to detect a man-in-the-middle attack. <br /> <br /> === Rule - Only Support Strong Protocols ===<br /> <br /> SSL/TLS is a collection of protocols. Weaknesses have been identified with earlier SSL protocols, including [http://www.schneier.com/paper-ssl-revised.pdf SSLv2] and [http://www.yaksman.org/~lweith/ssl.pdf SSLv3]. The best practice for transport layer protection is to only provide support for the TLS protocols - TLS1.0, TLS 1.1 and TLS 1.2. This configuration will provide maximum protection against skilled and determined attackers and is appropriate for applications handling sensitive data or performing critical operations.<br /> <br /> [http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers Nearly all modern browsers support at least TLS 1.0]. As of February 2013, contemporary browsers (Chrome v20+, IE v8+, Opera v10+, and Safari v5+) [http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers support TLS 1.1 and TLS 1.2]. You should provide support for TLS 1.1 and TLS 1.2 to accommodate clients which support the protocols.<br /> <br /> In situations where lesser security requirements are necessary, it may be acceptable to also provide support for SSL 3.0 and TLS 1.0. [http://www.yaksman.org/~lweith/ssl.pdf SSLv3 has known weaknesses] which severely compromise the channel's security. TLS 1.0 suffers [http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html CBC Chaining attacks and Padding Oracle attacks]. SSLv3 and TLSv1.0 should only be used only after risk analysis and acceptance.<br /> <br /> Under no circumstances should SSLv2 be enabled as a protocol selection. The [http://www.schneier.com/paper-ssl-revised.pdf SSLv2 protocol is broken] and does not provide adequate transport layer protection.<br /> <br /> === Rule - Only Support Strong Cryptographic Ciphers ===<br /> <br /> Each protocol (SSLv3, TLSv1.0, etc) provides cipher suites. As of TLS 1.2, [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 there is support for over 300 suites (320+ and counting)], including [http://www.mail-archive.com/cryptography@randombit.net/msg03785.html national vanity cipher suites]. The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected the server must be modified to disable the use of weak ciphers. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes. In general, the following should be observed when selecting CipherSuites:<br /> <br /> * Disable cipher suites that do not offer authentication (NULL ciphersuites, aNULL or eNULL)<br /> * Disable anonymous Diffie-Hellman key exchange (ADH)<br /> * Disable export level ciphers (EXP, eg. ciphers containing DES)<br /> * Disable key sizes smaller than 128 bits for encrypting payload traffic<br /> * Disable the use of MD5 as a hashing mechanism for payload traffic<br /> * Use AES, 3-key 3DES for encryption operated in CBC mode <br /> * Stream Ciphers which XOR the key stream with plaintext (such as AES/CTR mode)<br /> * Use SHA1 or above for digests, prefer SHA2 (or equivalent)<br /> * Support ephemeral Diffie-Hellman key exchange<br /> <br /> Note: The TLS usage of MD5 does not expose the TLS protocol to any of the weaknesses of the MD5 algorithm (see FIPS 140-2 IG). However, MD5 must never be used outside of TLS protocol (e.g. for general hashing). For example, the RSA client authentication signature always uses both SHA-1 and MD5, and that usage is allowed.<br /> <br /> Note: Use of Ephemeral Diffie-Hellman key exchange will protect confidentiality of the transmitted plaintext data even if the corresponding RSA or DSS server private key got compromised. An attacker would have to perform active man-in-the-middle attack at the time of the key exchange to be able to extract the transmitted plaintext. All modern browsers support this key exchange with the notable exception of Internet Explorer prior to Windows Vista.<br /> <br /> Additional information can be obtained within the [http://www.ietf.org/rfc/rfc4346.txt TLS 1.1 RFC 4346] and [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf FIPS 140-2 IG], and [<br /> <br /> === Rule - Support TLS-PSK and TLS-SRP for Mutual Authentication ===<br /> <br /> When using a shared secret or password offer TLS-PSK (Pre-Shared Key) or TLS-SRP (Secure Remote Password), which are known as Password Authenticated Key Exchange (PAKEs). TLS-PSK and TLS-SRP properly bind the channel, which refers to the cryptographic binding between the outer tunnel and the inner authentication protocol. IANA currently reserves [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 79 PSK cipehr suites] and [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 9 SRP cipher suites].<br /> <br /> Basic authentication places the user's password on the wire in the plain text after a server authenticates itself. Basic authentication only provides unilateral authentication. In contrast, both TLS-PSK and TLS-SRP provide mutual authentication, meaning each party proves it knows the password without placing the password on the wire in the plain text.<br /> <br /> Finally, using a PAKE removes the need to trust an outside party, such as a Certification Authority (CA).<br /> <br /> === Rule - Only Support Secure Renegotiations ===<br /> <br /> A design weakness in TLS, identified as [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555 CVE-2009-3555], allows an attacker to inject a plaintext of his choice into a TLS session of a victim. In the HTTPS context the attacker might be able to inject his own HTTP requests on behalf of the victim. The issue can be mitigated either by disabling support for TLS renegotiations or by supporting only renegotiations compliant with [http://www.ietf.org/rfc/rfc5746.txt RFC 5746]. All modern browsers have been updated to comply with this RFC.<br /> <br /> === Rule - Disable Compression ===<br /> <br /> Compression Ratio Info-leak Made Easy (CRIME) is an exploit against the data compression scheme used by the TLS and SPDY protocols. The exploit allows an adversary to recover user authentication cookies from HTTPS. The recovered cookie can be subsequently used for session hijacking attacks.<br /> <br /> === Rule - Use Strong Keys &amp; Protect Them ===<br /> <br /> The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048. Keys of length 1024 will be obsolete beginning in 2010. Additional information on key lifetimes and comparable key strengths can be found in [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf NIST SP 800-57]. In addition, the private key must be stored in a location that is protected from unauthorized access.<br /> <br /> === Rule - Use a Certificate That Supports Required Domain Names ===<br /> <br /> A user should never be presented with a certificate error, including prompts to reconcile domain or hostname mismatches, or expired certificates. If the application is available at both [https://owasp.org https://www.example.com] and [https://owasp.org https://example.com] then an appropriate certificate, or certificates, must be presented to accommodate the situation. The presence of certificate errors desensitizes users to TLS error messages and increases the possibility an attacker could launch a convincing phishing or man-in-the-middle attack.<br /> <br /> For example, consider a web application accessible at [https://owasp.org https://abc.example.com] and [https://owasp.org https://xyz.example.com]. One certificate should be acquired for the host or server ''abc.example.com''; and a second certificate for host or server ''xyz.example.com''. In both cases, the hostname would be present in the Subject's Common Name (CN).<br /> <br /> Alternatively, the Subject Alternate Names (SANs) can be used to provide a specific listing of multiple names where the certificate is valid. In the example above, the certificate could list the Subject's CN as ''example.com'', and list two SANs: ''abc.example.com'' and ''xyz.example.com''. These certificates are sometimes referred to as &quot;multiple domain certificates&quot;.<br /> <br /> === Rule - Use Fully Qualified Names in Certificates ===<br /> <br /> Use fully qualified names in the DNS name field, and do not use unqualifed names (e.g., 'www'), local names (e.g., 'localhost'), or private IP addresses (e.g., 192.168.1.1) in the DNS name field. Unqualifed names, local names, or private IP addresses violate the certificate specification.<br /> <br /> === Rule - Do Not Use Wildcard Certificates ===<br /> <br /> You should refrain from using wildcard certificates. Though they are expedient at circumventing annoying user prompts, they also [[Least_privilege|violate the principal of least privilege]] and asks the user to trust all machines, including developer's machines, the secretary's machine in the lobby and the sign-in kiosk. Obtaining access to the private key is left as an exercise for the attacker, but its made much easier when stored on the file system unprotected.<br /> <br /> Statistics gathered by Qualys for [http://media.blackhat.com/bh-us-10/presentations/Ristic/BlackHat-USA-2010-Ristic-Qualys-SSL-Survey-HTTP-Rating-Guide-slides.pdf Internet SSL Survey 2010] indicate wildcard certificates have a 4.4% share, so the practice is not standard for public facing hosts. Finally, wildcard certificates violate [https://www.cabforum.org/EV_Certificate_Guidelines.pdf EV Certificate Guidelines].<br /> <br /> === Rule - Do Not Use RFC 1918 Addresses in Certificates ===<br /> <br /> Certificates should not use private addresses. RFC 1918 is [http://tools.ietf.org/rfc/rfc1918.txt Address Allocation for Private Internets]. Private addresses are Internet Assigned Numbers Authority (IANA) reserved and include 192.168/16, 172.16/12, and 10/8.<br /> <br /> Certificates issued with private addresses violate [https://www.cabforum.org/EV_Certificate_Guidelines.pdf EV Certificate Guidelines]. In addition, Peter Gutmann writes in in [http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf Engineering Security]: &quot;This one is particularly troublesome because, in combination with the router-compromise attacks... and ...OSCP-defeating measures, it allows an attacker to spoof any EV-certificate site.&quot;<br /> <br /> === Rule - Always Provide All Needed Certificates ===<br /> <br /> Clients attempt to solve the problem of identifying a server or host using PKI and X509 certificate. When a user receives a server or host's certificate, the certificate must be validated back to a trusted root certification authority. This is known as path validation.<br /> <br /> There can be one or more intermediate certificates in between the end-entity (server or host) certificate and root certificate. In addition to validating both endpoints, the user will also have to validate all intermediate certificates. Validating all intermediate certificates can be tricky because the user may not have them locally. This is a well-known PKI issue called the “Which Directory?&quot; problem.<br /> <br /> To avoid the “Which Directory?&quot; problem, a server should provide the user with all required certificates used in a path validation.<br /> <br /> == Client (Browser) Configuration ==<br /> <br /> The validation procedures to ensure that a certificate is valid are complex and difficult to correctly perform. In a typical web application model, these checks will be performed by the client's web browser in accordance with local browser settings and are out of the control of the application. However, these items do need to be addressed in the following scenarios:<br /> <br /> * The application server establishes connections to other applications over TLS for purposes such as web services or any exchange of data<br /> * A thick client application is connecting to a server via TLS<br /> <br /> In these situations extensive certificate validation checks must occur in order to establish the validity of the certificate. Consult the following resources to assist in the design and testing of this functionality. The NIST PKI testing site includes a full test suite of certificates and expected outcomes of the test cases.<br /> * [http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html NIST PKI Testing]<br /> * [http://www.ietf.org/rfc/rfc5280.txt IETF RFC 5280]<br /> <br /> As specified in the above guidance, if the certificate can not be validated for any reason then the connection between the client and server must be dropped. Any data exchanged over a connection where the certificate has not properly been validated could be exposed to unauthorized access or modification.<br /> <br /> == Additional Controls ==<br /> <br /> === Extended Validation Certificates ===<br /> <br /> Extended validation certificates (EV Certificates) proffer an enhanced investigation by the issuer into the requesting party due to the industry's race to the bottom. The purpose of EV certificates is to provide the user with greater assurance that the owner of the certificate is a verified legal entity for the site. Browsers with support for EV certificates distinguish an EV certificate in a variety of ways. Internet Explorer will color a portion of the URL in green, while Mozilla will add a green portion to the left of the URL indicating the company name. <br /> <br /> High value websites should consider the use of EV certificates to enhance customer confidence in the certificate. It should also be noted that EV certificates do not provide any greater technical security for the TLS. The purpose of the EV certificate is to increase user confidence that the target site is indeed who it claims to be.<br /> <br /> === Client-Side Certificates ===<br /> <br /> Client side certificates can be used with TLS to prove the identity of the client to the server. Referred to as &quot;two-way TLS&quot;, this configuration requires the client to provide their certificate to the server, in addition to the server providing their's to the client. If client certificates are used, ensure that the same validation of the client certificate is performed by the server, as indicated for the validation of server certificates above. In addition, the server should be configured to drop the TLS connection if the client certificate cannot be verified or is not provided. <br /> <br /> The use of client side certificates is relatively rare currently due to the complexities of certificate generation, safe distribution, client side configuration, certificate revocation and reissuance, and the fact that clients can only authenticate on machines where their client side certificate is installed. Such certificates are typically used for very high value connections that have small user populations.<br /> <br /> === Certificate and Public Key Pinning ===<br /> <br /> Hybrid and native applications can take advantage of [[Certificate_and_Public_Key_Pinning|certificate and public key pinning]]. Pinning associates a host (for example, server) with an identity (for example, certificate or public key), and allows an application to leverage knowledge of the pre-existing relationship. At runtime, the application would inspect the certificate or public key received after connecting to the server. If the certificate or public key is expected, then the application would proceed as normal. If unexpected, the application would stop using the channel and close the connection since an adversary could control the channel or server.<br /> <br /> Pinning still requires customary X509 checks, such as revocation, since CRLs and OCSP provides real time status information. Otherwise, an application could possibly (1) accept a known bad certificate; or (2) require an out-of-band update, which could result in a lengthy App Store approval.<br /> <br /> Browser based applications are at a disadvantage since most browsers do not allow the user to leverage pre-existing relationships and ''a priori'' knowledge. In addition, Javascript and Websockets do not expose methods to for a web app to query the underlying secure connection information (such as the certificate or public key). It is noteworthy that Chromium based browsers perform pinning on selected sites, but the list is currently maintained by the vendor.<br /> <br /> For more information, please see the [[Pinning Cheat Sheet]].<br /> <br /> = Providing Transport Layer Protection for Back End and Other Connections =<br /> <br /> Although not the focus of this cheat sheet, it should be stressed that transport layer protection is necessary for back-end connections and any other connection where sensitive data is exchanged or where user identity is established. Failure to implement an effective and robust transport layer security will expose sensitive data and undermine the effectiveness of any authentication or access control mechanism. <br /> <br /> == Secure Internal Network Fallacy ==<br /> <br /> The internal network of a corporation is not immune to attacks. Many recent high profile intrusions, where thousands of sensitive customer records were compromised, have been perpetrated by attackers that have gained internal network access and then used sniffers to capture unencrypted data as it traversed the internal network.<br /> <br /> = Related Articles =<br /> <br /> * OWASP – [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]] <br /> * OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]<br /> * OWASP – ASVS Article on [[Why you need to use a FIPS 140-2 validated cryptomodule]]<br /> * SSL Labs http://www.ssllabs.com/projects/rating-guide/index.html SSL Server Rating Guide]<br /> * yaSSL – [http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html Differences between SSL and TLS Protocol Versions]<br /> * NIST – [http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf SP 800-52 Guidelines for the selection and use of transport layer security (TLS) Implementations]<br /> * NIST – [http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf FIPS 140-2 Security Requirements for Cryptographic Modules]<br /> * NIST – [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program]<br /> * NIST – [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf SP 800-57 Recommendation for Key Management, Revision 2]<br /> * NIST – [http://csrc.nist.gov/publications/drafts.html#sp800-95 SP 800-95 Guide to Secure Web Services] <br /> * IETF – [http://www.ietf.org/rfc/rfc5280.txt RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]<br /> * IETF – [http://www.ietf.org/rfc/rfc2246.txt RFC 2246 The Transport Layer Security (TLS) Protocol Version 1.0 (JAN 1999)]<br /> * IETF – [http://www.ietf.org/rfc/rfc4346.txt RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 (APR 2006)]<br /> * IETF – [http://www.ietf.org/rfc/rfc5246.txt RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 (AUG 2008)]<br /> <br /> = Authors and Primary Editors =<br /> <br /> Michael Coates - michael.coates[at]owasp.org &lt;br/&gt;<br /> Dave Wichers - dave.wichers[at]aspectsecurity.com &lt;br/&gt;<br /> Michael Boberski - boberski_michael[at]bah.com&lt;br/&gt;<br /> Tyler Reguly -treguly[at]sslfail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=OWASP_Application_Security_FAQ&diff=156410 2013-08-05T00:00:48Z

<p>Webappsecguy: Removing because highly ambiguous.</p> <hr /> <div>=Login Issues =<br /> <br /> ==What are the best practices I should remember while designing the login pages? ==<br /> <br /> * From the login page, the user should be sent to a page for authentication. Once authenticated, the user should be sent to the next page. This is explained in the answer to the next question. <br /> * The password should never be sent in clear text (unencrypted) because it can be stolen by sniffing; saving the password in clear text in the database is dangerous too. The best method of sending passwords is the Salted MD5 hashing technique and the passwords should be hashed and then stored in the database.<br /> * The best way to manage sessions would be to use one session token with two values during authentication. One value before authentication and one after.<br /> <br /> ==Is it really required to redirect the user to a new page after login? ==<br /> <br /> Is it really required to redirect the user to a new page after login? <br /> <br /> Yes. Consider the application has a login page that sends the username and password as a POST request to the server. If a user clicks refresh on the second page (the page after login), the same request including the username and password in the POST will be sent again. Now suppose a valid user browses through our application and logs out, but does not close the window. The attackers come along and click the back button of the browser till they reach the second page. They only have to do a refresh and since the username and password are resubmitted and revalidated, the attackers can login as the user. Now let's assume the application has a login page which takes the user to an intermediate page for authentication. Once authenticated, the user is redirected to the second page with a session token. In this case, even if the attackers reach the second page and do a refresh, the username and password will not be resubmitted. This is so because the request that will be submitted is the one for the second page which does not contain the username and password. Therefore, it is always better to redirect the user. <br /> <br /> ==How does the salted MD5 technique work? ==<br /> <br /> Here is how the salted MD5 technique works: the database stores a MD5 hash of the password. (MD5 hash is a cryptographic technique in which the actual value can never be recovered.) When a client requests for the login page, the server generates a random number, the salt, and sends it to the client along with the page. A JavaScript code on the client computes the MD5 hash of the password entered by the user. It then concatenates the salt to the hash and re-computes the MD5 hash. This result is then sent to the server. The server picks the hash of the password from its database, concatenates the salt and computes the MD5 hash. If the user entered the correct password these two hashes should match. The server compares the two and if they match, the user is authenticated. <br /> <br /> ==How can my &quot;Forgot Password&quot; feature be exploited? ==<br /> <br /> The Forgot Password feature is implemented in a number of different ways. One common way is to ask the user a hint question for which the user has submitted the answer during registration. These are questions like What is your favorite color? or What is your favorite pastime? If the answer is correct, either the original password is displayed or a temporary password is displayed which can be used to log in. In this method, an attacker trying to steal the password of a user may be able to guess the correct answer of the hint question and even reset the password. <br /> <br /> ==In &quot;Forgot Password&quot;, is it safe to display the old password? ==<br /> <br /> If the old password is displayed on the screen, it can be seen by shoulder surfers. So it is a good idea not to display the password and let the user change to a new one. Moreover, displaying the password means it has to be stored in a recoverable form in the database which is not a good practice. If the password is stored as a one way hash in the database, the only way Forgot Password can be implemented is by letting the user reset the old password. So, it is always better to force the users reset their passwords when they forget their passwords. (A one way hash is the result obtained when we pass a string to a one way hash function. The result is such that it is impossible to get back the original value from it. Passwords are best stored as non-recoverable hashes in the database.) <br /> <br /> ==Is there any risk in emailing the new password to the user's authorized mail id? ==<br /> <br /> Emailing the actual password in clear text can be risky as an attacker can obtain it by sniffing. Also the mail containing the password might have a long life time and could be viewed by an attacker while it is lying in the mailbox of the user.<br /> <br /> Apart form the above threats, a malicious user can do shoulder-surfing to view the password or login credentials.<br /> <br /> ==What is the most secure way to design the Forgot Password feature? ==<br /> <br /> We should first ask the user to supply some details like personal details or ask a hint question. Then we should send a mail to the users authorized mail id with a link which will take the user to a page for resetting the password. This link should be active for only a short time, and should be SSL- enabled. This way the actual password is never seen. The security benefits of this method are: the password is not sent in the mail; since the link is active for a short time, there is no harm even if the mail remains in the mailbox for a long time. <br /> <br /> ==How do I protect against automated password guessing attacks? ==<br /> <br /> Password guessing with automated tools is a serious problem since there are a number of tools available for this purpose. These tools essentially keep trying out different passwords till one matches. Locking out the account after 5 failed attempts is a good defense against these tools. However, the important point then is how long you lock out the account for. If it is for too long, service to valid users might be denied as the attackers repeatedly lock out your users. If the time is too short say about 1-2 minutes, the tool could start again after the timeout. So the best method would be to insist on human intervention after a few failed attempts. A method used by a number of sites these days is to have the user read and enter a random word that appears in an image on the page. Since this cannot be done by a tool, we can thwart automated password guessing. The following are some tools that guess passwords of web applications: Brutus - http://www.hoobie.net/brutus/ WebCracker http://www.securityfocus.com/tools/706<br /> <br /> ==How can I protect against keystroke loggers on the client machine? ==<br /> <br /> Keystroke loggers on the end users machines can sometimes ruin all our efforts of securely transmitting and storing the passwords. The users themselves may not be aware that a key logger has been installed on their machines and records each key pressed. Since the highest risk is with the password, if we can authenticate the users without having them use the keyboard, or reveal the entire password, we solve the problem. The different ways of doing this are: <br /> <br /> * Having a graphical keyboard where the users can enter the characters they want by clicking the mouse on it. This is especially useful for numeric PINs. <br /> * Asking the users to type a part of their password each time and not the whole password. For example you could say &quot;Please enter the 1st, 3rd and 6th letters of your password&quot; and this rule could be a random one each time. <br /> ==My site will be used from publicly shared computers. What precautions must I take? ==<br /> <br /> If your application will be accessed from publicly shared computers like libraries, you could take the following precautions: <br /> <br /> * You can make sure your pages do not get cached on the system by setting the correct cache control directives. <br /> * You could take care that no sensitive information is included in the URLs since the history of the client browser will store these. <br /> * Have a graphical keyboard for entering the password or ask the user to enter a different part of the password each time. This protects the password against keystroke loggers. <br /> * To prevent sniffing of passwords and replay attacks using those, you should either use SSL or salted MD5 for passwords. The clear text password in the memory should be reset after computing the MD5. <br /> =SQL Injection =<br /> <br /> ==What is SQL Injection? ==<br /> <br /> SQL Injection is a technique by which attackers can execute SQL statements of their choice on the backend database by manipulating the input to the application. Let's understand SQL Injection through the example of a login page in a web application where the database is SQL Server. The user needs to input Username and Password in the text boxes in Login.asp page. Suppose the user enters the following: Username : Obelix and Password : Dogmatix This input is then used to build a query dynamically which would be something like: SELECT * FROM Users WHERE username= 'Obelix' and password='Dogmatix' This query would return to the application a row from the database with the given values. The user is considered authenticated if the database returns one or more rows to the application. Now, suppose an attacker enters the following input in the login page: Username : ' or 1=1-- The query built will look like this: SELECT * FROM Users WHERE username='' or 1=1-- and password='' -- in SQL Server is used to comment out the rest of the line. So, our query is now effectively: SELECT * FROM Users WHERE username='' or 1=1 This query will look in the database for a row where either username is blank or the condition 1=1 is met. Since the latter always evaluates to true, the query will return all rows of the Users table and the user is authenticated. The attacker has been successful in logging into the application without a username and password. You can read more on this at the Securiteam site: http://www.securiteam.com/securityreviews/5DP0N1P76E.html <br /> <br /> ==Is it just ASP and SQL Server or are all platforms vulnerable? ==<br /> <br /> Almost all platforms are vulnerable to SQL Injection. Inadequate checking of user input and the use of dynamic SQL queries are what make an application vulnerable to these attacks. The syntax of the input entered for SQL Injection will depend on the database being used. During our application security audits we have found many applications using other databases to be vulnerable. The above example would work on SQL Server, Oracle and MySQL. This shows that the problem is with the inadequate checking of user input and the use of dynamic SQL and not the underlying database. <br /> <br /> ==Apart from username and password which variables are candidates for SQL Injection? ==<br /> <br /> Any input field that makes up the where clause of a database query is a candidate for SQL Injection, eg. account numbers, and credit card numbers in the case of an online banking application. In addition to form fields, an attacker can use hidden fields and query strings also for injecting commands.<br /> <br /> Apart from input fields, URL parameters are also vulnerable to SQL Injection as well as other input based attacks.<br /> <br /> ==How do we prevent SQL Injection in our applications? ==<br /> <br /> It is quite simple to prevent SQL injection while developing the application. You need to check all input coming from the client before building a SQL query. The best method is to remove all unwanted input and accept only expected input. While server side input validation is the most effective method of preventing SQL Injection, the other method of prevention is not using dynamic SQL queries. This can be achieved by using stored procedures or bind variables in databases that support these features. For applications written in Java, CallableStatements and PreparedStatements can be used. For ASP applications, ADO Command Objects can be used. You can check the following article for more on SQL Injection in Oracle: http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf <br /> <br /> ==I'm using stored procedures for authentication, am I vulnerable? ==<br /> <br /> Maybe, but probably no. Using stored procedures can prevent SQL Injection because the user input is no longer used to build the query dynamically. Since a stored procedure is a group of precompiled SQL statements and the procedure accepts input as parameters, a dynamic query is avoided. Although input is put into the precompiled query as is, since the query itself is in a different format, it does not have the effect of changing the query as expected. By using stored procedures we are letting the database handle the execution of the query instead of asking it to execute a query we have built. The exception to this is where the stored procedure takes a string as input and uses this string to build the query without validating it. While this is more difficult to exploit, this scenario still often leads to successful SQL Injection. This article explains how SQL Injection affects stored procedures in more detail: http://palisade.plynt.com/issues/2006Jun/injection-stored-procedures/<br /> <br /> ==I'm using client side JavaScript code for checking user input. Isn't that enough? ==<br /> <br /> No. Although client side checking disallows the attacker to enter malicious data directly into the input fields, that alone is not enough to prevent SQL Injection. Client side scripts only check for input in the browser. But this does not guarantee that the information will remain the same till it reaches the server. To bypass client side JavaScript, the attacker can trap the request in a proxy (eg. WebScarab, [http://www.parosproxy.org Paros]) after it leaves the browser and before it reaches the server and there he can alter input fields. The attacker can also inject commands into the querystring variables which are not checked by the client side scripts, or could disable JavaScript rendering client-side scripting useless.<br /> <br /> ==Are Java servlets vulnerable to SQL injection? ==<br /> <br /> Yes, they are if the user input is not checked properly, and if they build SQL queries dynamically. But Java servlets also have certain features that prevent SQL Injection like CallableStatements and PreparedStatements. Like stored procedures and bind variables, they avoid the need of dynamic SQL statements.<br /> <br /> ==Can an automated scanner discover SQL Injection? ==<br /> <br /> Sometimes yes, sometimes no. Whether a scanner can discover SQL injection or not depends on a variety of factors: the discovery technique used, the response from the application when a malformed SQL snippet is added, and some luck. Specifically, scanners that use Blind SQL Injection are most likely to detect SQL Injection. Scanners that claim hundreds of test cases for SQL Injection are misleading. This entry from the [http://www.plynt.com/resources/learn/tools/do_scanners_catch_sql_injectio_1/ Penetration Testing Learning Center] explains this in detail.<br /> <br /> =Variable Manipulation =<br /> <br /> ==Why can't I trust the information coming from the browser? ==<br /> <br /> There are chances that the information is modified before it reaches the server. Attackers browsing the site can manipulate the information in a GET or POST request. There are a number of HTTP/HTTPS proxy tools like [http://www.mavensecurity.com/achilles Achilles], Paros, WebScarab, etc which are capable of intercepting all this information and allow the attacker running the tool to modify it. Also, the information that the user sees or provides on a web page has to travel through the internet before it reaches the server. Although the client and the server may be trusted, we cannot be sure that the information is not modified after it leaves the browser. Attackers can capture the information on the way and manipulate it.<br /> <br /> ==What information can be manipulated by the attacker? ==<br /> <br /> Manipulating the variables in the URL is simple. But attackers can also manipulate almost all information going from the client to the server like form fields, hidden fields, content-length, session-id and http methods.<br /> <br /> ==How do attackers manipulate the information? What tools do they use? ==<br /> <br /> For manipulating any information, including form fields, hidden variables and cookies, attackers use tools known as HTTP/HTTPS proxy tools. Once the browser's proxy settings are configured to go through the HTTP/HTTPS proxy, the tool can see all information flowing between the client and the server; it even allows the attacker to modify any part of the request before sending it. Some such tools are: WebScarab can be downloaded from the OWASP site. Odysseus can be found at http://www.bindshell.net/tools/odysseus Paros can be downloaded from http://www.parosproxy.org<br /> <br /> ==I'm using SSL. Can attackers still modify information? ==<br /> <br /> Although SSL provides a lot of security, SSL alone is not enough to prevent variable manipulation attacks. SSL was supposed to prevent against Man in the Middle attacks but it is vulnerable to it. To successfully carry out the MITM attack, first the attacker has to divert the victim's requests to his machine i.e. redirecting the packets meant for the server to himself. He can do this by ARP poisoning / DNS Cache poisoning. Once he is able to redirect, he can see all the requests the victim is trying to make. Now when the victim tries to establish an SSL connection with a legitimate server, he gets connected to the attacker. The attacker, during the SSL Handshaking, provides a fake certificate to the victim, which the victim accepts even though the browser warns him. Thus, the victim establishes an SSL connection with the attacker instead of the server. The attacker establishes a different SSL connection with that legitimate server, which the victim was trying to connect. Now all data flow between the victim and the server will be routed through the attacker and the attacker can see all data the victim (as well as the server) sends. This is because the victim will encrypt all data with the attacker's public key, which the attacker can decrypt with his private key. The attacker can then manipulate all data that is passing through his machine.<br /> <br /> ==Is there some way to prevent these proxy tools from editing the data? ==<br /> <br /> The main threat these proxy tools pose is editing the information sent from the client to the server. One way to prevent it is to sign the message sent from the client with a Java Applet downloaded onto the client machine. Since the applet we developed will be the one validating the certificate and not the browser, a proxy tool will not be able to get in between the client and the server with a fake certificate. The applet will reject the fake certificate. The public key of this certificate can then be used to digitally sign each message sent between the client and the server. An attacker would then have to replace the embedded certificate in the applet with a fake certificate to succeed - that raises the barrier for the attacker. <br /> <br /> =Browser Cache =<br /> <br /> ==How can the browser cache be used in attacks? ==<br /> <br /> The browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder, like the Temporary Internet Files folder in the case of Internet Explorer. When we ask for these pages again, the browser displays them from its cache. This is much faster than downloading the page from the server. Let's consider the particular scenario where a user has logged in to an application with username and password. The user browses the different pages which contain sensitive information. Let's suppose a page with the user's credit card information gets cached in the browser and the user logs out of the application. Now suppose the attackers access the same machine and searches through the Temporary Internet Files, they will get the credit card details. The attackers do not need to know the username and password of the user to steal the information. <br /> <br /> ==How do I ensure that sensitive pages are not cached on the user's browser? ==<br /> <br /> The response header sent from the server has some cache control directives that can be set from your code. These directives control the caching of content on any cache. The directives to be set are Cache-Control : no-cache, no-store and Expires: 0. But since legacy HTTP 1.0 servers do not support the Cache-Control headers, universally, Pragma: no-cache header should be used, too.<br /> <br /> ==What's the difference between the cache-control directives: no-cache, and no-store? ==<br /> <br /> The no-cache directive in a response indicates that the response must not be used to serve a subsequent request i.e. the cache must not display a response that has this directive set in the header but must let the server serve the request. The no-cache directive can include some field names; in which case the response can be shown from the cache except for the field names specified which should be served from the server. The no-store directive applies to the entire message and indicates that the cache must not store any part of the response or any request that asked for it. <br /> <br /> ==Am I totally safe with these directives? ==<br /> <br /> No. But generally, use both Cache-Control: no-cache, no-store and Pragma: no-cache, in addition to Expires: 0 (or a sufficiently backdated GMT date such as the UNIX epoch). Non-html content types like pdf, word documents, excel spreadsheets, etc often get cached even when the above cache control directives are set (although this varies by version and additional use of must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0 in practice can sometimes result at least in file deletion upon browser closure in some cases due to browser quirks and HTTP implementations). Also, 'Autocomplete' feature allows a browser to cache whatever the user types in an input field of a form. To check this, the form tag or the individual input tags should include 'Autocomplete=&quot;Off&quot; ' attribute. However, it should be noted that this attribute is non-standard (although it is supported by the major browsers) so it will break XHTML validation.<br /> <br /> ==Where can I learn more about caching? ==<br /> <br /> Some useful links that talk about caching are - Caching Tutorial for Web Authors and Webmasters by Mark Nottingham at http://www.mnot.net/cache_docs/ and HTTP RFC (sec14.9.1) at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html<br /> <br /> =Cross Site Scripting =<br /> <br /> ==What is Cross Site Scripting? ==<br /> <br /> Cross Site scripting (XSS) is a type of attack that can be carried out to steal sensitive information belonging to the users of a web site. This relies on the server reflecting back user input without checking for embedded javascript. This can be used to steal cookies and session IDs. Let's see how it works. We would all have come across the following situation sometime - we type a URL in the browser, say www.abcd.com/mypage.asp, and receive an error page that says &quot;Sorry www.abcd.com/mypage.asp does not exist&quot; or a page with a similar message. In other words, pages that display the user input back on the browser. Pages like this could be exploited using XSS. Instead of a normal input, think what will happen if the input contains a script in it. While reflecting back the input, instead of rendering it as normal HTML output, the browser treats it as a script and executes it. This script could contain some malicious code. The attackers can send a link that contains a script as part of the URL to a user. When the user clicks it, the script gets executed on the user's browser. This script may have been written to collect important information about the user and send it to the attacker. Kevin Spett's paper Cross Site Scripting, Are your web applications vulnerable? is a good source of information on this topic and is available at http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf The Cross Site Scripting FAQ at CGI Security is another good place to learn more on XSS. <br /> <br /> ==What information can an attacker steal using XSS? ==<br /> <br /> The attackers can steal the session ID of a valid user using XSS. The session ID is very valuable because it is the secret token that the user presents after login as proof of identity until logout. If the session ID is stored in a cookie, the attackers can write a script which will run on the user's browser, query the value in the cookie and send it to the attackers. The attackers can then use the valid session ID to browse the site without logging in. The script could also collect other information from the page, including the entire contents of the page. <br /> <br /> ==Apart from mailing links of error pages, are there other methods of exploiting XSS? ==<br /> <br /> Yes, there are other methods. Let's take the example of a bulletin board application that has a page where data entered by one user can be viewed by other users. The attackers enter a script into this page. When a valid user tries to view the page, the script gets executed on the user's browser. It will send the user's information to the attackers. <br /> <br /> ==How can I prevent XSS? ==<br /> <br /> XSS can be prevented while coding the application. You should be validating all input and output to and from the application and escape all special characters that may be used in a script. If the code replaces the special characters by the following before displaying the output, XSS can be prevented to some extent.<br /> <br /> <br /> <br /> &lt; &amp;lt;<br /> <br /> &gt; &amp;gt; <br /> <br /> ( &amp;*40; <br /> <br /> ) &amp;*41; <br /> <br /> * &amp;*35; <br /> &amp; &amp;*38;<br /> <br /> <br /> <br /> Gunter Ollmann has written an excellent paper on the use of special characters in XSS attacks. For instance, the above technique of escaping special characters cannot protect against a script injected like &quot;javascript:self.location.href = 'www.evil.org' &quot; as this script does not use any of the special characters.<br /> <br /> ==Can XSS be prevented without modifying the source code? ==<br /> <br /> There is a method that requires minimal coding as compared to performing input, output validation to prevent the stealing of cookies by XSS. Internet Explorer 6 has an attribute called HTTP Only that can be set for cookies. Using this attribute makes sure that the cookie can not be accessed by any scripts. More details are available at the MSDN site on httpcookies at http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/httponly_cookies.asp Mozilla also has plans to implement a similar feature. Researchers have found a method to beat this. It is known as Cross Site Tracing. <br /> <br /> ==What is Cross Site Tracing (XST)? How can it be prevented? ==<br /> <br /> Attackers are able to bypass the HTTP Only attribute to steal cookie information by Cross Site tracing (XST). TRACE is a HTTP method that can be sent to the server. The server sends back anything included in the TRACE request back to the browser. In a site that uses cookies, the cookie information is sent to the server in each request. If we send a TRACE request in a URL of such a site, the server will send back all cookie information to the browser. Now imagine a situation similar to the one described in XSS but the site in this case is using the HTTP Only cookies. The attackers make a valid user click on a link that contains a script that calls the TRACE method. When the user clicks on the link the TRACE request as well as all the cookie information is sent to the server. The server then sends back the cookie information back to the script in the browser. Suppose that the malicious script also contains code to send this information to the attackers. The attackers have succeeded again in stealing the cookies although HTTP Only Cookies were used. To summarize, HTTP Only cookies prevent the JavaScript from directly accessing the cookies but the attacker was able to retrieve it through an indirect method. XST can be prevented by disabling the TRACE method on the web server. This paper by Jeremiah Grossman discusses XST in greater detail http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf <br /> <br /> =Web Server Fingerprinting =<br /> <br /> ==How do attackers identify which web server I'm using? ==<br /> <br /> Identifying the application running on a remote web server is known as fingerprinting the server. The simplest way to do this is to send a request to the server and see the banner sent in the response. Banners will generally have the server name and the version number in it. We can address this problem by either configuring the server not to display the banner at all or by changing it to make the server look like something else.<br /> <br /> ==How can I fake the banners or rewrite the headers from my web server? ==<br /> <br /> There are a number of tools that help in faking the banners. URLScan is a tool that can change the banner of an IIS web server. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/URLScan.asp mod_security has a feature for changing the identity of the Apache web server. It can be found at http://www.modsecurity.org/ Servermask for faking banners of IIS, can be found at http://www.servermask.com/ <br /> <br /> ==Once I fake the banners, can my web server still be fingerprinted? ==<br /> <br /> Yes. Unfortunately there are tools that fingerprint the web server without relying on the banners. Different web servers may implement features not specified in HTTP RFCs differently. Suppose we make a database of these special requests and the responses of each web server. We can now send these requests to the web server we want to fingerprint and compare the responses with the database. This is the technique used by tools like Fire &amp; Water. This tool can be found at http://www.ntobjectives.com/products/firewater/ There is a paper by Saumil Shah that discusses the tool httprint at http://net-square.com/httprint/httprint_paper.html httprint can be found at http://net-square.com/httprint/ <br /> <br /> ==A friend told me it's safer to run my web server on a non-standard port. Is that right? ==<br /> <br /> A web server generally needs to be accessed by a lot of people on the internet. Since it normally runs on port 80 and all browsers are configured to access port 80 of the web server, users are able to browse the site. If we change the port, the users will have to specify the port in addition to the domain name. But this is a good idea for an intranet application where all users know where to connect. It is more secure since the web server will not be targeted by automated attacks like worms that scan port 80 and other standard ports. <br /> <br /> ==Should I really be concerned that my web server can be fingerprinted? ==<br /> <br /> Well, there are two schools of thought here. According to the first school, yes you should take precaution against fingerprinting as correctly identiying the web server maybe the first step in a more dangerous attack. Once attackers have found out that the web server is say IIS 5, they will search for known vulnerabilities for IIS 5. If the web server is not patched for all known vulnerabilities or the attackers find one for which a patch has not been released yet, there is nothing to stop them from attacking it. Also automated tools and worms can be fooled by changing the version information. Some determined and focused attackers might go to additional lengths to identify the server but the hurdles that the attackers have to overcome have increased when it's more difficult to fingerprint the web server name and version. Jeremiah Grossman pointed out the other school of thought. Evasive measures are futile as any scanner targeting a web site, will normally not care what the web server is. The scanner will run ALL its tests no matter if they apply to the system or not. This is a typical shotgun approach. A bad guy targeting the site might be hampered by not knowing the exact version, but if he's determined he would still try out all related exploits and try to break in. <br /> <br /> =Testing =<br /> <br /> ==I want to chain my proxy tool with a proxy server; are there tools that let me do that? ==<br /> <br /> Yes, there are several tools that allow proxy chaining. Some of these are: WebScarab - http://www.owasp.org/development/webscarab Exodus - http://home.intekom.com/rdawes/exodus.html Odysseus - http://www.wastelands.gen.nz/odysseus/index.php <br /> <br /> ==Can't web application testing be automated? Are there any tools for that? ==<br /> <br /> There are tools that scan applications for security flaws. But these tools can only look for a limited number of vulnerabilities, and do not find all the problems in the application. Moreover, a lot of attacks require understanding of the business context of the application to decide on the variables to manipulate in a particular request, which a tool is incapable of doing. A presentation by Jeremiah Grossman of White Hat Security which talks about the [http://www.blackhat.com/presentations/bh-federal-03/bh-fed-03-grossman-up.pdf limitations of automated scanning]. <br /> <br /> This piece explains [http://www.plynt.com/resources/learn/tools/what_cant_a_scanner_find_1/ what a scanner can't find].<br /> <br /> In our tests using a slightly modified WebGoat the best Black-box scanning tool found less than 20% of the issues ! Some tools for automated scanning are: SpikeProxy, open source and freely available at http://www.immunitysec.com/spikeproxy.html WebInspect, can be found at http://www.spidynamics.com/productline/WE_over.html<br /> <br /> ==Where can I try out my testing skills? Is there a sample application I can practice with? ==<br /> <br /> OWASP provides a sample application that can be used for this purpose called . As the site says, the WebGoat project's goal is to teach web security in an interactive teaching environment. There are lessons on most of the common vulnerabilities. Another interesting site is Hackingzone which has a game on SQL Injection at http://www.hackingzone.org/sql/index.php <br /> <br /> ==Are there source code scanning tools for .NET languages, Java, PHP etc that predict vulnerabilities in the source code? ==<br /> <br /> Rough Auditing Tool for Security (RATS) is a tool that scans the source code for security flaws in C, C++, Python, Perl and PHP programs. It can be found at http://code.google.com/p/rough-auditing-tool-for-security/downloads/list FX Cop was created by the Microsoft Team at the GotDotNet community site to check for the .NET Frameowork guidelines which include security. Prexis is a commercial source code and run-time analyzer. Flawfinder is a static source code analyzer. Compaq ESC is a run-time analyzer for Java. Parasoft AEP is a commercial source code analyzer for Java. Fortify SCA from Fortify Software is another source code analyzer that supports mixed language analysis of C, C++, C#, ASP.NET, Java, JSP, PL/SQL, VB.NET, XML, etc. Secure Coding plugins are also available. Similar source code analyzers are Klocwork K7 for C, C++ and Java; Coverity Prevent for detecting security violations and defects in code; Ounce Solutions for C, C++, C#, ASP.NET, Java and JSP. We would like to know about more tools for scanning source code. If you know about any, please inform us and we'll add to this FAQ<br /> <br /> ==Can non-HTTP protocols also be intercepted and played with like this? ==<br /> <br /> Yes, Interactive TCP Replay is a tool that acts as a proxy for non-HTTP applications and also allows modifying the traffic. It allows editing of the messages in a hex editor. ITR also logs all the messages passing between the client and the server. It can use different types of character encoding like ASCII or EBCDIC for editing and logging. More information on this can be found at http://www.webcohort.com/web_application_security/research/tools.html <br /> <br /> =Cryptography/SSL =<br /> <br /> ==What is SSL? ==<br /> <br /> Secure Socket Layer (SSL) gives us assurance of two things. Firstly when a client connects to a web server, the client can be sure that it is talking to the right server by checking the certificate the server sends it. Secondly, SSL assures you of the confidentiality of the data, as the client and the server exchange encrypted messages that cannot be understood by anybody else. This is how SSL works: When the client requests for a SSL page, the server sends a certificate that it has obtained from a trusted certificate authority. This certificate contains the public key of the server. After satisfying itself that the certificate is correct and the server is a genuine one, the client generates one random number, the session key. This key is encrypted by the public key of the server and sent across. The server decrypts the message with its private key. Now both sides have a session key known only to the two of them. All communication to and fro is encrypted and decrypted with the session key. An interesting link on SSL is http://www.rsasecurity.com/standards/ssl/basics.html <br /> <br /> ==Should I use 40-bit or 128-bit SSL? ==<br /> <br /> There are 2 strengths in SSL - 40-bit and 128-bit. These refer to the length of the secret key used for encrypting the session. This key is generated for every SSL session and is used to encrypt the rest of the session. The longer the key the more difficult it is to break the encrypted data. So, 128-bit encryption is much more secure than 40-bit. Most browsers today support 128-bit encryption. There are a few countries which have browsers with only 40-bit support. In case you are using 40-bit SSL, you may need to take further precautions to protect sensitive data. Salted hash for transmitting passwords is a good technique. This ensures that the password can not be stolen even if the SSL key is broken. <br /> <br /> ==Is 40-bit SSL really unsafe? ==<br /> <br /> 40-bit SSL is not really unsafe. It's just that it is computationally feasible to break the key used in 40-bit but not the key used in 128-bit. Even though 40-bit can be broken, it takes a fairly large number of computers to break it. Nobody would even attempt to do that for a credit card number or the like. But there are claims of breaking the 40-bit RC4 key in a few hours. So depending on the data your application deals with, you can decide on the SSL strength. Using 128-bit is definitely safer.<br /> <br /> With home computers gtting faster day by day, a dedicated, expensive and very fast computer can break 40-bit encryption in few minutes (ideally testing a million keys per second). On the other hand, 128-bit encryotion will have about 339,000,000,000,000,000,000,000,000,000,000,000 (Couple of Trillions or 2^128) possible key combinations and it will take around 1000 Years to break 128-bit encryptions with the help of a cluster of very fast computers.<br /> <br /> ==What all are encrypted when I use SSL? Is the page request also encrypted? ==<br /> <br /> After the initial SSL negotiation is done and the connection is on HTTPS, everything is encrypted including the page request. So any data sent in the query string will also be encrypted. <br /> <br /> ==Which cryptographic algorithms do SSL use? ==<br /> <br /> SSL supports a number of cryptographic algorithms. During the initial &quot;handshaking&quot; phase, it uses the RSA public key algorithm. For encrypting the data with the session key the following algorithms are used - RC2, RC4, IDEA, DES, triple-DES and MD5 message digest algorithm. <br /> <br /> ==I want to use SSL. Where do I begin? ==<br /> <br /> There are several Certificate Authorities that you can buy a SSL certificate from. Whichever CA you choose, the basic procedure will be as follows - <br /> <br /> * Create key pair for the server <br /> * Create the Certificate Signing Request. This will require you to provide certain details like location and fully qualified domain name of the server. <br /> * Submit the CSR to the CA along with documentary proof of identity. <br /> * Install the certificate sent by the CA<br /> The first two steps are done from the web server. All servers have these features. While installing the certificate issued by the CA, you will have to specify which web pages are to be on SSL.<br /> <br /> A good starting point for working on POC in a Windows development environment could be: &quot;HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000&quot; - http://support.microsoft.com/default.aspx?scid=kb;en-us;q307267&amp;sd=tech<br /> <br /> =Cookies and Session Management =<br /> <br /> ==Are there any risks in using persistent vs non-persistent cookies? ==<br /> <br /> Persistent cookies are data that a web site places on the user's hard drive (or equivalent) for maintaining information over more than one browser session. This data will stay in the user's system and can be accessed by the site the next time the user browses the site. Non-persistent cookies on the other hand are those that are used only in the browser session that creates it. They stay only in the memory of the machine and are not persisted on the hard disk. The security risk with persistent cookies is that they are generally stored in a text file on the client and an attacker with access to the victim's machine can steal this information. <br /> <br /> ==Can another web site steal the cookies that my site places on a user's machine? ==<br /> <br /> No, it is not possible for a website to access another site's cookies. Cookies have a domain attribute associated with them. Only a request coming from the domain specified in the attribute can access the cookie. This attribute can have only one value. <br /> <br /> ==Which is the best way to transmit session ids- in cookies, or URL or a hidden variable? ==<br /> <br /> Transmitting session IDs in the URL can lead to several risks. Shoulder surfers can see the session ID; if the URL gets cached on the client system, the session ID will also be stored; the session ID will get stored in the referrer logs of other sites. Hidden variables are not always practical as every request might not be a POST. Cookies are the safest method as cookies do not get cached, are not visible in the W3C or referrer logs, and most users anyway accept cookies. <br /> <br /> ==What are these secure cookies? ==<br /> <br /> A cookie can be marked as &quot;secure&quot; which ensures the cookie is used only over SSL sessions. If &quot;secure&quot; is not specified, the cookie will be sent unencrypted over non-SSL channels. Sensitive cookies like session tokens should be marked as secure if all pages in the web site requiring session tokens are SSL-enabled. One thing to keep in mind here is that images are generally not downloaded over SSL and they usually don't require a session token to be presented. By setting the session cookie to be secure, we ensure that the browser does not send the cookie while downloading the image over the non-SSL connection.&lt;&gt; <br /> <br /> ==If I use a session ID that is a function of the client's IP address, will session hijacking be prevented? ==<br /> <br /> An attacker can hijack another user's session by stealing the session token. Methods have been suggested to prevent the session from being hijacked even if the session token is stolen. For instance, using a session token that is a function of the user's IP address. In this approach, even if the attacker stole the token, he would need the same IP address as the user to successfully hijack a session. However, session hijacking can still be possible. Suppose the attacker is on the same LAN as the user and uses the same Proxy IP as the user to access the web site. The attacker can still steal the session if he is able to sniff the session token. It may also be not possible to implement this if the IP of the client changes during a session, making the session invalid if the token is tied to the initial IP address. This may happen if the client is coming from behind a bank of proxy servers. <br /> <br /> ==How about encrypting the session id cookies instead of using SSL? ==<br /> <br /> Encrypting just the session ID over a non-SSL connection will not serve any purpose. Since the session ID will be encrypted once and the same value will be sent back and forth each time, an attacker can use the encrypted value to hijack the session. <br /> <br /> ==What is the concept of using a page id, in addition to the session id? ==<br /> <br /> A Session ID or token has the lifetime of a session and is tied to the logged in user. A page ID or token has a lifetime of a page and is tied to a page that is served. It is a unique token given when a page is downloaded and is presented by the user when accessing the next page. The server expects a particular value for the user to access the next page. Only if the token submitted matches what the server is expecting is the next page served. An application can use this to ensure that a user accesses pages only in the sequence determined by the application. The user cannot paste a deep URL in the browser and skip pages just because he has a session token, as the page token would not be authorized to access the deeper URL directly. Good Read: [http://palisade.plynt.com/issues/2005Aug/page-tokens/ Secure your sessions with Page Tokens]<br /> <br /> =Logging and Audit Trails =<br /> <br /> ==What are these W3C logs? ==<br /> <br /> W3C is a logging format used for Web server log files. W3C logs record access details of each request: the timestamp, source IP, page requested, the method used, http protocol version, browser type, the referrer page, the response code etc. Note that these are access logs, and so a separate record is maintained for each request. When a page with multiple gif files is downloaded, it would be recorded as multiple entries in the W3C log; so, W3C logs tend to be voluminous. <br /> <br /> ==Do I need to have logging in my application even if I've W3C logs? ==<br /> <br /> Yes, it's important that your application maintains &quot;application level&quot; logs even when W3C logging is used. As W3C logs contain records for every http request, it is difficult (and, at times impossible) to extract a higher level meaning from these logs. For instance, the W3C logs are cumbersome to identify a specific session of user and the activities that the user performed. It's better that the application keeps a trail of important activities, rather than decode it from W3C logs. <br /> <br /> ==What should I log from within my application? ==<br /> <br /> Keep an audit trail of activity that you might want to review while troubleshooting or conducting forensic analysis. Please note that it is inadvisable to keep sensitive business information itself in these logs, as administrators have access to these logs for troubleshooting. Activities commonly kept track of are: <br /> <br /> * Login and logout of users <br /> * Critical transactions (eg. fund transfer across accounts) <br /> * Failed login attempts <br /> * Account lockouts <br /> * Violation of policies <br /> The data that is logged for each of these activities usually include: <br /> <br /> * User ID <br /> * Time stamp <br /> * Source IP <br /> * Error codes, if any <br /> * Priority <br /> ==Should I encrypt my logs? Isn't that a performance hit? ==<br /> <br /> Encryption is required when information has to be protected from being read by unauthorized users. Yes, encryption does take a performance hit, so if your logs do not contain sensitive information you might want to forego encryption. However, we strongly urge that you protect your logs from being tampered by using digital signatures. Digital signatures are less processor intensive than encryption and ensure that your logs are not tampered. <br /> <br /> ==Can I trust the IP address of a user I see in my audit logs? Could a user be spoofing/impersonating their IP address? ==<br /> <br /> A bad guy who wants to hide his actual IP address might use a service like anonymizer, or use open HTTP relays. [HTTP open relays are improperly configured web servers on the web that are used as a HTTP proxy to connect to other sites.] In such cases, the IP address you see in your log files will be those of these services or the open relay that is being used. So, the IP address you see in your log files might not always be trustworthy. <br /> <br /> =Miscellaneous =<br /> <br /> ==What are Buffer Overflows? ==<br /> <br /> Buffer overflow vulnerability affects the web applications that require user input. The application stores the input in a buffer which is of a fixed size, as defined by the programmer. When the input that is sent to the application is more than the buffer capacity and the buffers are left unchecked, buffer overflow occurs. The severity depends on the user input. If a malicious code executes as a result of the overflow, it can even compromise the whole system.<br /> To learn more, please read the OWASP article on [http://www.owasp.org/index.php/Buffer_Overflow buffer overflows.]<br /> <br /> ==What are application firewalls? How good are they really? ==<br /> <br /> Application firewalls analyze the requests at the application level. These firewalls are used for specific applications like a web server or a database server. The web application firewalls protect the web server from HTTP based attacks. They monitor the requests for attacks that involve SQL Injection, XSS, URL encoding etcetera. However, application layer firewalls cannot protect against attacks that require an understanding of the business context - this includes most attacks that rely on variable manipulation. Some application firewalls are: Netcontinuum's NC-1000 Kavado Inc.'s InterDo Teros Inc.'s Teros-100 APS<br /> <br /> ==What is all this about &quot;referrer logs&quot;, and sensitive URLs? ==<br /> <br /> The HTTP header contains a field known as Referrer. For visiting a web page we may either: <br /> <br /> * Type its URL directly into the address bar of the browser <br /> * Click a link on some other page that brings us there <br /> * Be redirected there by some page. <br /> In the first case, the referrer field will be empty but in the other two cases it will contain the URL of the previous page. The URL of the first page will get stored in the web server access logs of the second page when the user reaches the second page from the first page. Now suppose, the two pages belong to different sites and the first URL contains sensitive information like a user's session ID. If the second site belongs to attackers, they can obtain this information by just going through the logs. Information in the URLs will get stored in the referrer logs as well as the history of the browser. Therefore, we should be careful not to have any sensitive information in the URL. <br /> <br /> ==I want to use the most secure language; which language do you recommend? ==<br /> <br /> Any language can be used since secure programming practices are what make applications safe. Most security techniques can be implemented in any language. Our advice would be to use any language you are comfortable with. But some languages like Java have additional features like bind variables that aid security; you could use those additional features if you decide to program in that language. <br /> <br /> ==What are the good books to learn secure programming practices? ==<br /> <br /> The OWASP Guide to Building Secure Web Application and Web Services is a good guide for web application developers. You can download it from http://www.owasp.org/documentation/guide Writing Secure Code by Michael Howard and David LeBlanc has a chapter on Securing Web-Based Services. More information on this book can be found at: http://www.microsoft.com/mspress/books/toc/5612.asp Secure Programming for Linux and Unix HOWTO by David Wheeler talks about writing secure applications including web applications; it also specifies guidance for a number of languages. The book can be found at: http://www.dwheeler.com/secure-programs<br /> <br /> Another good book on application security, which also covers some web service specific topics: 19 Deadly Sins of Software Security, by: Michael Howard, David LeBlanc and John Viega (http://books.mcgraw-hill.com/getbook.php?isbn=0072260858).<br /> <br /> ==Are there any training programs on secure programming that I can attend? ==<br /> <br /> Microsoft offers training programs on Developing Security-Enhanced Web Applications and Developing and Deploying Secure Microsoft .NET Framework Application. More information can be found at http://www.microsoft.com/traincert/syllabi/2300AFinal.asp and http://www.microsoft.com/traincert/syllabi/2350BFinal.asp Foundstone offers secure coding training through Global Knowledge Aspect Security offers a similar course. <br /> <br /> OWASP_FAQ_Ver3.doc</div>

Webappsecguy https://wiki.owasp.org/index.php?title=OWASP_Application_Security_FAQ&diff=156409 2013-08-04T23:52:10Z

<p>Webappsecguy: quick updates of stale content</p> <hr /> <div>=Login Issues =<br /> <br /> ==What are the best practices I should remember while designing the login pages? ==<br /> <br /> * From the login page, the user should be sent to a page for authentication. Once authenticated, the user should be sent to the next page. This is explained in the answer to the next question. <br /> * The password should never be sent in clear text (unencrypted) because it can be stolen by sniffing; saving the password in clear text in the database is dangerous too. The best method of sending passwords is the Salted MD5 hashing technique and the passwords should be hashed and then stored in the database.<br /> * The best way to manage sessions would be to use one session token with two values during authentication. One value before authentication and one after.<br /> <br /> ==Is it really required to redirect the user to a new page after login? ==<br /> <br /> Is it really required to redirect the user to a new page after login? <br /> <br /> Yes. Consider the application has a login page that sends the username and password as a POST request to the server. If a user clicks refresh on the second page (the page after login), the same request including the username and password in the POST will be sent again. Now suppose a valid user browses through our application and logs out, but does not close the window. The attackers come along and click the back button of the browser till they reach the second page. They only have to do a refresh and since the username and password are resubmitted and revalidated, the attackers can login as the user. Now let's assume the application has a login page which takes the user to an intermediate page for authentication. Once authenticated, the user is redirected to the second page with a session token. In this case, even if the attackers reach the second page and do a refresh, the username and password will not be resubmitted. This is so because the request that will be submitted is the one for the second page which does not contain the username and password. Therefore, it is always better to redirect the user. <br /> <br /> ==How does the salted MD5 technique work? ==<br /> <br /> Here is how the salted MD5 technique works: the database stores a MD5 hash of the password. (MD5 hash is a cryptographic technique in which the actual value can never be recovered.) When a client requests for the login page, the server generates a random number, the salt, and sends it to the client along with the page. A JavaScript code on the client computes the MD5 hash of the password entered by the user. It then concatenates the salt to the hash and re-computes the MD5 hash. This result is then sent to the server. The server picks the hash of the password from its database, concatenates the salt and computes the MD5 hash. If the user entered the correct password these two hashes should match. The server compares the two and if they match, the user is authenticated. <br /> <br /> ==How can my &quot;Forgot Password&quot; feature be exploited? ==<br /> <br /> The Forgot Password feature is implemented in a number of different ways. One common way is to ask the user a hint question for which the user has submitted the answer during registration. These are questions like What is your favorite color? or What is your favorite pastime? If the answer is correct, either the original password is displayed or a temporary password is displayed which can be used to log in. In this method, an attacker trying to steal the password of a user may be able to guess the correct answer of the hint question and even reset the password. <br /> <br /> ==In &quot;Forgot Password&quot;, is it safe to display the old password? ==<br /> <br /> If the old password is displayed on the screen, it can be seen by shoulder surfers. So it is a good idea not to display the password and let the user change to a new one. Moreover, displaying the password means it has to be stored in a recoverable form in the database which is not a good practice. If the password is stored as a one way hash in the database, the only way Forgot Password can be implemented is by letting the user reset the old password. So, it is always better to force the users reset their passwords when they forget their passwords. (A one way hash is the result obtained when we pass a string to a one way hash function. The result is such that it is impossible to get back the original value from it. Passwords are best stored as non-recoverable hashes in the database.) <br /> <br /> ==Is there any risk in emailing the new password to the user's authorized mail id? ==<br /> <br /> Emailing the actual password in clear text can be risky as an attacker can obtain it by sniffing. Also the mail containing the password might have a long life time and could be viewed by an attacker while it is lying in the mailbox of the user.<br /> <br /> Apart form the above threats, a malicious user can do shoulder-surfing to view the password or login credentials.<br /> <br /> ==What is the most secure way to design the Forgot Password feature? ==<br /> <br /> We should first ask the user to supply some details like personal details or ask a hint question. Then we should send a mail to the users authorized mail id with a link which will take the user to a page for resetting the password. This link should be active for only a short time, and should be SSL- enabled. This way the actual password is never seen. The security benefits of this method are: the password is not sent in the mail; since the link is active for a short time, there is no harm even if the mail remains in the mailbox for a long time. <br /> <br /> ==How do I protect against automated password guessing attacks? ==<br /> <br /> Password guessing with automated tools is a serious problem since there are a number of tools available for this purpose. These tools essentially keep trying out different passwords till one matches. Locking out the account after 5 failed attempts is a good defense against these tools. However, the important point then is how long you lock out the account for. If it is for too long, service to valid users might be denied as the attackers repeatedly lock out your users. If the time is too short say about 1-2 minutes, the tool could start again after the timeout. So the best method would be to insist on human intervention after a few failed attempts. A method used by a number of sites these days is to have the user read and enter a random word that appears in an image on the page. Since this cannot be done by a tool, we can thwart automated password guessing. The following are some tools that guess passwords of web applications: Brutus - http://www.hoobie.net/brutus/ WebCracker http://www.securityfocus.com/tools/706<br /> <br /> ==How can I protect against keystroke loggers on the client machine? ==<br /> <br /> Keystroke loggers on the end users machines can sometimes ruin all our efforts of securely transmitting and storing the passwords. The users themselves may not be aware that a key logger has been installed on their machines and records each key pressed. Since the highest risk is with the password, if we can authenticate the users without having them use the keyboard, or reveal the entire password, we solve the problem. The different ways of doing this are: <br /> <br /> * Having a graphical keyboard where the users can enter the characters they want by clicking the mouse on it. This is especially useful for numeric PINs. <br /> * Asking the users to type a part of their password each time and not the whole password. For example you could say &quot;Please enter the 1st, 3rd and 6th letters of your password&quot; and this rule could be a random one each time. <br /> ==My site will be used from publicly shared computers. What precautions must I take? ==<br /> <br /> If your application will be accessed from publicly shared computers like libraries, you could take the following precautions: <br /> <br /> * You can make sure your pages do not get cached on the system by setting the correct cache control directives. <br /> * You could take care that no sensitive information is included in the URLs since the history of the client browser will store these. <br /> * Have a graphical keyboard for entering the password or ask the user to enter a different part of the password each time. This protects the password against keystroke loggers. <br /> * To prevent sniffing of passwords and replay attacks using those, you should either use SSL or salted MD5 for passwords. The clear text password in the memory should be reset after computing the MD5. <br /> =SQL Injection =<br /> <br /> ==What is SQL Injection? ==<br /> <br /> SQL Injection is a technique by which attackers can execute SQL statements of their choice on the backend database by manipulating the input to the application. Let's understand SQL Injection through the example of a login page in a web application where the database is SQL Server. The user needs to input Username and Password in the text boxes in Login.asp page. Suppose the user enters the following: Username : Obelix and Password : Dogmatix This input is then used to build a query dynamically which would be something like: SELECT * FROM Users WHERE username= 'Obelix' and password='Dogmatix' This query would return to the application a row from the database with the given values. The user is considered authenticated if the database returns one or more rows to the application. Now, suppose an attacker enters the following input in the login page: Username : ' or 1=1-- The query built will look like this: SELECT * FROM Users WHERE username='' or 1=1-- and password='' -- in SQL Server is used to comment out the rest of the line. So, our query is now effectively: SELECT * FROM Users WHERE username='' or 1=1 This query will look in the database for a row where either username is blank or the condition 1=1 is met. Since the latter always evaluates to true, the query will return all rows of the Users table and the user is authenticated. The attacker has been successful in logging into the application without a username and password. You can read more on this at the Securiteam site: http://www.securiteam.com/securityreviews/5DP0N1P76E.html <br /> <br /> ==Is it just ASP and SQL Server or are all platforms vulnerable? ==<br /> <br /> Almost all platforms are vulnerable to SQL Injection. Inadequate checking of user input and the use of dynamic SQL queries are what make an application vulnerable to these attacks. The syntax of the input entered for SQL Injection will depend on the database being used. During our application security audits we have found many applications using other databases to be vulnerable. The above example would work on SQL Server, Oracle and MySQL. This shows that the problem is with the inadequate checking of user input and the use of dynamic SQL and not the underlying database. <br /> <br /> ==Apart from username and password which variables are candidates for SQL Injection? ==<br /> <br /> Any input field that makes up the where clause of a database query is a candidate for SQL Injection, eg. account numbers, and credit card numbers in the case of an online banking application. In addition to form fields, an attacker can use hidden fields and query strings also for injecting commands.<br /> <br /> Apart from input fields, URL parameters are also vulnerable to SQL Injection as well as other input based attacks.<br /> <br /> ==How do we prevent SQL Injection in our applications? ==<br /> <br /> It is quite simple to prevent SQL injection while developing the application. You need to check all input coming from the client before building a SQL query. The best method is to remove all unwanted input and accept only expected input. While server side input validation is the most effective method of preventing SQL Injection, the other method of prevention is not using dynamic SQL queries. This can be achieved by using stored procedures or bind variables in databases that support these features. For applications written in Java, CallableStatements and PreparedStatements can be used. For ASP applications, ADO Command Objects can be used. You can check the following article for more on SQL Injection in Oracle: http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf <br /> <br /> ==I'm using stored procedures for authentication, am I vulnerable? ==<br /> <br /> Maybe, but probably no. Using stored procedures can prevent SQL Injection because the user input is no longer used to build the query dynamically. Since a stored procedure is a group of precompiled SQL statements and the procedure accepts input as parameters, a dynamic query is avoided. Although input is put into the precompiled query as is, since the query itself is in a different format, it does not have the effect of changing the query as expected. By using stored procedures we are letting the database handle the execution of the query instead of asking it to execute a query we have built. The exception to this is where the stored procedure takes a string as input and uses this string to build the query without validating it. While this is more difficult to exploit, this scenario still often leads to successful SQL Injection. This article explains how SQL Injection affects stored procedures in more detail: http://palisade.plynt.com/issues/2006Jun/injection-stored-procedures/<br /> <br /> ==I'm using client side JavaScript code for checking user input. Isn't that enough? ==<br /> <br /> No. Although client side checking disallows the attacker to enter malicious data directly into the input fields, that alone is not enough to prevent SQL Injection. Client side scripts only check for input in the browser. But this does not guarantee that the information will remain the same till it reaches the server. To bypass client side JavaScript, the attacker can trap the request in a proxy (eg. WebScarab, [http://www.parosproxy.org Paros]) after it leaves the browser and before it reaches the server and there he can alter input fields. The attacker can also inject commands into the querystring variables which are not checked by the client side scripts, or could disable JavaScript rendering client-side scripting useless.<br /> <br /> ==Are Java servlets vulnerable to SQL injection? ==<br /> <br /> Yes, they are if the user input is not checked properly, and if they build SQL queries dynamically. But Java servlets also have certain features that prevent SQL Injection like CallableStatements and PreparedStatements. Like stored procedures and bind variables, they avoid the need of dynamic SQL statements.<br /> <br /> ==Can an automated scanner discover SQL Injection? ==<br /> <br /> Sometimes yes, sometimes no. Whether a scanner can discover SQL injection or not depends on a variety of factors: the discovery technique used, the response from the application when a malformed SQL snippet is added, and some luck. Specifically, scanners that use Blind SQL Injection are most likely to detect SQL Injection. Scanners that claim hundreds of test cases for SQL Injection are misleading. This entry from the [http://www.plynt.com/resources/learn/tools/do_scanners_catch_sql_injectio_1/ Penetration Testing Learning Center] explains this in detail.<br /> <br /> =Variable Manipulation =<br /> <br /> ==Why can't I trust the information coming from the browser? ==<br /> <br /> There are chances that the information is modified before it reaches the server. Attackers browsing the site can manipulate the information in a GET or POST request. There are a number of HTTP/HTTPS proxy tools like [http://www.mavensecurity.com/achilles Achilles], Paros, WebScarab, etc which are capable of intercepting all this information and allow the attacker running the tool to modify it. Also, the information that the user sees or provides on a web page has to travel through the internet before it reaches the server. Although the client and the server may be trusted, we cannot be sure that the information is not modified after it leaves the browser. Attackers can capture the information on the way and manipulate it.<br /> <br /> ==What information can be manipulated by the attacker? ==<br /> <br /> Manipulating the variables in the URL is simple. But attackers can also manipulate almost all information going from the client to the server like form fields, hidden fields, content-length, session-id and http methods.<br /> <br /> ==How do attackers manipulate the information? What tools do they use? ==<br /> <br /> For manipulating any information, including form fields, hidden variables and cookies, attackers use tools known as HTTP/HTTPS proxy tools. Once the browser's proxy settings are configured to go through the HTTP/HTTPS proxy, the tool can see all information flowing between the client and the server; it even allows the attacker to modify any part of the request before sending it. Some such tools are: WebScarab can be downloaded from the OWASP site. Odysseus can be found at http://www.bindshell.net/tools/odysseus Paros can be downloaded from http://www.parosproxy.org<br /> <br /> ==I'm using SSL. Can attackers still modify information? ==<br /> <br /> Although SSL provides a lot of security, SSL alone is not enough to prevent variable manipulation attacks. SSL was supposed to prevent against Man in the Middle attacks but it is vulnerable to it. To successfully carry out the MITM attack, first the attacker has to divert the victim's requests to his machine i.e. redirecting the packets meant for the server to himself. He can do this by ARP poisoning / DNS Cache poisoning. Once he is able to redirect, he can see all the requests the victim is trying to make. Now when the victim tries to establish an SSL connection with a legitimate server, he gets connected to the attacker. The attacker, during the SSL Handshaking, provides a fake certificate to the victim, which the victim accepts even though the browser warns him. Thus, the victim establishes an SSL connection with the attacker instead of the server. The attacker establishes a different SSL connection with that legitimate server, which the victim was trying to connect. Now all data flow between the victim and the server will be routed through the attacker and the attacker can see all data the victim (as well as the server) sends. This is because the victim will encrypt all data with the attacker's public key, which the attacker can decrypt with his private key. The attacker can then manipulate all data that is passing through his machine.<br /> <br /> ==Is there some way to prevent these proxy tools from editing the data? ==<br /> <br /> The main threat these proxy tools pose is editing the information sent from the client to the server. One way to prevent it is to sign the message sent from the client with a Java Applet downloaded onto the client machine. Since the applet we developed will be the one validating the certificate and not the browser, a proxy tool will not be able to get in between the client and the server with a fake certificate. The applet will reject the fake certificate. The public key of this certificate can then be used to digitally sign each message sent between the client and the server. An attacker would then have to replace the embedded certificate in the applet with a fake certificate to succeed - that raises the barrier for the attacker. <br /> <br /> =Browser Cache =<br /> <br /> ==How can the browser cache be used in attacks? ==<br /> <br /> The browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder, like the Temporary Internet Files folder in the case of Internet Explorer. When we ask for these pages again, the browser displays them from its cache. This is much faster than downloading the page from the server. Let's consider the particular scenario where a user has logged in to an application with username and password. The user browses the different pages which contain sensitive information. Let's suppose a page with the user's credit card information gets cached in the browser and the user logs out of the application. Now suppose the attackers access the same machine and searches through the Temporary Internet Files, they will get the credit card details. The attackers do not need to know the username and password of the user to steal the information. <br /> <br /> ==How do I ensure that sensitive pages are not cached on the user's browser? ==<br /> <br /> The response header sent from the server has some cache control directives that can be set from your code. These directives control the caching of content on any cache. The directives to be set are Cache-Control : no-cache, no-store and Expires: 0. But since legacy HTTP 1.0 servers do not support the Cache-Control headers, universally, Pragma: no-cache header should be used, too.<br /> <br /> ==What is the best way to implement Pragma: No-cache? ==<br /> <br /> Pragma: No-cache directive is used in the meta tag in the header, which is normally at the beginning of an HTML webpage. When an HTML code is parsed (in a top-to-bottom approach), the browser looks for the presence of the page in the cache as soon as it reads the Pragma directive. But since at that moment the page has not been cached (a webpage gets cached only after it has filled at least 32kb of the buffer), the browser will not clear the cache and it will go ahead with parsing the rest of the code. As a result, all the contents of webpage that are loaded after the parsing of Pragma get cached. The best way to implement Pragma: No-cahce is to place another header just before the html code ends. This way, the browser will parse the pragma no-cache directive after the comlete page has been loaded.<br /> <br /> ==What's the difference between the cache-control directives: no-cache, and no-store? ==<br /> <br /> The no-cache directive in a response indicates that the response must not be used to serve a subsequent request i.e. the cache must not display a response that has this directive set in the header but must let the server serve the request. The no-cache directive can include some field names; in which case the response can be shown from the cache except for the field names specified which should be served from the server. The no-store directive applies to the entire message and indicates that the cache must not store any part of the response or any request that asked for it. <br /> <br /> ==Am I totally safe with these directives? ==<br /> <br /> No. But generally, use both Cache-Control: no-cache, no-store and Pragma: no-cache, in addition to Expires: 0 (or a sufficiently backdated GMT date such as the UNIX epoch). Non-html content types like pdf, word documents, excel spreadsheets, etc often get cached even when the above cache control directives are set (although this varies by version and additional use of must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0 in practice can sometimes result at least in file deletion upon browser closure in some cases due to browser quirks and HTTP implementations). Also, 'Autocomplete' feature allows a browser to cache whatever the user types in an input field of a form. To check this, the form tag or the individual input tags should include 'Autocomplete=&quot;Off&quot; ' attribute. However, it should be noted that this attribute is non-standard (although it is supported by the major browsers) so it will break XHTML validation.<br /> <br /> ==Where can I learn more about caching? ==<br /> <br /> Some useful links that talk about caching are - Caching Tutorial for Web Authors and Webmasters by Mark Nottingham at http://www.mnot.net/cache_docs/ and HTTP RFC (sec14.9.1) at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html<br /> <br /> =Cross Site Scripting =<br /> <br /> ==What is Cross Site Scripting? ==<br /> <br /> Cross Site scripting (XSS) is a type of attack that can be carried out to steal sensitive information belonging to the users of a web site. This relies on the server reflecting back user input without checking for embedded javascript. This can be used to steal cookies and session IDs. Let's see how it works. We would all have come across the following situation sometime - we type a URL in the browser, say www.abcd.com/mypage.asp, and receive an error page that says &quot;Sorry www.abcd.com/mypage.asp does not exist&quot; or a page with a similar message. In other words, pages that display the user input back on the browser. Pages like this could be exploited using XSS. Instead of a normal input, think what will happen if the input contains a script in it. While reflecting back the input, instead of rendering it as normal HTML output, the browser treats it as a script and executes it. This script could contain some malicious code. The attackers can send a link that contains a script as part of the URL to a user. When the user clicks it, the script gets executed on the user's browser. This script may have been written to collect important information about the user and send it to the attacker. Kevin Spett's paper Cross Site Scripting, Are your web applications vulnerable? is a good source of information on this topic and is available at http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf The Cross Site Scripting FAQ at CGI Security is another good place to learn more on XSS. <br /> <br /> ==What information can an attacker steal using XSS? ==<br /> <br /> The attackers can steal the session ID of a valid user using XSS. The session ID is very valuable because it is the secret token that the user presents after login as proof of identity until logout. If the session ID is stored in a cookie, the attackers can write a script which will run on the user's browser, query the value in the cookie and send it to the attackers. The attackers can then use the valid session ID to browse the site without logging in. The script could also collect other information from the page, including the entire contents of the page. <br /> <br /> ==Apart from mailing links of error pages, are there other methods of exploiting XSS? ==<br /> <br /> Yes, there are other methods. Let's take the example of a bulletin board application that has a page where data entered by one user can be viewed by other users. The attackers enter a script into this page. When a valid user tries to view the page, the script gets executed on the user's browser. It will send the user's information to the attackers. <br /> <br /> ==How can I prevent XSS? ==<br /> <br /> XSS can be prevented while coding the application. You should be validating all input and output to and from the application and escape all special characters that may be used in a script. If the code replaces the special characters by the following before displaying the output, XSS can be prevented to some extent.<br /> <br /> <br /> <br /> &lt; &amp;lt;<br /> <br /> &gt; &amp;gt; <br /> <br /> ( &amp;*40; <br /> <br /> ) &amp;*41; <br /> <br /> * &amp;*35; <br /> &amp; &amp;*38;<br /> <br /> <br /> <br /> Gunter Ollmann has written an excellent paper on the use of special characters in XSS attacks. For instance, the above technique of escaping special characters cannot protect against a script injected like &quot;javascript:self.location.href = 'www.evil.org' &quot; as this script does not use any of the special characters.<br /> <br /> ==Can XSS be prevented without modifying the source code? ==<br /> <br /> There is a method that requires minimal coding as compared to performing input, output validation to prevent the stealing of cookies by XSS. Internet Explorer 6 has an attribute called HTTP Only that can be set for cookies. Using this attribute makes sure that the cookie can not be accessed by any scripts. More details are available at the MSDN site on httpcookies at http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/httponly_cookies.asp Mozilla also has plans to implement a similar feature. Researchers have found a method to beat this. It is known as Cross Site Tracing. <br /> <br /> ==What is Cross Site Tracing (XST)? How can it be prevented? ==<br /> <br /> Attackers are able to bypass the HTTP Only attribute to steal cookie information by Cross Site tracing (XST). TRACE is a HTTP method that can be sent to the server. The server sends back anything included in the TRACE request back to the browser. In a site that uses cookies, the cookie information is sent to the server in each request. If we send a TRACE request in a URL of such a site, the server will send back all cookie information to the browser. Now imagine a situation similar to the one described in XSS but the site in this case is using the HTTP Only cookies. The attackers make a valid user click on a link that contains a script that calls the TRACE method. When the user clicks on the link the TRACE request as well as all the cookie information is sent to the server. The server then sends back the cookie information back to the script in the browser. Suppose that the malicious script also contains code to send this information to the attackers. The attackers have succeeded again in stealing the cookies although HTTP Only Cookies were used. To summarize, HTTP Only cookies prevent the JavaScript from directly accessing the cookies but the attacker was able to retrieve it through an indirect method. XST can be prevented by disabling the TRACE method on the web server. This paper by Jeremiah Grossman discusses XST in greater detail http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf <br /> <br /> =Web Server Fingerprinting =<br /> <br /> ==How do attackers identify which web server I'm using? ==<br /> <br /> Identifying the application running on a remote web server is known as fingerprinting the server. The simplest way to do this is to send a request to the server and see the banner sent in the response. Banners will generally have the server name and the version number in it. We can address this problem by either configuring the server not to display the banner at all or by changing it to make the server look like something else.<br /> <br /> ==How can I fake the banners or rewrite the headers from my web server? ==<br /> <br /> There are a number of tools that help in faking the banners. URLScan is a tool that can change the banner of an IIS web server. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/URLScan.asp mod_security has a feature for changing the identity of the Apache web server. It can be found at http://www.modsecurity.org/ Servermask for faking banners of IIS, can be found at http://www.servermask.com/ <br /> <br /> ==Once I fake the banners, can my web server still be fingerprinted? ==<br /> <br /> Yes. Unfortunately there are tools that fingerprint the web server without relying on the banners. Different web servers may implement features not specified in HTTP RFCs differently. Suppose we make a database of these special requests and the responses of each web server. We can now send these requests to the web server we want to fingerprint and compare the responses with the database. This is the technique used by tools like Fire &amp; Water. This tool can be found at http://www.ntobjectives.com/products/firewater/ There is a paper by Saumil Shah that discusses the tool httprint at http://net-square.com/httprint/httprint_paper.html httprint can be found at http://net-square.com/httprint/ <br /> <br /> ==A friend told me it's safer to run my web server on a non-standard port. Is that right? ==<br /> <br /> A web server generally needs to be accessed by a lot of people on the internet. Since it normally runs on port 80 and all browsers are configured to access port 80 of the web server, users are able to browse the site. If we change the port, the users will have to specify the port in addition to the domain name. But this is a good idea for an intranet application where all users know where to connect. It is more secure since the web server will not be targeted by automated attacks like worms that scan port 80 and other standard ports. <br /> <br /> ==Should I really be concerned that my web server can be fingerprinted? ==<br /> <br /> Well, there are two schools of thought here. According to the first school, yes you should take precaution against fingerprinting as correctly identiying the web server maybe the first step in a more dangerous attack. Once attackers have found out that the web server is say IIS 5, they will search for known vulnerabilities for IIS 5. If the web server is not patched for all known vulnerabilities or the attackers find one for which a patch has not been released yet, there is nothing to stop them from attacking it. Also automated tools and worms can be fooled by changing the version information. Some determined and focused attackers might go to additional lengths to identify the server but the hurdles that the attackers have to overcome have increased when it's more difficult to fingerprint the web server name and version. Jeremiah Grossman pointed out the other school of thought. Evasive measures are futile as any scanner targeting a web site, will normally not care what the web server is. The scanner will run ALL its tests no matter if they apply to the system or not. This is a typical shotgun approach. A bad guy targeting the site might be hampered by not knowing the exact version, but if he's determined he would still try out all related exploits and try to break in. <br /> <br /> =Testing =<br /> <br /> ==I want to chain my proxy tool with a proxy server; are there tools that let me do that? ==<br /> <br /> Yes, there are several tools that allow proxy chaining. Some of these are: WebScarab - http://www.owasp.org/development/webscarab Exodus - http://home.intekom.com/rdawes/exodus.html Odysseus - http://www.wastelands.gen.nz/odysseus/index.php <br /> <br /> ==Can't web application testing be automated? Are there any tools for that? ==<br /> <br /> There are tools that scan applications for security flaws. But these tools can only look for a limited number of vulnerabilities, and do not find all the problems in the application. Moreover, a lot of attacks require understanding of the business context of the application to decide on the variables to manipulate in a particular request, which a tool is incapable of doing. A presentation by Jeremiah Grossman of White Hat Security which talks about the [http://www.blackhat.com/presentations/bh-federal-03/bh-fed-03-grossman-up.pdf limitations of automated scanning]. <br /> <br /> This piece explains [http://www.plynt.com/resources/learn/tools/what_cant_a_scanner_find_1/ what a scanner can't find].<br /> <br /> In our tests using a slightly modified WebGoat the best Black-box scanning tool found less than 20% of the issues ! Some tools for automated scanning are: SpikeProxy, open source and freely available at http://www.immunitysec.com/spikeproxy.html WebInspect, can be found at http://www.spidynamics.com/productline/WE_over.html<br /> <br /> ==Where can I try out my testing skills? Is there a sample application I can practice with? ==<br /> <br /> OWASP provides a sample application that can be used for this purpose called . As the site says, the WebGoat project's goal is to teach web security in an interactive teaching environment. There are lessons on most of the common vulnerabilities. Another interesting site is Hackingzone which has a game on SQL Injection at http://www.hackingzone.org/sql/index.php <br /> <br /> ==Are there source code scanning tools for .NET languages, Java, PHP etc that predict vulnerabilities in the source code? ==<br /> <br /> Rough Auditing Tool for Security (RATS) is a tool that scans the source code for security flaws in C, C++, Python, Perl and PHP programs. It can be found at http://code.google.com/p/rough-auditing-tool-for-security/downloads/list FX Cop was created by the Microsoft Team at the GotDotNet community site to check for the .NET Frameowork guidelines which include security. Prexis is a commercial source code and run-time analyzer. Flawfinder is a static source code analyzer. Compaq ESC is a run-time analyzer for Java. Parasoft AEP is a commercial source code analyzer for Java. Fortify SCA from Fortify Software is another source code analyzer that supports mixed language analysis of C, C++, C#, ASP.NET, Java, JSP, PL/SQL, VB.NET, XML, etc. Secure Coding plugins are also available. Similar source code analyzers are Klocwork K7 for C, C++ and Java; Coverity Prevent for detecting security violations and defects in code; Ounce Solutions for C, C++, C#, ASP.NET, Java and JSP. We would like to know about more tools for scanning source code. If you know about any, please inform us and we'll add to this FAQ<br /> <br /> ==Can non-HTTP protocols also be intercepted and played with like this? ==<br /> <br /> Yes, Interactive TCP Replay is a tool that acts as a proxy for non-HTTP applications and also allows modifying the traffic. It allows editing of the messages in a hex editor. ITR also logs all the messages passing between the client and the server. It can use different types of character encoding like ASCII or EBCDIC for editing and logging. More information on this can be found at http://www.webcohort.com/web_application_security/research/tools.html <br /> <br /> =Cryptography/SSL =<br /> <br /> ==What is SSL? ==<br /> <br /> Secure Socket Layer (SSL) gives us assurance of two things. Firstly when a client connects to a web server, the client can be sure that it is talking to the right server by checking the certificate the server sends it. Secondly, SSL assures you of the confidentiality of the data, as the client and the server exchange encrypted messages that cannot be understood by anybody else. This is how SSL works: When the client requests for a SSL page, the server sends a certificate that it has obtained from a trusted certificate authority. This certificate contains the public key of the server. After satisfying itself that the certificate is correct and the server is a genuine one, the client generates one random number, the session key. This key is encrypted by the public key of the server and sent across. The server decrypts the message with its private key. Now both sides have a session key known only to the two of them. All communication to and fro is encrypted and decrypted with the session key. An interesting link on SSL is http://www.rsasecurity.com/standards/ssl/basics.html <br /> <br /> ==Should I use 40-bit or 128-bit SSL? ==<br /> <br /> There are 2 strengths in SSL - 40-bit and 128-bit. These refer to the length of the secret key used for encrypting the session. This key is generated for every SSL session and is used to encrypt the rest of the session. The longer the key the more difficult it is to break the encrypted data. So, 128-bit encryption is much more secure than 40-bit. Most browsers today support 128-bit encryption. There are a few countries which have browsers with only 40-bit support. In case you are using 40-bit SSL, you may need to take further precautions to protect sensitive data. Salted hash for transmitting passwords is a good technique. This ensures that the password can not be stolen even if the SSL key is broken. <br /> <br /> ==Is 40-bit SSL really unsafe? ==<br /> <br /> 40-bit SSL is not really unsafe. It's just that it is computationally feasible to break the key used in 40-bit but not the key used in 128-bit. Even though 40-bit can be broken, it takes a fairly large number of computers to break it. Nobody would even attempt to do that for a credit card number or the like. But there are claims of breaking the 40-bit RC4 key in a few hours. So depending on the data your application deals with, you can decide on the SSL strength. Using 128-bit is definitely safer.<br /> <br /> With home computers gtting faster day by day, a dedicated, expensive and very fast computer can break 40-bit encryption in few minutes (ideally testing a million keys per second). On the other hand, 128-bit encryotion will have about 339,000,000,000,000,000,000,000,000,000,000,000 (Couple of Trillions or 2^128) possible key combinations and it will take around 1000 Years to break 128-bit encryptions with the help of a cluster of very fast computers.<br /> <br /> ==What all are encrypted when I use SSL? Is the page request also encrypted? ==<br /> <br /> After the initial SSL negotiation is done and the connection is on HTTPS, everything is encrypted including the page request. So any data sent in the query string will also be encrypted. <br /> <br /> ==Which cryptographic algorithms do SSL use? ==<br /> <br /> SSL supports a number of cryptographic algorithms. During the initial &quot;handshaking&quot; phase, it uses the RSA public key algorithm. For encrypting the data with the session key the following algorithms are used - RC2, RC4, IDEA, DES, triple-DES and MD5 message digest algorithm. <br /> <br /> ==I want to use SSL. Where do I begin? ==<br /> <br /> There are several Certificate Authorities that you can buy a SSL certificate from. Whichever CA you choose, the basic procedure will be as follows - <br /> <br /> * Create key pair for the server <br /> * Create the Certificate Signing Request. This will require you to provide certain details like location and fully qualified domain name of the server. <br /> * Submit the CSR to the CA along with documentary proof of identity. <br /> * Install the certificate sent by the CA<br /> The first two steps are done from the web server. All servers have these features. While installing the certificate issued by the CA, you will have to specify which web pages are to be on SSL.<br /> <br /> A good starting point for working on POC in a Windows development environment could be: &quot;HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000&quot; - http://support.microsoft.com/default.aspx?scid=kb;en-us;q307267&amp;sd=tech<br /> <br /> =Cookies and Session Management =<br /> <br /> ==Are there any risks in using persistent vs non-persistent cookies? ==<br /> <br /> Persistent cookies are data that a web site places on the user's hard drive (or equivalent) for maintaining information over more than one browser session. This data will stay in the user's system and can be accessed by the site the next time the user browses the site. Non-persistent cookies on the other hand are those that are used only in the browser session that creates it. They stay only in the memory of the machine and are not persisted on the hard disk. The security risk with persistent cookies is that they are generally stored in a text file on the client and an attacker with access to the victim's machine can steal this information. <br /> <br /> ==Can another web site steal the cookies that my site places on a user's machine? ==<br /> <br /> No, it is not possible for a website to access another site's cookies. Cookies have a domain attribute associated with them. Only a request coming from the domain specified in the attribute can access the cookie. This attribute can have only one value. <br /> <br /> ==Which is the best way to transmit session ids- in cookies, or URL or a hidden variable? ==<br /> <br /> Transmitting session IDs in the URL can lead to several risks. Shoulder surfers can see the session ID; if the URL gets cached on the client system, the session ID will also be stored; the session ID will get stored in the referrer logs of other sites. Hidden variables are not always practical as every request might not be a POST. Cookies are the safest method as cookies do not get cached, are not visible in the W3C or referrer logs, and most users anyway accept cookies. <br /> <br /> ==What are these secure cookies? ==<br /> <br /> A cookie can be marked as &quot;secure&quot; which ensures the cookie is used only over SSL sessions. If &quot;secure&quot; is not specified, the cookie will be sent unencrypted over non-SSL channels. Sensitive cookies like session tokens should be marked as secure if all pages in the web site requiring session tokens are SSL-enabled. One thing to keep in mind here is that images are generally not downloaded over SSL and they usually don't require a session token to be presented. By setting the session cookie to be secure, we ensure that the browser does not send the cookie while downloading the image over the non-SSL connection.&lt;&gt; <br /> <br /> ==If I use a session ID that is a function of the client's IP address, will session hijacking be prevented? ==<br /> <br /> An attacker can hijack another user's session by stealing the session token. Methods have been suggested to prevent the session from being hijacked even if the session token is stolen. For instance, using a session token that is a function of the user's IP address. In this approach, even if the attacker stole the token, he would need the same IP address as the user to successfully hijack a session. However, session hijacking can still be possible. Suppose the attacker is on the same LAN as the user and uses the same Proxy IP as the user to access the web site. The attacker can still steal the session if he is able to sniff the session token. It may also be not possible to implement this if the IP of the client changes during a session, making the session invalid if the token is tied to the initial IP address. This may happen if the client is coming from behind a bank of proxy servers. <br /> <br /> ==How about encrypting the session id cookies instead of using SSL? ==<br /> <br /> Encrypting just the session ID over a non-SSL connection will not serve any purpose. Since the session ID will be encrypted once and the same value will be sent back and forth each time, an attacker can use the encrypted value to hijack the session. <br /> <br /> ==What is the concept of using a page id, in addition to the session id? ==<br /> <br /> A Session ID or token has the lifetime of a session and is tied to the logged in user. A page ID or token has a lifetime of a page and is tied to a page that is served. It is a unique token given when a page is downloaded and is presented by the user when accessing the next page. The server expects a particular value for the user to access the next page. Only if the token submitted matches what the server is expecting is the next page served. An application can use this to ensure that a user accesses pages only in the sequence determined by the application. The user cannot paste a deep URL in the browser and skip pages just because he has a session token, as the page token would not be authorized to access the deeper URL directly. Good Read: [http://palisade.plynt.com/issues/2005Aug/page-tokens/ Secure your sessions with Page Tokens]<br /> <br /> =Logging and Audit Trails =<br /> <br /> ==What are these W3C logs? ==<br /> <br /> W3C is a logging format used for Web server log files. W3C logs record access details of each request: the timestamp, source IP, page requested, the method used, http protocol version, browser type, the referrer page, the response code etc. Note that these are access logs, and so a separate record is maintained for each request. When a page with multiple gif files is downloaded, it would be recorded as multiple entries in the W3C log; so, W3C logs tend to be voluminous. <br /> <br /> ==Do I need to have logging in my application even if I've W3C logs? ==<br /> <br /> Yes, it's important that your application maintains &quot;application level&quot; logs even when W3C logging is used. As W3C logs contain records for every http request, it is difficult (and, at times impossible) to extract a higher level meaning from these logs. For instance, the W3C logs are cumbersome to identify a specific session of user and the activities that the user performed. It's better that the application keeps a trail of important activities, rather than decode it from W3C logs. <br /> <br /> ==What should I log from within my application? ==<br /> <br /> Keep an audit trail of activity that you might want to review while troubleshooting or conducting forensic analysis. Please note that it is inadvisable to keep sensitive business information itself in these logs, as administrators have access to these logs for troubleshooting. Activities commonly kept track of are: <br /> <br /> * Login and logout of users <br /> * Critical transactions (eg. fund transfer across accounts) <br /> * Failed login attempts <br /> * Account lockouts <br /> * Violation of policies <br /> The data that is logged for each of these activities usually include: <br /> <br /> * User ID <br /> * Time stamp <br /> * Source IP <br /> * Error codes, if any <br /> * Priority <br /> ==Should I encrypt my logs? Isn't that a performance hit? ==<br /> <br /> Encryption is required when information has to be protected from being read by unauthorized users. Yes, encryption does take a performance hit, so if your logs do not contain sensitive information you might want to forego encryption. However, we strongly urge that you protect your logs from being tampered by using digital signatures. Digital signatures are less processor intensive than encryption and ensure that your logs are not tampered. <br /> <br /> ==Can I trust the IP address of a user I see in my audit logs? Could a user be spoofing/impersonating their IP address? ==<br /> <br /> A bad guy who wants to hide his actual IP address might use a service like anonymizer, or use open HTTP relays. [HTTP open relays are improperly configured web servers on the web that are used as a HTTP proxy to connect to other sites.] In such cases, the IP address you see in your log files will be those of these services or the open relay that is being used. So, the IP address you see in your log files might not always be trustworthy. <br /> <br /> =Miscellaneous =<br /> <br /> ==What are Buffer Overflows? ==<br /> <br /> Buffer overflow vulnerability affects the web applications that require user input. The application stores the input in a buffer which is of a fixed size, as defined by the programmer. When the input that is sent to the application is more than the buffer capacity and the buffers are left unchecked, buffer overflow occurs. The severity depends on the user input. If a malicious code executes as a result of the overflow, it can even compromise the whole system.<br /> To learn more, please read the OWASP article on [http://www.owasp.org/index.php/Buffer_Overflow buffer overflows.]<br /> <br /> ==What are application firewalls? How good are they really? ==<br /> <br /> Application firewalls analyze the requests at the application level. These firewalls are used for specific applications like a web server or a database server. The web application firewalls protect the web server from HTTP based attacks. They monitor the requests for attacks that involve SQL Injection, XSS, URL encoding etcetera. However, application layer firewalls cannot protect against attacks that require an understanding of the business context - this includes most attacks that rely on variable manipulation. Some application firewalls are: Netcontinuum's NC-1000 Kavado Inc.'s InterDo Teros Inc.'s Teros-100 APS<br /> <br /> ==What is all this about &quot;referrer logs&quot;, and sensitive URLs? ==<br /> <br /> The HTTP header contains a field known as Referrer. For visiting a web page we may either: <br /> <br /> * Type its URL directly into the address bar of the browser <br /> * Click a link on some other page that brings us there <br /> * Be redirected there by some page. <br /> In the first case, the referrer field will be empty but in the other two cases it will contain the URL of the previous page. The URL of the first page will get stored in the web server access logs of the second page when the user reaches the second page from the first page. Now suppose, the two pages belong to different sites and the first URL contains sensitive information like a user's session ID. If the second site belongs to attackers, they can obtain this information by just going through the logs. Information in the URLs will get stored in the referrer logs as well as the history of the browser. Therefore, we should be careful not to have any sensitive information in the URL. <br /> <br /> ==I want to use the most secure language; which language do you recommend? ==<br /> <br /> Any language can be used since secure programming practices are what make applications safe. Most security techniques can be implemented in any language. Our advice would be to use any language you are comfortable with. But some languages like Java have additional features like bind variables that aid security; you could use those additional features if you decide to program in that language. <br /> <br /> ==What are the good books to learn secure programming practices? ==<br /> <br /> The OWASP Guide to Building Secure Web Application and Web Services is a good guide for web application developers. You can download it from http://www.owasp.org/documentation/guide Writing Secure Code by Michael Howard and David LeBlanc has a chapter on Securing Web-Based Services. More information on this book can be found at: http://www.microsoft.com/mspress/books/toc/5612.asp Secure Programming for Linux and Unix HOWTO by David Wheeler talks about writing secure applications including web applications; it also specifies guidance for a number of languages. The book can be found at: http://www.dwheeler.com/secure-programs<br /> <br /> Another good book on application security, which also covers some web service specific topics: 19 Deadly Sins of Software Security, by: Michael Howard, David LeBlanc and John Viega (http://books.mcgraw-hill.com/getbook.php?isbn=0072260858).<br /> <br /> ==Are there any training programs on secure programming that I can attend? ==<br /> <br /> Microsoft offers training programs on Developing Security-Enhanced Web Applications and Developing and Deploying Secure Microsoft .NET Framework Application. More information can be found at http://www.microsoft.com/traincert/syllabi/2300AFinal.asp and http://www.microsoft.com/traincert/syllabi/2350BFinal.asp Foundstone offers secure coding training through Global Knowledge Aspect Security offers a similar course. <br /> <br /> OWASP_FAQ_Ver3.doc</div>

Webappsecguy https://wiki.owasp.org/index.php?title=OWASP_Application_Security_FAQ&diff=156408 2013-08-04T23:41:17Z

<p>Webappsecguy: clarification</p> <hr /> <div>=Login Issues =<br /> <br /> ==What are the best practices I should remember while designing the login pages? ==<br /> <br /> * From the login page, the user should be sent to a page for authentication. Once authenticated, the user should be sent to the next page. This is explained in the answer to the next question. <br /> * The password should never be sent in clear text (unencrypted) because it can be stolen by sniffing; saving the password in clear text in the database is dangerous too. The best method of sending passwords is the Salted MD5 hashing technique and the passwords should be hashed and then stored in the database.<br /> * The best way to manage sessions would be to use one session token with two values during authentication. One value before authentication and one after.<br /> <br /> ==Is it really required to redirect the user to a new page after login? ==<br /> <br /> Is it really required to redirect the user to a new page after login? <br /> <br /> Yes. Consider the application has a login page that sends the username and password as a POST request to the server. If a user clicks refresh on the second page (the page after login), the same request including the username and password in the POST will be sent again. Now suppose a valid user browses through our application and logs out, but does not close the window. The attackers come along and click the back button of the browser till they reach the second page. They only have to do a refresh and since the username and password are resubmitted and revalidated, the attackers can login as the user. Now let's assume the application has a login page which takes the user to an intermediate page for authentication. Once authenticated, the user is redirected to the second page with a session token. In this case, even if the attackers reach the second page and do a refresh, the username and password will not be resubmitted. This is so because the request that will be submitted is the one for the second page which does not contain the username and password. Therefore, it is always better to redirect the user. <br /> <br /> ==How does the salted MD5 technique work? ==<br /> <br /> Here is how the salted MD5 technique works: the database stores a MD5 hash of the password. (MD5 hash is a cryptographic technique in which the actual value can never be recovered.) When a client requests for the login page, the server generates a random number, the salt, and sends it to the client along with the page. A JavaScript code on the client computes the MD5 hash of the password entered by the user. It then concatenates the salt to the hash and re-computes the MD5 hash. This result is then sent to the server. The server picks the hash of the password from its database, concatenates the salt and computes the MD5 hash. If the user entered the correct password these two hashes should match. The server compares the two and if they match, the user is authenticated. <br /> <br /> ==How can my &quot;Forgot Password&quot; feature be exploited? ==<br /> <br /> The Forgot Password feature is implemented in a number of different ways. One common way is to ask the user a hint question for which the user has submitted the answer during registration. These are questions like What is your favorite color? or What is your favorite pastime? If the answer is correct, either the original password is displayed or a temporary password is displayed which can be used to log in. In this method, an attacker trying to steal the password of a user may be able to guess the correct answer of the hint question and even reset the password. <br /> <br /> ==In &quot;Forgot Password&quot;, is it safe to display the old password? ==<br /> <br /> If the old password is displayed on the screen, it can be seen by shoulder surfers. So it is a good idea not to display the password and let the user change to a new one. Moreover, displaying the password means it has to be stored in a recoverable form in the database which is not a good practice. If the password is stored as a one way hash in the database, the only way Forgot Password can be implemented is by letting the user reset the old password. So, it is always better to force the users reset their passwords when they forget their passwords. (A one way hash is the result obtained when we pass a string to a one way hash function. The result is such that it is impossible to get back the original value from it. Passwords are best stored as non-recoverable hashes in the database.) <br /> <br /> ==Is there any risk in emailing the new password to the user's authorized mail id? ==<br /> <br /> Emailing the actual password in clear text can be risky as an attacker can obtain it by sniffing. Also the mail containing the password might have a long life time and could be viewed by an attacker while it is lying in the mailbox of the user.<br /> <br /> Apart form the above threats, a malicious user can do shoulder-surfing to view the password or login credentials.<br /> <br /> ==What is the most secure way to design the Forgot Password feature? ==<br /> <br /> We should first ask the user to supply some details like personal details or ask a hint question. Then we should send a mail to the users authorized mail id with a link which will take the user to a page for resetting the password. This link should be active for only a short time, and should be SSL- enabled. This way the actual password is never seen. The security benefits of this method are: the password is not sent in the mail; since the link is active for a short time, there is no harm even if the mail remains in the mailbox for a long time. <br /> <br /> ==How do I protect against automated password guessing attacks? ==<br /> <br /> Password guessing with automated tools is a serious problem since there are a number of tools available for this purpose. These tools essentially keep trying out different passwords till one matches. Locking out the account after 5 failed attempts is a good defense against these tools. However, the important point then is how long you lock out the account for. If it is for too long, service to valid users might be denied as the attackers repeatedly lock out your users. If the time is too short say about 1-2 minutes, the tool could start again after the timeout. So the best method would be to insist on human intervention after a few failed attempts. A method used by a number of sites these days is to have the user read and enter a random word that appears in an image on the page. Since this cannot be done by a tool, we can thwart automated password guessing. The following are some tools that guess passwords of web applications: Brutus - http://www.hoobie.net/brutus/ WebCracker http://www.securityfocus.com/tools/706<br /> <br /> ==How can I protect against keystroke loggers on the client machine? ==<br /> <br /> Keystroke loggers on the end users machines can sometimes ruin all our efforts of securely transmitting and storing the passwords. The users themselves may not be aware that a key logger has been installed on their machines and records each key pressed. Since the highest risk is with the password, if we can authenticate the users without having them use the keyboard, or reveal the entire password, we solve the problem. The different ways of doing this are: <br /> <br /> * Having a graphical keyboard where the users can enter the characters they want by clicking the mouse on it. This is especially useful for numeric PINs. <br /> * Asking the users to type a part of their password each time and not the whole password. For example you could say &quot;Please enter the 1st, 3rd and 6th letters of your password&quot; and this rule could be a random one each time. <br /> ==My site will be used from publicly shared computers. What precautions must I take? ==<br /> <br /> If your application will be accessed from publicly shared computers like libraries, you could take the following precautions: <br /> <br /> * You can make sure your pages do not get cached on the system by setting the correct cache control directives. <br /> * You could take care that no sensitive information is included in the URLs since the history of the client browser will store these. <br /> * Have a graphical keyboard for entering the password or ask the user to enter a different part of the password each time. This protects the password against keystroke loggers. <br /> * To prevent sniffing of passwords and replay attacks using those, you should either use SSL or salted MD5 for passwords. The clear text password in the memory should be reset after computing the MD5. <br /> =SQL Injection =<br /> <br /> ==What is SQL Injection? ==<br /> <br /> SQL Injection is a technique by which attackers can execute SQL statements of their choice on the backend database by manipulating the input to the application. Let's understand SQL Injection through the example of a login page in a web application where the database is SQL Server. The user needs to input Username and Password in the text boxes in Login.asp page. Suppose the user enters the following: Username : Obelix and Password : Dogmatix This input is then used to build a query dynamically which would be something like: SELECT * FROM Users WHERE username= 'Obelix' and password='Dogmatix' This query would return to the application a row from the database with the given values. The user is considered authenticated if the database returns one or more rows to the application. Now, suppose an attacker enters the following input in the login page: Username : ' or 1=1-- The query built will look like this: SELECT * FROM Users WHERE username='' or 1=1-- and password='' -- in SQL Server is used to comment out the rest of the line. So, our query is now effectively: SELECT * FROM Users WHERE username='' or 1=1 This query will look in the database for a row where either username is blank or the condition 1=1 is met. Since the latter always evaluates to true, the query will return all rows of the Users table and the user is authenticated. The attacker has been successful in logging into the application without a username and password. You can read more on this at the Securiteam site: http://www.securiteam.com/securityreviews/5DP0N1P76E.html <br /> <br /> ==Is it just ASP and SQL Server or are all platforms vulnerable? ==<br /> <br /> Almost all platforms are vulnerable to SQL Injection. Inadequate checking of user input and the use of dynamic SQL queries are what make an application vulnerable to these attacks. The syntax of the input entered for SQL Injection will depend on the database being used. During our application security audits we have found many applications using other databases to be vulnerable. The above example would work on SQL Server, Oracle and MySQL. This shows that the problem is with the inadequate checking of user input and the use of dynamic SQL and not the underlying database. <br /> <br /> ==Apart from username and password which variables are candidates for SQL Injection? ==<br /> <br /> Any input field that makes up the where clause of a database query is a candidate for SQL Injection, eg. account numbers, and credit card numbers in the case of an online banking application. In addition to form fields, an attacker can use hidden fields and query strings also for injecting commands.<br /> <br /> Apart from input fields, URL parameters are also vulnerable to SQL Injection as well as other input based attacks.<br /> <br /> ==How do we prevent SQL Injection in our applications? ==<br /> <br /> It is quite simple to prevent SQL injection while developing the application. You need to check all input coming from the client before building a SQL query. The best method is to remove all unwanted input and accept only expected input. While server side input validation is the most effective method of preventing SQL Injection, the other method of prevention is not using dynamic SQL queries. This can be achieved by using stored procedures or bind variables in databases that support these features. For applications written in Java, CallableStatements and PreparedStatements can be used. For ASP applications, ADO Command Objects can be used. You can check the following article for more on SQL Injection in Oracle: http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf <br /> <br /> ==I'm using stored procedures for authentication, am I vulnerable? ==<br /> <br /> Maybe, but probably no. Using stored procedures can prevent SQL Injection because the user input is no longer used to build the query dynamically. Since a stored procedure is a group of precompiled SQL statements and the procedure accepts input as parameters, a dynamic query is avoided. Although input is put into the precompiled query as is, since the query itself is in a different format, it does not have the effect of changing the query as expected. By using stored procedures we are letting the database handle the execution of the query instead of asking it to execute a query we have built. The exception to this is where the stored procedure takes a string as input and uses this string to build the query without validating it. While this is more difficult to exploit, this scenario still often leads to successful SQL Injection. This article explains how SQL Injection affects stored procedures in more detail: http://palisade.plynt.com/issues/2006Jun/injection-stored-procedures/<br /> <br /> ==I'm using client side JavaScript code for checking user input. Isn't that enough? ==<br /> <br /> No. Although client side checking disallows the attacker to enter malicious data directly into the input fields, that alone is not enough to prevent SQL Injection. Client side scripts only check for input in the browser. But this does not guarantee that the information will remain the same till it reaches the server. To bypass client side JavaScript, the attacker can trap the request in a proxy (eg. WebScarab, [http://www.parosproxy.org Paros]) after it leaves the browser and before it reaches the server and there he can alter input fields. The attacker can also inject commands into the querystring variables which are not checked by the client side scripts, or could disable JavaScript rendering client-side scripting useless.<br /> <br /> ==Are Java servlets vulnerable to SQL injection? ==<br /> <br /> Yes, they are if the user input is not checked properly, and if they build SQL queries dynamically. But Java servlets also have certain features that prevent SQL Injection like CallableStatements and PreparedStatements. Like stored procedures and bind variables, they avoid the need of dynamic SQL statements.<br /> <br /> ==Can an automated scanner discover SQL Injection? ==<br /> <br /> Sometimes yes, sometimes no. Whether a scanner can discover SQL injection or not depends on a variety of factors: the discovery technique used, the response from the application when a malformed SQL snippet is added, and some luck. Specifically, scanners that use Blind SQL Injection are most likely to detect SQL Injection. Scanners that claim hundreds of test cases for SQL Injection are misleading. This entry from the [http://www.plynt.com/resources/learn/tools/do_scanners_catch_sql_injectio_1/ Penetration Testing Learning Center] explains this in detail.<br /> <br /> =Variable Manipulation =<br /> <br /> ==Why can't I trust the information coming from the browser? ==<br /> <br /> There are chances that the information is modified before it reaches the server. Attackers browsing the site can manipulate the information in a GET or POST request. There are a number of HTTP/HTTPS proxy tools like [http://www.mavensecurity.com/achilles Achilles], Paros, WebScarab, etc which are capable of intercepting all this information and allow the attacker running the tool to modify it. Also, the information that the user sees or provides on a web page has to travel through the internet before it reaches the server. Although the client and the server may be trusted, we cannot be sure that the information is not modified after it leaves the browser. Attackers can capture the information on the way and manipulate it.<br /> <br /> ==What information can be manipulated by the attacker? ==<br /> <br /> Manipulating the variables in the URL is simple. But attackers can also manipulate almost all information going from the client to the server like form fields, hidden fields, content-length, session-id and http methods.<br /> <br /> ==How do attackers manipulate the information? What tools do they use? ==<br /> <br /> For manipulating any information, including form fields, hidden variables and cookies, attackers use tools known as HTTP/HTTPS proxy tools. Once the browser's proxy settings are configured to go through the HTTP/HTTPS proxy, the tool can see all information flowing between the client and the server; it even allows the attacker to modify any part of the request before sending it. Some such tools are: WebScarab can be downloaded from the OWASP site. Odysseus can be found at http://www.bindshell.net/tools/odysseus Paros can be downloaded from http://www.parosproxy.org<br /> <br /> ==I'm using SSL. Can attackers still modify information? ==<br /> <br /> Although SSL provides a lot of security, SSL alone is not enough to prevent variable manipulation attacks. SSL was supposed to prevent against Man in the Middle attacks but it is vulnerable to it. To successfully carry out the MITM attack, first the attacker has to divert the victim's requests to his machine i.e. redirecting the packets meant for the server to himself. He can do this by ARP poisoning / DNS Cache poisoning. Once he is able to redirect, he can see all the requests the victim is trying to make. Now when the victim tries to establish an SSL connection with a legitimate server, he gets connected to the attacker. The attacker, during the SSL Handshaking, provides a fake certificate to the victim, which the victim accepts even though the browser warns him. Thus, the victim establishes an SSL connection with the attacker instead of the server. The attacker establishes a different SSL connection with that legitimate server, which the victim was trying to connect. Now all data flow between the victim and the server will be routed through the attacker and the attacker can see all data the victim (as well as the server) sends. This is because the victim will encrypt all data with the attacker's public key, which the attacker can decrypt with his private key. The attacker can then manipulate all data that is passing through his machine.<br /> <br /> ==Is there some way to prevent these proxy tools from editing the data? ==<br /> <br /> The main threat these proxy tools pose is editing the information sent from the client to the server. One way to prevent it is to sign the message sent from the client with a Java Applet downloaded onto the client machine. Since the applet we developed will be the one validating the certificate and not the browser, a proxy tool will not be able to get in between the client and the server with a fake certificate. The applet will reject the fake certificate. The public key of this certificate can then be used to digitally sign each message sent between the client and the server. An attacker would then have to replace the embedded certificate in the applet with a fake certificate to succeed - that raises the barrier for the attacker. <br /> <br /> =Browser Cache =<br /> <br /> ==How can the browser cache be used in attacks? ==<br /> <br /> The browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder, like the Temporary Internet Files folder in the case of Internet Explorer. When we ask for these pages again, the browser displays them from its cache. This is much faster than downloading the page from the server. Let's consider the particular scenario where a user has logged in to an application with username and password. The user browses the different pages which contain sensitive information. Let's suppose a page with the user's credit card information gets cached in the browser and the user logs out of the application. Now suppose the attackers access the same machine and searches through the Temporary Internet Files, they will get the credit card details. The attackers do not need to know the username and password of the user to steal the information. <br /> <br /> ==How do I ensure that sensitive pages are not cached on the user's browser? ==<br /> <br /> The response header sent from the server has some cache control directives that can be set from your code. These directives control the caching of content on any cache. The directives to be set are Cache-Control : no-cache or Cache-Control : no-store. But since legacy HTTP 1.0 servers do not support the Cache-Control headers, HTTP Pragma: no-cache header can be used. However, pragma no-cache can prevent caching only if it is used for ssl page. For a non-ssl page, it is eqivalent to 'Expires = -1'.<br /> <br /> ==What is the best way to implement Pragma: No-cache? ==<br /> <br /> Pragma: No-cache directive is used in the meta tag in the header, which is normally at the beginning of an HTML webpage. When an HTML code is parsed (in a top-to-bottom approach), the browser looks for the presence of the page in the cache as soon as it reads the Pragma directive. But since at that moment the page has not been cached (a webpage gets cached only after it has filled at least 32kb of the buffer), the browser will not clear the cache and it will go ahead with parsing the rest of the code. As a result, all the contents of webpage that are loaded after the parsing of Pragma get cached. The best way to implement Pragma: No-cahce is to place another header just before the html code ends. This way, the browser will parse the pragma no-cache directive after the comlete page has been loaded.<br /> <br /> ==What's the difference between the cache-control directives: no-cache, and no-store? ==<br /> <br /> The no-cache directive in a response indicates that the response must not be used to serve a subsequent request i.e. the cache must not display a response that has this directive set in the header but must let the server serve the request. The no-cache directive can include some field names; in which case the response can be shown from the cache except for the field names specified which should be served from the server. The no-store directive applies to the entire message and indicates that the cache must not store any part of the response or any request that asked for it. <br /> <br /> ==Am I totally safe with these directives? ==<br /> <br /> No. But generally, use both Cache-Control: no-cache, no-store and Pragma: no-cache, in addition to Expires: 0 (or a sufficiently backdated GMT date such as the UNIX epoch). Non-html content types like pdf, word documents, excel spreadsheets, etc often get cached even when the above cache control directives are set (although this varies by version and additional use of must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0 in practice can sometimes result at least in file deletion upon browser closure in some cases due to browser quirks and HTTP implementations). Also, 'Autocomplete' feature allows a browser to cache whatever the user types in an input field of a form. To check this, the form tag or the individual input tags should include 'Autocomplete=&quot;Off&quot; ' attribute. However, it should be noted that this attribute is non-standard (although it is supported by the major browsers) so it will break XHTML validation.<br /> <br /> ==Where can I learn more about caching? ==<br /> <br /> Some useful links that talk about caching are - Caching Tutorial for Web Authors and Webmasters by Mark Nottingham at http://www.mnot.net/cache_docs/ and HTTP RFC (sec14.9.1) at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html<br /> <br /> =Cross Site Scripting =<br /> <br /> ==What is Cross Site Scripting? ==<br /> <br /> Cross Site scripting (XSS) is a type of attack that can be carried out to steal sensitive information belonging to the users of a web site. This relies on the server reflecting back user input without checking for embedded javascript. This can be used to steal cookies and session IDs. Let's see how it works. We would all have come across the following situation sometime - we type a URL in the browser, say www.abcd.com/mypage.asp, and receive an error page that says &quot;Sorry www.abcd.com/mypage.asp does not exist&quot; or a page with a similar message. In other words, pages that display the user input back on the browser. Pages like this could be exploited using XSS. Instead of a normal input, think what will happen if the input contains a script in it. While reflecting back the input, instead of rendering it as normal HTML output, the browser treats it as a script and executes it. This script could contain some malicious code. The attackers can send a link that contains a script as part of the URL to a user. When the user clicks it, the script gets executed on the user's browser. This script may have been written to collect important information about the user and send it to the attacker. Kevin Spett's paper Cross Site Scripting, Are your web applications vulnerable? is a good source of information on this topic and is available at http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf The Cross Site Scripting FAQ at CGI Security is another good place to learn more on XSS. <br /> <br /> ==What information can an attacker steal using XSS? ==<br /> <br /> The attackers can steal the session ID of a valid user using XSS. The session ID is very valuable because it is the secret token that the user presents after login as proof of identity until logout. If the session ID is stored in a cookie, the attackers can write a script which will run on the user's browser, query the value in the cookie and send it to the attackers. The attackers can then use the valid session ID to browse the site without logging in. The script could also collect other information from the page, including the entire contents of the page. <br /> <br /> ==Apart from mailing links of error pages, are there other methods of exploiting XSS? ==<br /> <br /> Yes, there are other methods. Let's take the example of a bulletin board application that has a page where data entered by one user can be viewed by other users. The attackers enter a script into this page. When a valid user tries to view the page, the script gets executed on the user's browser. It will send the user's information to the attackers. <br /> <br /> ==How can I prevent XSS? ==<br /> <br /> XSS can be prevented while coding the application. You should be validating all input and output to and from the application and escape all special characters that may be used in a script. If the code replaces the special characters by the following before displaying the output, XSS can be prevented to some extent.<br /> <br /> <br /> <br /> &lt; &amp;lt;<br /> <br /> &gt; &amp;gt; <br /> <br /> ( &amp;*40; <br /> <br /> ) &amp;*41; <br /> <br /> * &amp;*35; <br /> &amp; &amp;*38;<br /> <br /> <br /> <br /> Gunter Ollmann has written an excellent paper on the use of special characters in XSS attacks. For instance, the above technique of escaping special characters cannot protect against a script injected like &quot;javascript:self.location.href = 'www.evil.org' &quot; as this script does not use any of the special characters.<br /> <br /> ==Can XSS be prevented without modifying the source code? ==<br /> <br /> There is a method that requires minimal coding as compared to performing input, output validation to prevent the stealing of cookies by XSS. Internet Explorer 6 has an attribute called HTTP Only that can be set for cookies. Using this attribute makes sure that the cookie can not be accessed by any scripts. More details are available at the MSDN site on httpcookies at http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/httponly_cookies.asp Mozilla also has plans to implement a similar feature. Researchers have found a method to beat this. It is known as Cross Site Tracing. <br /> <br /> ==What is Cross Site Tracing (XST)? How can it be prevented? ==<br /> <br /> Attackers are able to bypass the HTTP Only attribute to steal cookie information by Cross Site tracing (XST). TRACE is a HTTP method that can be sent to the server. The server sends back anything included in the TRACE request back to the browser. In a site that uses cookies, the cookie information is sent to the server in each request. If we send a TRACE request in a URL of such a site, the server will send back all cookie information to the browser. Now imagine a situation similar to the one described in XSS but the site in this case is using the HTTP Only cookies. The attackers make a valid user click on a link that contains a script that calls the TRACE method. When the user clicks on the link the TRACE request as well as all the cookie information is sent to the server. The server then sends back the cookie information back to the script in the browser. Suppose that the malicious script also contains code to send this information to the attackers. The attackers have succeeded again in stealing the cookies although HTTP Only Cookies were used. To summarize, HTTP Only cookies prevent the JavaScript from directly accessing the cookies but the attacker was able to retrieve it through an indirect method. XST can be prevented by disabling the TRACE method on the web server. This paper by Jeremiah Grossman discusses XST in greater detail http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf <br /> <br /> =Web Server Fingerprinting =<br /> <br /> ==How do attackers identify which web server I'm using? ==<br /> <br /> Identifying the application running on a remote web server is known as fingerprinting the server. The simplest way to do this is to send a request to the server and see the banner sent in the response. Banners will generally have the server name and the version number in it. We can address this problem by either configuring the server not to display the banner at all or by changing it to make the server look like something else.<br /> <br /> ==How can I fake the banners or rewrite the headers from my web server? ==<br /> <br /> There are a number of tools that help in faking the banners. URLScan is a tool that can change the banner of an IIS web server. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/URLScan.asp mod_security has a feature for changing the identity of the Apache web server. It can be found at http://www.modsecurity.org/ Servermask for faking banners of IIS, can be found at http://www.servermask.com/ <br /> <br /> ==Once I fake the banners, can my web server still be fingerprinted? ==<br /> <br /> Yes. Unfortunately there are tools that fingerprint the web server without relying on the banners. Different web servers may implement features not specified in HTTP RFCs differently. Suppose we make a database of these special requests and the responses of each web server. We can now send these requests to the web server we want to fingerprint and compare the responses with the database. This is the technique used by tools like Fire &amp; Water. This tool can be found at http://www.ntobjectives.com/products/firewater/ There is a paper by Saumil Shah that discusses the tool httprint at http://net-square.com/httprint/httprint_paper.html httprint can be found at http://net-square.com/httprint/ <br /> <br /> ==A friend told me it's safer to run my web server on a non-standard port. Is that right? ==<br /> <br /> A web server generally needs to be accessed by a lot of people on the internet. Since it normally runs on port 80 and all browsers are configured to access port 80 of the web server, users are able to browse the site. If we change the port, the users will have to specify the port in addition to the domain name. But this is a good idea for an intranet application where all users know where to connect. It is more secure since the web server will not be targeted by automated attacks like worms that scan port 80 and other standard ports. <br /> <br /> ==Should I really be concerned that my web server can be fingerprinted? ==<br /> <br /> Well, there are two schools of thought here. According to the first school, yes you should take precaution against fingerprinting as correctly identiying the web server maybe the first step in a more dangerous attack. Once attackers have found out that the web server is say IIS 5, they will search for known vulnerabilities for IIS 5. If the web server is not patched for all known vulnerabilities or the attackers find one for which a patch has not been released yet, there is nothing to stop them from attacking it. Also automated tools and worms can be fooled by changing the version information. Some determined and focused attackers might go to additional lengths to identify the server but the hurdles that the attackers have to overcome have increased when it's more difficult to fingerprint the web server name and version. Jeremiah Grossman pointed out the other school of thought. Evasive measures are futile as any scanner targeting a web site, will normally not care what the web server is. The scanner will run ALL its tests no matter if they apply to the system or not. This is a typical shotgun approach. A bad guy targeting the site might be hampered by not knowing the exact version, but if he's determined he would still try out all related exploits and try to break in. <br /> <br /> =Testing =<br /> <br /> ==I want to chain my proxy tool with a proxy server; are there tools that let me do that? ==<br /> <br /> Yes, there are several tools that allow proxy chaining. Some of these are: WebScarab - http://www.owasp.org/development/webscarab Exodus - http://home.intekom.com/rdawes/exodus.html Odysseus - http://www.wastelands.gen.nz/odysseus/index.php <br /> <br /> ==Can't web application testing be automated? Are there any tools for that? ==<br /> <br /> There are tools that scan applications for security flaws. But these tools can only look for a limited number of vulnerabilities, and do not find all the problems in the application. Moreover, a lot of attacks require understanding of the business context of the application to decide on the variables to manipulate in a particular request, which a tool is incapable of doing. A presentation by Jeremiah Grossman of White Hat Security which talks about the [http://www.blackhat.com/presentations/bh-federal-03/bh-fed-03-grossman-up.pdf limitations of automated scanning]. <br /> <br /> This piece explains [http://www.plynt.com/resources/learn/tools/what_cant_a_scanner_find_1/ what a scanner can't find].<br /> <br /> In our tests using a slightly modified WebGoat the best Black-box scanning tool found less than 20% of the issues ! Some tools for automated scanning are: SpikeProxy, open source and freely available at http://www.immunitysec.com/spikeproxy.html WebInspect, can be found at http://www.spidynamics.com/productline/WE_over.html<br /> <br /> ==Where can I try out my testing skills? Is there a sample application I can practice with? ==<br /> <br /> OWASP provides a sample application that can be used for this purpose called . As the site says, the WebGoat project's goal is to teach web security in an interactive teaching environment. There are lessons on most of the common vulnerabilities. Another interesting site is Hackingzone which has a game on SQL Injection at http://www.hackingzone.org/sql/index.php <br /> <br /> ==Are there source code scanning tools for .NET languages, Java, PHP etc that predict vulnerabilities in the source code? ==<br /> <br /> Rough Auditing Tool for Security (RATS) is a tool that scans the source code for security flaws in C, C++, Python, Perl and PHP programs. It can be found at http://code.google.com/p/rough-auditing-tool-for-security/downloads/list FX Cop was created by the Microsoft Team at the GotDotNet community site to check for the .NET Frameowork guidelines which include security. Prexis is a commercial source code and run-time analyzer. Flawfinder is a static source code analyzer. Compaq ESC is a run-time analyzer for Java. Parasoft AEP is a commercial source code analyzer for Java. Fortify SCA from Fortify Software is another source code analyzer that supports mixed language analysis of C, C++, C#, ASP.NET, Java, JSP, PL/SQL, VB.NET, XML, etc. Secure Coding plugins are also available. Similar source code analyzers are Klocwork K7 for C, C++ and Java; Coverity Prevent for detecting security violations and defects in code; Ounce Solutions for C, C++, C#, ASP.NET, Java and JSP. We would like to know about more tools for scanning source code. If you know about any, please inform us and we'll add to this FAQ<br /> <br /> ==Can non-HTTP protocols also be intercepted and played with like this? ==<br /> <br /> Yes, Interactive TCP Replay is a tool that acts as a proxy for non-HTTP applications and also allows modifying the traffic. It allows editing of the messages in a hex editor. ITR also logs all the messages passing between the client and the server. It can use different types of character encoding like ASCII or EBCDIC for editing and logging. More information on this can be found at http://www.webcohort.com/web_application_security/research/tools.html <br /> <br /> =Cryptography/SSL =<br /> <br /> ==What is SSL? ==<br /> <br /> Secure Socket Layer (SSL) gives us assurance of two things. Firstly when a client connects to a web server, the client can be sure that it is talking to the right server by checking the certificate the server sends it. Secondly, SSL assures you of the confidentiality of the data, as the client and the server exchange encrypted messages that cannot be understood by anybody else. This is how SSL works: When the client requests for a SSL page, the server sends a certificate that it has obtained from a trusted certificate authority. This certificate contains the public key of the server. After satisfying itself that the certificate is correct and the server is a genuine one, the client generates one random number, the session key. This key is encrypted by the public key of the server and sent across. The server decrypts the message with its private key. Now both sides have a session key known only to the two of them. All communication to and fro is encrypted and decrypted with the session key. An interesting link on SSL is http://www.rsasecurity.com/standards/ssl/basics.html <br /> <br /> ==Should I use 40-bit or 128-bit SSL? ==<br /> <br /> There are 2 strengths in SSL - 40-bit and 128-bit. These refer to the length of the secret key used for encrypting the session. This key is generated for every SSL session and is used to encrypt the rest of the session. The longer the key the more difficult it is to break the encrypted data. So, 128-bit encryption is much more secure than 40-bit. Most browsers today support 128-bit encryption. There are a few countries which have browsers with only 40-bit support. In case you are using 40-bit SSL, you may need to take further precautions to protect sensitive data. Salted hash for transmitting passwords is a good technique. This ensures that the password can not be stolen even if the SSL key is broken. <br /> <br /> ==Is 40-bit SSL really unsafe? ==<br /> <br /> 40-bit SSL is not really unsafe. It's just that it is computationally feasible to break the key used in 40-bit but not the key used in 128-bit. Even though 40-bit can be broken, it takes a fairly large number of computers to break it. Nobody would even attempt to do that for a credit card number or the like. But there are claims of breaking the 40-bit RC4 key in a few hours. So depending on the data your application deals with, you can decide on the SSL strength. Using 128-bit is definitely safer.<br /> <br /> With home computers gtting faster day by day, a dedicated, expensive and very fast computer can break 40-bit encryption in few minutes (ideally testing a million keys per second). On the other hand, 128-bit encryotion will have about 339,000,000,000,000,000,000,000,000,000,000,000 (Couple of Trillions or 2^128) possible key combinations and it will take around 1000 Years to break 128-bit encryptions with the help of a cluster of very fast computers.<br /> <br /> ==What all are encrypted when I use SSL? Is the page request also encrypted? ==<br /> <br /> After the initial SSL negotiation is done and the connection is on HTTPS, everything is encrypted including the page request. So any data sent in the query string will also be encrypted. <br /> <br /> ==Which cryptographic algorithms do SSL use? ==<br /> <br /> SSL supports a number of cryptographic algorithms. During the initial &quot;handshaking&quot; phase, it uses the RSA public key algorithm. For encrypting the data with the session key the following algorithms are used - RC2, RC4, IDEA, DES, triple-DES and MD5 message digest algorithm. <br /> <br /> ==I want to use SSL. Where do I begin? ==<br /> <br /> There are several Certificate Authorities that you can buy a SSL certificate from. Whichever CA you choose, the basic procedure will be as follows - <br /> <br /> * Create key pair for the server <br /> * Create the Certificate Signing Request. This will require you to provide certain details like location and fully qualified domain name of the server. <br /> * Submit the CSR to the CA along with documentary proof of identity. <br /> * Install the certificate sent by the CA<br /> The first two steps are done from the web server. All servers have these features. While installing the certificate issued by the CA, you will have to specify which web pages are to be on SSL.<br /> <br /> A good starting point for working on POC in a Windows development environment could be: &quot;HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000&quot; - http://support.microsoft.com/default.aspx?scid=kb;en-us;q307267&amp;sd=tech<br /> <br /> =Cookies and Session Management =<br /> <br /> ==Are there any risks in using persistent vs non-persistent cookies? ==<br /> <br /> Persistent cookies are data that a web site places on the user's hard drive (or equivalent) for maintaining information over more than one browser session. This data will stay in the user's system and can be accessed by the site the next time the user browses the site. Non-persistent cookies on the other hand are those that are used only in the browser session that creates it. They stay only in the memory of the machine and are not persisted on the hard disk. The security risk with persistent cookies is that they are generally stored in a text file on the client and an attacker with access to the victim's machine can steal this information. <br /> <br /> ==Can another web site steal the cookies that my site places on a user's machine? ==<br /> <br /> No, it is not possible for a website to access another site's cookies. Cookies have a domain attribute associated with them. Only a request coming from the domain specified in the attribute can access the cookie. This attribute can have only one value. <br /> <br /> ==Which is the best way to transmit session ids- in cookies, or URL or a hidden variable? ==<br /> <br /> Transmitting session IDs in the URL can lead to several risks. Shoulder surfers can see the session ID; if the URL gets cached on the client system, the session ID will also be stored; the session ID will get stored in the referrer logs of other sites. Hidden variables are not always practical as every request might not be a POST. Cookies are the safest method as cookies do not get cached, are not visible in the W3C or referrer logs, and most users anyway accept cookies. <br /> <br /> ==What are these secure cookies? ==<br /> <br /> A cookie can be marked as &quot;secure&quot; which ensures the cookie is used only over SSL sessions. If &quot;secure&quot; is not specified, the cookie will be sent unencrypted over non-SSL channels. Sensitive cookies like session tokens should be marked as secure if all pages in the web site requiring session tokens are SSL-enabled. One thing to keep in mind here is that images are generally not downloaded over SSL and they usually don't require a session token to be presented. By setting the session cookie to be secure, we ensure that the browser does not send the cookie while downloading the image over the non-SSL connection.&lt;&gt; <br /> <br /> ==If I use a session ID that is a function of the client's IP address, will session hijacking be prevented? ==<br /> <br /> An attacker can hijack another user's session by stealing the session token. Methods have been suggested to prevent the session from being hijacked even if the session token is stolen. For instance, using a session token that is a function of the user's IP address. In this approach, even if the attacker stole the token, he would need the same IP address as the user to successfully hijack a session. However, session hijacking can still be possible. Suppose the attacker is on the same LAN as the user and uses the same Proxy IP as the user to access the web site. The attacker can still steal the session if he is able to sniff the session token. It may also be not possible to implement this if the IP of the client changes during a session, making the session invalid if the token is tied to the initial IP address. This may happen if the client is coming from behind a bank of proxy servers. <br /> <br /> ==How about encrypting the session id cookies instead of using SSL? ==<br /> <br /> Encrypting just the session ID over a non-SSL connection will not serve any purpose. Since the session ID will be encrypted once and the same value will be sent back and forth each time, an attacker can use the encrypted value to hijack the session. <br /> <br /> ==What is the concept of using a page id, in addition to the session id? ==<br /> <br /> A Session ID or token has the lifetime of a session and is tied to the logged in user. A page ID or token has a lifetime of a page and is tied to a page that is served. It is a unique token given when a page is downloaded and is presented by the user when accessing the next page. The server expects a particular value for the user to access the next page. Only if the token submitted matches what the server is expecting is the next page served. An application can use this to ensure that a user accesses pages only in the sequence determined by the application. The user cannot paste a deep URL in the browser and skip pages just because he has a session token, as the page token would not be authorized to access the deeper URL directly. Good Read: [http://palisade.plynt.com/issues/2005Aug/page-tokens/ Secure your sessions with Page Tokens]<br /> <br /> =Logging and Audit Trails =<br /> <br /> ==What are these W3C logs? ==<br /> <br /> W3C is a logging format used for Web server log files. W3C logs record access details of each request: the timestamp, source IP, page requested, the method used, http protocol version, browser type, the referrer page, the response code etc. Note that these are access logs, and so a separate record is maintained for each request. When a page with multiple gif files is downloaded, it would be recorded as multiple entries in the W3C log; so, W3C logs tend to be voluminous. <br /> <br /> ==Do I need to have logging in my application even if I've W3C logs? ==<br /> <br /> Yes, it's important that your application maintains &quot;application level&quot; logs even when W3C logging is used. As W3C logs contain records for every http request, it is difficult (and, at times impossible) to extract a higher level meaning from these logs. For instance, the W3C logs are cumbersome to identify a specific session of user and the activities that the user performed. It's better that the application keeps a trail of important activities, rather than decode it from W3C logs. <br /> <br /> ==What should I log from within my application? ==<br /> <br /> Keep an audit trail of activity that you might want to review while troubleshooting or conducting forensic analysis. Please note that it is inadvisable to keep sensitive business information itself in these logs, as administrators have access to these logs for troubleshooting. Activities commonly kept track of are: <br /> <br /> * Login and logout of users <br /> * Critical transactions (eg. fund transfer across accounts) <br /> * Failed login attempts <br /> * Account lockouts <br /> * Violation of policies <br /> The data that is logged for each of these activities usually include: <br /> <br /> * User ID <br /> * Time stamp <br /> * Source IP <br /> * Error codes, if any <br /> * Priority <br /> ==Should I encrypt my logs? Isn't that a performance hit? ==<br /> <br /> Encryption is required when information has to be protected from being read by unauthorized users. Yes, encryption does take a performance hit, so if your logs do not contain sensitive information you might want to forego encryption. However, we strongly urge that you protect your logs from being tampered by using digital signatures. Digital signatures are less processor intensive than encryption and ensure that your logs are not tampered. <br /> <br /> ==Can I trust the IP address of a user I see in my audit logs? Could a user be spoofing/impersonating their IP address? ==<br /> <br /> A bad guy who wants to hide his actual IP address might use a service like anonymizer, or use open HTTP relays. [HTTP open relays are improperly configured web servers on the web that are used as a HTTP proxy to connect to other sites.] In such cases, the IP address you see in your log files will be those of these services or the open relay that is being used. So, the IP address you see in your log files might not always be trustworthy. <br /> <br /> =Miscellaneous =<br /> <br /> ==What are Buffer Overflows? ==<br /> <br /> Buffer overflow vulnerability affects the web applications that require user input. The application stores the input in a buffer which is of a fixed size, as defined by the programmer. When the input that is sent to the application is more than the buffer capacity and the buffers are left unchecked, buffer overflow occurs. The severity depends on the user input. If a malicious code executes as a result of the overflow, it can even compromise the whole system.<br /> To learn more, please read the OWASP article on [http://www.owasp.org/index.php/Buffer_Overflow buffer overflows.]<br /> <br /> ==What are application firewalls? How good are they really? ==<br /> <br /> Application firewalls analyze the requests at the application level. These firewalls are used for specific applications like a web server or a database server. The web application firewalls protect the web server from HTTP based attacks. They monitor the requests for attacks that involve SQL Injection, XSS, URL encoding etcetera. However, application layer firewalls cannot protect against attacks that require an understanding of the business context - this includes most attacks that rely on variable manipulation. Some application firewalls are: Netcontinuum's NC-1000 Kavado Inc.'s InterDo Teros Inc.'s Teros-100 APS<br /> <br /> ==What is all this about &quot;referrer logs&quot;, and sensitive URLs? ==<br /> <br /> The HTTP header contains a field known as Referrer. For visiting a web page we may either: <br /> <br /> * Type its URL directly into the address bar of the browser <br /> * Click a link on some other page that brings us there <br /> * Be redirected there by some page. <br /> In the first case, the referrer field will be empty but in the other two cases it will contain the URL of the previous page. The URL of the first page will get stored in the web server access logs of the second page when the user reaches the second page from the first page. Now suppose, the two pages belong to different sites and the first URL contains sensitive information like a user's session ID. If the second site belongs to attackers, they can obtain this information by just going through the logs. Information in the URLs will get stored in the referrer logs as well as the history of the browser. Therefore, we should be careful not to have any sensitive information in the URL. <br /> <br /> ==I want to use the most secure language; which language do you recommend? ==<br /> <br /> Any language can be used since secure programming practices are what make applications safe. Most security techniques can be implemented in any language. Our advice would be to use any language you are comfortable with. But some languages like Java have additional features like bind variables that aid security; you could use those additional features if you decide to program in that language. <br /> <br /> ==What are the good books to learn secure programming practices? ==<br /> <br /> The OWASP Guide to Building Secure Web Application and Web Services is a good guide for web application developers. You can download it from http://www.owasp.org/documentation/guide Writing Secure Code by Michael Howard and David LeBlanc has a chapter on Securing Web-Based Services. More information on this book can be found at: http://www.microsoft.com/mspress/books/toc/5612.asp Secure Programming for Linux and Unix HOWTO by David Wheeler talks about writing secure applications including web applications; it also specifies guidance for a number of languages. The book can be found at: http://www.dwheeler.com/secure-programs<br /> <br /> Another good book on application security, which also covers some web service specific topics: 19 Deadly Sins of Software Security, by: Michael Howard, David LeBlanc and John Viega (http://books.mcgraw-hill.com/getbook.php?isbn=0072260858).<br /> <br /> ==Are there any training programs on secure programming that I can attend? ==<br /> <br /> Microsoft offers training programs on Developing Security-Enhanced Web Applications and Developing and Deploying Secure Microsoft .NET Framework Application. More information can be found at http://www.microsoft.com/traincert/syllabi/2300AFinal.asp and http://www.microsoft.com/traincert/syllabi/2350BFinal.asp Foundstone offers secure coding training through Global Knowledge Aspect Security offers a similar course. <br /> <br /> OWASP_FAQ_Ver3.doc</div>

Webappsecguy https://wiki.owasp.org/index.php?title=OWASP_Application_Security_FAQ&diff=156407 2013-08-04T23:37:34Z

<p>Webappsecguy: updating specifically stale info</p> <hr /> <div>=Login Issues =<br /> <br /> ==What are the best practices I should remember while designing the login pages? ==<br /> <br /> * From the login page, the user should be sent to a page for authentication. Once authenticated, the user should be sent to the next page. This is explained in the answer to the next question. <br /> * The password should never be sent in clear text (unencrypted) because it can be stolen by sniffing; saving the password in clear text in the database is dangerous too. The best method of sending passwords is the Salted MD5 hashing technique and the passwords should be hashed and then stored in the database.<br /> * The best way to manage sessions would be to use one session token with two values during authentication. One value before authentication and one after.<br /> <br /> ==Is it really required to redirect the user to a new page after login? ==<br /> <br /> Is it really required to redirect the user to a new page after login? <br /> <br /> Yes. Consider the application has a login page that sends the username and password as a POST request to the server. If a user clicks refresh on the second page (the page after login), the same request including the username and password in the POST will be sent again. Now suppose a valid user browses through our application and logs out, but does not close the window. The attackers come along and click the back button of the browser till they reach the second page. They only have to do a refresh and since the username and password are resubmitted and revalidated, the attackers can login as the user. Now let's assume the application has a login page which takes the user to an intermediate page for authentication. Once authenticated, the user is redirected to the second page with a session token. In this case, even if the attackers reach the second page and do a refresh, the username and password will not be resubmitted. This is so because the request that will be submitted is the one for the second page which does not contain the username and password. Therefore, it is always better to redirect the user. <br /> <br /> ==How does the salted MD5 technique work? ==<br /> <br /> Here is how the salted MD5 technique works: the database stores a MD5 hash of the password. (MD5 hash is a cryptographic technique in which the actual value can never be recovered.) When a client requests for the login page, the server generates a random number, the salt, and sends it to the client along with the page. A JavaScript code on the client computes the MD5 hash of the password entered by the user. It then concatenates the salt to the hash and re-computes the MD5 hash. This result is then sent to the server. The server picks the hash of the password from its database, concatenates the salt and computes the MD5 hash. If the user entered the correct password these two hashes should match. The server compares the two and if they match, the user is authenticated. <br /> <br /> ==How can my &quot;Forgot Password&quot; feature be exploited? ==<br /> <br /> The Forgot Password feature is implemented in a number of different ways. One common way is to ask the user a hint question for which the user has submitted the answer during registration. These are questions like What is your favorite color? or What is your favorite pastime? If the answer is correct, either the original password is displayed or a temporary password is displayed which can be used to log in. In this method, an attacker trying to steal the password of a user may be able to guess the correct answer of the hint question and even reset the password. <br /> <br /> ==In &quot;Forgot Password&quot;, is it safe to display the old password? ==<br /> <br /> If the old password is displayed on the screen, it can be seen by shoulder surfers. So it is a good idea not to display the password and let the user change to a new one. Moreover, displaying the password means it has to be stored in a recoverable form in the database which is not a good practice. If the password is stored as a one way hash in the database, the only way Forgot Password can be implemented is by letting the user reset the old password. So, it is always better to force the users reset their passwords when they forget their passwords. (A one way hash is the result obtained when we pass a string to a one way hash function. The result is such that it is impossible to get back the original value from it. Passwords are best stored as non-recoverable hashes in the database.) <br /> <br /> ==Is there any risk in emailing the new password to the user's authorized mail id? ==<br /> <br /> Emailing the actual password in clear text can be risky as an attacker can obtain it by sniffing. Also the mail containing the password might have a long life time and could be viewed by an attacker while it is lying in the mailbox of the user.<br /> <br /> Apart form the above threats, a malicious user can do shoulder-surfing to view the password or login credentials.<br /> <br /> ==What is the most secure way to design the Forgot Password feature? ==<br /> <br /> We should first ask the user to supply some details like personal details or ask a hint question. Then we should send a mail to the users authorized mail id with a link which will take the user to a page for resetting the password. This link should be active for only a short time, and should be SSL- enabled. This way the actual password is never seen. The security benefits of this method are: the password is not sent in the mail; since the link is active for a short time, there is no harm even if the mail remains in the mailbox for a long time. <br /> <br /> ==How do I protect against automated password guessing attacks? ==<br /> <br /> Password guessing with automated tools is a serious problem since there are a number of tools available for this purpose. These tools essentially keep trying out different passwords till one matches. Locking out the account after 5 failed attempts is a good defense against these tools. However, the important point then is how long you lock out the account for. If it is for too long, service to valid users might be denied as the attackers repeatedly lock out your users. If the time is too short say about 1-2 minutes, the tool could start again after the timeout. So the best method would be to insist on human intervention after a few failed attempts. A method used by a number of sites these days is to have the user read and enter a random word that appears in an image on the page. Since this cannot be done by a tool, we can thwart automated password guessing. The following are some tools that guess passwords of web applications: Brutus - http://www.hoobie.net/brutus/ WebCracker http://www.securityfocus.com/tools/706<br /> <br /> ==How can I protect against keystroke loggers on the client machine? ==<br /> <br /> Keystroke loggers on the end users machines can sometimes ruin all our efforts of securely transmitting and storing the passwords. The users themselves may not be aware that a key logger has been installed on their machines and records each key pressed. Since the highest risk is with the password, if we can authenticate the users without having them use the keyboard, or reveal the entire password, we solve the problem. The different ways of doing this are: <br /> <br /> * Having a graphical keyboard where the users can enter the characters they want by clicking the mouse on it. This is especially useful for numeric PINs. <br /> * Asking the users to type a part of their password each time and not the whole password. For example you could say &quot;Please enter the 1st, 3rd and 6th letters of your password&quot; and this rule could be a random one each time. <br /> ==My site will be used from publicly shared computers. What precautions must I take? ==<br /> <br /> If your application will be accessed from publicly shared computers like libraries, you could take the following precautions: <br /> <br /> * You can make sure your pages do not get cached on the system by setting the correct cache control directives. <br /> * You could take care that no sensitive information is included in the URLs since the history of the client browser will store these. <br /> * Have a graphical keyboard for entering the password or ask the user to enter a different part of the password each time. This protects the password against keystroke loggers. <br /> * To prevent sniffing of passwords and replay attacks using those, you should either use SSL or salted MD5 for passwords. The clear text password in the memory should be reset after computing the MD5. <br /> =SQL Injection =<br /> <br /> ==What is SQL Injection? ==<br /> <br /> SQL Injection is a technique by which attackers can execute SQL statements of their choice on the backend database by manipulating the input to the application. Let's understand SQL Injection through the example of a login page in a web application where the database is SQL Server. The user needs to input Username and Password in the text boxes in Login.asp page. Suppose the user enters the following: Username : Obelix and Password : Dogmatix This input is then used to build a query dynamically which would be something like: SELECT * FROM Users WHERE username= 'Obelix' and password='Dogmatix' This query would return to the application a row from the database with the given values. The user is considered authenticated if the database returns one or more rows to the application. Now, suppose an attacker enters the following input in the login page: Username : ' or 1=1-- The query built will look like this: SELECT * FROM Users WHERE username='' or 1=1-- and password='' -- in SQL Server is used to comment out the rest of the line. So, our query is now effectively: SELECT * FROM Users WHERE username='' or 1=1 This query will look in the database for a row where either username is blank or the condition 1=1 is met. Since the latter always evaluates to true, the query will return all rows of the Users table and the user is authenticated. The attacker has been successful in logging into the application without a username and password. You can read more on this at the Securiteam site: http://www.securiteam.com/securityreviews/5DP0N1P76E.html <br /> <br /> ==Is it just ASP and SQL Server or are all platforms vulnerable? ==<br /> <br /> Almost all platforms are vulnerable to SQL Injection. Inadequate checking of user input and the use of dynamic SQL queries are what make an application vulnerable to these attacks. The syntax of the input entered for SQL Injection will depend on the database being used. During our application security audits we have found many applications using other databases to be vulnerable. The above example would work on SQL Server, Oracle and MySQL. This shows that the problem is with the inadequate checking of user input and the use of dynamic SQL and not the underlying database. <br /> <br /> ==Apart from username and password which variables are candidates for SQL Injection? ==<br /> <br /> Any input field that makes up the where clause of a database query is a candidate for SQL Injection, eg. account numbers, and credit card numbers in the case of an online banking application. In addition to form fields, an attacker can use hidden fields and query strings also for injecting commands.<br /> <br /> Apart from input fields, URL parameters are also vulnerable to SQL Injection as well as other input based attacks.<br /> <br /> ==How do we prevent SQL Injection in our applications? ==<br /> <br /> It is quite simple to prevent SQL injection while developing the application. You need to check all input coming from the client before building a SQL query. The best method is to remove all unwanted input and accept only expected input. While server side input validation is the most effective method of preventing SQL Injection, the other method of prevention is not using dynamic SQL queries. This can be achieved by using stored procedures or bind variables in databases that support these features. For applications written in Java, CallableStatements and PreparedStatements can be used. For ASP applications, ADO Command Objects can be used. You can check the following article for more on SQL Injection in Oracle: http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf <br /> <br /> ==I'm using stored procedures for authentication, am I vulnerable? ==<br /> <br /> Maybe, but probably no. Using stored procedures can prevent SQL Injection because the user input is no longer used to build the query dynamically. Since a stored procedure is a group of precompiled SQL statements and the procedure accepts input as parameters, a dynamic query is avoided. Although input is put into the precompiled query as is, since the query itself is in a different format, it does not have the effect of changing the query as expected. By using stored procedures we are letting the database handle the execution of the query instead of asking it to execute a query we have built. The exception to this is where the stored procedure takes a string as input and uses this string to build the query without validating it. While this is more difficult to exploit, this scenario still often leads to successful SQL Injection. This article explains how SQL Injection affects stored procedures in more detail: http://palisade.plynt.com/issues/2006Jun/injection-stored-procedures/<br /> <br /> ==I'm using client side JavaScript code for checking user input. Isn't that enough? ==<br /> <br /> No. Although client side checking disallows the attacker to enter malicious data directly into the input fields, that alone is not enough to prevent SQL Injection. Client side scripts only check for input in the browser. But this does not guarantee that the information will remain the same till it reaches the server. To bypass client side JavaScript, the attacker can trap the request in a proxy (eg. WebScarab, [http://www.parosproxy.org Paros]) after it leaves the browser and before it reaches the server and there he can alter input fields. The attacker can also inject commands into the querystring variables which are not checked by the client side scripts, or could disable JavaScript rendering client-side scripting useless.<br /> <br /> ==Are Java servlets vulnerable to SQL injection? ==<br /> <br /> Yes, they are if the user input is not checked properly, and if they build SQL queries dynamically. But Java servlets also have certain features that prevent SQL Injection like CallableStatements and PreparedStatements. Like stored procedures and bind variables, they avoid the need of dynamic SQL statements.<br /> <br /> ==Can an automated scanner discover SQL Injection? ==<br /> <br /> Sometimes yes, sometimes no. Whether a scanner can discover SQL injection or not depends on a variety of factors: the discovery technique used, the response from the application when a malformed SQL snippet is added, and some luck. Specifically, scanners that use Blind SQL Injection are most likely to detect SQL Injection. Scanners that claim hundreds of test cases for SQL Injection are misleading. This entry from the [http://www.plynt.com/resources/learn/tools/do_scanners_catch_sql_injectio_1/ Penetration Testing Learning Center] explains this in detail.<br /> <br /> =Variable Manipulation =<br /> <br /> ==Why can't I trust the information coming from the browser? ==<br /> <br /> There are chances that the information is modified before it reaches the server. Attackers browsing the site can manipulate the information in a GET or POST request. There are a number of HTTP/HTTPS proxy tools like [http://www.mavensecurity.com/achilles Achilles], Paros, WebScarab, etc which are capable of intercepting all this information and allow the attacker running the tool to modify it. Also, the information that the user sees or provides on a web page has to travel through the internet before it reaches the server. Although the client and the server may be trusted, we cannot be sure that the information is not modified after it leaves the browser. Attackers can capture the information on the way and manipulate it.<br /> <br /> ==What information can be manipulated by the attacker? ==<br /> <br /> Manipulating the variables in the URL is simple. But attackers can also manipulate almost all information going from the client to the server like form fields, hidden fields, content-length, session-id and http methods.<br /> <br /> ==How do attackers manipulate the information? What tools do they use? ==<br /> <br /> For manipulating any information, including form fields, hidden variables and cookies, attackers use tools known as HTTP/HTTPS proxy tools. Once the browser's proxy settings are configured to go through the HTTP/HTTPS proxy, the tool can see all information flowing between the client and the server; it even allows the attacker to modify any part of the request before sending it. Some such tools are: WebScarab can be downloaded from the OWASP site. Odysseus can be found at http://www.bindshell.net/tools/odysseus Paros can be downloaded from http://www.parosproxy.org<br /> <br /> ==I'm using SSL. Can attackers still modify information? ==<br /> <br /> Although SSL provides a lot of security, SSL alone is not enough to prevent variable manipulation attacks. SSL was supposed to prevent against Man in the Middle attacks but it is vulnerable to it. To successfully carry out the MITM attack, first the attacker has to divert the victim's requests to his machine i.e. redirecting the packets meant for the server to himself. He can do this by ARP poisoning / DNS Cache poisoning. Once he is able to redirect, he can see all the requests the victim is trying to make. Now when the victim tries to establish an SSL connection with a legitimate server, he gets connected to the attacker. The attacker, during the SSL Handshaking, provides a fake certificate to the victim, which the victim accepts even though the browser warns him. Thus, the victim establishes an SSL connection with the attacker instead of the server. The attacker establishes a different SSL connection with that legitimate server, which the victim was trying to connect. Now all data flow between the victim and the server will be routed through the attacker and the attacker can see all data the victim (as well as the server) sends. This is because the victim will encrypt all data with the attacker's public key, which the attacker can decrypt with his private key. The attacker can then manipulate all data that is passing through his machine.<br /> <br /> ==Is there some way to prevent these proxy tools from editing the data? ==<br /> <br /> The main threat these proxy tools pose is editing the information sent from the client to the server. One way to prevent it is to sign the message sent from the client with a Java Applet downloaded onto the client machine. Since the applet we developed will be the one validating the certificate and not the browser, a proxy tool will not be able to get in between the client and the server with a fake certificate. The applet will reject the fake certificate. The public key of this certificate can then be used to digitally sign each message sent between the client and the server. An attacker would then have to replace the embedded certificate in the applet with a fake certificate to succeed - that raises the barrier for the attacker. <br /> <br /> =Browser Cache =<br /> <br /> ==How can the browser cache be used in attacks? ==<br /> <br /> The browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder, like the Temporary Internet Files folder in the case of Internet Explorer. When we ask for these pages again, the browser displays them from its cache. This is much faster than downloading the page from the server. Let's consider the particular scenario where a user has logged in to an application with username and password. The user browses the different pages which contain sensitive information. Let's suppose a page with the user's credit card information gets cached in the browser and the user logs out of the application. Now suppose the attackers access the same machine and searches through the Temporary Internet Files, they will get the credit card details. The attackers do not need to know the username and password of the user to steal the information. <br /> <br /> ==How do I ensure that sensitive pages are not cached on the user's browser? ==<br /> <br /> The response header sent from the server has some cache control directives that can be set from your code. These directives control the caching of content on any cache. The directives to be set are Cache-Control : no-cache or Cache-Control : no-store. But since legacy HTTP 1.0 servers do not support the Cache-Control headers, HTTP Pragma: no-cache header can be used. However, pragma no-cache can prevent caching only if it is used for ssl page. For a non-ssl page, it is eqivalent to 'Expires = -1'.<br /> <br /> ==What is the best way to implement Pragma: No-cache? ==<br /> <br /> Pragma: No-cache directive is used in the meta tag in the header, which is normally at the beginning of an HTML webpage. When an HTML code is parsed (in a top-to-bottom approach), the browser looks for the presence of the page in the cache as soon as it reads the Pragma directive. But since at that moment the page has not been cached (a webpage gets cached only after it has filled at least 32kb of the buffer), the browser will not clear the cache and it will go ahead with parsing the rest of the code. As a result, all the contents of webpage that are loaded after the parsing of Pragma get cached. The best way to implement Pragma: No-cahce is to place another header just before the html code ends. This way, the browser will parse the pragma no-cache directive after the comlete page has been loaded.<br /> <br /> ==What's the difference between the cache-control directives: no-cache, and no-store? ==<br /> <br /> The no-cache directive in a response indicates that the response must not be used to serve a subsequent request i.e. the cache must not display a response that has this directive set in the header but must let the server serve the request. The no-cache directive can include some field names; in which case the response can be shown from the cache except for the field names specified which should be served from the server. The no-store directive applies to the entire message and indicates that the cache must not store any part of the response or any request that asked for it. <br /> <br /> ==Am I totally safe with these directives? ==<br /> <br /> No. But generally, use both Cache-Control: no-cache, no-store and Pragma: no-cache, in addition to Expires: 0 (or a sufficiently backdated GMT date such as the UNIX epoch). Non-html content types like pdf, word documents, excel spreadsheets, etc often get cached even when the above cache control directives are set (although this varies by version and additional use of must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0 in practice can affect outcomes upon browser closure in some cases due to browser quirks and HTTP implementations). Also, 'Autocomplete' feature allows a browser to cache whatever the user types in an input field of a form. To check this, the form tag or the individual input tags should include 'Autocomplete=&quot;Off&quot; ' attribute. However, it should be noted that this attribute is non-standard (although it is supported by the major browsers) so it will break XHTML validation.<br /> <br /> ==Where can I learn more about caching? ==<br /> <br /> Some useful links that talk about caching are - Caching Tutorial for Web Authors and Webmasters by Mark Nottingham at http://www.mnot.net/cache_docs/ and HTTP RFC (sec14.9.1) at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html<br /> <br /> =Cross Site Scripting =<br /> <br /> ==What is Cross Site Scripting? ==<br /> <br /> Cross Site scripting (XSS) is a type of attack that can be carried out to steal sensitive information belonging to the users of a web site. This relies on the server reflecting back user input without checking for embedded javascript. This can be used to steal cookies and session IDs. Let's see how it works. We would all have come across the following situation sometime - we type a URL in the browser, say www.abcd.com/mypage.asp, and receive an error page that says &quot;Sorry www.abcd.com/mypage.asp does not exist&quot; or a page with a similar message. In other words, pages that display the user input back on the browser. Pages like this could be exploited using XSS. Instead of a normal input, think what will happen if the input contains a script in it. While reflecting back the input, instead of rendering it as normal HTML output, the browser treats it as a script and executes it. This script could contain some malicious code. The attackers can send a link that contains a script as part of the URL to a user. When the user clicks it, the script gets executed on the user's browser. This script may have been written to collect important information about the user and send it to the attacker. Kevin Spett's paper Cross Site Scripting, Are your web applications vulnerable? is a good source of information on this topic and is available at http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf The Cross Site Scripting FAQ at CGI Security is another good place to learn more on XSS. <br /> <br /> ==What information can an attacker steal using XSS? ==<br /> <br /> The attackers can steal the session ID of a valid user using XSS. The session ID is very valuable because it is the secret token that the user presents after login as proof of identity until logout. If the session ID is stored in a cookie, the attackers can write a script which will run on the user's browser, query the value in the cookie and send it to the attackers. The attackers can then use the valid session ID to browse the site without logging in. The script could also collect other information from the page, including the entire contents of the page. <br /> <br /> ==Apart from mailing links of error pages, are there other methods of exploiting XSS? ==<br /> <br /> Yes, there are other methods. Let's take the example of a bulletin board application that has a page where data entered by one user can be viewed by other users. The attackers enter a script into this page. When a valid user tries to view the page, the script gets executed on the user's browser. It will send the user's information to the attackers. <br /> <br /> ==How can I prevent XSS? ==<br /> <br /> XSS can be prevented while coding the application. You should be validating all input and output to and from the application and escape all special characters that may be used in a script. If the code replaces the special characters by the following before displaying the output, XSS can be prevented to some extent.<br /> <br /> <br /> <br /> &lt; &amp;lt;<br /> <br /> &gt; &amp;gt; <br /> <br /> ( &amp;*40; <br /> <br /> ) &amp;*41; <br /> <br /> * &amp;*35; <br /> &amp; &amp;*38;<br /> <br /> <br /> <br /> Gunter Ollmann has written an excellent paper on the use of special characters in XSS attacks. For instance, the above technique of escaping special characters cannot protect against a script injected like &quot;javascript:self.location.href = 'www.evil.org' &quot; as this script does not use any of the special characters.<br /> <br /> ==Can XSS be prevented without modifying the source code? ==<br /> <br /> There is a method that requires minimal coding as compared to performing input, output validation to prevent the stealing of cookies by XSS. Internet Explorer 6 has an attribute called HTTP Only that can be set for cookies. Using this attribute makes sure that the cookie can not be accessed by any scripts. More details are available at the MSDN site on httpcookies at http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/httponly_cookies.asp Mozilla also has plans to implement a similar feature. Researchers have found a method to beat this. It is known as Cross Site Tracing. <br /> <br /> ==What is Cross Site Tracing (XST)? How can it be prevented? ==<br /> <br /> Attackers are able to bypass the HTTP Only attribute to steal cookie information by Cross Site tracing (XST). TRACE is a HTTP method that can be sent to the server. The server sends back anything included in the TRACE request back to the browser. In a site that uses cookies, the cookie information is sent to the server in each request. If we send a TRACE request in a URL of such a site, the server will send back all cookie information to the browser. Now imagine a situation similar to the one described in XSS but the site in this case is using the HTTP Only cookies. The attackers make a valid user click on a link that contains a script that calls the TRACE method. When the user clicks on the link the TRACE request as well as all the cookie information is sent to the server. The server then sends back the cookie information back to the script in the browser. Suppose that the malicious script also contains code to send this information to the attackers. The attackers have succeeded again in stealing the cookies although HTTP Only Cookies were used. To summarize, HTTP Only cookies prevent the JavaScript from directly accessing the cookies but the attacker was able to retrieve it through an indirect method. XST can be prevented by disabling the TRACE method on the web server. This paper by Jeremiah Grossman discusses XST in greater detail http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf <br /> <br /> =Web Server Fingerprinting =<br /> <br /> ==How do attackers identify which web server I'm using? ==<br /> <br /> Identifying the application running on a remote web server is known as fingerprinting the server. The simplest way to do this is to send a request to the server and see the banner sent in the response. Banners will generally have the server name and the version number in it. We can address this problem by either configuring the server not to display the banner at all or by changing it to make the server look like something else.<br /> <br /> ==How can I fake the banners or rewrite the headers from my web server? ==<br /> <br /> There are a number of tools that help in faking the banners. URLScan is a tool that can change the banner of an IIS web server. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/URLScan.asp mod_security has a feature for changing the identity of the Apache web server. It can be found at http://www.modsecurity.org/ Servermask for faking banners of IIS, can be found at http://www.servermask.com/ <br /> <br /> ==Once I fake the banners, can my web server still be fingerprinted? ==<br /> <br /> Yes. Unfortunately there are tools that fingerprint the web server without relying on the banners. Different web servers may implement features not specified in HTTP RFCs differently. Suppose we make a database of these special requests and the responses of each web server. We can now send these requests to the web server we want to fingerprint and compare the responses with the database. This is the technique used by tools like Fire &amp; Water. This tool can be found at http://www.ntobjectives.com/products/firewater/ There is a paper by Saumil Shah that discusses the tool httprint at http://net-square.com/httprint/httprint_paper.html httprint can be found at http://net-square.com/httprint/ <br /> <br /> ==A friend told me it's safer to run my web server on a non-standard port. Is that right? ==<br /> <br /> A web server generally needs to be accessed by a lot of people on the internet. Since it normally runs on port 80 and all browsers are configured to access port 80 of the web server, users are able to browse the site. If we change the port, the users will have to specify the port in addition to the domain name. But this is a good idea for an intranet application where all users know where to connect. It is more secure since the web server will not be targeted by automated attacks like worms that scan port 80 and other standard ports. <br /> <br /> ==Should I really be concerned that my web server can be fingerprinted? ==<br /> <br /> Well, there are two schools of thought here. According to the first school, yes you should take precaution against fingerprinting as correctly identiying the web server maybe the first step in a more dangerous attack. Once attackers have found out that the web server is say IIS 5, they will search for known vulnerabilities for IIS 5. If the web server is not patched for all known vulnerabilities or the attackers find one for which a patch has not been released yet, there is nothing to stop them from attacking it. Also automated tools and worms can be fooled by changing the version information. Some determined and focused attackers might go to additional lengths to identify the server but the hurdles that the attackers have to overcome have increased when it's more difficult to fingerprint the web server name and version. Jeremiah Grossman pointed out the other school of thought. Evasive measures are futile as any scanner targeting a web site, will normally not care what the web server is. The scanner will run ALL its tests no matter if they apply to the system or not. This is a typical shotgun approach. A bad guy targeting the site might be hampered by not knowing the exact version, but if he's determined he would still try out all related exploits and try to break in. <br /> <br /> =Testing =<br /> <br /> ==I want to chain my proxy tool with a proxy server; are there tools that let me do that? ==<br /> <br /> Yes, there are several tools that allow proxy chaining. Some of these are: WebScarab - http://www.owasp.org/development/webscarab Exodus - http://home.intekom.com/rdawes/exodus.html Odysseus - http://www.wastelands.gen.nz/odysseus/index.php <br /> <br /> ==Can't web application testing be automated? Are there any tools for that? ==<br /> <br /> There are tools that scan applications for security flaws. But these tools can only look for a limited number of vulnerabilities, and do not find all the problems in the application. Moreover, a lot of attacks require understanding of the business context of the application to decide on the variables to manipulate in a particular request, which a tool is incapable of doing. A presentation by Jeremiah Grossman of White Hat Security which talks about the [http://www.blackhat.com/presentations/bh-federal-03/bh-fed-03-grossman-up.pdf limitations of automated scanning]. <br /> <br /> This piece explains [http://www.plynt.com/resources/learn/tools/what_cant_a_scanner_find_1/ what a scanner can't find].<br /> <br /> In our tests using a slightly modified WebGoat the best Black-box scanning tool found less than 20% of the issues ! Some tools for automated scanning are: SpikeProxy, open source and freely available at http://www.immunitysec.com/spikeproxy.html WebInspect, can be found at http://www.spidynamics.com/productline/WE_over.html<br /> <br /> ==Where can I try out my testing skills? Is there a sample application I can practice with? ==<br /> <br /> OWASP provides a sample application that can be used for this purpose called . As the site says, the WebGoat project's goal is to teach web security in an interactive teaching environment. There are lessons on most of the common vulnerabilities. Another interesting site is Hackingzone which has a game on SQL Injection at http://www.hackingzone.org/sql/index.php <br /> <br /> ==Are there source code scanning tools for .NET languages, Java, PHP etc that predict vulnerabilities in the source code? ==<br /> <br /> Rough Auditing Tool for Security (RATS) is a tool that scans the source code for security flaws in C, C++, Python, Perl and PHP programs. It can be found at http://code.google.com/p/rough-auditing-tool-for-security/downloads/list FX Cop was created by the Microsoft Team at the GotDotNet community site to check for the .NET Frameowork guidelines which include security. Prexis is a commercial source code and run-time analyzer. Flawfinder is a static source code analyzer. Compaq ESC is a run-time analyzer for Java. Parasoft AEP is a commercial source code analyzer for Java. Fortify SCA from Fortify Software is another source code analyzer that supports mixed language analysis of C, C++, C#, ASP.NET, Java, JSP, PL/SQL, VB.NET, XML, etc. Secure Coding plugins are also available. Similar source code analyzers are Klocwork K7 for C, C++ and Java; Coverity Prevent for detecting security violations and defects in code; Ounce Solutions for C, C++, C#, ASP.NET, Java and JSP. We would like to know about more tools for scanning source code. If you know about any, please inform us and we'll add to this FAQ<br /> <br /> ==Can non-HTTP protocols also be intercepted and played with like this? ==<br /> <br /> Yes, Interactive TCP Replay is a tool that acts as a proxy for non-HTTP applications and also allows modifying the traffic. It allows editing of the messages in a hex editor. ITR also logs all the messages passing between the client and the server. It can use different types of character encoding like ASCII or EBCDIC for editing and logging. More information on this can be found at http://www.webcohort.com/web_application_security/research/tools.html <br /> <br /> =Cryptography/SSL =<br /> <br /> ==What is SSL? ==<br /> <br /> Secure Socket Layer (SSL) gives us assurance of two things. Firstly when a client connects to a web server, the client can be sure that it is talking to the right server by checking the certificate the server sends it. Secondly, SSL assures you of the confidentiality of the data, as the client and the server exchange encrypted messages that cannot be understood by anybody else. This is how SSL works: When the client requests for a SSL page, the server sends a certificate that it has obtained from a trusted certificate authority. This certificate contains the public key of the server. After satisfying itself that the certificate is correct and the server is a genuine one, the client generates one random number, the session key. This key is encrypted by the public key of the server and sent across. The server decrypts the message with its private key. Now both sides have a session key known only to the two of them. All communication to and fro is encrypted and decrypted with the session key. An interesting link on SSL is http://www.rsasecurity.com/standards/ssl/basics.html <br /> <br /> ==Should I use 40-bit or 128-bit SSL? ==<br /> <br /> There are 2 strengths in SSL - 40-bit and 128-bit. These refer to the length of the secret key used for encrypting the session. This key is generated for every SSL session and is used to encrypt the rest of the session. The longer the key the more difficult it is to break the encrypted data. So, 128-bit encryption is much more secure than 40-bit. Most browsers today support 128-bit encryption. There are a few countries which have browsers with only 40-bit support. In case you are using 40-bit SSL, you may need to take further precautions to protect sensitive data. Salted hash for transmitting passwords is a good technique. This ensures that the password can not be stolen even if the SSL key is broken. <br /> <br /> ==Is 40-bit SSL really unsafe? ==<br /> <br /> 40-bit SSL is not really unsafe. It's just that it is computationally feasible to break the key used in 40-bit but not the key used in 128-bit. Even though 40-bit can be broken, it takes a fairly large number of computers to break it. Nobody would even attempt to do that for a credit card number or the like. But there are claims of breaking the 40-bit RC4 key in a few hours. So depending on the data your application deals with, you can decide on the SSL strength. Using 128-bit is definitely safer.<br /> <br /> With home computers gtting faster day by day, a dedicated, expensive and very fast computer can break 40-bit encryption in few minutes (ideally testing a million keys per second). On the other hand, 128-bit encryotion will have about 339,000,000,000,000,000,000,000,000,000,000,000 (Couple of Trillions or 2^128) possible key combinations and it will take around 1000 Years to break 128-bit encryptions with the help of a cluster of very fast computers.<br /> <br /> ==What all are encrypted when I use SSL? Is the page request also encrypted? ==<br /> <br /> After the initial SSL negotiation is done and the connection is on HTTPS, everything is encrypted including the page request. So any data sent in the query string will also be encrypted. <br /> <br /> ==Which cryptographic algorithms do SSL use? ==<br /> <br /> SSL supports a number of cryptographic algorithms. During the initial &quot;handshaking&quot; phase, it uses the RSA public key algorithm. For encrypting the data with the session key the following algorithms are used - RC2, RC4, IDEA, DES, triple-DES and MD5 message digest algorithm. <br /> <br /> ==I want to use SSL. Where do I begin? ==<br /> <br /> There are several Certificate Authorities that you can buy a SSL certificate from. Whichever CA you choose, the basic procedure will be as follows - <br /> <br /> * Create key pair for the server <br /> * Create the Certificate Signing Request. This will require you to provide certain details like location and fully qualified domain name of the server. <br /> * Submit the CSR to the CA along with documentary proof of identity. <br /> * Install the certificate sent by the CA<br /> The first two steps are done from the web server. All servers have these features. While installing the certificate issued by the CA, you will have to specify which web pages are to be on SSL.<br /> <br /> A good starting point for working on POC in a Windows development environment could be: &quot;HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000&quot; - http://support.microsoft.com/default.aspx?scid=kb;en-us;q307267&amp;sd=tech<br /> <br /> =Cookies and Session Management =<br /> <br /> ==Are there any risks in using persistent vs non-persistent cookies? ==<br /> <br /> Persistent cookies are data that a web site places on the user's hard drive (or equivalent) for maintaining information over more than one browser session. This data will stay in the user's system and can be accessed by the site the next time the user browses the site. Non-persistent cookies on the other hand are those that are used only in the browser session that creates it. They stay only in the memory of the machine and are not persisted on the hard disk. The security risk with persistent cookies is that they are generally stored in a text file on the client and an attacker with access to the victim's machine can steal this information. <br /> <br /> ==Can another web site steal the cookies that my site places on a user's machine? ==<br /> <br /> No, it is not possible for a website to access another site's cookies. Cookies have a domain attribute associated with them. Only a request coming from the domain specified in the attribute can access the cookie. This attribute can have only one value. <br /> <br /> ==Which is the best way to transmit session ids- in cookies, or URL or a hidden variable? ==<br /> <br /> Transmitting session IDs in the URL can lead to several risks. Shoulder surfers can see the session ID; if the URL gets cached on the client system, the session ID will also be stored; the session ID will get stored in the referrer logs of other sites. Hidden variables are not always practical as every request might not be a POST. Cookies are the safest method as cookies do not get cached, are not visible in the W3C or referrer logs, and most users anyway accept cookies. <br /> <br /> ==What are these secure cookies? ==<br /> <br /> A cookie can be marked as &quot;secure&quot; which ensures the cookie is used only over SSL sessions. If &quot;secure&quot; is not specified, the cookie will be sent unencrypted over non-SSL channels. Sensitive cookies like session tokens should be marked as secure if all pages in the web site requiring session tokens are SSL-enabled. One thing to keep in mind here is that images are generally not downloaded over SSL and they usually don't require a session token to be presented. By setting the session cookie to be secure, we ensure that the browser does not send the cookie while downloading the image over the non-SSL connection.&lt;&gt; <br /> <br /> ==If I use a session ID that is a function of the client's IP address, will session hijacking be prevented? ==<br /> <br /> An attacker can hijack another user's session by stealing the session token. Methods have been suggested to prevent the session from being hijacked even if the session token is stolen. For instance, using a session token that is a function of the user's IP address. In this approach, even if the attacker stole the token, he would need the same IP address as the user to successfully hijack a session. However, session hijacking can still be possible. Suppose the attacker is on the same LAN as the user and uses the same Proxy IP as the user to access the web site. The attacker can still steal the session if he is able to sniff the session token. It may also be not possible to implement this if the IP of the client changes during a session, making the session invalid if the token is tied to the initial IP address. This may happen if the client is coming from behind a bank of proxy servers. <br /> <br /> ==How about encrypting the session id cookies instead of using SSL? ==<br /> <br /> Encrypting just the session ID over a non-SSL connection will not serve any purpose. Since the session ID will be encrypted once and the same value will be sent back and forth each time, an attacker can use the encrypted value to hijack the session. <br /> <br /> ==What is the concept of using a page id, in addition to the session id? ==<br /> <br /> A Session ID or token has the lifetime of a session and is tied to the logged in user. A page ID or token has a lifetime of a page and is tied to a page that is served. It is a unique token given when a page is downloaded and is presented by the user when accessing the next page. The server expects a particular value for the user to access the next page. Only if the token submitted matches what the server is expecting is the next page served. An application can use this to ensure that a user accesses pages only in the sequence determined by the application. The user cannot paste a deep URL in the browser and skip pages just because he has a session token, as the page token would not be authorized to access the deeper URL directly. Good Read: [http://palisade.plynt.com/issues/2005Aug/page-tokens/ Secure your sessions with Page Tokens]<br /> <br /> =Logging and Audit Trails =<br /> <br /> ==What are these W3C logs? ==<br /> <br /> W3C is a logging format used for Web server log files. W3C logs record access details of each request: the timestamp, source IP, page requested, the method used, http protocol version, browser type, the referrer page, the response code etc. Note that these are access logs, and so a separate record is maintained for each request. When a page with multiple gif files is downloaded, it would be recorded as multiple entries in the W3C log; so, W3C logs tend to be voluminous. <br /> <br /> ==Do I need to have logging in my application even if I've W3C logs? ==<br /> <br /> Yes, it's important that your application maintains &quot;application level&quot; logs even when W3C logging is used. As W3C logs contain records for every http request, it is difficult (and, at times impossible) to extract a higher level meaning from these logs. For instance, the W3C logs are cumbersome to identify a specific session of user and the activities that the user performed. It's better that the application keeps a trail of important activities, rather than decode it from W3C logs. <br /> <br /> ==What should I log from within my application? ==<br /> <br /> Keep an audit trail of activity that you might want to review while troubleshooting or conducting forensic analysis. Please note that it is inadvisable to keep sensitive business information itself in these logs, as administrators have access to these logs for troubleshooting. Activities commonly kept track of are: <br /> <br /> * Login and logout of users <br /> * Critical transactions (eg. fund transfer across accounts) <br /> * Failed login attempts <br /> * Account lockouts <br /> * Violation of policies <br /> The data that is logged for each of these activities usually include: <br /> <br /> * User ID <br /> * Time stamp <br /> * Source IP <br /> * Error codes, if any <br /> * Priority <br /> ==Should I encrypt my logs? Isn't that a performance hit? ==<br /> <br /> Encryption is required when information has to be protected from being read by unauthorized users. Yes, encryption does take a performance hit, so if your logs do not contain sensitive information you might want to forego encryption. However, we strongly urge that you protect your logs from being tampered by using digital signatures. Digital signatures are less processor intensive than encryption and ensure that your logs are not tampered. <br /> <br /> ==Can I trust the IP address of a user I see in my audit logs? Could a user be spoofing/impersonating their IP address? ==<br /> <br /> A bad guy who wants to hide his actual IP address might use a service like anonymizer, or use open HTTP relays. [HTTP open relays are improperly configured web servers on the web that are used as a HTTP proxy to connect to other sites.] In such cases, the IP address you see in your log files will be those of these services or the open relay that is being used. So, the IP address you see in your log files might not always be trustworthy. <br /> <br /> =Miscellaneous =<br /> <br /> ==What are Buffer Overflows? ==<br /> <br /> Buffer overflow vulnerability affects the web applications that require user input. The application stores the input in a buffer which is of a fixed size, as defined by the programmer. When the input that is sent to the application is more than the buffer capacity and the buffers are left unchecked, buffer overflow occurs. The severity depends on the user input. If a malicious code executes as a result of the overflow, it can even compromise the whole system.<br /> To learn more, please read the OWASP article on [http://www.owasp.org/index.php/Buffer_Overflow buffer overflows.]<br /> <br /> ==What are application firewalls? How good are they really? ==<br /> <br /> Application firewalls analyze the requests at the application level. These firewalls are used for specific applications like a web server or a database server. The web application firewalls protect the web server from HTTP based attacks. They monitor the requests for attacks that involve SQL Injection, XSS, URL encoding etcetera. However, application layer firewalls cannot protect against attacks that require an understanding of the business context - this includes most attacks that rely on variable manipulation. Some application firewalls are: Netcontinuum's NC-1000 Kavado Inc.'s InterDo Teros Inc.'s Teros-100 APS<br /> <br /> ==What is all this about &quot;referrer logs&quot;, and sensitive URLs? ==<br /> <br /> The HTTP header contains a field known as Referrer. For visiting a web page we may either: <br /> <br /> * Type its URL directly into the address bar of the browser <br /> * Click a link on some other page that brings us there <br /> * Be redirected there by some page. <br /> In the first case, the referrer field will be empty but in the other two cases it will contain the URL of the previous page. The URL of the first page will get stored in the web server access logs of the second page when the user reaches the second page from the first page. Now suppose, the two pages belong to different sites and the first URL contains sensitive information like a user's session ID. If the second site belongs to attackers, they can obtain this information by just going through the logs. Information in the URLs will get stored in the referrer logs as well as the history of the browser. Therefore, we should be careful not to have any sensitive information in the URL. <br /> <br /> ==I want to use the most secure language; which language do you recommend? ==<br /> <br /> Any language can be used since secure programming practices are what make applications safe. Most security techniques can be implemented in any language. Our advice would be to use any language you are comfortable with. But some languages like Java have additional features like bind variables that aid security; you could use those additional features if you decide to program in that language. <br /> <br /> ==What are the good books to learn secure programming practices? ==<br /> <br /> The OWASP Guide to Building Secure Web Application and Web Services is a good guide for web application developers. You can download it from http://www.owasp.org/documentation/guide Writing Secure Code by Michael Howard and David LeBlanc has a chapter on Securing Web-Based Services. More information on this book can be found at: http://www.microsoft.com/mspress/books/toc/5612.asp Secure Programming for Linux and Unix HOWTO by David Wheeler talks about writing secure applications including web applications; it also specifies guidance for a number of languages. The book can be found at: http://www.dwheeler.com/secure-programs<br /> <br /> Another good book on application security, which also covers some web service specific topics: 19 Deadly Sins of Software Security, by: Michael Howard, David LeBlanc and John Viega (http://books.mcgraw-hill.com/getbook.php?isbn=0072260858).<br /> <br /> ==Are there any training programs on secure programming that I can attend? ==<br /> <br /> Microsoft offers training programs on Developing Security-Enhanced Web Applications and Developing and Deploying Secure Microsoft .NET Framework Application. More information can be found at http://www.microsoft.com/traincert/syllabi/2300AFinal.asp and http://www.microsoft.com/traincert/syllabi/2350BFinal.asp Foundstone offers secure coding training through Global Knowledge Aspect Security offers a similar course. <br /> <br /> OWASP_FAQ_Ver3.doc</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.css&diff=136781 2012-09-29T20:27:34Z

<p>Webappsecguy: Adding another CSS selector to remove distracting tab on home page.</p> <hr /> <div>.hiddenStructure {display: none}<br /> <br /> .if {display: none}<br /> <br /> <br /> /* wikitable/prettytable class for skinning normal tables */<br /> <br /> table.wikitable,<br /> table.prettytable {<br /> margin: 1em 1em 1em 0;<br /> background: #f9f9f9;<br /> border: 1px #aaaaaa solid;<br /> border-collapse: collapse;<br /> }<br /> <br /> table.wikitable th, table.wikitable td,<br /> table.prettytable th, table.prettytable td {<br /> border: 1px #aaaaaa solid;<br /> padding: 0.2em;<br /> }<br /> <br /> table.wikitable th,<br /> table.prettytable th {<br /> background: #f2f2f2;<br /> text-align: center;<br /> }<br /> <br /> table.wikitable caption,<br /> table.prettytable caption {<br /> margin-left: inherit;<br /> margin-right: inherit;<br /> }<br /> <br /> .allpagesredirect {<br /> font-style: italic;<br /> }<br /> <br /> /* Infobox template style */<br /> <br /> .infobox {<br /> border: 1px solid #aaaaaa;<br /> background-color: #f9f9f9;<br /> color: black;<br /> margin-bottom: 0.5em;<br /> margin-left: 1em;<br /> padding: 0.2em;<br /> float: right;<br /> clear: right;<br /> }<br /> .infobox td,<br /> .infobox th {<br /> vertical-align: top;<br /> }<br /> .infobox caption {<br /> font-size: larger;<br /> margin-left: inherit;<br /> }<br /> .infobox.bordered {<br /> border-collapse: collapse;<br /> }<br /> .infobox.bordered td,<br /> .infobox.bordered th {<br /> border: 1px solid #aaaaaa;<br /> }<br /> .infobox.bordered .borderless td,<br /> .infobox.bordered .borderless th {<br /> border: 0;<br /> }<br /> <br /> .infobox.sisterproject {<br /> width: 20em;<br /> font-size: 90%;<br /> }<br /> <br /> table.collapsed tr.collapsible {<br /> display: none;<br /> }<br /> <br /> .collapseButton { /* 'show'/'hide' buttons created dynamically by the */<br /> float: right; /* CollapsibleTables JavaScript in [[MediaWiki:Common.js]] */<br /> font-weight: normal; /* are styled here so they can be customised. */<br /> text-align: right;<br /> width: auto;<br /> <br /> }<br /> <br /> /* Default styling for Navbar template */<br /> .navbar {<br /> display: inline;<br /> font-size: 88%;<br /> font-weight: normal;<br /> }<br /> .navbar ul {<br /> display: inline;<br /> white-space: nowrap;<br /> }<br /> .navbar li {<br /> word-spacing: -0.125em;<br /> }<br /> /* Navbar styling when nested in navbox */<br /> .navbox .navbar {<br /> display: block;<br /> font-size: 100%;<br /> }<br /> .navbox-title .navbar {<br /> /* @noflip */<br /> float: left;<br /> /* @noflip */<br /> text-align: left;<br /> /* @noflip */<br /> margin-right: 0.5em;<br /> width: 6em;<br /> }<br /> <br /> /* Default style for navigation boxes */<br /> .navbox { /* Navbox container style */<br /> border: 1px solid #aaa;<br /> width: 100%; <br /> margin: auto;<br /> clear: both;<br /> font-size: 88%;<br /> text-align: center;<br /> padding: 1px;<br /> }<br /> .navbox-inner,<br /> .navbox-subgroup {<br /> width: 100%;<br /> }<br /> .navbox th,<br /> .navbox-title,<br /> .navbox-abovebelow {<br /> text-align: center; /* Title and above/below styles */<br /> padding-left: 1em;<br /> padding-right: 1em;<br /> }<br /> th.navbox-group { /* Group style */<br /> white-space: nowrap;<br /> /* @noflip */<br /> text-align: right;<br /> }<br /> .navbox,<br /> .navbox-subgroup {<br /> background: #fdfdfd; /* Background color */<br /> }<br /> .navbox-list {<br /> border-color: #fdfdfd; /* Must match background color */<br /> }<br /> .navbox th,<br /> .navbox-title {<br /> background: #ccccff; /* Level 1 color */<br /> }<br /> .navbox-abovebelow,<br /> th.navbox-group,<br /> .navbox-subgroup .navbox-title {<br /> background: #ddddff; /* Level 2 color */<br /> }<br /> .navbox-subgroup .navbox-group,<br /> .navbox-subgroup .navbox-abovebelow {<br /> background: #e6e6ff; /* Level 3 color */<br /> }<br /> .navbox-even {<br /> background: #f7f7f7; /* Even row striping */<br /> }<br /> .navbox-odd {<br /> background: transparent; /* Odd row striping */<br /> }<br /> table.navbox + table.navbox { /* Single pixel border between adjacent navboxes */<br /> margin-top: -1px; /* (doesn't work for IE6, but that's okay) */<br /> }<br /> .navbox .hlist td dl,<br /> .navbox .hlist td ol,<br /> .navbox .hlist td ul,<br /> .navbox td.hlist dl,<br /> .navbox td.hlist ol,<br /> .navbox td.hlist ul {<br /> padding: 0.125em 0; /* Adjust hlist padding in navboxes */<br /> }<br /> .navbox .hlist dd,<br /> .navbox .hlist dt,<br /> .navbox .hlist li {<br /> white-space: nowrap; /* Nowrap list items in navboxes */<br /> white-space: normal !ie; /* IE &lt; 8 no-wraps entire list, so disable it */<br /> }<br /> .navbox .hlist dd dl,<br /> .navbox .hlist dt dl,<br /> .navbox .hlist li ol,<br /> .navbox .hlist li ul {<br /> white-space: normal; /* But allow parent list items to be wrapped */<br /> }<br /> ol + table.navbox,<br /> ul + table.navbox {<br /> margin-top: 0.5em; /* Prevent lists from clinging to navboxes */<br /> }<br /> <br /> <br /> <br /> <br /> body.page-Main_Page h1.firstHeading { display:none; } /* Hide heading on home page for title */<br /> <br /> body.page-Main_Page #p-actions { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-talk { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-view { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-edit { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-history { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #p-cactions { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-nstab-main { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-viewsource { display: none !important; } /* Hide distracting tab button on home page */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.css&diff=136777 2012-09-29T17:01:48Z

<p>Webappsecguy: </p> <hr /> <div>.hiddenStructure {display: none}<br /> <br /> .if {display: none}<br /> <br /> <br /> /* wikitable/prettytable class for skinning normal tables */<br /> <br /> table.wikitable,<br /> table.prettytable {<br /> margin: 1em 1em 1em 0;<br /> background: #f9f9f9;<br /> border: 1px #aaaaaa solid;<br /> border-collapse: collapse;<br /> }<br /> <br /> table.wikitable th, table.wikitable td,<br /> table.prettytable th, table.prettytable td {<br /> border: 1px #aaaaaa solid;<br /> padding: 0.2em;<br /> }<br /> <br /> table.wikitable th,<br /> table.prettytable th {<br /> background: #f2f2f2;<br /> text-align: center;<br /> }<br /> <br /> table.wikitable caption,<br /> table.prettytable caption {<br /> margin-left: inherit;<br /> margin-right: inherit;<br /> }<br /> <br /> .allpagesredirect {<br /> font-style: italic;<br /> }<br /> <br /> /* Infobox template style */<br /> <br /> .infobox {<br /> border: 1px solid #aaaaaa;<br /> background-color: #f9f9f9;<br /> color: black;<br /> margin-bottom: 0.5em;<br /> margin-left: 1em;<br /> padding: 0.2em;<br /> float: right;<br /> clear: right;<br /> }<br /> .infobox td,<br /> .infobox th {<br /> vertical-align: top;<br /> }<br /> .infobox caption {<br /> font-size: larger;<br /> margin-left: inherit;<br /> }<br /> .infobox.bordered {<br /> border-collapse: collapse;<br /> }<br /> .infobox.bordered td,<br /> .infobox.bordered th {<br /> border: 1px solid #aaaaaa;<br /> }<br /> .infobox.bordered .borderless td,<br /> .infobox.bordered .borderless th {<br /> border: 0;<br /> }<br /> <br /> .infobox.sisterproject {<br /> width: 20em;<br /> font-size: 90%;<br /> }<br /> <br /> table.collapsed tr.collapsible {<br /> display: none;<br /> }<br /> <br /> .collapseButton { /* 'show'/'hide' buttons created dynamically by the */<br /> float: right; /* CollapsibleTables JavaScript in [[MediaWiki:Common.js]] */<br /> font-weight: normal; /* are styled here so they can be customised. */<br /> text-align: right;<br /> width: auto;<br /> <br /> }<br /> <br /> /* Default styling for Navbar template */<br /> .navbar {<br /> display: inline;<br /> font-size: 88%;<br /> font-weight: normal;<br /> }<br /> .navbar ul {<br /> display: inline;<br /> white-space: nowrap;<br /> }<br /> .navbar li {<br /> word-spacing: -0.125em;<br /> }<br /> /* Navbar styling when nested in navbox */<br /> .navbox .navbar {<br /> display: block;<br /> font-size: 100%;<br /> }<br /> .navbox-title .navbar {<br /> /* @noflip */<br /> float: left;<br /> /* @noflip */<br /> text-align: left;<br /> /* @noflip */<br /> margin-right: 0.5em;<br /> width: 6em;<br /> }<br /> <br /> /* Default style for navigation boxes */<br /> .navbox { /* Navbox container style */<br /> border: 1px solid #aaa;<br /> width: 100%; <br /> margin: auto;<br /> clear: both;<br /> font-size: 88%;<br /> text-align: center;<br /> padding: 1px;<br /> }<br /> .navbox-inner,<br /> .navbox-subgroup {<br /> width: 100%;<br /> }<br /> .navbox th,<br /> .navbox-title,<br /> .navbox-abovebelow {<br /> text-align: center; /* Title and above/below styles */<br /> padding-left: 1em;<br /> padding-right: 1em;<br /> }<br /> th.navbox-group { /* Group style */<br /> white-space: nowrap;<br /> /* @noflip */<br /> text-align: right;<br /> }<br /> .navbox,<br /> .navbox-subgroup {<br /> background: #fdfdfd; /* Background color */<br /> }<br /> .navbox-list {<br /> border-color: #fdfdfd; /* Must match background color */<br /> }<br /> .navbox th,<br /> .navbox-title {<br /> background: #ccccff; /* Level 1 color */<br /> }<br /> .navbox-abovebelow,<br /> th.navbox-group,<br /> .navbox-subgroup .navbox-title {<br /> background: #ddddff; /* Level 2 color */<br /> }<br /> .navbox-subgroup .navbox-group,<br /> .navbox-subgroup .navbox-abovebelow {<br /> background: #e6e6ff; /* Level 3 color */<br /> }<br /> .navbox-even {<br /> background: #f7f7f7; /* Even row striping */<br /> }<br /> .navbox-odd {<br /> background: transparent; /* Odd row striping */<br /> }<br /> table.navbox + table.navbox { /* Single pixel border between adjacent navboxes */<br /> margin-top: -1px; /* (doesn't work for IE6, but that's okay) */<br /> }<br /> .navbox .hlist td dl,<br /> .navbox .hlist td ol,<br /> .navbox .hlist td ul,<br /> .navbox td.hlist dl,<br /> .navbox td.hlist ol,<br /> .navbox td.hlist ul {<br /> padding: 0.125em 0; /* Adjust hlist padding in navboxes */<br /> }<br /> .navbox .hlist dd,<br /> .navbox .hlist dt,<br /> .navbox .hlist li {<br /> white-space: nowrap; /* Nowrap list items in navboxes */<br /> white-space: normal !ie; /* IE &lt; 8 no-wraps entire list, so disable it */<br /> }<br /> .navbox .hlist dd dl,<br /> .navbox .hlist dt dl,<br /> .navbox .hlist li ol,<br /> .navbox .hlist li ul {<br /> white-space: normal; /* But allow parent list items to be wrapped */<br /> }<br /> ol + table.navbox,<br /> ul + table.navbox {<br /> margin-top: 0.5em; /* Prevent lists from clinging to navboxes */<br /> }<br /> <br /> <br /> <br /> <br /> body.page-Main_Page h1.firstHeading { display:none; } /* Hide heading on home page for title */<br /> <br /> body.page-Main_Page #p-actions { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-talk { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-view { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-edit { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-history { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #p-cactions { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-nstab-main { display: none !important; } /* Hide distracting tab button on home page */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.css&diff=136776 2012-09-29T17:01:03Z

<p>Webappsecguy: </p> <hr /> <div>.hiddenStructure {display: none}<br /> <br /> .if {display: none}<br /> <br /> <br /> /* wikitable/prettytable class for skinning normal tables */<br /> <br /> table.wikitable,<br /> table.prettytable {<br /> margin: 1em 1em 1em 0;<br /> background: #f9f9f9;<br /> border: 1px #aaaaaa solid;<br /> border-collapse: collapse;<br /> }<br /> <br /> table.wikitable th, table.wikitable td,<br /> table.prettytable th, table.prettytable td {<br /> border: 1px #aaaaaa solid;<br /> padding: 0.2em;<br /> }<br /> <br /> table.wikitable th,<br /> table.prettytable th {<br /> background: #f2f2f2;<br /> text-align: center;<br /> }<br /> <br /> table.wikitable caption,<br /> table.prettytable caption {<br /> margin-left: inherit;<br /> margin-right: inherit;<br /> }<br /> <br /> .allpagesredirect {<br /> font-style: italic;<br /> }<br /> <br /> /* Infobox template style */<br /> <br /> .infobox {<br /> border: 1px solid #aaaaaa;<br /> background-color: #f9f9f9;<br /> color: black;<br /> margin-bottom: 0.5em;<br /> margin-left: 1em;<br /> padding: 0.2em;<br /> float: right;<br /> clear: right;<br /> }<br /> .infobox td,<br /> .infobox th {<br /> vertical-align: top;<br /> }<br /> .infobox caption {<br /> font-size: larger;<br /> margin-left: inherit;<br /> }<br /> .infobox.bordered {<br /> border-collapse: collapse;<br /> }<br /> .infobox.bordered td,<br /> .infobox.bordered th {<br /> border: 1px solid #aaaaaa;<br /> }<br /> .infobox.bordered .borderless td,<br /> .infobox.bordered .borderless th {<br /> border: 0;<br /> }<br /> <br /> .infobox.sisterproject {<br /> width: 20em;<br /> font-size: 90%;<br /> }<br /> <br /> table.collapsed tr.collapsible {<br /> display: none;<br /> }<br /> <br /> .collapseButton { /* 'show'/'hide' buttons created dynamically by the */<br /> float: right; /* CollapsibleTables JavaScript in [[MediaWiki:Common.js]] */<br /> font-weight: normal; /* are styled here so they can be customised. */<br /> text-align: right;<br /> width: auto;<br /> <br /> }<br /> <br /> /* Default styling for Navbar template */<br /> .navbar {<br /> display: inline;<br /> font-size: 88%;<br /> font-weight: normal;<br /> }<br /> .navbar ul {<br /> display: inline;<br /> white-space: nowrap;<br /> }<br /> .navbar li {<br /> word-spacing: -0.125em;<br /> }<br /> /* Navbar styling when nested in navbox */<br /> .navbox .navbar {<br /> display: block;<br /> font-size: 100%;<br /> }<br /> .navbox-title .navbar {<br /> /* @noflip */<br /> float: left;<br /> /* @noflip */<br /> text-align: left;<br /> /* @noflip */<br /> margin-right: 0.5em;<br /> width: 6em;<br /> }<br /> <br /> /* Default style for navigation boxes */<br /> .navbox { /* Navbox container style */<br /> border: 1px solid #aaa;<br /> width: 100%; <br /> margin: auto;<br /> clear: both;<br /> font-size: 88%;<br /> text-align: center;<br /> padding: 1px;<br /> }<br /> .navbox-inner,<br /> .navbox-subgroup {<br /> width: 100%;<br /> }<br /> .navbox th,<br /> .navbox-title,<br /> .navbox-abovebelow {<br /> text-align: center; /* Title and above/below styles */<br /> padding-left: 1em;<br /> padding-right: 1em;<br /> }<br /> th.navbox-group { /* Group style */<br /> white-space: nowrap;<br /> /* @noflip */<br /> text-align: right;<br /> }<br /> .navbox,<br /> .navbox-subgroup {<br /> background: #fdfdfd; /* Background color */<br /> }<br /> .navbox-list {<br /> border-color: #fdfdfd; /* Must match background color */<br /> }<br /> .navbox th,<br /> .navbox-title {<br /> background: #ccccff; /* Level 1 color */<br /> }<br /> .navbox-abovebelow,<br /> th.navbox-group,<br /> .navbox-subgroup .navbox-title {<br /> background: #ddddff; /* Level 2 color */<br /> }<br /> .navbox-subgroup .navbox-group,<br /> .navbox-subgroup .navbox-abovebelow {<br /> background: #e6e6ff; /* Level 3 color */<br /> }<br /> .navbox-even {<br /> background: #f7f7f7; /* Even row striping */<br /> }<br /> .navbox-odd {<br /> background: transparent; /* Odd row striping */<br /> }<br /> table.navbox + table.navbox { /* Single pixel border between adjacent navboxes */<br /> margin-top: -1px; /* (doesn't work for IE6, but that's okay) */<br /> }<br /> .navbox .hlist td dl,<br /> .navbox .hlist td ol,<br /> .navbox .hlist td ul,<br /> .navbox td.hlist dl,<br /> .navbox td.hlist ol,<br /> .navbox td.hlist ul {<br /> padding: 0.125em 0; /* Adjust hlist padding in navboxes */<br /> }<br /> .navbox .hlist dd,<br /> .navbox .hlist dt,<br /> .navbox .hlist li {<br /> white-space: nowrap; /* Nowrap list items in navboxes */<br /> white-space: normal !ie; /* IE &lt; 8 no-wraps entire list, so disable it */<br /> }<br /> .navbox .hlist dd dl,<br /> .navbox .hlist dt dl,<br /> .navbox .hlist li ol,<br /> .navbox .hlist li ul {<br /> white-space: normal; /* But allow parent list items to be wrapped */<br /> }<br /> ol + table.navbox,<br /> ul + table.navbox {<br /> margin-top: 0.5em; /* Prevent lists from clinging to navboxes */<br /> }<br /> <br /> <br /> <br /> <br /> body.page-Main_Page h1.firstHeading { display:none; } /* Hide heading on home page for title */<br /> <br /> body.page-Main_Page #p-actions { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-talk { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-view { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-edit { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-history { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #p-actions { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-nstab-main { display: none !important; } /* Hide distracting tab button on home page */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.css&diff=136775 2012-09-29T16:59:50Z

<p>Webappsecguy: </p> <hr /> <div>.hiddenStructure {display: none}<br /> <br /> .if {display: none}<br /> <br /> <br /> /* wikitable/prettytable class for skinning normal tables */<br /> <br /> table.wikitable,<br /> table.prettytable {<br /> margin: 1em 1em 1em 0;<br /> background: #f9f9f9;<br /> border: 1px #aaaaaa solid;<br /> border-collapse: collapse;<br /> }<br /> <br /> table.wikitable th, table.wikitable td,<br /> table.prettytable th, table.prettytable td {<br /> border: 1px #aaaaaa solid;<br /> padding: 0.2em;<br /> }<br /> <br /> table.wikitable th,<br /> table.prettytable th {<br /> background: #f2f2f2;<br /> text-align: center;<br /> }<br /> <br /> table.wikitable caption,<br /> table.prettytable caption {<br /> margin-left: inherit;<br /> margin-right: inherit;<br /> }<br /> <br /> .allpagesredirect {<br /> font-style: italic;<br /> }<br /> <br /> /* Infobox template style */<br /> <br /> .infobox {<br /> border: 1px solid #aaaaaa;<br /> background-color: #f9f9f9;<br /> color: black;<br /> margin-bottom: 0.5em;<br /> margin-left: 1em;<br /> padding: 0.2em;<br /> float: right;<br /> clear: right;<br /> }<br /> .infobox td,<br /> .infobox th {<br /> vertical-align: top;<br /> }<br /> .infobox caption {<br /> font-size: larger;<br /> margin-left: inherit;<br /> }<br /> .infobox.bordered {<br /> border-collapse: collapse;<br /> }<br /> .infobox.bordered td,<br /> .infobox.bordered th {<br /> border: 1px solid #aaaaaa;<br /> }<br /> .infobox.bordered .borderless td,<br /> .infobox.bordered .borderless th {<br /> border: 0;<br /> }<br /> <br /> .infobox.sisterproject {<br /> width: 20em;<br /> font-size: 90%;<br /> }<br /> <br /> table.collapsed tr.collapsible {<br /> display: none;<br /> }<br /> <br /> .collapseButton { /* 'show'/'hide' buttons created dynamically by the */<br /> float: right; /* CollapsibleTables JavaScript in [[MediaWiki:Common.js]] */<br /> font-weight: normal; /* are styled here so they can be customised. */<br /> text-align: right;<br /> width: auto;<br /> <br /> }<br /> <br /> /* Default styling for Navbar template */<br /> .navbar {<br /> display: inline;<br /> font-size: 88%;<br /> font-weight: normal;<br /> }<br /> .navbar ul {<br /> display: inline;<br /> white-space: nowrap;<br /> }<br /> .navbar li {<br /> word-spacing: -0.125em;<br /> }<br /> /* Navbar styling when nested in navbox */<br /> .navbox .navbar {<br /> display: block;<br /> font-size: 100%;<br /> }<br /> .navbox-title .navbar {<br /> /* @noflip */<br /> float: left;<br /> /* @noflip */<br /> text-align: left;<br /> /* @noflip */<br /> margin-right: 0.5em;<br /> width: 6em;<br /> }<br /> <br /> /* Default style for navigation boxes */<br /> .navbox { /* Navbox container style */<br /> border: 1px solid #aaa;<br /> width: 100%; <br /> margin: auto;<br /> clear: both;<br /> font-size: 88%;<br /> text-align: center;<br /> padding: 1px;<br /> }<br /> .navbox-inner,<br /> .navbox-subgroup {<br /> width: 100%;<br /> }<br /> .navbox th,<br /> .navbox-title,<br /> .navbox-abovebelow {<br /> text-align: center; /* Title and above/below styles */<br /> padding-left: 1em;<br /> padding-right: 1em;<br /> }<br /> th.navbox-group { /* Group style */<br /> white-space: nowrap;<br /> /* @noflip */<br /> text-align: right;<br /> }<br /> .navbox,<br /> .navbox-subgroup {<br /> background: #fdfdfd; /* Background color */<br /> }<br /> .navbox-list {<br /> border-color: #fdfdfd; /* Must match background color */<br /> }<br /> .navbox th,<br /> .navbox-title {<br /> background: #ccccff; /* Level 1 color */<br /> }<br /> .navbox-abovebelow,<br /> th.navbox-group,<br /> .navbox-subgroup .navbox-title {<br /> background: #ddddff; /* Level 2 color */<br /> }<br /> .navbox-subgroup .navbox-group,<br /> .navbox-subgroup .navbox-abovebelow {<br /> background: #e6e6ff; /* Level 3 color */<br /> }<br /> .navbox-even {<br /> background: #f7f7f7; /* Even row striping */<br /> }<br /> .navbox-odd {<br /> background: transparent; /* Odd row striping */<br /> }<br /> table.navbox + table.navbox { /* Single pixel border between adjacent navboxes */<br /> margin-top: -1px; /* (doesn't work for IE6, but that's okay) */<br /> }<br /> .navbox .hlist td dl,<br /> .navbox .hlist td ol,<br /> .navbox .hlist td ul,<br /> .navbox td.hlist dl,<br /> .navbox td.hlist ol,<br /> .navbox td.hlist ul {<br /> padding: 0.125em 0; /* Adjust hlist padding in navboxes */<br /> }<br /> .navbox .hlist dd,<br /> .navbox .hlist dt,<br /> .navbox .hlist li {<br /> white-space: nowrap; /* Nowrap list items in navboxes */<br /> white-space: normal !ie; /* IE &lt; 8 no-wraps entire list, so disable it */<br /> }<br /> .navbox .hlist dd dl,<br /> .navbox .hlist dt dl,<br /> .navbox .hlist li ol,<br /> .navbox .hlist li ul {<br /> white-space: normal; /* But allow parent list items to be wrapped */<br /> }<br /> ol + table.navbox,<br /> ul + table.navbox {<br /> margin-top: 0.5em; /* Prevent lists from clinging to navboxes */<br /> }<br /> <br /> <br /> <br /> <br /> body.page-Main_Page h1.firstHeading { display:none; } /* Hide heading on home page for title */<br /> <br /> body.page-Main_Page #p-actions { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-talk { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-view { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-edit { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-history { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #p-views { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-nstab-main { display: none !important; } /* Hide distracting tab button on home page */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.css&diff=136774 2012-09-29T16:57:30Z

<p>Webappsecguy: Hiding other unnecessary buttons</p> <hr /> <div>.hiddenStructure {display: none}<br /> <br /> .if {display: none}<br /> <br /> <br /> /* wikitable/prettytable class for skinning normal tables */<br /> <br /> table.wikitable,<br /> table.prettytable {<br /> margin: 1em 1em 1em 0;<br /> background: #f9f9f9;<br /> border: 1px #aaaaaa solid;<br /> border-collapse: collapse;<br /> }<br /> <br /> table.wikitable th, table.wikitable td,<br /> table.prettytable th, table.prettytable td {<br /> border: 1px #aaaaaa solid;<br /> padding: 0.2em;<br /> }<br /> <br /> table.wikitable th,<br /> table.prettytable th {<br /> background: #f2f2f2;<br /> text-align: center;<br /> }<br /> <br /> table.wikitable caption,<br /> table.prettytable caption {<br /> margin-left: inherit;<br /> margin-right: inherit;<br /> }<br /> <br /> .allpagesredirect {<br /> font-style: italic;<br /> }<br /> <br /> /* Infobox template style */<br /> <br /> .infobox {<br /> border: 1px solid #aaaaaa;<br /> background-color: #f9f9f9;<br /> color: black;<br /> margin-bottom: 0.5em;<br /> margin-left: 1em;<br /> padding: 0.2em;<br /> float: right;<br /> clear: right;<br /> }<br /> .infobox td,<br /> .infobox th {<br /> vertical-align: top;<br /> }<br /> .infobox caption {<br /> font-size: larger;<br /> margin-left: inherit;<br /> }<br /> .infobox.bordered {<br /> border-collapse: collapse;<br /> }<br /> .infobox.bordered td,<br /> .infobox.bordered th {<br /> border: 1px solid #aaaaaa;<br /> }<br /> .infobox.bordered .borderless td,<br /> .infobox.bordered .borderless th {<br /> border: 0;<br /> }<br /> <br /> .infobox.sisterproject {<br /> width: 20em;<br /> font-size: 90%;<br /> }<br /> <br /> table.collapsed tr.collapsible {<br /> display: none;<br /> }<br /> <br /> .collapseButton { /* 'show'/'hide' buttons created dynamically by the */<br /> float: right; /* CollapsibleTables JavaScript in [[MediaWiki:Common.js]] */<br /> font-weight: normal; /* are styled here so they can be customised. */<br /> text-align: right;<br /> width: auto;<br /> <br /> }<br /> <br /> /* Default styling for Navbar template */<br /> .navbar {<br /> display: inline;<br /> font-size: 88%;<br /> font-weight: normal;<br /> }<br /> .navbar ul {<br /> display: inline;<br /> white-space: nowrap;<br /> }<br /> .navbar li {<br /> word-spacing: -0.125em;<br /> }<br /> /* Navbar styling when nested in navbox */<br /> .navbox .navbar {<br /> display: block;<br /> font-size: 100%;<br /> }<br /> .navbox-title .navbar {<br /> /* @noflip */<br /> float: left;<br /> /* @noflip */<br /> text-align: left;<br /> /* @noflip */<br /> margin-right: 0.5em;<br /> width: 6em;<br /> }<br /> <br /> /* Default style for navigation boxes */<br /> .navbox { /* Navbox container style */<br /> border: 1px solid #aaa;<br /> width: 100%; <br /> margin: auto;<br /> clear: both;<br /> font-size: 88%;<br /> text-align: center;<br /> padding: 1px;<br /> }<br /> .navbox-inner,<br /> .navbox-subgroup {<br /> width: 100%;<br /> }<br /> .navbox th,<br /> .navbox-title,<br /> .navbox-abovebelow {<br /> text-align: center; /* Title and above/below styles */<br /> padding-left: 1em;<br /> padding-right: 1em;<br /> }<br /> th.navbox-group { /* Group style */<br /> white-space: nowrap;<br /> /* @noflip */<br /> text-align: right;<br /> }<br /> .navbox,<br /> .navbox-subgroup {<br /> background: #fdfdfd; /* Background color */<br /> }<br /> .navbox-list {<br /> border-color: #fdfdfd; /* Must match background color */<br /> }<br /> .navbox th,<br /> .navbox-title {<br /> background: #ccccff; /* Level 1 color */<br /> }<br /> .navbox-abovebelow,<br /> th.navbox-group,<br /> .navbox-subgroup .navbox-title {<br /> background: #ddddff; /* Level 2 color */<br /> }<br /> .navbox-subgroup .navbox-group,<br /> .navbox-subgroup .navbox-abovebelow {<br /> background: #e6e6ff; /* Level 3 color */<br /> }<br /> .navbox-even {<br /> background: #f7f7f7; /* Even row striping */<br /> }<br /> .navbox-odd {<br /> background: transparent; /* Odd row striping */<br /> }<br /> table.navbox + table.navbox { /* Single pixel border between adjacent navboxes */<br /> margin-top: -1px; /* (doesn't work for IE6, but that's okay) */<br /> }<br /> .navbox .hlist td dl,<br /> .navbox .hlist td ol,<br /> .navbox .hlist td ul,<br /> .navbox td.hlist dl,<br /> .navbox td.hlist ol,<br /> .navbox td.hlist ul {<br /> padding: 0.125em 0; /* Adjust hlist padding in navboxes */<br /> }<br /> .navbox .hlist dd,<br /> .navbox .hlist dt,<br /> .navbox .hlist li {<br /> white-space: nowrap; /* Nowrap list items in navboxes */<br /> white-space: normal !ie; /* IE &lt; 8 no-wraps entire list, so disable it */<br /> }<br /> .navbox .hlist dd dl,<br /> .navbox .hlist dt dl,<br /> .navbox .hlist li ol,<br /> .navbox .hlist li ul {<br /> white-space: normal; /* But allow parent list items to be wrapped */<br /> }<br /> ol + table.navbox,<br /> ul + table.navbox {<br /> margin-top: 0.5em; /* Prevent lists from clinging to navboxes */<br /> }<br /> <br /> <br /> <br /> <br /> body.page-Main_Page h1.firstHeading { display:none; } /* Hide heading on home page for title */<br /> <br /> body.page-Main_Page #ca-talk { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-view { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-edit { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #ca-history { display: none !important; } /* Hide distracting tab button on home page */<br /> body.page-Main_Page #p-actions { display: none !important; } /* Hide distracting tab button on home page */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.css&diff=136773 2012-09-29T16:53:40Z

<p>Webappsecguy: </p> <hr /> <div>.hiddenStructure {display: none}<br /> <br /> .if {display: none}<br /> <br /> <br /> /* wikitable/prettytable class for skinning normal tables */<br /> <br /> table.wikitable,<br /> table.prettytable {<br /> margin: 1em 1em 1em 0;<br /> background: #f9f9f9;<br /> border: 1px #aaaaaa solid;<br /> border-collapse: collapse;<br /> }<br /> <br /> table.wikitable th, table.wikitable td,<br /> table.prettytable th, table.prettytable td {<br /> border: 1px #aaaaaa solid;<br /> padding: 0.2em;<br /> }<br /> <br /> table.wikitable th,<br /> table.prettytable th {<br /> background: #f2f2f2;<br /> text-align: center;<br /> }<br /> <br /> table.wikitable caption,<br /> table.prettytable caption {<br /> margin-left: inherit;<br /> margin-right: inherit;<br /> }<br /> <br /> .allpagesredirect {<br /> font-style: italic;<br /> }<br /> <br /> /* Infobox template style */<br /> <br /> .infobox {<br /> border: 1px solid #aaaaaa;<br /> background-color: #f9f9f9;<br /> color: black;<br /> margin-bottom: 0.5em;<br /> margin-left: 1em;<br /> padding: 0.2em;<br /> float: right;<br /> clear: right;<br /> }<br /> .infobox td,<br /> .infobox th {<br /> vertical-align: top;<br /> }<br /> .infobox caption {<br /> font-size: larger;<br /> margin-left: inherit;<br /> }<br /> .infobox.bordered {<br /> border-collapse: collapse;<br /> }<br /> .infobox.bordered td,<br /> .infobox.bordered th {<br /> border: 1px solid #aaaaaa;<br /> }<br /> .infobox.bordered .borderless td,<br /> .infobox.bordered .borderless th {<br /> border: 0;<br /> }<br /> <br /> .infobox.sisterproject {<br /> width: 20em;<br /> font-size: 90%;<br /> }<br /> <br /> table.collapsed tr.collapsible {<br /> display: none;<br /> }<br /> <br /> .collapseButton { /* 'show'/'hide' buttons created dynamically by the */<br /> float: right; /* CollapsibleTables JavaScript in [[MediaWiki:Common.js]] */<br /> font-weight: normal; /* are styled here so they can be customised. */<br /> text-align: right;<br /> width: auto;<br /> <br /> }<br /> <br /> /* Default styling for Navbar template */<br /> .navbar {<br /> display: inline;<br /> font-size: 88%;<br /> font-weight: normal;<br /> }<br /> .navbar ul {<br /> display: inline;<br /> white-space: nowrap;<br /> }<br /> .navbar li {<br /> word-spacing: -0.125em;<br /> }<br /> /* Navbar styling when nested in navbox */<br /> .navbox .navbar {<br /> display: block;<br /> font-size: 100%;<br /> }<br /> .navbox-title .navbar {<br /> /* @noflip */<br /> float: left;<br /> /* @noflip */<br /> text-align: left;<br /> /* @noflip */<br /> margin-right: 0.5em;<br /> width: 6em;<br /> }<br /> <br /> /* Default style for navigation boxes */<br /> .navbox { /* Navbox container style */<br /> border: 1px solid #aaa;<br /> width: 100%; <br /> margin: auto;<br /> clear: both;<br /> font-size: 88%;<br /> text-align: center;<br /> padding: 1px;<br /> }<br /> .navbox-inner,<br /> .navbox-subgroup {<br /> width: 100%;<br /> }<br /> .navbox th,<br /> .navbox-title,<br /> .navbox-abovebelow {<br /> text-align: center; /* Title and above/below styles */<br /> padding-left: 1em;<br /> padding-right: 1em;<br /> }<br /> th.navbox-group { /* Group style */<br /> white-space: nowrap;<br /> /* @noflip */<br /> text-align: right;<br /> }<br /> .navbox,<br /> .navbox-subgroup {<br /> background: #fdfdfd; /* Background color */<br /> }<br /> .navbox-list {<br /> border-color: #fdfdfd; /* Must match background color */<br /> }<br /> .navbox th,<br /> .navbox-title {<br /> background: #ccccff; /* Level 1 color */<br /> }<br /> .navbox-abovebelow,<br /> th.navbox-group,<br /> .navbox-subgroup .navbox-title {<br /> background: #ddddff; /* Level 2 color */<br /> }<br /> .navbox-subgroup .navbox-group,<br /> .navbox-subgroup .navbox-abovebelow {<br /> background: #e6e6ff; /* Level 3 color */<br /> }<br /> .navbox-even {<br /> background: #f7f7f7; /* Even row striping */<br /> }<br /> .navbox-odd {<br /> background: transparent; /* Odd row striping */<br /> }<br /> table.navbox + table.navbox { /* Single pixel border between adjacent navboxes */<br /> margin-top: -1px; /* (doesn't work for IE6, but that's okay) */<br /> }<br /> .navbox .hlist td dl,<br /> .navbox .hlist td ol,<br /> .navbox .hlist td ul,<br /> .navbox td.hlist dl,<br /> .navbox td.hlist ol,<br /> .navbox td.hlist ul {<br /> padding: 0.125em 0; /* Adjust hlist padding in navboxes */<br /> }<br /> .navbox .hlist dd,<br /> .navbox .hlist dt,<br /> .navbox .hlist li {<br /> white-space: nowrap; /* Nowrap list items in navboxes */<br /> white-space: normal !ie; /* IE &lt; 8 no-wraps entire list, so disable it */<br /> }<br /> .navbox .hlist dd dl,<br /> .navbox .hlist dt dl,<br /> .navbox .hlist li ol,<br /> .navbox .hlist li ul {<br /> white-space: normal; /* But allow parent list items to be wrapped */<br /> }<br /> ol + table.navbox,<br /> ul + table.navbox {<br /> margin-top: 0.5em; /* Prevent lists from clinging to navboxes */<br /> }<br /> <br /> <br /> <br /> <br /> body.page-Main_Page h1.firstHeading { display:none; } /* Hide heading on home page for title */<br /> <br /> body.page-Main_Page #ca-talk { display: none !important; } /* Hide distracting Discussion button on home page */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.css&diff=136772 2012-09-29T16:52:41Z

<p>Webappsecguy: Hiding distracting Discussion button on home page.</p> <hr /> <div>.hiddenStructure {display: none}<br /> <br /> .if {display: none}<br /> <br /> <br /> /* wikitable/prettytable class for skinning normal tables */<br /> <br /> table.wikitable,<br /> table.prettytable {<br /> margin: 1em 1em 1em 0;<br /> background: #f9f9f9;<br /> border: 1px #aaaaaa solid;<br /> border-collapse: collapse;<br /> }<br /> <br /> table.wikitable th, table.wikitable td,<br /> table.prettytable th, table.prettytable td {<br /> border: 1px #aaaaaa solid;<br /> padding: 0.2em;<br /> }<br /> <br /> table.wikitable th,<br /> table.prettytable th {<br /> background: #f2f2f2;<br /> text-align: center;<br /> }<br /> <br /> table.wikitable caption,<br /> table.prettytable caption {<br /> margin-left: inherit;<br /> margin-right: inherit;<br /> }<br /> <br /> .allpagesredirect {<br /> font-style: italic;<br /> }<br /> <br /> /* Infobox template style */<br /> <br /> .infobox {<br /> border: 1px solid #aaaaaa;<br /> background-color: #f9f9f9;<br /> color: black;<br /> margin-bottom: 0.5em;<br /> margin-left: 1em;<br /> padding: 0.2em;<br /> float: right;<br /> clear: right;<br /> }<br /> .infobox td,<br /> .infobox th {<br /> vertical-align: top;<br /> }<br /> .infobox caption {<br /> font-size: larger;<br /> margin-left: inherit;<br /> }<br /> .infobox.bordered {<br /> border-collapse: collapse;<br /> }<br /> .infobox.bordered td,<br /> .infobox.bordered th {<br /> border: 1px solid #aaaaaa;<br /> }<br /> .infobox.bordered .borderless td,<br /> .infobox.bordered .borderless th {<br /> border: 0;<br /> }<br /> <br /> .infobox.sisterproject {<br /> width: 20em;<br /> font-size: 90%;<br /> }<br /> <br /> table.collapsed tr.collapsible {<br /> display: none;<br /> }<br /> <br /> .collapseButton { /* 'show'/'hide' buttons created dynamically by the */<br /> float: right; /* CollapsibleTables JavaScript in [[MediaWiki:Common.js]] */<br /> font-weight: normal; /* are styled here so they can be customised. */<br /> text-align: right;<br /> width: auto;<br /> <br /> }<br /> <br /> /* Default styling for Navbar template */<br /> .navbar {<br /> display: inline;<br /> font-size: 88%;<br /> font-weight: normal;<br /> }<br /> .navbar ul {<br /> display: inline;<br /> white-space: nowrap;<br /> }<br /> .navbar li {<br /> word-spacing: -0.125em;<br /> }<br /> /* Navbar styling when nested in navbox */<br /> .navbox .navbar {<br /> display: block;<br /> font-size: 100%;<br /> }<br /> .navbox-title .navbar {<br /> /* @noflip */<br /> float: left;<br /> /* @noflip */<br /> text-align: left;<br /> /* @noflip */<br /> margin-right: 0.5em;<br /> width: 6em;<br /> }<br /> <br /> /* Default style for navigation boxes */<br /> .navbox { /* Navbox container style */<br /> border: 1px solid #aaa;<br /> width: 100%; <br /> margin: auto;<br /> clear: both;<br /> font-size: 88%;<br /> text-align: center;<br /> padding: 1px;<br /> }<br /> .navbox-inner,<br /> .navbox-subgroup {<br /> width: 100%;<br /> }<br /> .navbox th,<br /> .navbox-title,<br /> .navbox-abovebelow {<br /> text-align: center; /* Title and above/below styles */<br /> padding-left: 1em;<br /> padding-right: 1em;<br /> }<br /> th.navbox-group { /* Group style */<br /> white-space: nowrap;<br /> /* @noflip */<br /> text-align: right;<br /> }<br /> .navbox,<br /> .navbox-subgroup {<br /> background: #fdfdfd; /* Background color */<br /> }<br /> .navbox-list {<br /> border-color: #fdfdfd; /* Must match background color */<br /> }<br /> .navbox th,<br /> .navbox-title {<br /> background: #ccccff; /* Level 1 color */<br /> }<br /> .navbox-abovebelow,<br /> th.navbox-group,<br /> .navbox-subgroup .navbox-title {<br /> background: #ddddff; /* Level 2 color */<br /> }<br /> .navbox-subgroup .navbox-group,<br /> .navbox-subgroup .navbox-abovebelow {<br /> background: #e6e6ff; /* Level 3 color */<br /> }<br /> .navbox-even {<br /> background: #f7f7f7; /* Even row striping */<br /> }<br /> .navbox-odd {<br /> background: transparent; /* Odd row striping */<br /> }<br /> table.navbox + table.navbox { /* Single pixel border between adjacent navboxes */<br /> margin-top: -1px; /* (doesn't work for IE6, but that's okay) */<br /> }<br /> .navbox .hlist td dl,<br /> .navbox .hlist td ol,<br /> .navbox .hlist td ul,<br /> .navbox td.hlist dl,<br /> .navbox td.hlist ol,<br /> .navbox td.hlist ul {<br /> padding: 0.125em 0; /* Adjust hlist padding in navboxes */<br /> }<br /> .navbox .hlist dd,<br /> .navbox .hlist dt,<br /> .navbox .hlist li {<br /> white-space: nowrap; /* Nowrap list items in navboxes */<br /> white-space: normal !ie; /* IE &lt; 8 no-wraps entire list, so disable it */<br /> }<br /> .navbox .hlist dd dl,<br /> .navbox .hlist dt dl,<br /> .navbox .hlist li ol,<br /> .navbox .hlist li ul {<br /> white-space: normal; /* But allow parent list items to be wrapped */<br /> }<br /> ol + table.navbox,<br /> ul + table.navbox {<br /> margin-top: 0.5em; /* Prevent lists from clinging to navboxes */<br /> }<br /> <br /> <br /> <br /> <br /> body.page-Main_Page h1.firstHeading { display:none; } /* Hide heading on home page for title */<br /> <br /> body.page-Main_Page li#ca-talk { display: none !important; } /* Hide distracting Discussion button on home page */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.css&diff=136771 2012-09-29T16:38:31Z

<p>Webappsecguy: Added CSS to hide heading on the home page for the title.</p> <hr /> <div>.hiddenStructure {display: none}<br /> <br /> .if {display: none}<br /> <br /> <br /> /* wikitable/prettytable class for skinning normal tables */<br /> <br /> table.wikitable,<br /> table.prettytable {<br /> margin: 1em 1em 1em 0;<br /> background: #f9f9f9;<br /> border: 1px #aaaaaa solid;<br /> border-collapse: collapse;<br /> }<br /> <br /> table.wikitable th, table.wikitable td,<br /> table.prettytable th, table.prettytable td {<br /> border: 1px #aaaaaa solid;<br /> padding: 0.2em;<br /> }<br /> <br /> table.wikitable th,<br /> table.prettytable th {<br /> background: #f2f2f2;<br /> text-align: center;<br /> }<br /> <br /> table.wikitable caption,<br /> table.prettytable caption {<br /> margin-left: inherit;<br /> margin-right: inherit;<br /> }<br /> <br /> .allpagesredirect {<br /> font-style: italic;<br /> }<br /> <br /> /* Infobox template style */<br /> <br /> .infobox {<br /> border: 1px solid #aaaaaa;<br /> background-color: #f9f9f9;<br /> color: black;<br /> margin-bottom: 0.5em;<br /> margin-left: 1em;<br /> padding: 0.2em;<br /> float: right;<br /> clear: right;<br /> }<br /> .infobox td,<br /> .infobox th {<br /> vertical-align: top;<br /> }<br /> .infobox caption {<br /> font-size: larger;<br /> margin-left: inherit;<br /> }<br /> .infobox.bordered {<br /> border-collapse: collapse;<br /> }<br /> .infobox.bordered td,<br /> .infobox.bordered th {<br /> border: 1px solid #aaaaaa;<br /> }<br /> .infobox.bordered .borderless td,<br /> .infobox.bordered .borderless th {<br /> border: 0;<br /> }<br /> <br /> .infobox.sisterproject {<br /> width: 20em;<br /> font-size: 90%;<br /> }<br /> <br /> table.collapsed tr.collapsible {<br /> display: none;<br /> }<br /> <br /> .collapseButton { /* 'show'/'hide' buttons created dynamically by the */<br /> float: right; /* CollapsibleTables JavaScript in [[MediaWiki:Common.js]] */<br /> font-weight: normal; /* are styled here so they can be customised. */<br /> text-align: right;<br /> width: auto;<br /> <br /> }<br /> <br /> /* Default styling for Navbar template */<br /> .navbar {<br /> display: inline;<br /> font-size: 88%;<br /> font-weight: normal;<br /> }<br /> .navbar ul {<br /> display: inline;<br /> white-space: nowrap;<br /> }<br /> .navbar li {<br /> word-spacing: -0.125em;<br /> }<br /> /* Navbar styling when nested in navbox */<br /> .navbox .navbar {<br /> display: block;<br /> font-size: 100%;<br /> }<br /> .navbox-title .navbar {<br /> /* @noflip */<br /> float: left;<br /> /* @noflip */<br /> text-align: left;<br /> /* @noflip */<br /> margin-right: 0.5em;<br /> width: 6em;<br /> }<br /> <br /> /* Default style for navigation boxes */<br /> .navbox { /* Navbox container style */<br /> border: 1px solid #aaa;<br /> width: 100%; <br /> margin: auto;<br /> clear: both;<br /> font-size: 88%;<br /> text-align: center;<br /> padding: 1px;<br /> }<br /> .navbox-inner,<br /> .navbox-subgroup {<br /> width: 100%;<br /> }<br /> .navbox th,<br /> .navbox-title,<br /> .navbox-abovebelow {<br /> text-align: center; /* Title and above/below styles */<br /> padding-left: 1em;<br /> padding-right: 1em;<br /> }<br /> th.navbox-group { /* Group style */<br /> white-space: nowrap;<br /> /* @noflip */<br /> text-align: right;<br /> }<br /> .navbox,<br /> .navbox-subgroup {<br /> background: #fdfdfd; /* Background color */<br /> }<br /> .navbox-list {<br /> border-color: #fdfdfd; /* Must match background color */<br /> }<br /> .navbox th,<br /> .navbox-title {<br /> background: #ccccff; /* Level 1 color */<br /> }<br /> .navbox-abovebelow,<br /> th.navbox-group,<br /> .navbox-subgroup .navbox-title {<br /> background: #ddddff; /* Level 2 color */<br /> }<br /> .navbox-subgroup .navbox-group,<br /> .navbox-subgroup .navbox-abovebelow {<br /> background: #e6e6ff; /* Level 3 color */<br /> }<br /> .navbox-even {<br /> background: #f7f7f7; /* Even row striping */<br /> }<br /> .navbox-odd {<br /> background: transparent; /* Odd row striping */<br /> }<br /> table.navbox + table.navbox { /* Single pixel border between adjacent navboxes */<br /> margin-top: -1px; /* (doesn't work for IE6, but that's okay) */<br /> }<br /> .navbox .hlist td dl,<br /> .navbox .hlist td ol,<br /> .navbox .hlist td ul,<br /> .navbox td.hlist dl,<br /> .navbox td.hlist ol,<br /> .navbox td.hlist ul {<br /> padding: 0.125em 0; /* Adjust hlist padding in navboxes */<br /> }<br /> .navbox .hlist dd,<br /> .navbox .hlist dt,<br /> .navbox .hlist li {<br /> white-space: nowrap; /* Nowrap list items in navboxes */<br /> white-space: normal !ie; /* IE &lt; 8 no-wraps entire list, so disable it */<br /> }<br /> .navbox .hlist dd dl,<br /> .navbox .hlist dt dl,<br /> .navbox .hlist li ol,<br /> .navbox .hlist li ul {<br /> white-space: normal; /* But allow parent list items to be wrapped */<br /> }<br /> ol + table.navbox,<br /> ul + table.navbox {<br /> margin-top: 0.5em; /* Prevent lists from clinging to navboxes */<br /> }<br /> <br /> <br /> <br /> <br /> body.page-Main_Page h1.firstHeading { display:none; } /* Hide heading on home page for title */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Main_Page&diff=136770 2012-09-29T16:31:56Z

<p>Webappsecguy: Reinstating &lt;openx&gt; ads, image-based only.</p> <hr /> <div><br /> &lt;div style=&quot;font-size:7pt;&quot;&gt;<br /> &lt;div align=&quot;center&quot;&gt;<br /> <br /> &lt;openx&gt;&lt;/openx&gt;<br /> <br /> &lt;b&gt;Disclaimer: Banner ads are not endorsements, and reflect the messages of the advertiser only. | [https://www.owasp.org/index.php/Advertising More Information]&lt;/b&gt;&lt;/div&gt;&lt;/div&gt;<br /> <br /> &lt;!-- Header --&gt;<br /> <br /> {|style=&quot;width:100%;background-color:#C4D7ED;border:1px solid #183152&quot;<br /> |style=&quot;width:56%;color:#000&quot;|<br /> <br /> {|style=&quot;width:280px;border:solid 0px;background:none&quot;<br /> |-<br /> |style=&quot;width:280px;text-align:center;color:#000&quot; |<br /> &lt;IfLanguage Is=&quot;en&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Welcome to [[About The Open Web Application Security Project|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;the free and open software security community&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> &lt;IfLanguage Is=&quot;es&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Bienvenido a [[About The Open Web Application Security Project/es|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;la comunidad libre y abierta sobre seguridad en aplicaciones&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> |}<br /> <br /> &lt;!-- Special Links --&gt;<br /> |style=&quot;width:110px;font-size:95%;color:#000&quot;|<br /> *[https://www.owasp.org/index.php/Projects_Reboot_2012 2012 Project Support Initiative]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP Top Ten Project|Top Ten]]<br /> *[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ZAP Proxy]<br /> *[[:Category:OWASP WebScarab Project|WebScarab]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP_Enterprise_Security_API|ESAPI]]<br /> *[[:Category:OWASP_Application_Security_Verification_Standard_Project |ASVS]]<br /> *[[:Category:OWASP_AntiSamy_Project|AntiSamy]]<br /> |style=&quot;width:180px;font-size:95%&quot;|<br /> *[[:Category:OWASP Guide Project|Development Guide]]<br /> *[[:Category:OWASP Code Review Project|Code Review Guide]]<br /> *[[:Category:OWASP Testing Project|Testing Guide]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:Software_Assurance_Maturity_Model|SAMM]]<br /> *[[:Category:OWASP Legal Project|Contracting]]<br /> *'''[[:Category:OWASP_Project|More...]]'''<br /> <br /> |} &lt;!-- End Banner --&gt;<br /> <br /> <br /> &lt;center&gt;[https://www.owasp.org/index.php/Membership/2012_Election '''&lt;span style=&quot;color:red&quot;&gt;&lt;font size=&quot;4&quot;&gt;***2012 ELECTION INFORMATION***''']&lt;/font&gt;&lt;/span&gt;<br /> <br /> {|style=&quot;width:100%;background:none;&quot;<br /> |style=&quot;font-size:95%;text-align:left;color:#000&quot;|[[About The Open Web Application Security Project|About]] '''·''' [[Searching|Searching]] '''·''' [[Tutorial|Editing]] '''·''' [[How to add a new article|New Article]] '''·''' [[OWASP Categories]]<br /> |style=&quot;font-size:95%;padding:10px 0;margin:0px;text-align:right;color:#000&quot;| [[Special:Statistics|Statistics]] '''·''' [https://www.owasp.org/index.php?title=Special:Recentchanges&amp;limit=100&amp;hidebots=0 Recent Changes]<br /> |}<br /> <br /> &lt;!-- Main Content --&gt;<br /> {|style=&quot;width:100%;border-spacing:8px;margin:0px -8px&quot;<br /> <br /> &lt;!-- Start of left-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Left Panel}}<br /> <br /> &lt;!-- Start of right-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Right Panel}}<br /> <br /> &lt;!-- End of Main Content --&gt;<br /> |}<br /> <br /> &lt;!-- Member Area --&gt;<br /> <br /> {{Template:OWASP Members Horizontal}}<br /> <br /> __NOTOC__ __NOEDITSECTION__</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Main_Page&diff=136769 2012-09-29T16:27:04Z

<p>Webappsecguy: </p> <hr /> <div><br /> <br /> <br /> &lt;div style=&quot;font-size:7pt;&quot;&gt;<br /> &lt;div align=&quot;center&quot;&gt;<br /> <br /> <br /> <br /> &lt;b&gt;Disclaimer: Banner ads are not endorsements and reflect the messages of the advertiser only. | [https://www.owasp.org/index.php/Advertising More Information]&lt;/b&gt;&lt;/div&gt;&lt;/div&gt;<br /> <br /> &lt;!-- Header --&gt;<br /> <br /> {|style=&quot;width:100%;background-color:#C4D7ED;border:1px solid #183152&quot;<br /> |style=&quot;width:56%;color:#000&quot;|<br /> <br /> {|style=&quot;width:280px;border:solid 0px;background:none&quot;<br /> |-<br /> |style=&quot;width:280px;text-align:center;color:#000&quot; |<br /> &lt;IfLanguage Is=&quot;en&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Welcome to [[About The Open Web Application Security Project|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;the free and open software security community&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> &lt;IfLanguage Is=&quot;es&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Bienvenido a [[About The Open Web Application Security Project/es|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;la comunidad libre y abierta sobre seguridad en aplicaciones&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> |}<br /> <br /> &lt;!-- Special Links --&gt;<br /> |style=&quot;width:110px;font-size:95%;color:#000&quot;|<br /> *[https://www.owasp.org/index.php/Projects_Reboot_2012 2012 Project Support Initiative]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP Top Ten Project|Top Ten]]<br /> *[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ZAP Proxy]<br /> *[[:Category:OWASP WebScarab Project|WebScarab]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP_Enterprise_Security_API|ESAPI]]<br /> *[[:Category:OWASP_Application_Security_Verification_Standard_Project |ASVS]]<br /> *[[:Category:OWASP_AntiSamy_Project|AntiSamy]]<br /> |style=&quot;width:180px;font-size:95%&quot;|<br /> *[[:Category:OWASP Guide Project|Development Guide]]<br /> *[[:Category:OWASP Code Review Project|Code Review Guide]]<br /> *[[:Category:OWASP Testing Project|Testing Guide]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:Software_Assurance_Maturity_Model|SAMM]]<br /> *[[:Category:OWASP Legal Project|Contracting]]<br /> *'''[[:Category:OWASP_Project|More...]]'''<br /> <br /> |} &lt;!-- End Banner --&gt;<br /> <br /> <br /> &lt;center&gt;[https://www.owasp.org/index.php/Membership/2012_Election '''&lt;span style=&quot;color:red&quot;&gt;&lt;font size=&quot;4&quot;&gt;***2012 ELECTION INFORMATION***''']&lt;/font&gt;&lt;/span&gt;<br /> <br /> {|style=&quot;width:100%;background:none;&quot;<br /> |style=&quot;font-size:95%;text-align:left;color:#000&quot;|[[About The Open Web Application Security Project|About]] '''·''' [[Searching|Searching]] '''·''' [[Tutorial|Editing]] '''·''' [[How to add a new article|New Article]] '''·''' [[OWASP Categories]]<br /> |style=&quot;font-size:95%;padding:10px 0;margin:0px;text-align:right;color:#000&quot;| [[Special:Statistics|Statistics]] '''·''' [https://www.owasp.org/index.php?title=Special:Recentchanges&amp;limit=100&amp;hidebots=0 Recent Changes]<br /> |}<br /> <br /> &lt;!-- Main Content --&gt;<br /> {|style=&quot;width:100%;border-spacing:8px;margin:0px -8px&quot;<br /> <br /> &lt;!-- Start of left-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Left Panel}}<br /> <br /> &lt;!-- Start of right-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Right Panel}}<br /> <br /> &lt;!-- End of Main Content --&gt;<br /> |}<br /> <br /> &lt;!-- Member Area --&gt;<br /> <br /> {{Template:OWASP Members Horizontal}}<br /> <br /> __NOTOC__ __NOEDITSECTION__</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Main_Page&diff=136768 2012-09-29T16:26:12Z

<p>Webappsecguy: Putting &lt;openx&gt; tag at top of page.</p> <hr /> <div><br /> <br /> <br /> &lt;div style=&quot;font-size:7pt;&quot;&gt;<br /> &lt;div align=&quot;center&quot;&gt;<br /> <br /> &lt;openx&gt;<br /> <br /> &lt;b&gt;Disclaimer: Banner ads are not endorsements and reflect the messages of the advertiser only. | [https://www.owasp.org/index.php/Advertising More Information]&lt;/b&gt;&lt;/div&gt;&lt;/div&gt;<br /> <br /> &lt;!-- Header --&gt;<br /> <br /> {|style=&quot;width:100%;background-color:#C4D7ED;border:1px solid #183152&quot;<br /> |style=&quot;width:56%;color:#000&quot;|<br /> <br /> {|style=&quot;width:280px;border:solid 0px;background:none&quot;<br /> |-<br /> |style=&quot;width:280px;text-align:center;color:#000&quot; |<br /> &lt;IfLanguage Is=&quot;en&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Welcome to [[About The Open Web Application Security Project|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;the free and open software security community&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> &lt;IfLanguage Is=&quot;es&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Bienvenido a [[About The Open Web Application Security Project/es|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;la comunidad libre y abierta sobre seguridad en aplicaciones&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> |}<br /> <br /> &lt;!-- Special Links --&gt;<br /> |style=&quot;width:110px;font-size:95%;color:#000&quot;|<br /> *[https://www.owasp.org/index.php/Projects_Reboot_2012 2012 Project Support Initiative]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP Top Ten Project|Top Ten]]<br /> *[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ZAP Proxy]<br /> *[[:Category:OWASP WebScarab Project|WebScarab]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP_Enterprise_Security_API|ESAPI]]<br /> *[[:Category:OWASP_Application_Security_Verification_Standard_Project |ASVS]]<br /> *[[:Category:OWASP_AntiSamy_Project|AntiSamy]]<br /> |style=&quot;width:180px;font-size:95%&quot;|<br /> *[[:Category:OWASP Guide Project|Development Guide]]<br /> *[[:Category:OWASP Code Review Project|Code Review Guide]]<br /> *[[:Category:OWASP Testing Project|Testing Guide]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:Software_Assurance_Maturity_Model|SAMM]]<br /> *[[:Category:OWASP Legal Project|Contracting]]<br /> *'''[[:Category:OWASP_Project|More...]]'''<br /> <br /> |} &lt;!-- End Banner --&gt;<br /> <br /> <br /> &lt;center&gt;[https://www.owasp.org/index.php/Membership/2012_Election '''&lt;span style=&quot;color:red&quot;&gt;&lt;font size=&quot;4&quot;&gt;***2012 ELECTION INFORMATION***''']&lt;/font&gt;&lt;/span&gt;<br /> <br /> {|style=&quot;width:100%;background:none;&quot;<br /> |style=&quot;font-size:95%;text-align:left;color:#000&quot;|[[About The Open Web Application Security Project|About]] '''·''' [[Searching|Searching]] '''·''' [[Tutorial|Editing]] '''·''' [[How to add a new article|New Article]] '''·''' [[OWASP Categories]]<br /> |style=&quot;font-size:95%;padding:10px 0;margin:0px;text-align:right;color:#000&quot;| [[Special:Statistics|Statistics]] '''·''' [https://www.owasp.org/index.php?title=Special:Recentchanges&amp;limit=100&amp;hidebots=0 Recent Changes]<br /> |}<br /> <br /> &lt;!-- Main Content --&gt;<br /> {|style=&quot;width:100%;border-spacing:8px;margin:0px -8px&quot;<br /> <br /> &lt;!-- Start of left-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Left Panel}}<br /> <br /> &lt;!-- Start of right-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Right Panel}}<br /> <br /> &lt;!-- End of Main Content --&gt;<br /> |}<br /> <br /> &lt;!-- Member Area --&gt;<br /> <br /> {{Template:OWASP Members Horizontal}}<br /> <br /> __NOTOC__ __NOEDITSECTION__</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.js&diff=136767 2012-09-29T15:38:48Z

<p>Webappsecguy: Removing unnecessary OpenX JavaScript.</p> <hr /> <div>/* Any JavaScript here will be loaded for all users on every page load. */<br /> <br /> /** Collapsible tables *********************************************************<br /> *<br /> * Description: Allows tables to be collapsed, showing only the header. See<br /> * http://www.mediawiki.org/wiki/Manual:Collapsible_tables.<br /> * Maintainers: [[en:User:R. Koot]]<br /> */<br /> <br /> var autoCollapse = 2;<br /> var collapseCaption = 'hide';<br /> var expandCaption = 'show';<br /> <br /> function collapseTable( tableIndex ) {<br /> var Button = document.getElementById( 'collapseButton' + tableIndex );<br /> var Table = document.getElementById( 'collapsibleTable' + tableIndex );<br /> <br /> if ( !Table || !Button ) {<br /> return false;<br /> }<br /> <br /> var Rows = Table.rows;<br /> <br /> if ( Button.firstChild.data == collapseCaption ) {<br /> for ( var i = 1; i &lt; Rows.length; i++ ) {<br /> Rows[i].style.display = 'none';<br /> }<br /> Button.firstChild.data = expandCaption;<br /> } else {<br /> for ( var i = 1; i &lt; Rows.length; i++ ) {<br /> Rows[i].style.display = Rows[0].style.display;<br /> }<br /> Button.firstChild.data = collapseCaption;<br /> }<br /> }<br /> <br /> function createCollapseButtons() {<br /> var tableIndex = 0;<br /> var NavigationBoxes = new Object();<br /> var Tables = document.getElementsByTagName( 'table' );<br /> <br /> for ( var i = 0; i &lt; Tables.length; i++ ) {<br /> if ( hasClass( Tables[i], 'collapsible' ) ) {<br /> <br /> /* only add button and increment count if there is a header row to work with */<br /> var HeaderRow = Tables[i].getElementsByTagName( 'tr' )[0];<br /> if ( !HeaderRow ) {<br /> continue;<br /> }<br /> var Header = HeaderRow.getElementsByTagName( 'th' )[0];<br /> if ( !Header ) {<br /> continue;<br /> }<br /> <br /> NavigationBoxes[tableIndex] = Tables[i];<br /> Tables[i].setAttribute( 'id', 'collapsibleTable' + tableIndex );<br /> <br /> var Button = document.createElement( 'span' );<br /> var ButtonLink = document.createElement( 'a' );<br /> var ButtonText = document.createTextNode( collapseCaption );<br /> <br /> Button.className = 'collapseButton'; // Styles are declared in [[MediaWiki:Common.css]]<br /> <br /> ButtonLink.style.color = Header.style.color;<br /> ButtonLink.setAttribute( 'id', 'collapseButton' + tableIndex );<br /> ButtonLink.setAttribute( 'href', &quot;javascript:collapseTable(&quot; + tableIndex + &quot;);&quot; );<br /> ButtonLink.appendChild( ButtonText );<br /> <br /> Button.appendChild( document.createTextNode( '[' ) );<br /> Button.appendChild( ButtonLink );<br /> Button.appendChild( document.createTextNode( ']' ) );<br /> <br /> Header.insertBefore( Button, Header.childNodes[0] );<br /> tableIndex++;<br /> }<br /> }<br /> <br /> for ( var i = 0; i &lt; tableIndex; i++ ) {<br /> if ( hasClass( NavigationBoxes[i], 'collapsed' ) || ( tableIndex &gt;= autoCollapse &amp;&amp; hasClass( NavigationBoxes[i], 'autocollapse' ) ) ) {<br /> collapseTable( i );<br /> } else if ( hasClass( NavigationBoxes[i], 'innercollapse' ) ) {<br /> var element = NavigationBoxes[i];<br /> while ( element = element.parentNode ) {<br /> if ( hasClass( element, 'outercollapse' ) ) {<br /> collapseTable( i );<br /> break;<br /> }<br /> }<br /> }<br /> }<br /> }<br /> <br /> addOnloadHook( createCollapseButtons );<br /> <br /> /** Test if an element has a certain class **************************************<br /> *<br /> * Description: Uses regular expressions and caching for better performance.<br /> * Maintainers: [[User:Mike Dillon]], [[User:R. Koot]], [[User:SG]]<br /> */<br /> <br /> var hasClass = ( function() {<br /> var reCache = {};<br /> return function( element, className ) {<br /> return ( reCache[className] ? reCache[className] : ( reCache[className] = new RegExp( &quot;(?:\\s|^)&quot; + className + &quot;(?:\\s|$)&quot; ) ) ).test( element.className );<br /> };<br /> })();</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Main_Page&diff=136766 2012-09-29T14:34:58Z

<p>Webappsecguy: Adding &lt;openx&gt; at page footer for demo.</p> <hr /> <div><br /> <br /> <br /> &lt;div style=&quot;font-size:7pt;&quot;&gt;<br /> &lt;div align=&quot;center&quot;&gt; [[Image:Cenzic.png|link=https://info.cenzic.com/start-risk-calculator.html]] --- [[Image:Checkmarx_Logo_Final.gif‎|link=http://lp.checkmarx.com/owasp-home-page-start-free-trial/]]&lt;br&gt; &lt;hr&gt; [[Image:HackerHalted_468x60px.jpg|link=http://www.hackerhalted.com/2012/]] --- [[Image:Trustwave_banner_ad_Sept_18,_2012.png|link=https://www.trustwave.com/application-security/]]&lt;br&gt;<br /> <br /> &lt;b&gt;Disclaimer: Banner ads are not endorsements and reflect the messages of the advertiser only. | [https://www.owasp.org/index.php/Advertising More Information]&lt;/b&gt;&lt;/div&gt;&lt;/div&gt;<br /> <br /> &lt;!-- Header --&gt;<br /> <br /> {|style=&quot;width:100%;background-color:#C4D7ED;border:1px solid #183152&quot;<br /> |style=&quot;width:56%;color:#000&quot;|<br /> <br /> {|style=&quot;width:280px;border:solid 0px;background:none&quot;<br /> |-<br /> |style=&quot;width:280px;text-align:center;color:#000&quot; |<br /> &lt;IfLanguage Is=&quot;en&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Welcome to [[About The Open Web Application Security Project|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;the free and open software security community&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> &lt;IfLanguage Is=&quot;es&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Bienvenido a [[About The Open Web Application Security Project/es|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;la comunidad libre y abierta sobre seguridad en aplicaciones&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> |}<br /> <br /> &lt;!-- Special Links --&gt;<br /> |style=&quot;width:110px;font-size:95%;color:#000&quot;|<br /> *[https://www.owasp.org/index.php/Projects_Reboot_2012 2012 Project Support Initiative]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP Top Ten Project|Top Ten]]<br /> *[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ZAP Proxy]<br /> *[[:Category:OWASP WebScarab Project|WebScarab]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP_Enterprise_Security_API|ESAPI]]<br /> *[[:Category:OWASP_Application_Security_Verification_Standard_Project |ASVS]]<br /> *[[:Category:OWASP_AntiSamy_Project|AntiSamy]]<br /> |style=&quot;width:180px;font-size:95%&quot;|<br /> *[[:Category:OWASP Guide Project|Development Guide]]<br /> *[[:Category:OWASP Code Review Project|Code Review Guide]]<br /> *[[:Category:OWASP Testing Project|Testing Guide]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:Software_Assurance_Maturity_Model|SAMM]]<br /> *[[:Category:OWASP Legal Project|Contracting]]<br /> *'''[[:Category:OWASP_Project|More...]]'''<br /> <br /> |} &lt;!-- End Banner --&gt;<br /> <br /> <br /> &lt;center&gt;[https://www.owasp.org/index.php/Membership/2012_Election '''&lt;span style=&quot;color:red&quot;&gt;&lt;font size=&quot;4&quot;&gt;***2012 ELECTION INFORMATION***''']&lt;/font&gt;&lt;/span&gt;<br /> <br /> {|style=&quot;width:100%;background:none;&quot;<br /> |style=&quot;font-size:95%;text-align:left;color:#000&quot;|[[About The Open Web Application Security Project|About]] '''·''' [[Searching|Searching]] '''·''' [[Tutorial|Editing]] '''·''' [[How to add a new article|New Article]] '''·''' [[OWASP Categories]]<br /> |style=&quot;font-size:95%;padding:10px 0;margin:0px;text-align:right;color:#000&quot;| [[Special:Statistics|Statistics]] '''·''' [https://www.owasp.org/index.php?title=Special:Recentchanges&amp;limit=100&amp;hidebots=0 Recent Changes]<br /> |}<br /> <br /> &lt;!-- Main Content --&gt;<br /> {|style=&quot;width:100%;border-spacing:8px;margin:0px -8px&quot;<br /> <br /> &lt;!-- Start of left-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Left Panel}}<br /> <br /> &lt;!-- Start of right-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Right Panel}}<br /> <br /> &lt;!-- End of Main Content --&gt;<br /> |}<br /> <br /> &lt;!-- Member Area --&gt;<br /> <br /> {{Template:OWASP Members Horizontal}}<br /> <br /> <br /> &lt;openx&gt;<br /> <br /> __NOTOC__ __NOEDITSECTION__</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Main_Page&diff=136765 2012-09-29T14:32:15Z

<p>Webappsecguy: Removing &lt;openx&gt;</p> <hr /> <div><br /> <br /> <br /> &lt;div style=&quot;font-size:7pt;&quot;&gt;<br /> &lt;div align=&quot;center&quot;&gt; [[Image:Cenzic.png|link=https://info.cenzic.com/start-risk-calculator.html]] --- [[Image:Checkmarx_Logo_Final.gif‎|link=http://lp.checkmarx.com/owasp-home-page-start-free-trial/]]&lt;br&gt; &lt;hr&gt; [[Image:HackerHalted_468x60px.jpg|link=http://www.hackerhalted.com/2012/]] --- [[Image:Trustwave_banner_ad_Sept_18,_2012.png|link=https://www.trustwave.com/application-security/]]&lt;br&gt;<br /> <br /> &lt;b&gt;Disclaimer: Banner ads are not endorsements and reflect the messages of the advertiser only. | [https://www.owasp.org/index.php/Advertising More Information]&lt;/b&gt;&lt;/div&gt;&lt;/div&gt;<br /> <br /> &lt;!-- Header --&gt;<br /> <br /> {|style=&quot;width:100%;background-color:#C4D7ED;border:1px solid #183152&quot;<br /> |style=&quot;width:56%;color:#000&quot;|<br /> <br /> {|style=&quot;width:280px;border:solid 0px;background:none&quot;<br /> |-<br /> |style=&quot;width:280px;text-align:center;color:#000&quot; |<br /> &lt;IfLanguage Is=&quot;en&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Welcome to [[About The Open Web Application Security Project|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;the free and open software security community&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> &lt;IfLanguage Is=&quot;es&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Bienvenido a [[About The Open Web Application Security Project/es|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;la comunidad libre y abierta sobre seguridad en aplicaciones&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> |}<br /> <br /> &lt;!-- Special Links --&gt;<br /> |style=&quot;width:110px;font-size:95%;color:#000&quot;|<br /> *[https://www.owasp.org/index.php/Projects_Reboot_2012 2012 Project Support Initiative]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP Top Ten Project|Top Ten]]<br /> *[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ZAP Proxy]<br /> *[[:Category:OWASP WebScarab Project|WebScarab]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP_Enterprise_Security_API|ESAPI]]<br /> *[[:Category:OWASP_Application_Security_Verification_Standard_Project |ASVS]]<br /> *[[:Category:OWASP_AntiSamy_Project|AntiSamy]]<br /> |style=&quot;width:180px;font-size:95%&quot;|<br /> *[[:Category:OWASP Guide Project|Development Guide]]<br /> *[[:Category:OWASP Code Review Project|Code Review Guide]]<br /> *[[:Category:OWASP Testing Project|Testing Guide]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:Software_Assurance_Maturity_Model|SAMM]]<br /> *[[:Category:OWASP Legal Project|Contracting]]<br /> *'''[[:Category:OWASP_Project|More...]]'''<br /> <br /> |} &lt;!-- End Banner --&gt;<br /> <br /> <br /> &lt;center&gt;[https://www.owasp.org/index.php/Membership/2012_Election '''&lt;span style=&quot;color:red&quot;&gt;&lt;font size=&quot;4&quot;&gt;***2012 ELECTION INFORMATION***''']&lt;/font&gt;&lt;/span&gt;<br /> <br /> {|style=&quot;width:100%;background:none;&quot;<br /> |style=&quot;font-size:95%;text-align:left;color:#000&quot;|[[About The Open Web Application Security Project|About]] '''·''' [[Searching|Searching]] '''·''' [[Tutorial|Editing]] '''·''' [[How to add a new article|New Article]] '''·''' [[OWASP Categories]]<br /> |style=&quot;font-size:95%;padding:10px 0;margin:0px;text-align:right;color:#000&quot;| [[Special:Statistics|Statistics]] '''·''' [https://www.owasp.org/index.php?title=Special:Recentchanges&amp;limit=100&amp;hidebots=0 Recent Changes]<br /> |}<br /> <br /> &lt;!-- Main Content --&gt;<br /> {|style=&quot;width:100%;border-spacing:8px;margin:0px -8px&quot;<br /> <br /> &lt;!-- Start of left-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Left Panel}}<br /> <br /> &lt;!-- Start of right-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Right Panel}}<br /> <br /> &lt;!-- End of Main Content --&gt;<br /> |}<br /> <br /> &lt;!-- Member Area --&gt;<br /> <br /> {{Template:OWASP Members Horizontal}}<br /> <br /> __NOTOC__ __NOEDITSECTION__</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Main_Page&diff=136764 2012-09-29T14:31:40Z

<p>Webappsecguy: Re-adding &lt;openx&gt;.</p> <hr /> <div>&lt;openx&gt;<br /> <br /> <br /> &lt;div style=&quot;font-size:7pt;&quot;&gt;<br /> &lt;div align=&quot;center&quot;&gt; [[Image:Cenzic.png|link=https://info.cenzic.com/start-risk-calculator.html]] --- [[Image:Checkmarx_Logo_Final.gif‎|link=http://lp.checkmarx.com/owasp-home-page-start-free-trial/]]&lt;br&gt; &lt;hr&gt; [[Image:HackerHalted_468x60px.jpg|link=http://www.hackerhalted.com/2012/]] --- [[Image:Trustwave_banner_ad_Sept_18,_2012.png|link=https://www.trustwave.com/application-security/]]&lt;br&gt;<br /> <br /> &lt;b&gt;Disclaimer: Banner ads are not endorsements and reflect the messages of the advertiser only. | [https://www.owasp.org/index.php/Advertising More Information]&lt;/b&gt;&lt;/div&gt;&lt;/div&gt;<br /> <br /> &lt;!-- Header --&gt;<br /> <br /> {|style=&quot;width:100%;background-color:#C4D7ED;border:1px solid #183152&quot;<br /> |style=&quot;width:56%;color:#000&quot;|<br /> <br /> {|style=&quot;width:280px;border:solid 0px;background:none&quot;<br /> |-<br /> |style=&quot;width:280px;text-align:center;color:#000&quot; |<br /> &lt;IfLanguage Is=&quot;en&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Welcome to [[About The Open Web Application Security Project|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;the free and open software security community&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> &lt;IfLanguage Is=&quot;es&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Bienvenido a [[About The Open Web Application Security Project/es|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;la comunidad libre y abierta sobre seguridad en aplicaciones&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> |}<br /> <br /> &lt;!-- Special Links --&gt;<br /> |style=&quot;width:110px;font-size:95%;color:#000&quot;|<br /> *[https://www.owasp.org/index.php/Projects_Reboot_2012 2012 Project Support Initiative]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP Top Ten Project|Top Ten]]<br /> *[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ZAP Proxy]<br /> *[[:Category:OWASP WebScarab Project|WebScarab]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP_Enterprise_Security_API|ESAPI]]<br /> *[[:Category:OWASP_Application_Security_Verification_Standard_Project |ASVS]]<br /> *[[:Category:OWASP_AntiSamy_Project|AntiSamy]]<br /> |style=&quot;width:180px;font-size:95%&quot;|<br /> *[[:Category:OWASP Guide Project|Development Guide]]<br /> *[[:Category:OWASP Code Review Project|Code Review Guide]]<br /> *[[:Category:OWASP Testing Project|Testing Guide]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:Software_Assurance_Maturity_Model|SAMM]]<br /> *[[:Category:OWASP Legal Project|Contracting]]<br /> *'''[[:Category:OWASP_Project|More...]]'''<br /> <br /> |} &lt;!-- End Banner --&gt;<br /> <br /> <br /> &lt;center&gt;[https://www.owasp.org/index.php/Membership/2012_Election '''&lt;span style=&quot;color:red&quot;&gt;&lt;font size=&quot;4&quot;&gt;***2012 ELECTION INFORMATION***''']&lt;/font&gt;&lt;/span&gt;<br /> <br /> {|style=&quot;width:100%;background:none;&quot;<br /> |style=&quot;font-size:95%;text-align:left;color:#000&quot;|[[About The Open Web Application Security Project|About]] '''·''' [[Searching|Searching]] '''·''' [[Tutorial|Editing]] '''·''' [[How to add a new article|New Article]] '''·''' [[OWASP Categories]]<br /> |style=&quot;font-size:95%;padding:10px 0;margin:0px;text-align:right;color:#000&quot;| [[Special:Statistics|Statistics]] '''·''' [https://www.owasp.org/index.php?title=Special:Recentchanges&amp;limit=100&amp;hidebots=0 Recent Changes]<br /> |}<br /> <br /> &lt;!-- Main Content --&gt;<br /> {|style=&quot;width:100%;border-spacing:8px;margin:0px -8px&quot;<br /> <br /> &lt;!-- Start of left-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Left Panel}}<br /> <br /> &lt;!-- Start of right-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Right Panel}}<br /> <br /> &lt;!-- End of Main Content --&gt;<br /> |}<br /> <br /> &lt;!-- Member Area --&gt;<br /> <br /> {{Template:OWASP Members Horizontal}}<br /> <br /> __NOTOC__ __NOEDITSECTION__</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Main_Page&diff=136763 2012-09-29T14:29:17Z

<p>Webappsecguy: Removing &lt;openx&gt;</p> <hr /> <div><br /> &lt;div style=&quot;font-size:7pt;&quot;&gt;<br /> &lt;div align=&quot;center&quot;&gt; [[Image:Cenzic.png|link=https://info.cenzic.com/start-risk-calculator.html]] --- [[Image:Checkmarx_Logo_Final.gif‎|link=http://lp.checkmarx.com/owasp-home-page-start-free-trial/]]&lt;br&gt; &lt;hr&gt; [[Image:HackerHalted_468x60px.jpg|link=http://www.hackerhalted.com/2012/]] --- [[Image:Trustwave_banner_ad_Sept_18,_2012.png|link=https://www.trustwave.com/application-security/]]&lt;br&gt;<br /> <br /> &lt;b&gt;Disclaimer: Banner ads are not endorsements and reflect the messages of the advertiser only. | [https://www.owasp.org/index.php/Advertising More Information]&lt;/b&gt;&lt;/div&gt;&lt;/div&gt;<br /> <br /> &lt;!-- Header --&gt;<br /> <br /> {|style=&quot;width:100%;background-color:#C4D7ED;border:1px solid #183152&quot;<br /> |style=&quot;width:56%;color:#000&quot;|<br /> <br /> {|style=&quot;width:280px;border:solid 0px;background:none&quot;<br /> |-<br /> |style=&quot;width:280px;text-align:center;color:#000&quot; |<br /> &lt;IfLanguage Is=&quot;en&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Welcome to [[About The Open Web Application Security Project|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;the free and open software security community&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> &lt;IfLanguage Is=&quot;es&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Bienvenido a [[About The Open Web Application Security Project/es|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;la comunidad libre y abierta sobre seguridad en aplicaciones&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> |}<br /> <br /> &lt;!-- Special Links --&gt;<br /> |style=&quot;width:110px;font-size:95%;color:#000&quot;|<br /> *[https://www.owasp.org/index.php/Projects_Reboot_2012 2012 Project Support Initiative]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP Top Ten Project|Top Ten]]<br /> *[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ZAP Proxy]<br /> *[[:Category:OWASP WebScarab Project|WebScarab]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP_Enterprise_Security_API|ESAPI]]<br /> *[[:Category:OWASP_Application_Security_Verification_Standard_Project |ASVS]]<br /> *[[:Category:OWASP_AntiSamy_Project|AntiSamy]]<br /> |style=&quot;width:180px;font-size:95%&quot;|<br /> *[[:Category:OWASP Guide Project|Development Guide]]<br /> *[[:Category:OWASP Code Review Project|Code Review Guide]]<br /> *[[:Category:OWASP Testing Project|Testing Guide]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:Software_Assurance_Maturity_Model|SAMM]]<br /> *[[:Category:OWASP Legal Project|Contracting]]<br /> *'''[[:Category:OWASP_Project|More...]]'''<br /> <br /> |} &lt;!-- End Banner --&gt;<br /> <br /> <br /> &lt;center&gt;[https://www.owasp.org/index.php/Membership/2012_Election '''&lt;span style=&quot;color:red&quot;&gt;&lt;font size=&quot;4&quot;&gt;***2012 ELECTION INFORMATION***''']&lt;/font&gt;&lt;/span&gt;<br /> <br /> {|style=&quot;width:100%;background:none;&quot;<br /> |style=&quot;font-size:95%;text-align:left;color:#000&quot;|[[About The Open Web Application Security Project|About]] '''·''' [[Searching|Searching]] '''·''' [[Tutorial|Editing]] '''·''' [[How to add a new article|New Article]] '''·''' [[OWASP Categories]]<br /> |style=&quot;font-size:95%;padding:10px 0;margin:0px;text-align:right;color:#000&quot;| [[Special:Statistics|Statistics]] '''·''' [https://www.owasp.org/index.php?title=Special:Recentchanges&amp;limit=100&amp;hidebots=0 Recent Changes]<br /> |}<br /> <br /> &lt;!-- Main Content --&gt;<br /> {|style=&quot;width:100%;border-spacing:8px;margin:0px -8px&quot;<br /> <br /> &lt;!-- Start of left-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Left Panel}}<br /> <br /> &lt;!-- Start of right-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Right Panel}}<br /> <br /> &lt;!-- End of Main Content --&gt;<br /> |}<br /> <br /> &lt;!-- Member Area --&gt;<br /> <br /> {{Template:OWASP Members Horizontal}}<br /> <br /> __NOTOC__ __NOEDITSECTION__</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Main_Page&diff=136762 2012-09-29T14:28:58Z

<p>Webappsecguy: Adding &lt;openx&gt;.</p> <hr /> <div>&lt;openx&gt;<br /> &lt;div style=&quot;font-size:7pt;&quot;&gt;<br /> &lt;div align=&quot;center&quot;&gt; [[Image:Cenzic.png|link=https://info.cenzic.com/start-risk-calculator.html]] --- [[Image:Checkmarx_Logo_Final.gif‎|link=http://lp.checkmarx.com/owasp-home-page-start-free-trial/]]&lt;br&gt; &lt;hr&gt; [[Image:HackerHalted_468x60px.jpg|link=http://www.hackerhalted.com/2012/]] --- [[Image:Trustwave_banner_ad_Sept_18,_2012.png|link=https://www.trustwave.com/application-security/]]&lt;br&gt;<br /> <br /> &lt;b&gt;Disclaimer: Banner ads are not endorsements and reflect the messages of the advertiser only. | [https://www.owasp.org/index.php/Advertising More Information]&lt;/b&gt;&lt;/div&gt;&lt;/div&gt;<br /> <br /> &lt;!-- Header --&gt;<br /> <br /> {|style=&quot;width:100%;background-color:#C4D7ED;border:1px solid #183152&quot;<br /> |style=&quot;width:56%;color:#000&quot;|<br /> <br /> {|style=&quot;width:280px;border:solid 0px;background:none&quot;<br /> |-<br /> |style=&quot;width:280px;text-align:center;color:#000&quot; |<br /> &lt;IfLanguage Is=&quot;en&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Welcome to [[About The Open Web Application Security Project|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;the free and open software security community&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> &lt;IfLanguage Is=&quot;es&quot;&gt;<br /> &lt;div style=&quot;font-size:162%;border:none;margin: 0;color:#000&quot;&gt;'''Bienvenido a [[About The Open Web Application Security Project/es|OWASP]]'''&lt;/div&gt;&lt;div style=&quot;top:+0.2em;font-size: 95%&quot;&gt;la comunidad libre y abierta sobre seguridad en aplicaciones&lt;/div&gt;<br /> &lt;/IfLanguage&gt;<br /> |}<br /> <br /> &lt;!-- Special Links --&gt;<br /> |style=&quot;width:110px;font-size:95%;color:#000&quot;|<br /> *[https://www.owasp.org/index.php/Projects_Reboot_2012 2012 Project Support Initiative]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP Top Ten Project|Top Ten]]<br /> *[https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ZAP Proxy]<br /> *[[:Category:OWASP WebScarab Project|WebScarab]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:OWASP_Enterprise_Security_API|ESAPI]]<br /> *[[:Category:OWASP_Application_Security_Verification_Standard_Project |ASVS]]<br /> *[[:Category:OWASP_AntiSamy_Project|AntiSamy]]<br /> |style=&quot;width:180px;font-size:95%&quot;|<br /> *[[:Category:OWASP Guide Project|Development Guide]]<br /> *[[:Category:OWASP Code Review Project|Code Review Guide]]<br /> *[[:Category:OWASP Testing Project|Testing Guide]]<br /> |style=&quot;width:110px;font-size:95%&quot;|<br /> *[[:Category:Software_Assurance_Maturity_Model|SAMM]]<br /> *[[:Category:OWASP Legal Project|Contracting]]<br /> *'''[[:Category:OWASP_Project|More...]]'''<br /> <br /> |} &lt;!-- End Banner --&gt;<br /> <br /> <br /> &lt;center&gt;[https://www.owasp.org/index.php/Membership/2012_Election '''&lt;span style=&quot;color:red&quot;&gt;&lt;font size=&quot;4&quot;&gt;***2012 ELECTION INFORMATION***''']&lt;/font&gt;&lt;/span&gt;<br /> <br /> {|style=&quot;width:100%;background:none;&quot;<br /> |style=&quot;font-size:95%;text-align:left;color:#000&quot;|[[About The Open Web Application Security Project|About]] '''·''' [[Searching|Searching]] '''·''' [[Tutorial|Editing]] '''·''' [[How to add a new article|New Article]] '''·''' [[OWASP Categories]]<br /> |style=&quot;font-size:95%;padding:10px 0;margin:0px;text-align:right;color:#000&quot;| [[Special:Statistics|Statistics]] '''·''' [https://www.owasp.org/index.php?title=Special:Recentchanges&amp;limit=100&amp;hidebots=0 Recent Changes]<br /> |}<br /> <br /> &lt;!-- Main Content --&gt;<br /> {|style=&quot;width:100%;border-spacing:8px;margin:0px -8px&quot;<br /> <br /> &lt;!-- Start of left-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Left Panel}}<br /> <br /> &lt;!-- Start of right-column --&gt;<br /> |class=&quot;MainPageBG&quot; style=&quot;width:50%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top&quot;|{{Main Right Panel}}<br /> <br /> &lt;!-- End of Main Content --&gt;<br /> |}<br /> <br /> &lt;!-- Member Area --&gt;<br /> <br /> {{Template:OWASP Members Horizontal}}<br /> <br /> __NOTOC__ __NOEDITSECTION__</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.js&diff=136761 2012-09-29T12:59:33Z

<p>Webappsecguy: removing commenting around OpenX code.</p> <hr /> <div>/* Any JavaScript here will be loaded for all users on every page load. */<br /> <br /> /** Collapsible tables *********************************************************<br /> *<br /> * Description: Allows tables to be collapsed, showing only the header. See<br /> * http://www.mediawiki.org/wiki/Manual:Collapsible_tables.<br /> * Maintainers: [[en:User:R. Koot]]<br /> */<br /> <br /> var autoCollapse = 2;<br /> var collapseCaption = 'hide';<br /> var expandCaption = 'show';<br /> <br /> function collapseTable( tableIndex ) {<br /> var Button = document.getElementById( 'collapseButton' + tableIndex );<br /> var Table = document.getElementById( 'collapsibleTable' + tableIndex );<br /> <br /> if ( !Table || !Button ) {<br /> return false;<br /> }<br /> <br /> var Rows = Table.rows;<br /> <br /> if ( Button.firstChild.data == collapseCaption ) {<br /> for ( var i = 1; i &lt; Rows.length; i++ ) {<br /> Rows[i].style.display = 'none';<br /> }<br /> Button.firstChild.data = expandCaption;<br /> } else {<br /> for ( var i = 1; i &lt; Rows.length; i++ ) {<br /> Rows[i].style.display = Rows[0].style.display;<br /> }<br /> Button.firstChild.data = collapseCaption;<br /> }<br /> }<br /> <br /> function createCollapseButtons() {<br /> var tableIndex = 0;<br /> var NavigationBoxes = new Object();<br /> var Tables = document.getElementsByTagName( 'table' );<br /> <br /> for ( var i = 0; i &lt; Tables.length; i++ ) {<br /> if ( hasClass( Tables[i], 'collapsible' ) ) {<br /> <br /> /* only add button and increment count if there is a header row to work with */<br /> var HeaderRow = Tables[i].getElementsByTagName( 'tr' )[0];<br /> if ( !HeaderRow ) {<br /> continue;<br /> }<br /> var Header = HeaderRow.getElementsByTagName( 'th' )[0];<br /> if ( !Header ) {<br /> continue;<br /> }<br /> <br /> NavigationBoxes[tableIndex] = Tables[i];<br /> Tables[i].setAttribute( 'id', 'collapsibleTable' + tableIndex );<br /> <br /> var Button = document.createElement( 'span' );<br /> var ButtonLink = document.createElement( 'a' );<br /> var ButtonText = document.createTextNode( collapseCaption );<br /> <br /> Button.className = 'collapseButton'; // Styles are declared in [[MediaWiki:Common.css]]<br /> <br /> ButtonLink.style.color = Header.style.color;<br /> ButtonLink.setAttribute( 'id', 'collapseButton' + tableIndex );<br /> ButtonLink.setAttribute( 'href', &quot;javascript:collapseTable(&quot; + tableIndex + &quot;);&quot; );<br /> ButtonLink.appendChild( ButtonText );<br /> <br /> Button.appendChild( document.createTextNode( '[' ) );<br /> Button.appendChild( ButtonLink );<br /> Button.appendChild( document.createTextNode( ']' ) );<br /> <br /> Header.insertBefore( Button, Header.childNodes[0] );<br /> tableIndex++;<br /> }<br /> }<br /> <br /> for ( var i = 0; i &lt; tableIndex; i++ ) {<br /> if ( hasClass( NavigationBoxes[i], 'collapsed' ) || ( tableIndex &gt;= autoCollapse &amp;&amp; hasClass( NavigationBoxes[i], 'autocollapse' ) ) ) {<br /> collapseTable( i );<br /> } else if ( hasClass( NavigationBoxes[i], 'innercollapse' ) ) {<br /> var element = NavigationBoxes[i];<br /> while ( element = element.parentNode ) {<br /> if ( hasClass( element, 'outercollapse' ) ) {<br /> collapseTable( i );<br /> break;<br /> }<br /> }<br /> }<br /> }<br /> }<br /> <br /> addOnloadHook( createCollapseButtons );<br /> <br /> /** Test if an element has a certain class **************************************<br /> *<br /> * Description: Uses regular expressions and caching for better performance.<br /> * Maintainers: [[User:Mike Dillon]], [[User:R. Koot]], [[User:SG]]<br /> */<br /> <br /> var hasClass = ( function() {<br /> var reCache = {};<br /> return function( element, className ) {<br /> return ( reCache[className] ? reCache[className] : ( reCache[className] = new RegExp( &quot;(?:\\s|^)&quot; + className + &quot;(?:\\s|$)&quot; ) ) ).test( element.className );<br /> };<br /> })();<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> /* openx copy-and-paste code from https://d1.openx.org/spcjs.php?id=65157&amp;amp;target=_blank */<br /> <br /> if (typeof(OA_zones) != 'undefined') {<br /> var OA_zoneids = '';<br /> for (var zonename in OA_zones) OA_zoneids += escape(zonename+'=' + OA_zones[zonename] + &quot;|&quot;);<br /> OA_zoneids += '&amp;amp;nz=1';<br /> } else {<br /> var OA_zoneids = escape('281199');<br /> }<br /> <br /> if (typeof(OA_source) == 'undefined') { OA_source = ''; }<br /> var OA_p=location.protocol=='https:'?'https://d1.openx.org/spc.php':'http://d1.openx.org/spc.php';<br /> var OA_r=Math.floor(Math.random()*99999999);<br /> OA_output = new Array();<br /> <br /> var OA_spc=&quot;&lt;&quot;+&quot;script type='text/javascript' &quot;;<br /> OA_spc+=&quot;src='&quot;+OA_p+&quot;?zones=&quot;+OA_zoneids;<br /> OA_spc+=&quot;&amp;amp;source=&quot;+escape(OA_source)+&quot;&amp;amp;r=&quot;+OA_r;<br /> OA_spc+=&quot;&amp;amp;amp%3Btarget=_blank&quot;;<br /> OA_spc+=(document.charset ? '&amp;amp;charset='+document.charset : (document.characterSet ? '&amp;amp;charset='+document.characterSet : ''));<br /> <br /> if (window.location) OA_spc+=&quot;&amp;amp;loc=&quot;+escape(window.location);<br /> if (document.referrer) OA_spc+=&quot;&amp;amp;referer=&quot;+escape(document.referrer);<br /> OA_spc+=&quot;'&gt;&lt;&quot;+&quot;/script&gt;&quot;;<br /> document.write(OA_spc);<br /> <br /> function OA_show(name) {<br /> if (typeof(OA_output[name]) == 'undefined') {<br /> return;<br /> } else {<br /> document.write(OA_output[name]);<br /> }<br /> }<br /> <br /> function OA_showpop(name) {<br /> zones = window.OA_zones ? window.OA_zones : false;<br /> var zoneid = name;<br /> if (typeof(window.OA_zones) != 'undefined') {<br /> if (typeof(zones[name]) == 'undefined') {<br /> return;<br /> }<br /> zoneid = zones[name];<br /> }<br /> <br /> OA_p=location.protocol=='https:'?'https://d1.openx.org/apu.php':'http://d1.openx.org/apu.php';<br /> <br /> var OA_pop=&quot;&lt;&quot;+&quot;script type='text/javascript' &quot;;<br /> OA_pop+=&quot;src='&quot;+OA_p+&quot;?zoneid=&quot;+zoneid;<br /> OA_pop+=&quot;&amp;amp;source=&quot;+escape(OA_source)+&quot;&amp;amp;r=&quot;+OA_r;<br /> OA_spc+=&quot;&amp;amp;amp%3Btarget=_blank&quot;;<br /> if (window.location) OA_pop+=&quot;&amp;amp;loc=&quot;+escape(window.location);<br /> if (document.referrer) OA_pop+=&quot;&amp;amp;referer=&quot;+escape(document.referrer);<br /> OA_pop+=&quot;'&gt;&lt;&quot;+&quot;/script&gt;&quot;;<br /> <br /> document.write(OA_pop);<br /> }<br /> var OA_fo = '';<br /> OA_fo += &quot;&lt;&quot;+&quot;script type=\'text/javascript\' src=\'https://d1.openx.org/fl.js\'&gt;&lt;&quot;+&quot;/script&gt;\n&quot;;<br /> document.write(OA_fo);<br /> <br /> <br /> /* end of OpenX copy-and-paste */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=MediaWiki:Common.js&diff=136760 2012-09-29T12:36:42Z

<p>Webappsecguy: Adding OpenX global JS, instead of &lt;script src&gt;ing it from the third party adserver.</p> <hr /> <div>/* Any JavaScript here will be loaded for all users on every page load. */<br /> <br /> /** Collapsible tables *********************************************************<br /> *<br /> * Description: Allows tables to be collapsed, showing only the header. See<br /> * http://www.mediawiki.org/wiki/Manual:Collapsible_tables.<br /> * Maintainers: [[en:User:R. Koot]]<br /> */<br /> <br /> var autoCollapse = 2;<br /> var collapseCaption = 'hide';<br /> var expandCaption = 'show';<br /> <br /> function collapseTable( tableIndex ) {<br /> var Button = document.getElementById( 'collapseButton' + tableIndex );<br /> var Table = document.getElementById( 'collapsibleTable' + tableIndex );<br /> <br /> if ( !Table || !Button ) {<br /> return false;<br /> }<br /> <br /> var Rows = Table.rows;<br /> <br /> if ( Button.firstChild.data == collapseCaption ) {<br /> for ( var i = 1; i &lt; Rows.length; i++ ) {<br /> Rows[i].style.display = 'none';<br /> }<br /> Button.firstChild.data = expandCaption;<br /> } else {<br /> for ( var i = 1; i &lt; Rows.length; i++ ) {<br /> Rows[i].style.display = Rows[0].style.display;<br /> }<br /> Button.firstChild.data = collapseCaption;<br /> }<br /> }<br /> <br /> function createCollapseButtons() {<br /> var tableIndex = 0;<br /> var NavigationBoxes = new Object();<br /> var Tables = document.getElementsByTagName( 'table' );<br /> <br /> for ( var i = 0; i &lt; Tables.length; i++ ) {<br /> if ( hasClass( Tables[i], 'collapsible' ) ) {<br /> <br /> /* only add button and increment count if there is a header row to work with */<br /> var HeaderRow = Tables[i].getElementsByTagName( 'tr' )[0];<br /> if ( !HeaderRow ) {<br /> continue;<br /> }<br /> var Header = HeaderRow.getElementsByTagName( 'th' )[0];<br /> if ( !Header ) {<br /> continue;<br /> }<br /> <br /> NavigationBoxes[tableIndex] = Tables[i];<br /> Tables[i].setAttribute( 'id', 'collapsibleTable' + tableIndex );<br /> <br /> var Button = document.createElement( 'span' );<br /> var ButtonLink = document.createElement( 'a' );<br /> var ButtonText = document.createTextNode( collapseCaption );<br /> <br /> Button.className = 'collapseButton'; // Styles are declared in [[MediaWiki:Common.css]]<br /> <br /> ButtonLink.style.color = Header.style.color;<br /> ButtonLink.setAttribute( 'id', 'collapseButton' + tableIndex );<br /> ButtonLink.setAttribute( 'href', &quot;javascript:collapseTable(&quot; + tableIndex + &quot;);&quot; );<br /> ButtonLink.appendChild( ButtonText );<br /> <br /> Button.appendChild( document.createTextNode( '[' ) );<br /> Button.appendChild( ButtonLink );<br /> Button.appendChild( document.createTextNode( ']' ) );<br /> <br /> Header.insertBefore( Button, Header.childNodes[0] );<br /> tableIndex++;<br /> }<br /> }<br /> <br /> for ( var i = 0; i &lt; tableIndex; i++ ) {<br /> if ( hasClass( NavigationBoxes[i], 'collapsed' ) || ( tableIndex &gt;= autoCollapse &amp;&amp; hasClass( NavigationBoxes[i], 'autocollapse' ) ) ) {<br /> collapseTable( i );<br /> } else if ( hasClass( NavigationBoxes[i], 'innercollapse' ) ) {<br /> var element = NavigationBoxes[i];<br /> while ( element = element.parentNode ) {<br /> if ( hasClass( element, 'outercollapse' ) ) {<br /> collapseTable( i );<br /> break;<br /> }<br /> }<br /> }<br /> }<br /> }<br /> <br /> addOnloadHook( createCollapseButtons );<br /> <br /> /** Test if an element has a certain class **************************************<br /> *<br /> * Description: Uses regular expressions and caching for better performance.<br /> * Maintainers: [[User:Mike Dillon]], [[User:R. Koot]], [[User:SG]]<br /> */<br /> <br /> var hasClass = ( function() {<br /> var reCache = {};<br /> return function( element, className ) {<br /> return ( reCache[className] ? reCache[className] : ( reCache[className] = new RegExp( &quot;(?:\\s|^)&quot; + className + &quot;(?:\\s|$)&quot; ) ) ).test( element.className );<br /> };<br /> })();<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> /* openx copy-and-paste code from https://d1.openx.org/spcjs.php?id=65157&amp;amp;target=_blank<br /> <br /> if (typeof(OA_zones) != 'undefined') {<br /> var OA_zoneids = '';<br /> for (var zonename in OA_zones) OA_zoneids += escape(zonename+'=' + OA_zones[zonename] + &quot;|&quot;);<br /> OA_zoneids += '&amp;amp;nz=1';<br /> } else {<br /> var OA_zoneids = escape('281199');<br /> }<br /> <br /> if (typeof(OA_source) == 'undefined') { OA_source = ''; }<br /> var OA_p=location.protocol=='https:'?'https://d1.openx.org/spc.php':'http://d1.openx.org/spc.php';<br /> var OA_r=Math.floor(Math.random()*99999999);<br /> OA_output = new Array();<br /> <br /> var OA_spc=&quot;&lt;&quot;+&quot;script type='text/javascript' &quot;;<br /> OA_spc+=&quot;src='&quot;+OA_p+&quot;?zones=&quot;+OA_zoneids;<br /> OA_spc+=&quot;&amp;amp;source=&quot;+escape(OA_source)+&quot;&amp;amp;r=&quot;+OA_r;<br /> OA_spc+=&quot;&amp;amp;amp%3Btarget=_blank&quot;;<br /> OA_spc+=(document.charset ? '&amp;amp;charset='+document.charset : (document.characterSet ? '&amp;amp;charset='+document.characterSet : ''));<br /> <br /> if (window.location) OA_spc+=&quot;&amp;amp;loc=&quot;+escape(window.location);<br /> if (document.referrer) OA_spc+=&quot;&amp;amp;referer=&quot;+escape(document.referrer);<br /> OA_spc+=&quot;'&gt;&lt;&quot;+&quot;/script&gt;&quot;;<br /> document.write(OA_spc);<br /> <br /> function OA_show(name) {<br /> if (typeof(OA_output[name]) == 'undefined') {<br /> return;<br /> } else {<br /> document.write(OA_output[name]);<br /> }<br /> }<br /> <br /> function OA_showpop(name) {<br /> zones = window.OA_zones ? window.OA_zones : false;<br /> var zoneid = name;<br /> if (typeof(window.OA_zones) != 'undefined') {<br /> if (typeof(zones[name]) == 'undefined') {<br /> return;<br /> }<br /> zoneid = zones[name];<br /> }<br /> <br /> OA_p=location.protocol=='https:'?'https://d1.openx.org/apu.php':'http://d1.openx.org/apu.php';<br /> <br /> var OA_pop=&quot;&lt;&quot;+&quot;script type='text/javascript' &quot;;<br /> OA_pop+=&quot;src='&quot;+OA_p+&quot;?zoneid=&quot;+zoneid;<br /> OA_pop+=&quot;&amp;amp;source=&quot;+escape(OA_source)+&quot;&amp;amp;r=&quot;+OA_r;<br /> OA_spc+=&quot;&amp;amp;amp%3Btarget=_blank&quot;;<br /> if (window.location) OA_pop+=&quot;&amp;amp;loc=&quot;+escape(window.location);<br /> if (document.referrer) OA_pop+=&quot;&amp;amp;referer=&quot;+escape(document.referrer);<br /> OA_pop+=&quot;'&gt;&lt;&quot;+&quot;/script&gt;&quot;;<br /> <br /> document.write(OA_pop);<br /> }<br /> var OA_fo = '';<br /> OA_fo += &quot;&lt;&quot;+&quot;script type=\'text/javascript\' src=\'https://d1.openx.org/fl.js\'&gt;&lt;&quot;+&quot;/script&gt;\n&quot;;<br /> document.write(OA_fo);<br /> <br /> <br /> <br /> <br /> <br /> */</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=125556 2012-03-04T17:49:04Z

<p>Webappsecguy: Updating Chapter Contacts</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:alex.bauert@owasp.org Alex Bauert] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri].&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time.&lt;br&gt;&lt;br&gt;OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!&lt;br&gt;|mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}}<br /> <br /> &lt;br&gt;<br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Academic Supporter membership]. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&lt;/div&gt;<br /> <br /> OWASP would also like to thank Best Buy for its additional financial support of [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]], [[ESAPI|OWASP ESAPI]], and the [[OWASP_Appsec_Tutorial_Series|OWASP AppSec Tutorial Series]].<br /> <br /> &lt;br&gt; <br /> <br /> = Upcoming Meetings and Events =<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> &lt;br&gt;<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> = Media and Documents =<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Gene Kim - Rugged DevOps - OWASP (MSP) - 7 November 2011 (61 minutes) [http://vimeo.com/36342207 Vimeo Video]<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> = Previous Events =<br /> <br /> === OWASP AppSec USA 2011 - September 20-23, 2011 ===<br /> <br /> OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!<br /> <br /> === OWASP Minneapolis-St. Paul 2010 Day of Talks - October 8, 2010 ===<br /> <br /> OWASP MSP and [http://dc612.org DC612] hosted an awesome lineup of technical talks October 8, 2010.<br /> <br /> '''[[OWASP Minneapolis St Paul 2010 Conference|Visit the day of talks page for a recap]]'''<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for '''[[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]]''' at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. '''[[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]]''' or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a '''[[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]]''' at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> = Chapter Contacts =<br /> <br /> '''President:''' [mailto:alex.bauert@owasp.org Alex Bauert] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Oversight:''' [mailto:dave@drstrangelove.net David Bryan]<br /> <br /> '''Content and Social Media:''' [Eric]<br /> <br /> '''Secure360 Representative:''' [mailto:alex.crittenden@netspi.com Alex Crittenden]<br /> <br /> <br /> <br /> &lt;headertabs /&gt; <br /> <br /> {{Social Media Links}}<br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Tutorial&diff=125555 2012-03-04T17:38:33Z

<p>Webappsecguy: Noting that the Toolbox link for</p> <hr /> <div>==Editing the OWASP Wiki==<br /> <br /> OWASP is built on the MediaWiki platform. Anyone can create an account and make the OWASP wiki better. To create a new account, click on the [[Special:Userlogin|create an account or log in]] link at the top-right of every page. When you make edits, please use the &quot;preview&quot; feature to make sure your changes are final, and then don't forget to save. Use the &quot;edit summary&quot; to describe what you did and why.<br /> <br /> Writing OWASP wiki articles is a bit different from writing on a standard word processor. Instead of a strict &quot;what you see is what you get&quot; approach, wiki uses simple text codes for formatting. The approach is similar to that used in writing HTML for web pages, but the codes are simpler. The [http://meta.wikimedia.org/wiki/Help:Contents MediaWiki help] is a great place to start learning about all the features available. Another option for you to investigate is [http://www.openoffice.org OpenOffice] as you can edit pages and export them into MediaWiki format.<br /> <br /> ==Style guidelines==<br /> <br /> In general, we follow the [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Keep_in_mind%29 editing guidelines] of Wikipedia. You should ensure that your additions to OWASP reflect a &quot;Neutral Point of View&quot; and a positive collaboration in the interest of better application security. Also, please remember that OWASP is not the right place for disclosure of actual vulnerabilities. The bugtraq or full-disclosure mailing lists are appropriate venues for that sort of thing.<br /> <br /> ==Content guidelines==<br /> <br /> OWASP is not a place to promote commercial products or services. We strive to provide unbiased information that will enable organizations and individuals to build and operate more secure applications. Information about commercial products is allowed, but MUST follow these guidelines. Violations of these policies should be reported to [mailto:owasp@owasp.org owasp@owasp.org].<br /> * Product discussions must mention all comparable tools available<br /> * &quot;Equal time&quot; must be given to all tools discussed<br /> * Unsubstantiable claims will not be allowed<br /> * Discussions of products should include both good and bad<br /> * Representatives of product companies must disclose their affiliation<br /> <br /> ==Bold and italics==<br /> Bold and italics are created like this:<br /> *&lt;tt&gt;&lt;nowiki&gt;''italics''&lt;/nowiki&gt;&lt;/tt&gt; appears as ''italics''. (2 apostrophes on both sides)<br /> *&lt;tt&gt;&lt;nowiki&gt;'''bold'''&lt;/nowiki&gt;&lt;/tt&gt; appears as '''bold'''. (3 apostrophes on both sides)<br /> <br /> ==Headings and subheadings==<br /> Headings and subheadings are an easy way to improve the organization of an article. If you can see two or more distinct topics being discussed, you can break up the article by inserting a heading for each section.<br /> <br /> Headings can be created like this:<br /> *&lt;tt&gt;&lt;nowiki&gt;==Top level heading==&lt;/nowiki&gt;&lt;/tt&gt; (2 equals signs)<br /> *&lt;tt&gt;&lt;nowiki&gt;===Subheading===&lt;/nowiki&gt;&lt;/tt&gt; (3 equals signs)<br /> *&lt;tt&gt;&lt;nowiki&gt;====Another level down====&lt;/nowiki&gt;&lt;/tt&gt; (4 equals signs)<br /> <br /> ==Discussion pages==<br /> <br /> There are &quot;discussion&quot; pages (also known as &quot;talk&quot; pages) associated with every article at OWASP. You can leave questions, comments, or ideas on these pages for other authors to review. These pages are a good place to propose ideas or discuss possible approaches to problems. You should &quot;sign&quot; your comments by adding four tilde characters (&lt;nowiki&gt;~~~~&lt;/nowiki&gt;) after your comment. Use section headings for different topic areas.<br /> <br /> See [http://meta.wikimedia.org/wiki/Help:Wiki_markup_examples Wiki markup examples] for more examples<br /> <br /> ==Internal links==<br /> One thing that makes the OWASP wiki useful (and highly habit-forming) is extensive cross-listing by internal links. These easily-created links allow users to access information related to the article they're reading.<br /> <br /> The easiest way to learn when to link is to look at OWASP (or Wikipedia) articles for examples. If you're trying to decide whether to make a link or not, ask yourself &quot;If I were reading this article, would the link be useful to me?&quot;<br /> <br /> When you want to make a link to another OWASP page (called a &lt;em&gt;wiki link&lt;/em&gt;) you have to put it in double square brackets, like this:<br /> :&lt;tt&gt;&lt;nowiki&gt;[[Threats]]&lt;/nowiki&gt;&lt;/tt&gt;<br /> <br /> If you want to use words other than the article title as the text of the link, you can do so by adding the &quot;|&quot; divider followed by the alternative name. For example, if you wanted to make a link to the [[Main Page]], but wanted it to say &quot;OWASP home&quot; you would write it as such:<br /> :&lt;tt&gt;To view the article, &lt;nowiki&gt;[[Main Page|OWASP home]]&lt;/nowiki&gt;...&lt;/tt&gt;<br /> <br /> ==Images and files==<br /> You can upload certain types of documents using the '''Upload File''' option under '''Toolbox''' in the lower lefthand part of the linkbar at the left side of any OWASP page. But you need to be logged in to see this option. We allow common image formats, Word documents, PowerPoint presentations, and PDF files. Choose your filename carefully, as you'll use that to reference the document from <br /> the rest of the site. Note that MediaWiki uses the term &quot;image&quot; to mean any file.<br /> <br /> Use this syntax to reference files from your page ...<br /> <br /> * Single click to get &quot;image&quot; page:<br /> &lt;nowiki&gt;[[Image:filename.ppt|PUT YOUR TITLE HERE]]&lt;/nowiki&gt;<br /> <br /> * Single click to show file:<br /> &lt;nowiki&gt;[http://www.owasp.org/index.php/Image:filename.ppt PUT YOUR TITLE HERE]&lt;/nowiki&gt;<br /> <br /> ==Categories==<br /> OWASP makes extensive use of categories. Categories are used to &quot;tag&quot; articles in OWASP so that people can find them. An article can be in lots of categories at the same time. For example, an article discussing a flaw in the Java sandbox might be in the [[:Category:Java]], [[:Category:Vulnerability]], and [[:Category:Access Control]] categories at the same time.<br /> <br /> To add a category to an article, just add &lt;nowiki&gt;[[Category:XXX]]&lt;/nowiki&gt; to the end of the article, replacing the XXX with the name of the appropriate category.<br /> <br /> To reference a Category page, simply put a colon (''':''') at the beginning of the &quot;Category&quot; tag, like this:<br /> <br /> :&lt;tt&gt;&lt;nowiki&gt;[[:Category:Principles]]&lt;/nowiki&gt;&lt;/tt&gt;<br /> <br /> '''It is very important to put in the correct categories so that other people can easily find your work.''' The best way to find which categories to put in is to look at pages on similar subjects, and check which categories they use. For example if you write an article about a type of tree, you may look at an article on another type of tree to see which categories could be appropriate.</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=125208 2012-02-29T16:34:44Z

<p>Webappsecguy: Updating president contact. Used to be Adam Baso. Now is Alex Bauert.</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:alex.bauert@owasp.org Alex Bauert] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri].&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time.&lt;br&gt;&lt;br&gt;OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!&lt;br&gt;|mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}}<br /> <br /> &lt;br&gt;<br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Academic Supporter membership]. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&lt;/div&gt;<br /> <br /> OWASP would also like to thank Best Buy for its additional financial support of [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]], [[ESAPI|OWASP ESAPI]], and the [[OWASP_Appsec_Tutorial_Series|OWASP AppSec Tutorial Series]].<br /> <br /> &lt;br&gt; <br /> <br /> = Upcoming Meetings and Events =<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> &lt;br&gt;<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> = Media and Documents =<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Gene Kim - Rugged DevOps - OWASP (MSP) - 7 November 2011 (61 minutes) [http://vimeo.com/36342207 Vimeo Video]<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> = Previous Events =<br /> <br /> === OWASP AppSec USA 2011 - September 20-23, 2011 ===<br /> <br /> OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!<br /> <br /> === OWASP Minneapolis-St. Paul 2010 Day of Talks - October 8, 2010 ===<br /> <br /> OWASP MSP and [http://dc612.org DC612] hosted an awesome lineup of technical talks October 8, 2010.<br /> <br /> '''[[OWASP Minneapolis St Paul 2010 Conference|Visit the day of talks page for a recap]]'''<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for '''[[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]]''' at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. '''[[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]]''' or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a '''[[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]]''' at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> = Chapter Contacts =<br /> <br /> '''President:''' [mailto:alex.bauert@owasp.org Alex Bauert] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:kuai.hinojosa@owasp.org Kuai Hinojosa] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:bob.sullivan@owasp.org Bob Sullivan] <br /> <br /> '''Board Member:''' [mailto:dave@drstrangelove.net David Bryan] <br /> <br /> &lt;headertabs /&gt; <br /> <br /> {{Social Media Links}}<br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=123951 2012-02-08T04:22:13Z

<p>Webappsecguy: Fixing date header for October 8, 2010 day of talks.</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:adam.baso@owasp.org Adam Baso] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri].&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time.&lt;br&gt;&lt;br&gt;OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!&lt;br&gt;|mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}}<br /> <br /> &lt;br&gt;<br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Academic Supporter membership]. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&lt;/div&gt;<br /> <br /> OWASP would also like to thank Best Buy for its additional financial support of [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]], [[ESAPI|OWASP ESAPI]], and the [[OWASP_Appsec_Tutorial_Series|OWASP AppSec Tutorial Series]].<br /> <br /> &lt;br&gt; <br /> <br /> = Upcoming Meetings and Events =<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> &lt;br&gt;<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> = Media and Documents =<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Gene Kim - Rugged DevOps - OWASP (MSP) - 7 November 2011 (61 minutes) [http://vimeo.com/36342207 Vimeo Video]<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> = Previous Events =<br /> <br /> === OWASP AppSec USA 2011 - September 20-23, 2011 ===<br /> <br /> OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!<br /> <br /> === OWASP Minneapolis-St. Paul 2010 Day of Talks - October 8, 2010 ===<br /> <br /> OWASP MSP and [http://dc612.org DC612] hosted an awesome lineup of technical talks October 8, 2010.<br /> <br /> '''[[OWASP Minneapolis St Paul 2010 Conference|Visit the day of talks page for a recap]]'''<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for '''[[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]]''' at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. '''[[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]]''' or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a '''[[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]]''' at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> = Chapter Contacts =<br /> <br /> '''President:''' [mailto:adam.baso@owasp.org Adam Baso] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:kuai.hinojosa@owasp.org Kuai Hinojosa] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:bob.sullivan@owasp.org Bob Sullivan] <br /> <br /> '''Board Member:''' [mailto:dave@drstrangelove.net David Bryan] <br /> <br /> &lt;headertabs /&gt; <br /> <br /> {{Social Media Links}}<br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=123950 2012-02-08T04:21:33Z

<p>Webappsecguy: Adding AppSec USA 2011 link and 2010 day of talks link to Previous Events section.</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:adam.baso@owasp.org Adam Baso] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri].&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time.&lt;br&gt;&lt;br&gt;OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!&lt;br&gt;|mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}}<br /> <br /> &lt;br&gt;<br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Academic Supporter membership]. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&lt;/div&gt;<br /> <br /> OWASP would also like to thank Best Buy for its additional financial support of [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]], [[ESAPI|OWASP ESAPI]], and the [[OWASP_Appsec_Tutorial_Series|OWASP AppSec Tutorial Series]].<br /> <br /> &lt;br&gt; <br /> <br /> = Upcoming Meetings and Events =<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> &lt;br&gt;<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> = Media and Documents =<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Gene Kim - Rugged DevOps - OWASP (MSP) - 7 November 2011 (61 minutes) [http://vimeo.com/36342207 Vimeo Video]<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> = Previous Events =<br /> <br /> === OWASP AppSec USA 2011 - September 20-23, 2011 ===<br /> <br /> OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!<br /> <br /> === OWASP Minneapolis-St. Paul 2010 Day of Talks - August 24, 2009 ===<br /> <br /> OWASP MSP and [http://dc612.org DC612] hosted an awesome lineup of technical talks October 8, 2010.<br /> <br /> '''[[OWASP Minneapolis St Paul 2010 Conference|Visit the day of talks page for a recap]]'''<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for '''[[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]]''' at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. '''[[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]]''' or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a '''[[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]]''' at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> = Chapter Contacts =<br /> <br /> '''President:''' [mailto:adam.baso@owasp.org Adam Baso] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:kuai.hinojosa@owasp.org Kuai Hinojosa] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:bob.sullivan@owasp.org Bob Sullivan] <br /> <br /> '''Board Member:''' [mailto:dave@drstrangelove.net David Bryan] <br /> <br /> &lt;headertabs /&gt; <br /> <br /> {{Social Media Links}}<br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=123949 2012-02-08T04:13:27Z

<p>Webappsecguy: Adding Gene Kim video.</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:adam.baso@owasp.org Adam Baso] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri].&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time.&lt;br&gt;&lt;br&gt;OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!&lt;br&gt;|mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}}<br /> <br /> &lt;br&gt;<br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Academic Supporter membership]. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&lt;/div&gt;<br /> <br /> OWASP would also like to thank Best Buy for its additional financial support of [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]], [[ESAPI|OWASP ESAPI]], and the [[OWASP_Appsec_Tutorial_Series|OWASP AppSec Tutorial Series]].<br /> <br /> &lt;br&gt; <br /> <br /> = Upcoming Meetings and Events =<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> &lt;br&gt;<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> = Media and Documents =<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Gene Kim - Rugged DevOps - OWASP (MSP) - 7 November 2011 (61 minutes) [http://vimeo.com/36342207 Vimeo Video]<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> = Previous Events =<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for [[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]] at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. [[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]] or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a [[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]] at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> = Chapter Contacts =<br /> <br /> '''President:''' [mailto:adam.baso@owasp.org Adam Baso] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:kuai.hinojosa@owasp.org Kuai Hinojosa] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:bob.sullivan@owasp.org Bob Sullivan] <br /> <br /> '''Board Member:''' [mailto:dave@drstrangelove.net David Bryan] <br /> <br /> &lt;headertabs /&gt; <br /> <br /> {{Social Media Links}}<br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=123429 2012-01-30T03:56:13Z

<p>Webappsecguy: Updating verbiage.</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:adam.baso@owasp.org Adam Baso] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri].&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time.&lt;br&gt;&lt;br&gt;OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!&lt;br&gt;|mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}}<br /> <br /> &lt;br&gt;<br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Academic Supporter membership]. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&lt;/div&gt;<br /> <br /> OWASP would also like to thank Best Buy for its additional financial support of [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]], [[ESAPI|OWASP ESAPI]], and the [[OWASP_Appsec_Tutorial_Series|OWASP AppSec Tutorial Series]].<br /> <br /> &lt;br&gt; <br /> <br /> = Upcoming Meetings and Events =<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> &lt;br&gt;<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> = Media and Documents =<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> = Previous Events =<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for [[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]] at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. [[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]] or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a [[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]] at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> = Chapter Contacts =<br /> <br /> '''President:''' [mailto:adam.baso@owasp.org Adam Baso] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:kuai.hinojosa@owasp.org Kuai Hinojosa] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:bob.sullivan@owasp.org Bob Sullivan] <br /> <br /> '''Board Member:''' [mailto:dave@drstrangelove.net David Bryan] <br /> <br /> &lt;headertabs /&gt; <br /> <br /> {{Social Media Links}}<br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=123428 2012-01-30T03:47:36Z

<p>Webappsecguy: Updating sponsorships.</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:adam.baso@owasp.org Adam Baso] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri].&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time.&lt;br&gt;&lt;br&gt;OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!&lt;br&gt;|mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}}<br /> <br /> &lt;br&gt;<br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Academic Supporter membership]. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&lt;/div&gt;<br /> <br /> OWASP would also like to thank Best Buy for its financial support of [[OWASP_Zed_Attack_Proxy_Project|OWASP ZAP]], [[ESAPI|OWASP ESAPI]], and the [[OWASP_Appsec_Tutorial_Series|OWASP AppSec Tutorial Series]].<br /> <br /> &lt;br&gt; <br /> <br /> = Upcoming Meetings and Events =<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> &lt;br&gt;<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> = Media and Documents =<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> = Previous Events =<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for [[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]] at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. [[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]] or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a [[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]] at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> = Chapter Contacts =<br /> <br /> '''President:''' [mailto:adam.baso@owasp.org Adam Baso] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:kuai.hinojosa@owasp.org Kuai Hinojosa] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:bob.sullivan@owasp.org Bob Sullivan] <br /> <br /> '''Board Member:''' [mailto:dave@drstrangelove.net David Bryan] <br /> <br /> &lt;headertabs /&gt; <br /> <br /> {{Social Media Links}}<br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=123427 2012-01-30T03:04:59Z

<p>Webappsecguy: Updating David's e-mail address.</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:adam.baso@owasp.org Adam Baso] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri].&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time.&lt;br&gt;&lt;br&gt;OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!&lt;br&gt;|mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}}<br /> <br /> &lt;br&gt;<br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Academic Supporter membership]. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:AccuvantLogoNEW.jpg|120px|link=http://www.accuvant.com]] &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [[Image:Midwave.gif|140px|link=http://www.midwave.com]]&lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> = Upcoming Meetings and Events =<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> &lt;br&gt;<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> = Media and Documents =<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> = Previous Events =<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for [[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]] at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. [[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]] or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a [[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]] at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> = Chapter Contacts =<br /> <br /> '''President:''' [mailto:adam.baso@owasp.org Adam Baso] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:kuai.hinojosa@owasp.org Kuai Hinojosa] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:bob.sullivan@owasp.org Bob Sullivan] <br /> <br /> '''Board Member:''' [mailto:dave@drstrangelove.net David Bryan] <br /> <br /> &lt;headertabs /&gt; <br /> <br /> {{Social Media Links}}<br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=123426 2012-01-30T03:03:05Z

<p>Webappsecguy: Fixing &lt;headertabs&gt;, adding social media widget, rearranging text at top of page, removing Joe (moving onto different security domain), modifying whitespace.</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:adam.baso@owasp.org Adam Baso] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri].&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time.&lt;br&gt;&lt;br&gt;OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org http://www.appsecusa.org]''' to find materials from AppSec USA 2011!&lt;br&gt;|mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}}<br /> <br /> &lt;br&gt;<br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Academic Supporter membership]. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:AccuvantLogoNEW.jpg|120px|link=http://www.accuvant.com]] &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [[Image:Midwave.gif|140px|link=http://www.midwave.com]]&lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> = Upcoming Meetings and Events =<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> &lt;br&gt;<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> = Media and Documents =<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> = Previous Events =<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for [[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]] at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. [[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]] or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a [[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]] at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> = Chapter Contacts =<br /> <br /> '''President:''' [mailto:adam.baso@owasp.org Adam Baso] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:kuai.hinojosa@owasp.org Kuai Hinojosa] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:bob.sullivan@owasp.org Bob Sullivan] <br /> <br /> '''Board Member:''' [mailto:david.bryan@owasp.org David Bryan] <br /> <br /> &lt;headertabs /&gt; <br /> <br /> {{Social Media Links}}<br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy https://wiki.owasp.org/index.php?title=Minneapolis_St_Paul&diff=123417 2012-01-30T00:40:04Z

<p>Webappsecguy: Undo revision 123416 by Webappsecguy (talk)</p> <hr /> <div>__NOTOC__ {{Chapter Template|chaptername=Minneapolis-St. Paul (OWASP MSP)|extra=The chapter president is [mailto:adam.baso@owasp.org Adam Baso] and the vice president is [mailto:lorna.alamri@owasp.org Lorna Alamri]. OWASP MSP was host to OWASP's 2011 flagship outreach effort, '''OWASP AppSec USA 2011''', at the Minneapolis Convention Center September 20-23, 2011. Visit '''[http://www.appsecusa.org/ http://www.appsecusa.org/]''' to find materials from AppSec USA 2011!&lt;br&gt;&lt;br&gt;'''Up Next:''' '''Marc Blanchou - [https://androidsecurecontainers.eventbrite.com Auditing Android Secure Containers]''' (live in person at Concord in Hopkins - [https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map]) on '''Monday, February 13, 2012'''. The presenter starts at 6:30 PM Central Time. |mailinglistsite=https://lists.owasp.org/mailman/listinfo/owasp-twincities|emailarchives=https://lists.owasp.org/pipermail/owasp-twincities}} <br /> <br /> &lt;br&gt; <br /> <br /> &lt;br&gt; <br /> <br /> == Sponsorship/Membership ==<br /> <br /> &lt;paypal&gt;Minneapolis St Paul&lt;/paypal&gt; <br /> <br /> Or consider the value of [http://www.owasp.org/index.php/Membership Individual, Organization, or Accredited University Supporter membership] to contribute to better application security in the Minneapolis-Saint Paul area, surrounding Twin Cities metropolitan region, greater Minnesota, and the global software community. <br /> <br /> &lt;br&gt; <br /> <br /> == Platinum Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px;width:340px;&quot;&gt;[[Image:Cargill.gif|link=http://www.cargill.com]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Best Buy logo.jpg|link=http://www.bestbuy.com/]]&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[[Image:Advance it minnesota logo.png|120px|link=http://advanceitmn.org]] &lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Gold Sponsors ==<br /> <br /> &lt;div style=&quot;background:#FFFFFF;padding:10px; width:290px&quot;&gt;[[Image:AccuvantLogoNEW.jpg|120px|link=http://www.accuvant.com]] &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [[Image:Midwave.gif|140px|link=http://www.midwave.com]]&lt;/div&gt;<br /> <br /> &lt;br&gt; <br /> <br /> == Meetings and More ==<br /> <br /> ==== Upcoming Meetings and Events ====<br /> <br /> === Monday, February 13, 2012&lt;br&gt;Marc Blanchou&lt;br&gt;Auditing Android Secure Containers ===<br /> <br /> '''Delivery Method:''' Live on site at Concord in Hopkins - presenter at 6:30 PM Central Time&lt;br&gt; <br /> <br /> '''Meeting Location:''' Concord, 509 2nd Avenue S, Hopkins, MN 55343 ([https://maps.google.com/maps?q=509+2nd+Avenue+S+Hopkins,+MN+55343 Google Map])<br /> <br /> '''Register:''' [https://androidsecurecontainers.eventbrite.com/ https://androidsecurecontainers.eventbrite.com/] <br /> <br /> '''Bring your business card''' for the raffle!<br /> <br /> '''Thank you''' to [http://concordusa.com Concord] for sponsoring our meeting location, for providing snacks &amp; refreshments, and for a raffle!<br /> <br /> &lt;br&gt;<br /> <br /> === Stay Updated ===<br /> <br /> '''[https://lists.owasp.org/mailman/listinfo/owasp-twincities Click here to join the local chapter mailing list]''' <br /> <br /> '''Follow''' OWASP MSP on your favorite social media sites: <br /> <br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/groupInvitation?groupID=2184116]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/owaspmsp]] [[Image:Facebook_mini.png|link=http://www.facebook.com/pages/OWASP-Minneapolis-St-Paul-OWASP-MSP-OWASPMSP/113583361381]] <br /> <br /> <br /> '''Share''' OWASP MSP on your favorite social media sites:<br /> <br /> [[Image:Linkedin_mini.png|link=http://www.linkedin.com/shareArticle?mini=true&amp;url=http%3A%2F%2Fwww.owasp.org%2Findex.php%2FMinneapolis_St_Paul&amp;title=OWASP%20Minneapolis-St.%20Paul%20(OWASP%20MSP)%20Home%20Page&amp;summary=Official%20OWASP%20Minneapolis-St.%20Paul%20(OWASP%20MSP)%20home%20page.%20Video%2C%20audio%2C%20slides%2C%20and%20other%20information%20on%20previous%20and%20upcoming%20chapter%20meetings%2C%20events%2C%20and%20conferences.&amp;source=OWASPMSP]] <br /> [[Image:Twitter_mini.png|link=http://twitter.com/home?status=Checking%20out%20OWASP%20MSP%20at%20http%3A%2F%2Fwww.owasp.org%2Findex.php%2FMinneapolis_St_Paul.]] [[Image:Facebook_mini.png|link=http://www.facebook.com/sharer.php?u=http%3A%2F%2Fwww.owasp.org%2Findex.php%2FMinneapolis_St_Paul&amp;t=OWASP%20Minneapolis-St.%20Paul%20(OWASP%20MSP)%20Home%20Page]] [[Image:Digg_mini.png|link=http://digg.com/submit?phase=2&amp;url=http%3A%2F%2Fwww.owasp.org%2Findex.php%2FMinneapolis_St_Paul&amp;title=OWASP%20Minneapolis-St.%20Paul%20(OWASP%20MSP)%20Home%20Page&amp;bodytext=Official%20OWASP%20Minneapolis-St.%20Paul%20(OWASP%20MSP)%20home%20page.%20Video%2C%20audio%2C%20slides%2C%20and%20other%20information%20on%20previous%20and%20upcoming%20chapter%20meetings%2C%20events%2C%20and%20conferences.]] [[Image:Delicious_mini.png|link=http://del.icio.us/post?url=http%3A%2F%2Fwww.owasp.org%2Findex.php%2FMinneapolis_St_Paul&amp;title=OWASP%20Minneapolis-St.%20Paul%20(OWASP%20MSP)%20Home%20Page]] [[Image:Reddit_mini.png|link=http://reddit.com/submit?url=http%3A%2F%2Fwww.owasp.org%2Findex.php%2FMinneapolis_St_Paul&amp;title=OWASP%20Minneapolis-St.%20Paul%20(OWASP%20MSP)%20Home%20Page]] [[Image:Myspace_mini.png|link=http://www.myspace.com/Modules/PostTo/Pages/?l=1&amp;u=http%3A%2F%2Fwww.owasp.org%2Findex.php%2FMinneapolis_St_Paul&amp;t=OWASP%20Minneapolis-St.%20Paul%20(OWASP%20MSP)%20Home%20Page]]<br /> <br /> === Secure360 ===<br /> <br /> [http://www.secure360.org/ Secure360] is an annual conference providing high quality educational sessions and networking opportunities while working to identify developing trends in risk management, physical security, governance, audit, information security, contingency planning and human capital. <br /> <br /> === DC612 Meetings ===<br /> <br /> DC612 meets the 2nd Thursday of the month.&lt;br&gt; [http://www.dc612.org/ http://www.dc612.org/] <br /> <br /> ==== Video/Audio/Slides/Handouts ====<br /> <br /> Videos of past meetings are available at the [[OWASPMSP Videos]] node, the [http://vimeo.com/channels/owaspmsp OWASP MSP Vimeo Channel], and [http://vimeo.com/owasp http://vimeo.com/owasp]. <br /> <br /> === Most Recent Content ===<br /> <br /> Michael Coates - Attack Aware Applications (AppSensor) - OWASP (MSP) - 18 April 2011 (75 minutes) [https://owasp.webex.com/owasp/ldr.php?AT=pb&amp;SP=MC&amp;rID=87764002&amp;rKey=14191b8f8c73dabc WebEx Replay]<br /> <br /> Dan Cornell - Smart Phones, Dumb Apps - OWASP (MSP) - 7 December 2010 (93 minutes) [http://vimeo.com/17692646 Vimeo Video] <br /> <br /> Gunnar Peterson - Audit Logging Done Right - OWASP (MSP) - 20 September 2010 (55 minutes) [http://vimeo.com/15423426 Vimeo Video] <br /> <br /> Dinis Cruz - How OWASP Works - OWASP (MSP) - 10 August 2010 (55 minutes) [http://vimeo.com/14343350 Vimeo Video] <br /> <br /> Dinis Cruz - O2 - OWASP (MSP) - 10 August 2010 (110 minutes) [http://vimeo.com/14392060 Vimeo Video] <br /> <br /> ==== Previous Events ====<br /> <br /> === OWASP Minneapolis-St. Paul 2009 Half Day Conference - August 24, 2009 ===<br /> <br /> Thanks again for another year to all who joined us for [[OWASP Minneapolis St Paul 2009 Conference|an afternoon of information security presentations on August 24, 2009]] at the [http://www1.umn.edu/twincities/maps/StCen/StCen-map.html St. Paul Student Center] [http://www.spsc.umn.edu/about/directory/lower.php Auditorium/Theater] on the [http://www1.umn.edu/twincities/index.php University of Minnesota - Twin Cities] campus. [[OWASP Minneapolis St Paul 2009 Conference|Visit the conference page for a recap]] or '''[http://vimeo.com/channels/owaspmsp watch the video at Vimeo]'''. <br /> <br /> === OWASP &amp;amp; FLOSS Application Security Mini-Conference 2008 - October 21, 2008 ===<br /> <br /> Thanks to all who joined us on October 21, 2008 for a [[OWASP Minneapolis St Paul 2008 Conference|mini conference in October 2008]] at University of Minnesota's Saint Paul campus. Our first conference was a great success, with around 150 people attending! We were fortunate to have even higher attendance in 2009. <br /> <br /> ==== Chapter Leaders/Contacts ====<br /> <br /> '''President:''' [mailto:adam.baso@owasp.org Adam Baso] <br /> <br /> '''Vice President:''' [mailto:lorna.alamri@owasp.org Lorna Alamri] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:kuai.hinojosa@owasp.org Kuai Hinojosa] <br /> <br /> '''Board Member and Former OWASP MSP President:''' [mailto:bob.sullivan@owasp.org Bob Sullivan] <br /> <br /> '''Board Member:''' [mailto:david.bryan@owasp.org David Bryan] <br /> <br /> '''Board Member:''' Joe Teff &lt;headertabs /&gt; <br /> <br /> [[Category:Minnesota]]</div>

Webappsecguy