Hacking HTML 5

Cross‐site Scripting via HTML5:
HTML5 introduces new elements that contain event attributes and new event attributes for existing tags. These event attributes can be used for executing JavaScript by bypassing blacklist based filters designed blocking Cross‐site Scripting attacks.
A filter that only looks for known malicious tags can be bypassed using the new HTML5 Audio and Video tags.
Example:

Reverse Web Shells with COR:
HTML5’s Cross Origin Request allows browsers to make cross domain Ajax calls from a.com to b.com and read the response as long as b.com allows it. This feature can be used to tunnel HTTP traffic over cross domain Ajax calls and set‐up a browser equivalent of a reverse shell.
By doing this an attacker can hijack a victim’s session using XSS even if anti‐session hijacking measure like Http‐Only cookie and Session ID‐IP address binding are used.
Once the JavaScript payload is injected to the victim’s browser either through Cross‐site Scripting or by convincing the victim to paste the scripting in the browser’s address bar, the script starts talking to the attacker’s server through Cross Origin Requests. Using this connection the attacker can browse the victim’s affected session by tunneling his requests through the victim’s browser.
Earlier this year I had released an open source tool named ‘Shell of the Future’[2] which is an implementation of this idea. It is extremely easy to use as it automates the entire attack and comes with two default JavaScript payloads.
Clickjacking via HTML5:
Text‐field Injection:
ClickJacking can be used to submit forms across domains by bypassing the CSRF protection. Though it is very easy to click links or buttons through ClickJacking, populating the Input fields of the target form is relatively harder to do.
HTML5’s Drag and Drop API can be used to fill the target forms simply by convincing the victim to perform a Drag and Drop action. The attacker’s site can camouflage the attack as a game that requires the player to drag and drop items while invisibly attacker controlled data is populated in to the input fields of the target form.
Example:

DRAG ME!!

This method was introduced by Paul Stone at BlackHat Europe 2010[3] .
IFRAME Sandboxing:
There is a general misconception that including Framebusting code in each page of the site is the best way to defend against Clickjacking attacks. This approach appears to be the most popular solution as well even though the OWASP guidelines[4] clearly mention its disadvantages.
If a websites’ only defense against ClickJacking attacks is FrameBusting then this protection can be bypassed in a few different ways. One of them is to use the IFRAME ‘sandbox’ attribute which is part of HTML5.
Example:

Setting this attribute disables JavaScript within the iframe. Since ‘framebusting’ relies on JavaScript, this attributes effectively neutralizes the defense. Popular sites like eBay, WordPress, PayPal rely only on ‘framebusting’ for protection and are hence open to this attack.
HTML5 Cache Poisoning:
HTML5 introduces a new type of caching system called as the Application Cache or the programmable cache. While traditional caches are meant to improve page load times, the Application Cache is designed to enable Offline web browsing. Hence this cache is more persistent than traditional cache.
By poisoning HTML5 caches an attacker can have his cached pages alive for longer durations and use it to steal the user’s credentials[5].
Earlier this year I released a new version of Imposter[6] that can be used to poison HTML5 caches.
Client‐side RFI:
Websites that perform Ajax requests to URLs mentioned in the location hash and include the response in the HTML of the page can be exploited using COR. By getting the victim to click on a link that includes the URL of an attacker controlled page in the Location hash, it is possible to perform client‐side RFI resulting in a Cross‐site Scripting attack. This attack was discovered by Matt Austin in July this year[7]. Mobile.facebook.com and other many other websites including the JQuery library was found to be vulnerable to this.
Cross‐site Posting:
This is a variation of the Client‐side RFI attack discussed earlier. If the URL of the Ajax request can be controlled by an attacker, like in the case of location hash then an attacker can redirect legitimate requests to his site and steal sensitive session information. Even though the response of the Ajax request might not be processed by the requesting site this attack would work.

Posted in: defendingemailadminlaninternet,hack