OWASP Application Security FAQ - Revision history

Gtorok: Added Application Hardening and Shielding explanation and internal OWASP link to misc. section

2018-07-19T17:49:35Z

Added Application Hardening and Shielding explanation and internal OWASP link to misc. section

Eelgheez: /* My site will be used from publicly shared computers. What precautions must I take? */ direct to up-to-date one-way encryption procedures; formalize the style

2016-07-01T01:23:30Z

‎My site will be used from publicly shared computers. What precautions must I take?: direct to up-to-date one-way encryption procedures; formalize the style

JRDePriest: /* How can I prevent XSS? */

2016-01-22T20:52:59Z

‎How can I prevent XSS?

Michael Brooks: md5 is a broken primitive and should never be used for password. The "salted md5 trick" does not improve security. HTTPS should be used instead.

2013-11-11T02:57:49Z

md5 is a broken primitive and should never be used for password. The "salted md5 trick" does not improve security. HTTPS should be used instead.

Webappsecguy: Removing because highly ambiguous.

2013-08-05T00:00:48Z

Removing because highly ambiguous.

Webappsecguy: quick updates of stale content

2013-08-04T23:52:10Z

quick updates of stale content

Webappsecguy: clarification

2013-08-04T23:41:17Z

clarification

Webappsecguy: updating specifically stale info

2013-08-04T23:37:34Z

updating specifically stale info

Samantha Groves at 21:16, 12 November 2012

2012-11-12T21:16:47Z

Samantha Groves at 21:16, 12 November 2012

2012-11-12T21:16:07Z

@@ Line 345: / Line 345: @@
 * Be redirected there by some page.
 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.
 ==I want to use the most secure language; which language do you recommend?  ==

@@ Line 44: / Line 44: @@
 ==My site will be used from publicly shared computers. What precautions must I take?  ==
-If your application will be accessed from publicly shared computers like libraries, you could take the following precautions:
+If the application will be accessed from publicly shared computers such as libraries, the following may protect its security.
 =SQL Injection  =

@@ Line 148: / Line 148: @@
 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.
+{| class="wikitable"
+! style="text-align:center;"| Special Character
-<   &lt;
+! Escape Sequence
+|-
->   &gt;
+|<||&amp;lt;
+|-
-(   &*40;
+|>||&amp;gt;
+|-
-)   &*41;
+|(||&amp;#40;
+|-
-*   &*35;
+|)||&amp;#41;
-&   &*38;
+|-
+|&#42;||&amp;#42;

@@ Line 4: / Line 4: @@
 * 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.
-* 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.
+* 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 way to manage sessions would be to use one session token with two values during authentication. One value before authentication and one after.
@@ Line 13: / Line 13: @@
 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.
 ==How can my "Forgot Password" feature be exploited?  ==

← Older revision		Revision as of 00:00, 5 August 2013
Line 120:		Line 120:

	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.		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.
−
−	~~==What is the best way to implement Pragma: No-cache? ==~~
−
−	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.

	==What's the difference between the cache-control directives: no-cache, and no-store? ==		==What's the difference between the cache-control directives: no-cache, and no-store? ==

@@ Line 119: / Line 119: @@
 ==How do I ensure that sensitive pages are not cached on the user's browser?  ==
-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'.
+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.
 ==What is the best way to implement Pragma: No-cache?  ==

@@ Line 131: / Line 131: @@
 ==Am I totally safe with these directives?  ==
-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="Off" ' 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.
+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="Off" ' 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.
 ==Where can I learn more about caching?  ==

@@ Line 222: / Line 222: @@
 ==Are there source code scanning tools for .NET languages, Java, PHP etc that predict vulnerabilities in the source code?  ==
-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://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
+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
 ==Can non-HTTP protocols also be intercepted and played with like this?  ==