I'm having trouble understanding how a particular XSS vulnerability might arise in the real world. Guides for two of the exercises on hackthissite.org:

recommend XSS attacks to steal cookie information. In the first example the script is inserted in a message to be displayed for another user, and I can imagine a naive message display system blindly parsing HTML and JavaScript. But in the second case the XSS is supposed to exploit a user agent logging script.

Why would a script for logging user agents interpret and execute JavaScript in the user agent string?

From searching online I get the impression that this is a fairly common attack vector, but (perhaps because my expertise is all in compiled languages) I'm having trouble imagining a realistic logging script that would involve actually executing the user agent string. Surely simply accessing navigator.userAgent does not cause the string to be evaluated.

  • 4
    E.g. you might be inspecting web server access logs through a JS enabled web client. XSS would hit you where you'd least expect. Unless you thought of that vector, of course.
    – TildalWave
    Feb 11, 2014 at 23:09
  • 1
    @TildalWave: Aha! OK, maybe that's my big misunderstanding. It's not that logging the user agent executes JS, it's that some admin might come along later and look at 'foo/theUserAgentLogs.html' and that page will have had the script inserted.
    – user39947
    Feb 11, 2014 at 23:14
  • 5
    Yup, some web log inspectors / analyzers have serious security problems and that could be the first step in gaining admin privileges, say stealing session tokens. It's a big problem with unpatched or old versions of such software. [insert "patch everything" meme] :)
    – TildalWave
    Feb 11, 2014 at 23:19
  • maybe Tidal should submit that as an answer?
    – Daisetsu
    Feb 11, 2014 at 23:50

1 Answer 1


In addition to the fine information provided by @TildalWave, there are also cases with very poorly written or parsed browser sniffers. Sometimes people have a tendency to just drop the code in their project and not really understand it leading to the spread of any flawed methodology. The problem most arises from the types of sniffers that pass the value of your UA to a function to decide which "page" to load and what values to set to mitigate issues in IE, Firefox, Chrome, or Opera. What happens is that if a person passes a well crafted UA to your code and you do not properly "sanitize" it before handling it in your core, you could allow it to find a vulnerability. They can hijack an active session, grab unencrypted cookie data and/or place them, etc.

You must log in to answer this question.

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