On 21 Jul 2009, at 08:12, Michal Zalewski wrote:
There are literally thousands of HTML- and JavaScript-related denial
of service vectors in modern browsers...
There's one significant difference in this one, though: while a bunch
of nested s (for instance) will just mess with the HTML renderer
Hi Michal,
Interesting,
http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html
--
readonly attribute long length;
--
MZ> Does not seem to be the case in HTML5 at least?
Ther
Hi Michal,
MZ> which does not seem to be that far
MZ> from creating an overly nested DOM tree, or drawing an oversized
Interesting tidbit:
The W3C DOM specifies the select.length attribute to be *read only*.
Yet (all) browsers have implemented it allowing to write to it. I
am not sure wha
> http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html
> --
> readonly attribute long length;
> --
That was DOM Level 1 (1999). Even level 2 (2000) has this as read-write:
Hi Steven,
[Removing a few addresses in CC that surely do not care too much
about this discussion]
SMC> I strongly suspect that as we collectively try to figure out how to solve
SMC> resource-consumption issues for all kinds of software, we will quickly run
SMC> into lots of complexity that
Hi Michal,
MZ> That was DOM Level 1 (1999). Even level 2 (2000) has this as read-write:
MZ> http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-94282980
Ah, now that makes sense. So my theory goes right down the drain =X
MZ> Also keep in mind that with relatively few exceptions, W3C simply
MZ> tr
> The W3C DOM specifies the select.length attribute to be *read only*.
Does not seem to be the case in HTML5 at least?
http://dev.w3.org/html5/spec/Overview.html#the-select-element
In fact, it has the behavior for writes defined:
"On setting, it must act like the attribute of the same name on t
On Tue, 21 Jul 2009, Thierry Zoller wrote:
> Yeah, security is too complex. Dude, the fix was to LIMIT the the
> number of elements. This is not rocket science.
I believe Michal and I are having the conversation in a larger context.
What you found is valid on its own merit and got addressed, wh
On Tue, 21 Jul 2009, Michal Zalewski wrote:
> The code created an oversized list, which does not seem to be that far
> from creating an overly nested DOM tree, or drawing an oversized CANVAS
> shape, or any other creating-too-many-things-for-the-renderer-to-handle
> attacks... but really, I'm not
Hi Steven,
SMC> we will quickly run
SMC> into lots of complexity that may well enter the realm of undecidable
SMC> problems,
Yeah, security is too complex. Dude, the fix was to LIMIT the
the number of elements. This is not rocket science.
--
http://blog.zoller.lu
Thierry Zoller
> Yes, we all know that. The flaw here was not looping on itself a
> thousands of times, wow. It was a DOM implementation flaw.
The code created an oversized list, which does not seem to be that far
from creating an overly nested DOM tree, or drawing an oversized
CANVAS shape, or any oth
Hi Michal,
Yes, we all know that. The flaw here was not looping on itself a
thousands of times, wow. It was a DOM implementation flaw. That's
what made it interesting. A border case that was not accounted for.
That's all, still interesting. I don't see how Javascripts endless
loops
> + 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
13 matches
Mail list logo
