Dealing with an incorrect security report

A colleague of mine has had his company’s code “security audited” by one of their clients; specifically, the client hired a firm to do security testing for many (all?) of that company’s services, and my colleague’s company was one of the services.

They’re told they’re in danger of losing the account unless all of the “security holes” are patched. The problem is, some of the things that are being reported don’t seem to be security holes, but their automated scanner is saying that they are, and people can’t understand the difference.

Here’s an example – you tell me if this is crazy or not.

For URL:

hostedapp.com/application/invite/?app_id="><script>alert(1407385165.6523)</script>&id=104

Output contains:

<input type="hidden" name="app_id" id="app_id" value=""><script>alert(1407385165.6523)</script>">

Report coming back is:

Cross-Site Scripting vulnerability found

Injected item: GET: app_id

Injection value: "><sCrIpT>alert(14073726.2017)</ScRiPt><input "

Detection value: 14073726.2017

This is a reflected XSS vulnerability, detected in an alert that was an immediate response

to the injection.

When you pass in a value, it is escaped; there is no alert box that pops up (in any browser at all). I’m *thinking* that the reporting tool is simply seeing that the number exists on the resulting page (“detection value”) and is flagging this as “bad”. That seems way too naive for a security tool, though.

Is there some other explanation for why a security tool would look at this and still report that this was ‘insecure’?

---

I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Get notified when the book is available!

more