2

I took a scan of a ASP site and it said that request validation was off. It caught it by sending a URL of example.com/?foo=<script> and received a response URL of example.com/?foo=<script> (Same one).

I took a look myself, and tried to see what was up. I took a closer look at the source code and saw this below the title tags:

<form name="frm" method="post" action="/default.aspx" id="frm" enctype="multipart/form-data">

When I try the URL that the scanner suggested, the source code changes to this:

<form name="Form" method="post" action="/default.aspx?bar=%3Cscript%3E" id="Form" enctype="multipart/form-data">

which is clearly encoded.

Does this mean that the webapp is protected from XSS, and the scanner found a false-positive?

Improve this question
1
  • Just checking: is it supposed to be foo in the request parameter and bar in the form's action attribute? Also, are you sure if that's the only place it echoes? I usually use a form like <locate"me'> because it won't get caught by a specific keyword filter (the way script will) and will check for other dangerous characters as well.
    – CBHacking
    Commented Sep 14, 2015 at 2:53

2 Answers 2

Reset to default
1

The encoding that is happening is URL encoding ("<" is encoded to "%3C" and so on). This is done by the browser when you type special characters in the URL.

This can be verified by intercepting the request going from the browser to the server using a proxy like Burp Suite.

Now, if you add your script in Burp instead of the browser, the script will certainly reflect back in the response without encoding. The same can be achieved by manually crafting a HTML page to fire the request.

The actual mitigation you are looking at is proper HTML encoding (&lt; and &gt; for "<" and ">"). In order to completely make your application armoured and protected against XSS, I would recommend using the ASP.NET's ValidateRequest filter along with a custom application-wide filter which encodes special characters in all requests.

The application should not accept any script, special character or HTML in fields whenever not required. It should escape special characters that may prove to be harmful. The characters can be escaped as per the list available at this link:

Improve this answer
0

It will be vulnerable as soon as you echo the foo variable without any kind of filter.

See information about how to print safe HTML content dinamically: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Improve this answer

You must log in to answer this question.

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