0

I have been tasked with fixing a XSS issue in an ASP.Net application, but I have never seen this kind of attack before so first it would be great if I could understand how this is working and then I need some help because I haven't been able to fix it.

The attack goes like so:

https://example.com/AnyPageInTheApplication.aspx/(A('onerror='alert%601%60'testabcd))/

When I look at the network tab in Chrome's dev tools I see that the request has been hijacked by the last section of the URL and the alert shows up, but I do not know how this is working. An explanation would be greatly appreciated.

To fix it I first looked at the application web.config file and I saw that the validateRequest switch is disabled so I changed it to true and the vulnerability is still there.

The application is really large and according to some documentation on it, apparently they disabled the validateRequest switch because it is supposed to be handled on the server by some backend code, obviously not working, and I am still to find out what are the reasons for this application to be designed this way (I'm very new to the company).

This issue begs a few questions:

  • Why would enabling the validateRequest switch does not fix the issue?
  • Where else could I look for the potential problem?
  • Is there an alternative to fix this vulnerability other than validateRequest?
4
  • I added a link to validateRequest and that seems to explain all your questions. It was the first hit for the Google search for "validateRequest"
    – schroeder
    Commented Sep 8, 2020 at 19:13
  • @schroeder - Thank you, but like I said I did change the value from false to true and I still see the alert popping up. The link you added is just the basic explanation of validateRequest, it doesn't explain why the behavior does not change when I switch the value. I even removed the attribute from the web.config file and I still see the alert. Commented Sep 8, 2020 at 19:54
  • The link explains that it triggers on non-HTML-encoded content. The inject appears to be HTML encoded.
    – schroeder
    Commented Sep 8, 2020 at 20:00
  • I think it works because your error page is trying to display the request var that caused the error. Commented Oct 8, 2020 at 23:14

2 Answers 2

3

This particular attack is related to how ASP.NET was dealing with support for cookieless browsers.

The case was that in old times there were browsers which have not supported cookies. In that case the only way to provide session identifier was through including this in URL (sic!) using special format:

  • A(...) for anonymous ID
  • S(...) for Session ID
  • F(...) for form authentication ticket.

So when ASP.NET page have found that browser do not support cookies, it was using URL to pass the session ID. That time it was by default.

Now when you build your modern app, you by default setup your app with Cookieless option equal to UseCookies. It means that if you will send request like http://localhost/A(ABCD)/page.aspx it is still considered as http://localhost/page.aspx. Unfortunately if you add the session indicator into URL, it will be treated as path and added to all paths on your which use "~" at the beginning. This happens when you for example loads some scripts like this:

<script src="<%= ResolveUrl("~/Script.js") %>"></script>

it will be changed into something like this:

<script src="/(A(ABCD))/Script.js"></script>

Now, when user have a control over the path in script tag, he can try to exploit this as XSS.

For any details please refer to this blog post. You will see the exact payload which can be used to make an XSS.

To mitigate you can try to use server-side resolution as HTML Control or as WebControl (details in attached link)

1

An XSS vulnerability basically executes in the browser and not the backend itself. So I will try to explain in details by an example so I can be clear.

Example:

  • An input name field that goes to the backend via a input field in html.
  • Instead of a name I issue a simple js tag that has the command <script>alert(33)</script> (notice that this is an javascript tag)
  • The code goes to the backend where ASP.NET is going to process it. (Can be stored or reflected more about that in the OWASP section).
  • ASP.NET does not validate the input and the input name goes back to the Browser so it can appear in the users page.
  • The Browser sees that tag and instead of interpreting as a regular input the Browser sees that an js tag, so by doing so it executes commands like html or js (as an exemple for people seeing this just an example only) and prints that alert from sending the alert step. Making the Browser interpret that command.

This can be used to trigger many evil things that i cannot say here.

  • Why would enabling the validateRequest switch does not fix the issue?

    Answer : From the OWASP page I see this: Do not disable validateRequest in the web.config or the page setup. This value enables limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built-in protections.

  • Where else could I look for the potential problem?

    If what I understand you should look for when you receive the input from any source rather an api or a normal input.

  • Is there an alternative to fix this vulnerability other than validateRequest?

    Validate every input as bad input. Where you can find viable ways is to look here: https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .