|
Content Hijacking16 July 2005 Programmers are always told, "Thou shalt never trust User Input".[?] Naturally most programmers don't listen. An instance of this problem is the treatment of search queries. When one types HTML into a search field, the result can be amusing. But when the attack is upgraded to DHTML, the result can be much more serious. DHTML allows an attacker to build a webpage from scratch, without the original search form around the content. It allows one to place arbitrary content on somebody else's website. Random surfing for an hour located twenty websites featuring this vulnerabilty; a ratio of roughly one in four for the ones I looked at. An automated tool which reports a thousand websites an hour wouldn't be difficult to build. US Office of Government Ethics - US Department of Labor - Pittsburgh Post-Gazette - Insane Cats - Dialog - Geological Society of America - University of Minnesota Duluth - State of Connecticut - The Jackson Laboratory - Scholastic - University of British Columbia Library - World Bank - Stanford University - National Science Teachers Association - Webster University - Ancestry - Global Spec - Find Law - Congress.Org - FinAid Ok, so what's the big deal? This 'defacement' can only be seen by the defacer, or people who click on his/her link. It doesn't affect the general public. So said the client who had asked me to do a security sweep of his site and didn't see the value of fixing this trivial bug. Well, if you think these tricks are just harmless fun, then check out this press release from Nominet. [Update: after several years they have finally fixed it, here's a screenshot.] Imagine if that link were sent out as bulk email. This technique would also allow spammers to dodge filters since the websites they are linking to are respectable. There clearly isn't an awareness of the threat posed by creative DHTML input. On the other hand, it doesn't look like script-kiddies have discovered this one yet. Otherwise someone like SCO would have been hit a long time ago. One of the larger offenders is WebGlimpse, a site search tool which adds this vulnerability to any website it indexes [Bug 106]. But since most of the bugs appear to be in custom-written code, the only thing to do is to thoroughly check one's own sites for vulnerabilities. All it takes is a single insecure form or argument, anywhere on your site. Hmm, this link crashes Firefox 1.0.x [ |