Reviewing Code for Cross-site scripting - Revision history

Bill Sempf at 23:37, 10 April 2014

2014-04-10T23:37:23Z

Ari Elias-Bachrach: readability improvements

2011-06-22T20:03:02Z

readability improvements

Thomas Herlea: Cleaned up "Stored Cross-Site Script" a little

2010-09-09T16:33:30Z

Cleaned up "Stored Cross-Site Script" a little

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T16:19:12Z

Added navigation to facilitate sequential reading online

Romain: cleaning the example rendering

2009-05-14T01:35:05Z

cleaning the example rendering

Romain: /* .NET Example (ASP.NET version 1.1 ASP.NET version 2.0) */

2009-05-14T01:30:41Z

‎.NET Example (ASP.NET version 1.1 ASP.NET version 2.0)

KirstenS: /* Vulnerable Code example */

2009-02-11T01:18:37Z

‎Vulnerable Code example

KirstenS: /* Stored Cross Site Script: */

2009-01-28T14:20:18Z

‎Stored Cross Site Script:

KirstenS: /* Protecting against XSS */

2009-01-28T14:11:52Z

‎Protecting against XSS

KirstenS: /* Protecting against XSS */

2009-01-28T14:10:38Z

‎Protecting against XSS

← Older revision		Revision as of 23:37, 10 April 2014
Line 232:		Line 232:

	[[Category:OWASP Code Review Project]]		[[Category:OWASP Code Review Project]]
		+	[[Category:OWASP .NET Project]]

@@ Line 6: / Line 6: @@
 ==Overview==
-Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates, without validating or encoding it.
+Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application reflects user input without validation or encoding.
 ==Related Security Activities==
@@ Line 28: / Line 28: @@
 ==Vulnerable Code example==
-If the text inputted by the user is reflected back and has not been data validated, the browser shall interpret the inputted script as part of the mark up, and execute the code accordingly.
+If the text inputted by the user is reflected back without proper encoding, the browser will interpret the inputted script as part of the mark up, and execute the code accordingly.
 To mitigate this type of vulnerability we need to perform a number of security tasks in our code:
@@ Line 75: / Line 75: @@
-The text above shows some common mistakes in the development of this struts action class. First, the data passed in the HttpServletRequest is placed into a parameter without being data validated.
+The text above shows some common mistakes in the development of this struts action class. First, the data passed in the HttpServletRequest is placed into a parameter without being validated.
 Focusing on XSS we can see that this action class returns a message, ActionMessage, if the function is successful. If an error the code in the Try/Catch block is executed, the data contained in the HttpServletRequest is returned to the user, unvalidated and exactly in the format in which the user inputted it.
@@ Line 97: / Line 97: @@
-Following is a second example of an XSS vulnerable function. Echoing un-validated user input back to the browser would give a nice large vulnerability footprint.
+Following is a second example of an XSS vulnerable function. Echoing un-validated user input back to the browser provides a large vulnerability footprint.
 ===.NET Example (ASP.NET version 1.1 ASP.NET version 2.0)===
@@ Line 194: / Line 194: @@
 '''Using HTML encoding to encode potentially unsafe output.'''
-Malicious script can be stored/persisted in a database and shall not execute until retrieved by a user. This can also be the case in bulletin boards and some early web email clients. This incubated attack can sit dormant for a long period of time until a user decides to view the page where the injected script is present. At this point the script shall execute on the user’s browser.
+Malicious scripts can be stored/persisted in a database and will not execute until retrieved by a user. This has been seen in bulletin boards and some early webmail applications. This incubated attack can sit dormant for a long period of time until a user decides to view the page where the injected script is present. At this point the script executes on the user’s browser.
 The original source of input for the injected script may be from another vulnerable application, which is common in enterprise architectures. Therefore the application at hand may have good input data validation but the data persisted may not have been entered via this application per se, but via another application.

@@ Line 191: / Line 191: @@
   Response.Write Server.HtmlEncode(inputTxt.Text)
-===Stored Cross Site Script:===
+===Stored Cross Site Script===
 '''Using HTML encoding to encode potentially unsafe output.'''
@@ Line 198: / Line 198: @@
 The original source of input for the injected script may be from another vulnerable application, which is common in enterprise architectures. Therefore the application at hand may have good input data validation but the data persisted may not have been entered via this application per se, but via another application.
-In this case we cannot be 100% sure the data to be displayed to the user is 100% safe (as it could find its way in via another path in the enterprise). The approach to mitigate against this is to ensure the data sent to the browser is not going to be interpreted by the browser as mark-up, and should be treated as user data.
+In this case we cannot be 100% sure the data to be displayed to the user is safe (as it could have found its way in via another path in the enterprise). The approach to mitigate against this is to ensure that data sent to the browser with the purpose of being displayed literally is not going to be interpreted by the browser as mark-up.
 We encode known bad to mitigate against this “enemy within”. This, in effect, assures that the browser interprets any special characters as data and markup.
@@ Line 204: / Line 204: @@
 HTML encoding usually means '''&lt;''' becomes '''&amp;lt;''', '''&gt;''' becomes '''&amp;gt;''', '''&amp;''' becomes '''&amp;amp;''', and '''&quot;''' becomes '''&amp;quot;'''.
-From	To
+{|
-&lt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	&amp;lt;
+So, for example, if the application has a string "<script>" and it wants a browser to display it as "<script>", it can first HTML-encode it to the form "&amp;lt;script&amp;gt;" before including it in the web page that gets sent to the browser.
 {{LinkBar

@@ Line 1: / Line 1: @@
-[[OWASP Code Review Guide Table of Contents]]
+{{LinkBar
+  | useprev=PrevLink | prev=Reviewing Code for Data Validation | lblprev=
 ==Overview==
@@ Line 218: / Line 221: @@
 So, for example, the text <script> would be displayed as <script> but on viewing the markup it would be represented by &amp;lt;script&amp;gt;
 [[Category:OWASP Code Review Project]]

@@ Line 170: / Line 170: @@
 Text Box: <%@ Page Language="C#" ValidateRequest="false" %>
- <script runat="server">
+  <script runat="server">
- void searchBtn _Click(object sender, EventArgs e) {
+  void searchBtn _Click(object sender, EventArgs e) {
- Response.Write(HttpUtility.HtmlEncode(inputTxt.Text)); }
+  Response.Write(HttpUtility.HtmlEncode(inputTxt.Text)); }
- </script>
+  </script>
- <html>
+  <html>
- <body>
+  <body>
- <form id="form1" runat="server">
+  <form id="form1" runat="server">
- <div>
+  <asp:TextBox ID="inputTxt" Runat="server" TextMode="MultiLine" Width="382px" Height="152px">
- <asp:TextBox ID="inputTxt" Runat="server" TextMode="MultiLine" Width="382px" Height="152px">
+  </asp:TextBox>
- </asp:TextBox>
+  <asp:Button ID="searchBtn" Runat="server" Text="Submit" OnClick=" searchBtn _Click" />
- <asp:Button ID="searchBtn" Runat="server" Text="Submit" OnClick=" searchBtn _Click" />
+  </form>
- </div>
+  </body>
- </form>
+  </html>
 For Classic ASP pages the encoding function is used pretty much the same as in ASP.NET

@@ Line 125: / Line 125: @@
   End Class
-This is a VB.NET example of a vulnerable piece of search functionality which echoes back the data inputted by the user. To mitigate against this, we need proper data validation and in the case of stored XSS attacks, we need to encode known bad input (as mentioned before).
+This is a VB.NET example of a vulnerable piece of search functionality which echoes back the data inputted by the user. To mitigate against this, we need proper data validation and in the case of stored XSS attacks, we need to encode known bad input (as mentioned before). Note that this code might not be vulnerable if the developers use a proper declarative validation (ASPX regexp validator or routine, and validateRequest not set to False).
 ===Classic ASP Example===

@@ Line 157: / Line 157: @@
    <'''pages'''> element with '''validateRequest="false"'''
-So when reviewing code, make sure the validateRequest directive is enabled and if not, investigate what method of data validation is being used, if any. Check that ASP.NET Request validation Is enabled in  '''Machine.config'''
+So when reviewing code, make sure the validateRequest directive is enabled and if not, investigate what method of data validation is being used, if any. Check that ASP.NET Request validation is enabled in  '''Machine.config'''.
 Request validation is enabled by ASP.NET by default. You can see the following default setting in the '''Machine.config''' file.

← Older revision		Revision as of 14:10, 28 January 2009
Line 146:		Line 146:

	The request validation feature is disabled on an individual page by specifying in the page directive.		The request validation feature is disabled on an individual page by specifying in the page directive.
−

	'''<%@ Page validateRequest="false" %>'''		'''<%@ Page validateRequest="false" %>'''