Paid Advertising
web application security lab

User Agent Spoofable Using Certain Programming Languages

Kuza55 and I have been trading emails over the last few days around a new technique he has been working on that he posted a few days ago regarding spoofing user agents. There are a lot of systems that use user agents to do operations. Typically that’s not a problem because the only person you can hurt is yourself. However, if you can force someone else to change their user agent, you can get them to exploit themselves.

So the problem is that Flash allows you to submit “User_Agent” instead of “User-Agent” and in some programming languages “User_Agent” gets changed to “HTTP_USER_AGENT” (in the case of PERL for instance). There are a number of vulnerable programming languages. The easiest fix would probably be for Flash to disallow injection of User_Agent and the other headers that may be used on the web in unsafe ways.

Very nice work by Kuza55. It took a while to get a demo that we could both use but click click here for an example of changing your user agent. I don’t allow the attack to render (for obvious reasons) but you can at least see the demo. Very nasty.

16 Responses to “User Agent Spoofable Using Certain Programming Languages”

  1. digi7al64 Says:

    When i worked on the cold fusion xss error 0 day i found something very similar in the ways in which certain applications determine header info (not just user agents).

    And this is the problem. Each application/language has it owns quirks and you simply can’t cover all of them all off (when you aren’t aware of them) in terms of ensuring you are managing your security risks.

    meh, for a life with standards that everybody followed.

    Hats off to kuza55

  2. navairum Says:

    Hey I joined up on last week, but I don’t think the email is working. I have tried to get it to send me another activation email, but still nothing. Any help?


  3. RSnake Says:

    Did you check your spam box? If not do. If you still don’t see it email me offline with your username and I’ll manually add you.

  4. Awesome AnDrEw Says:

    I don’t believe it worked for me. It was supposed to display a spoofed user-agent, right? I got the usual one.

  5. RSnake Says:

    What browser were you using? I was using Firefox 2.0 on Win XP at the time.

  6. Awesome AnDrEw Says:

    I was using Microsoft Internet Explorer 7 on Windows Vista.

  7. Stefan Esser Says:

    BTW: This technique is already around a while.

    During 2006 a related problem was sent to the apache security response team. The main problem is that this does not only allow fake user agent injection, it also allows attacking sites with mod_snakeoil^H^H^H_security that try to filter out attacks from the User-Agent header…

  8. alech Says:

    Could you be a bit more specific on the Perl (not PERL!) angle? I don’t see where Perl does any variable renaming when sending it User_Agent headers … - !?

  9. RSnake Says:

    @Stefan - interesting, did anything ever happen with that?

    @alech PERL is an acronym. ;) Sorry, “Perl” if it makes you feel better. I just assume people are too lazy to capitalize things. Alech, of course it does. If you send User-Agent it shows up in Perl as HTTP_USER_AGENT. Go to

  10. kuza55 Says:

    @Awesome AnDrEw:

    It doesn’t work with IE/Perl, go read the paper it has actual details.


    And I’m sure your vendor controlled mailing list cabals really appreciated being told, just like the security community would have appreciated being told.

    And really, I’m sure this problem has been known since way before 2006, I’d bet this problem has been known since the CGI spec was written, and people started looking at it, that doesn’t mean anything though, does it?

    On a slightly less snarky note, thanks for finally informing us about the mod_security issue.

  11. Stefan Esser Says:


    I never said that the problem is known since 2006. I only said that I shared this problem with the Apache folks in 2006.

    And well, the majority of people that discover things do not share them with the rest of the security community (until maybe years later)… For good reason.

    Speaking of mod_security… Maybe I should start doing a month of mod_security bugs ;)

  12. andrew Says:

    Offtopic, but Perl is not an acronym…

    “The name is occasionally given as “PERL” (for Practical Extraction and Report Language). Although the expansion has prevailed in many of today’s manuals, including the official Perl man page, it is merely a backronym. The name does not officially stand for anything, so spelling it in all caps is incorrect and is considered a shibboleth (label of outsiders) in the Perl community.”

  13. kuza55 Says:


    And what _good_ reason is there not to share something until years later?

    I’m honestly curious because the only thing I can think of is that they’re being payed to sit on it by some third party.

    And a month of mod_security bugs sounds like fun, and I’m sure it’ll give you a chance to showcase why you think its snake oil, :)

  14. alech Says:

    @RSnake: not exactly Perl’s fault, though, a shell script does the same thing here (Perl only reads the environment variables presented to it). Seems like Apache messes this up …

  15. kuza55 Says:

    @alech: Tehcnically its the spec’s fault, Apache just implements the CGI 1.1 spec properly.

    And who is at fault doesn’t really matter here, what matters is what languages are getting hit by it, because some languages provide other means of accessing headers other than the environment variables, like Java.

    So if you want to assign blame, then blame the CGI 1.1 spec, if you want to know which languages are vulnerable, its Perl, PHP Ruby and ColdFusion.

  16. Hallvord R. M. Steen Says:

    I’d say this is strictly a bug in those CGI backends. Or do you really argue that user agents/scripting hosts should disallow setting headers named user_agent? If you think so, now would be a good time to bring it up with the WebAPI working group specifying XMLHttpRequest:

    Current list of disallowed headers is here:;%20charset=utf-8#dfn-setrequestheader (BTW I’m sure a review of that list is welcome too!)