In this blog, we will focus on the root cause of this attack in ASP.NET based applications.
To understand the subject, lets take the case of a search feature. Here the application accepts search keywords from the user and displays the results on the screen. If there are no matches for the text entered, it displays back an error message to the user saying, there are no results for the given keyword, as shown below:
what might have caused this issue?
The code reveals that the keyword entered by the user is retrieved from the text box control and is used to look up the database. If the matching results are not found, its value is displayed back to the user. The “Response.Write” method is used in this case to display the output.
It is important to note that the “Response.Write” method prints the value of the variable to the output stream without any validation or encoding. Thus, whatever we entered in the search field got reflected in response, including JavaScript.
Same is the case with use of scriplets <%, <%# that are used to display un-validated data back to the users in views.
This is the main reason why applications are vulnerable to XSS attack.
So, are Response.Write and scriplets the only vulnerable instances?
What if the data is rendered through web controls?
Web Controls perform HTML encoding of the values that they render on the screen. Hence, they are safe to use, except for Labels and Literals.
If the untrusted inputs are displayed back using Label and Literal controls, as the one shown below, then they would still be vulnerable to XSS attack.
But other controls like <asp:textbox> apply HTML encoding to the data they render by default. Thus, if the application displays the data back to the user within a text box control instead of the label, the value would get encoded. And the javascript element present in the string will be rendered to the browser as encoded text.
![]() |
Add caption |
Comments
Post a Comment