Brendan Eich wrote:
> Trevor Jim wrote:
>>> It started out as a hash of something, but it ended up a key. I'll
>>> update my latest slides, which I'll be publishing soon. Thanks,
>>>
>>> /be
>>
>> Nor is it a key, e.g., you are not encrypting anything.
>
> Touche' -- not sure what to call it, othe
Robert Sayre wrote:
>
> As Brendan points out, you can't rely on web server applications to
> correctly parse HTML at this point.
I agree, and I think that our sandbox implementation does a good job
of avoiding this problem. I'll hold off on commenting on the
proposal until I see the details.
Brendan Eich wrote:
> I'm not kidding, and I'm not saying some web developers should not have
> the ability to script filtering of user-generated content. The expertise
> to do this well, and to track evolving browser features, is rare.
Possibly true. But so is the ability to write decent and we
Trevor Jim wrote:
>
> Yes, but it seems to me that you've got the untrusted content in your
> hands and you can deterministically ensure that the "hash" does not
> occur in it.
As Brendan points out, you can't rely on web server applications to
correctly parse HTML at this point. Libraries like h
Brendan Eich wrote:
> Trevor Jim wrote:
>> I don't
>> think I can anticipate just what policies web app developers will
>> want.
>
> Our experience is that they want everything, and only know to
> blacklist
> the obvious threats, which is of course insufficient for security, and
> also (they s
Trevor Jim wrote:
> Regarding putting the onus on browser developers, I don't think we should
> put the complete responsibility on them. Our idea is that the
> responsibility
> has to be shared between browser developers and web app writers. I don't
> think I can anticipate just what policies we
Trevor Jim wrote:
>> It started out as a hash of something, but it ended up a key. I'll
>> update my latest slides, which I'll be publishing soon. Thanks,
>>
>> /be
>
> Nor is it a key, e.g., you are not encrypting anything.
Touche' -- not sure what to call it, other than "id".
> An additional p
On Apr 11, 2007, at 5:20 PM, Brendan Eich wrote:
> My sketch was just that: a slideware sketch. The idea is to put the
> onus
> of whitelisting or sandboxing (or taint-tracking information flow,
> etc.)
> on the browser implementors, who are fewer and more used to this level
> of threat and st
Trevor Jim wrote:
> On Apr 10, 2007, at 6:15 AM, Gervase Markham wrote:
>
>>> To be foolproof, the proposal does need to scan the untrusted
>>> content to ensure that the "hash" is not in the content, this is
>>> slightly
>>> more involved than the HTML/JavaScript escaping our proposal requires.
> It started out as a hash of something, but it ended up a key. I'll
> update my latest slides, which I'll be publishing soon. Thanks,
>
> /be
Nor is it a key, e.g., you are not encrypting anything.
An additional problem: as far as I know, attributes are not allowed
on end tags.
-Trevor
___
On Apr 10, 2007, at 6:15 AM, Gervase Markham wrote:
>> To be foolproof, the proposal does need to scan the untrusted
>> content to ensure that the "hash" is not in the content, this is
>> slightly
>> more involved than the HTML/JavaScript escaping our proposal
>> requires.
>
> I don't think s
Gervase Markham wrote:
> Ka-Ping Yee wrote:
>> Is it actually a hash of anything? It looks to me more like a key.
>> If so, it should be called a key.
>
> From my reading, I don't think it is, no. BICBW.
>
> Gerv
It started out as a hash of something, but it ended up a key. I'll
update my lat
Trevor Jim wrote:
> A problem with our proposal is that it relies on scripting being
> turned on, and if scripting is not turned on you don't see the untrusted
> content at all --- even though with scripting turned off it should be
> safe. You can have a separate , but that means the content
> has
Ka-Ping Yee wrote:
> Is it actually a hash of anything? It looks to me more like a key.
> If so, it should be called a key.
From my reading, I don't think it is, no. BICBW.
Gerv
___
dev-security mailing list
dev-security@lists.mozilla.org
https://list
On Mon, 9 Apr 2007, Trevor Jim wrote:
> Gervase Markham wrote:
> >
> > Note to readers: Brendan proposed
> >
> >-- untrusted content here --
> >
>
> (BTW I think "hash" is a misleading word to use here, unless I am
> misunderstanding the details of Brendan's suggestion.)
Is it actually a has
Gervase Markham wrote:
>
> Note to readers: Brendan proposed
>
>-- untrusted content here --
>
Just to be complete, here's what we proposed:
document.getElementById('foo').innerHTML = "quoted untrusted content";
A problem with our proposal is that it relies on scripting being
turned
Trevor Jim wrote:
> I'm not so sure, because you would typically use the sandbox only around
> third-party content. In a typical web app that means you are inserting
> some variable like $x in a template, it would not be much of a change to
> use something like wrap($x) instead, where the wrap fun
Trevor Jim wrote:
> I think there are not race conditions because javascript does not have
> concurrency.
Actually, with things like synchronous XMLHttpRequest it does in practice...
As
long as a script is careful not to do anything which might require spinning the
event loop (XMLHttpRequest,
Gervase Markham wrote:
> Your proposal is very interesting indeed. Some thoughts:
>
> - A 6-15% rendering speed decrease may not seem like much, but browser
> makers generally consider that an enormous deal. A few years ago,
> someone rewrote our entire style system for what I believe was a 5%
Trevor Jim wrote:
> http://www.research.att.com/~trevor/beep.html
>
> Briefly, we modify browsers so that a web site can write a security
> policy on what scripts will be allowed to run in the browser. The
> policy takes the form of a JavaScript function that is simply embedded
> in a web pag
Hello. I wonder if there is any interest in adding some features
to firefox/mozilla for protecting against script injection/cross-site
scripting. Some colleagues and I have a proposal that we have
implemented in several other browsers (Konqueror, Safari, Opera) and
we believe it would be easy to
21 matches
Mail list logo
