Paid Advertising
web application security lab

History Hack Male vs. Female and Beyond

Strangely enough there’s been a ton of things happening in the CSS history hacking world lately, and I thought I should recap some of the more important events of late. Firstly, Firefox 3.0 came out, and wow - it feels an awful lot like when Firefox 2.0 came out. A good chunk of my favorite plugins no longer work - Switch Proxy, Auto Copy, LocalRodeo (since ironically it doesn’t install over SSL - and btw, that was the only public tool protecting anyone from JS based intranet hacking that I am aware of) and, of course, Safe History. Why is that a problem? Well, if you were relying on it to protect your history, it’s no longer an option.

Now, if that’s not bad enough, Jeremiah Grossman pointed me to a page that attempts to calculate your gender based on a portion of your history. An interesting take on the usefulness of the old CSS history hack. How accurate it is is questionable, but realistically this is pretty good for a first generation tool that is virtually un-tuned.

Last but not least, I did a little looking into the ol’ about:config options in Firefox and landed on a few options that were noteworthy. Not the least of which is browser.visitedcolor which can be re-set to anything you’d like. That means if you are simply looking for the color of a typical viewed link, you may be deceived if this color has been modified. That is - unless, the attacker knows that the victim has visited something before (a previous page perhaps), and the attacker’s code verifies that against something they couldn’t have visited (a domain that isn’t up, for instance) to isolate what the real viewed color is. So that option, if you were considering it, wouldn’t work for a more advanced version of the code that checked for this kind of thing.

It’s a sad day for the old CSS history hacking security though. And please, please don’t tell me that you’ll just turn off JavaScript to protect yourself!

12 Responses to “History Hack Male vs. Female and Beyond”

  1. Reiners Says:

    the CSS History Hack btw works in Opera 9.51 too.

  2. Wladimir Palant Says:

    That’s the problem with experimental extensions - nobody really wants to continue developing them :-(

    And in the case of the extensions you mentioned just changing compatibility info would most likely be enough. And removing the insecure update URL from install.rdf. Not exactly much work, if only somebody would be interested enough to do it…

  3. sana Says:

    About the browser.visitedcolor:
    Does it really have an effect?
    I think if the attacker uses the css to change the style, it doesn’t matter what color is the link. They can define a style and check for any property (for eg. a background-color, image, …)

  4. hisb Says:

    css history seemed to work at least somewhat in FF3. Of all sites to miss, though, i found it ironic not to see listed as “visited.”

    it seems like each of these hacks has some simple setting that will aid in mitigating the effects of the hack. disabling history stops this hack. likewise, setting the history to be auto cleared on browser close and/or running a virtualized browser (e.g. using sandboxie to open and operate the browser) will limit the history to the current session only. and while turning off javascript (or controlling it with the noscript addon) may not work for this hack, it does work for others.

    that said, not nearly enough people go to the proper lengths to limit the amount of information they put online. as these PoCs prove, lots of info can be gleaned by anyone who codes their site to ask properly.

  5. gubers33 Says:

    Or if you aren’t lazy you can just change the version number in the install.rdf and the insecure update yourself and it works. However they might not work again if Mozilla patches.

  6. Eponymous Says:

    FF3 also busted XSS Assistant.

  7. Awesome AnDrEw Says:

    I only use Firefox 3 on one of my desktop computers. On my laptop I had installed it, and noticed immediately that 99% of the extensions I had used were not compatible.

  8. Jim Manico Says:

    css history hacking = very low vulnerability criticality rating = not a very bid deal

  9. Bill Says:

    I just got possibly the most evil idea.

    1) create css history hack that hits everyone on the planet.
    2) use history information in browsers to determine search engine ranking
    3) destroy google with wildly successful new search engine.

  10. TheHorse13 Says:

    FF3 doesn’t support Access Me, a nifty tool that evaluates the source of any given site and searches for exploits. I hate it when add-ons are broken when major version releases come out.

  11. rvdh Says:


    Well, it’s a big issue. Because what if you are caught browsing websites that you do not want somebody to know? it’s easy to create a huge list of websites that are somwhat sensitive for other people’s eyes, think pr0n here. ’nuff reasons to black PR your enemy, or just for forensics. Considering that this thing is persistent, it’s more of a risk than a 10 day old patched zeroday imo.

  12. Mad Maverick 9 Says:

    @-moz-document url-prefix(http://),url-prefix(https://)
    body * a:visited * {
    background: #FFFFC0 !important;

    I added this to my “userContent.css” in SeaMonkey and the CSS history hack at “” does not work anymore.

    Is this sufficient to prevent this hack once and for all?