4

I'm currently trying to pass PCI compliance for one of my client's sites but the testing company are flagging up a vulnerability that I don't understand!

The (site removed) details from the testing company are as follows:

The issue here is a cross-site scripting vulnerability that is commonly associated with e-commerce applications. One of the tests appended a harmless script in a GET request on the end of the your site url. It flagged as a cross-site scripting vulnerability because this same script that was entered by the user (our scanner) was returned by the server unsanitized in the header. In this case, the script was returned in the header so our scanner flagged the vulnerability.

Here is the test I ran from my terminal to duplicate this:

GET /?osCsid=%22%3E%3Ciframe%20src=foo%3E%3C/iframe%3E HTTP/1.0 Host:(removed)

HTTP/1.1 302 Found
Connection: close
Date: Tue, 11 Jan 2011 23:33:19 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Location: http://www.(removed).co.uk/index.aspx?osCsid="><iframe src=foo></iframe>
Set-Cookie: ASP.NET_SessionId=bc3wq445qgovuk45ox5qdh55; path=/; HttpOnly
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 203

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="http://www.(removed).co.uk/index.aspx?osCsid=&quot;>&lt;iframe src=foo>&lt;/iframe>">here</a>.</h2>
</body></html>

The solution to this issue is to sanitize user input on these types of requests, making sure characters that could trigger executable scripts are not returned on the header or page.

Firstly, I can't get the result that the tester did, it only ever returns a 200 header which doesn't include the location, nor will it return the object moved page. Secondly, i'm not sure how (on iis 6) to stop it returning a header with the query string in it! Lastly, why does code in the header matter, surely browsers wouldn't actually execute code from the http header?

Chris Foot
  • 343
  • 1
  • 5
  • 17

2 Answers2

2

Request: GET /?osCsid=%22%3E%3Ciframe%20src=foo%3E%3C/iframe%3E HTTP/1.0 Host:(removed)

The <iframe src=foo></iframe> is the issue here.

Response text:

 <html><head><title>Object moved</title></head><body>
 <h2>Object moved to <a href="http://www.(removed).co.uk/index.aspx?osCsid=&quot;>&lt;iframe src=foo>&lt;/iframe>">here</a>.</h2>
 </body></html>

The response link is:

  http://www.(removed).co.uk/index.aspx?osCsid=&quot;>&lt;iframe src=foo>&lt;/iframe>

Which contains the contents from the request string.

Basically, someone can send someone else a link where your osCsid contains text that allows the page to be rendered in a different way. You need to make sure that osCsid sanitizes input or filters against things that could be like this. For example, I could provide a string that lets me load in whatever javascript I want, or make the page render entirely different.

As a side note, it tries to forward your browser to that non-existent page.

Incognito
  • 20,537
  • 15
  • 80
  • 120
  • The problem is, I don't use osCsid for anything, it has no relevance for the site at all (this is not an oscommerce site). They are saying that any query string parameter can be used for this, regardless of wether my site uses it or not! – Chris Foot Jan 13 '11 at 11:27
  • Right, and forget that osCsid means anything, the point is that you're letting someone provide code that will get injected to the page. If they can provide that argument, and it comes out in the HTML somewhere, it's an issue. – Incognito Jan 13 '11 at 14:06
  • Absolutely, I get that. But the code isn't coming out in the html, its in the http header! – Chris Foot Jan 14 '11 at 14:39
  • It doesn't matter. The `location:` header tag sends a redirect, so if they can manipulate that to a broken page they've 'broke' your website. ----- Secondly, if that data you've shown above is the actual sample, then yes it is coming out in the HTML, right below `content-length: 203` you have the new line and the page data. There's something on your website's programming or web server that allows for injection of code that compromises both the redirection and the data payload. – Incognito Jan 14 '11 at 15:02
0

It turned out that I have a Response.redirect for any pages which are accessed by https which don't need to be secure and this was returning the location as part of the redirect. Changing this to:

Response.Status = "301 Moved Permanently";
Response.AddHeader("Location", Request.Url.AbsoluteUri.Replace("https:", "http:"));
Response.End();

Fixed the issue

Chris Foot
  • 343
  • 1
  • 5
  • 17