5 Black Hat Attack Vulnerabilities & Defensive Strategies

[HTMLBasicTutor]

Interesting read. Something early adopters of HTML 5 should be aware of:

Although HTML 5 doesn't open up many new attacks, it does open up a broader surface for these attacks. Some examples are the new event attribute in the video tag. This can be used to inject JavaScript in an XSS attack and bypass traditional filters that would have traditionally caught the JavaScript execution of such a scripting attack.

Another method is to use the drag and drop functionality in HTML5 to hide hidden information and trick the user into dropping and dragging this into say a form control. This is a “ClickJacking” attack.

Another attack is HTML cache poisoning, where you can keep a cache alive longer than it should be so you can steal the user’s credentials or even create an HTML5 generated botnet. As HTML and CSS get more sophisticated, these mark-up languages become even more vulnerable to scripting, tunneling, hijacking and a whole variety of attacks.

Think this is years away? No, it can all be done today on any modern browser – even if your site is in HTML5, even if it isn’t using most HTML5 functionality.

Suggestion: Learn the HTML5 vulnerabilities and then prepare the best you can to eliminate those and the use of vulnerable tagging.

5 Black Hat Attack Vulnerabilities & Defensive Strategies

[weegillis]

Should we pack up our tent and go home? I think not; but, I am grateful for this article. A revealing read, especially the warning about JavaScript. I don't know how to take the warning about HTML5. Seems kind of ominous, to be sure.

For starters, most of us don't know how to spot holes in our logic, let alone know how to open them up. So cautions about JavaScript fall on deaf ears when our sites depend so heavily upon it. ECMA5 is supposed to be hardened, and more secure, but I'm no expert on this. It is the JavaScript specification for HTML5 compliant browsers so I would hope we small time developers can at least depend upon the added security it supposedly affords.

Here's a thought: Would we be safer to generate our scripts on every request, than say leave it laying around in .JS files?

How do we defend the cache control in HTML5? This seems to be the most vulnerable, since many sites will employ 'light' distributions of HTML5 elements, and not include video, audio, canvas, drag and drop, or the host of advanced features, at least not at first, I'd guess.