2

An auditing firm said we are not PCI compliant, but provided unhelpful instructions on how to resolve the issues. They are clearly hoping we will engage their consulting unit.

What resources/services have you used to plug gaps after receiving a PCI compliance audit alert?

Are there web sites that provide helpful resources on resolving PCI compliance issues?

For instance, here is one of the cryptic failure messages we were flagged on:

"Description: Cross-site scripting vulnerability in category parameter to URL X"

But there is no clear guidance on how to close this vulnerability.

Thanks.

Crashalot
  • 33,605
  • 61
  • 269
  • 439

1 Answers1

0

Did they say which URL is causing the vulnerability, or was it literally an "X"?

Check to make sure that no user input, or input that is being grabbed from the URL, is being displayed anywhere on the page (or being used in your javascript) without being properly sanitized.

If you post the URL I'm sure people here would be happy to look for the vulnerability.

[Edit after you posted the URL:]

Here is a link to a malformed request displaying the vulnerability:

http://www.cengraving.com/s/category?category=Outdoor+signs+'-'alert("Cross%20Site%20Scripting%20Vulnerability%20Here");

A way to prevent this attack would be to validate all user input.

Client side you can remove any suspicious characters like <>'"-

Server side you should use regex to whitelist valid queries before entering them into your database.

Petey B
  • 11,439
  • 25
  • 81
  • 101
  • Here is the full message: "Cross-site scripting vulnerability in category parameter to /s/category;jsessionid=6D8425AEB28A1C87D234AE3D97270C6B" where the only query parameter is something like this, "?category=Brass+plates" – Crashalot May 26 '11 at 22:53
  • @Crashalot, Are you displaying that 'category' somewhere on the page? If so someone could change it to something like '?category=' and that would be what is causing the vulnerability – Petey B May 27 '11 at 14:58
  • Yes, the parameter is a category ID we use to identify which category to display. Are you saying we need to change our URL structure to close this vulnerability? We don't execute any Javascript on the page with the parameter. The parameter is read on the backend and indexed into our database. – Crashalot May 27 '11 at 20:02
  • make sure you sanitize that categoryID on the back end before it is put into the database, else someone could use it for an injection attack. It doesnt matter if it is being used in javascript or not, if it is being displayed directly on the page it can be malformed to execute arbitrary client side code, thus there is the possibility of an XSS attack – Petey B May 27 '11 at 20:30
  • It is also not good practice to place the session ID in the URL, as it could be exploited to hijack a user's session. Sessions should be handled server side, this is a simple adjustment depending on the platform you are using – Petey B May 27 '11 at 20:35
  • The category ID is never displayed directly. It's Tomcat, our app server, that attaches the session ID -- not us. How do we stop the session ID from getting attached, and how can we close the security vulnerability while still using the category ID in the query string? – Crashalot May 28 '11 at 19:11
  • http://stackoverflow.com/questions/2276920/how-to-configure-tomcat-to-not-encode-the-session-id-into-the-url-when-httpservle http://stackoverflow.com/questions/962729/is-it-possible-to-disable-jsessionid-in-tomcat-servlet – Petey B May 29 '11 at 19:14
  • As for the category ID, what do you mean never displayed directly? Is it stored *somewhere* on the page? Like a hidden field in a form? How exactly are you using this category ID? – Petey B May 29 '11 at 19:16
  • the category ID is read by the back end and used to retrieve the category's items from the database, like here: http://www.cengraving.com/s/category;jsessionid=4498E6835F139141F7956DE3593A9975?category=Name+plates – Crashalot May 30 '11 at 04:49
  • @Crashalot, I updated my answer with a URL exploiting the XSS vulernability on your site. Don't worrry, it just displays an alert box, but that could be used to steal cookies/sessions – Petey B May 30 '11 at 13:37
  • Do I get a free key chain? ;) – Petey B May 30 '11 at 13:56
  • Haha, thanks, Petey. Maybe we can arrange something after we find the solution. :) It seems like the audit firm is flagging even the mere presence of a string parameter? If we follow your suggestion, the audit firm should detect this and consider the vulnerability closed? – Crashalot May 30 '11 at 21:23
  • Also, we tried clicking the link and no alert appears. The query string is not used for writing ... only reading (i.e., used in a database query to select matching records). – Crashalot May 30 '11 at 21:25
  • @Crashalot, the alert showed up for me at work in IE, but it does not back at home using chrome (probably a built in security feature). But the fact remains I can write code to your site from the URL, that is the reason you are getting flagged for a vulnerability. Here is a link without a script: http://www.cengraving.com/s/category?category=Name+plates+'-'%3Ch1%3EXSS%20VULNERABILITY%3C/h1%3E – Petey B May 31 '11 at 01:02
  • You are using that Category from the URL to display the current category on the web page without any sort of validation. Just add in some code to validate that the Category does not contain any of those special characters I mentioned. – Petey B May 31 '11 at 02:24