> + The bug was present in a 9 year old version of Netscape - draw your own > conclusions. There are literally thousands of HTML- and JavaScript-related denial of service vectors in modern browsers. If you want a silly, ad hoc example I just made up on the spot (and so could any reader of the list), try: foo = '<marquee>'; for (i=0;i<7;i++) foo += foo; for (i=0;i<10000;i++) document.write(foo); Likewise, it trahes just about any renderer (not the JS engine). So do attempts to render highly nested XML documents, render or rescale CANVAS objects with obscene geometries in pretty much all browsers that support the tag... and much, much more. Heck, even silly things such as looping window.print() are an excellent way to lock out the UI. In fact, such DoS scenarios are one of the most significant roadblocks in specialized fuzzing, and need to be painfully and comprehensively accounted for in any such code. Because of this, I am not entirely sure it makes much value to the community to report such patterns individually; developers may address some bugs at random, but will likely ignore most - and because of the nature of HTML and JavaScript, it's unlikely that a sensible set of memory- and CPU-related constraints could be imposed without running into scalability issues with legitimate websites, anyway. In other words, discussing this in a more holistic way, perhaps releasing test suites and recommending general mitigation schemes that do not require the web to be done from scratch, might be a better option. For example, even the approach taken by Chrome - letting attackers take down their own tabs only - is a significant improvement that prevents data loss pretty well in most such cases (though it's definitely not perfect). /mz PS. We may argue over whether DoS attacks in browsers are a security issue by one definition or another, but they are definitely an usability concern and an annoyance - so rest assured, I am not trying to dismiss your work.
