On Thu, 4 Feb 2010, Tab Atkins Jr. wrote:
On Thu, Feb 4, 2010 at 5:12 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 25 Jan 2010, Tab Atkins Jr. wrote:
Adam Barth rightfully points out that this only stops certain classes
of data exfiltration attacks, and so probably isn't worthwhile as a
On 4 Feb 2010, at 17:44, Michal Zalewski wrote:
If there's no HTML, there's no need for a sandbox, so the simplest
solution is just to escape the s and s.
Which people fail at, big time. There are 50,000+ entries on
xssed.com, many of them against big sites presumably developed by
skilled
Kornel Lesinski wrote:
However, if we're going to introduce token-based sandbox anyway, I
suggest putting token in tag name:
sandbox-$token.../sandbox-$token
where $token is the random part. This avoids oddity of attributes in
closing tag, and is compatible with XML. In XML you could also use:
Lachlan Hunt wrote:
Kornel Lesinski wrote:
However, if we're going to introduce token-based sandbox anyway, I
suggest putting token in tag name:
sandbox-$token.../sandbox-$token
where $token is the random part. This avoids oddity of attributes in
closing tag, and is compatible with XML. In
On 5 Feb 2010, at 14:19, Lachlan Hunt wrote:
where $token is the random part. This avoids oddity of attributes in
closing tag, and is compatible with XML. In XML you could also use:
$token:sandbox xmlns:$token=…/$token:sandbox
No, you couldn't use a namespace like that, because then the
On Thu, Feb 4, 2010 at 11:12 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 25 Jan 2010, Alex Russell wrote:
AFAICT, the objections fall into several buckets:
1.) Users might pick badly or may re-use nonces when they shouldn't.
2.) Escaping is believed to be more secure because it's
On Mon, 25 Jan 2010, Michal Zalewski wrote:
This has been proposed before. The concern is that many authors would
be likely to make mistakes in their selection of random tokens that
would lead to significant flaws in the deployment of the feature.
srcdoc= is less prone to errors.
On Thu, Feb 4, 2010 at 5:12 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 25 Jan 2010, Tab Atkins Jr. wrote:
Adam Barth rightfully points out that this only stops certain classes
of data exfiltration attacks, and so probably isn't worthwhile as a
solution to that matter. However, I think this
Not escaping is so easily and quickly discovered that I really don't
think that's a problem.
The same argument could be made for not escaping , but I don't think
it's valid in practice - particularly for (hypothetically) constrained
input fields.
That would be great. I think Adam proposed we
On Thu, Feb 4, 2010 at 12:44 PM, Michal Zalewski lcam...@coredump.cx wrote:
The same argument could be made for not escaping , but I don't think
it's valid in practice - particularly for (hypothetically) constrained
input fields.
The use-cases for srcdoc are only where you expect HTML input.
On Mon, Jan 25, 2010 at 1:29 AM, Adam Barth wha...@adambarth.com wrote:
That depends what information the attacker encodes in the host name.
Recall that we're imaging the attacker gets to run JavaScript within
the sandbox
If we're assuming that, then yes, it's probably hopeless. But are we
On Mon, Jan 25, 2010 at 5:39 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Mon, Jan 25, 2010 at 1:29 AM, Adam Barth wha...@adambarth.com wrote:
That depends what information the attacker encodes in the host name.
Recall that we're imaging the attacker gets to run JavaScript within
the
I've introduced srcdoc= to largely handle this. There is an example in
the spec showing how it can be used.
Yup, sounds good.
This has been proposed before. The concern is that many authors would be
likely to make mistakes in their selection of random tokens that would
lead to significant
The reason to use a MIME type here is to trick legacy browsers into
not rendering the response as HTML.
Legacy browsers probably will, anyway :-(
/mz
On Mon, Jan 25, 2010 at 1:51 PM, Michal Zalewski lcam...@coredump.cx wrote:
This has been proposed before. The concern is that many authors would be
likely to make mistakes in their selection of random tokens that would
lead to significant flaws in the deployment of the feature.
srcdoc= is
Michal Zalewski brings up several good suggestions for improvements to
@sandbox that would make it more useful for embedding general
untrusted user content. As well, Shelley Powers brought up a few
common uses that I think could fit into this model and prove useful.
1) Prevent cross-origin
On Sun, Jan 24, 2010 at 2:52 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Dec 2009, Michal Zalewski wrote:
1) IFRAME semantics make it exceedingly cumbersome to sandbox short
snippets of text, and this task is perhaps the most common and pressing
XSS-related challenge. Unless the document
On Mon, Jan 25, 2010 at 5:45 PM, Alex Russell slightly...@google.com wrote:
Sorry I'm late to this discussion. Would like to add my objection to
using attribute string escaping as a security feature in any way. I
strongly prefer required nonces attached to opening and closing of
sections.
Do
AFAICT, the objections fall into several buckets:
1.) Users might pick badly or may re-use nonces when they shouldn't.
2.) Escaping is believed to be more secure because it's likely to
break more often, raising developer awareness
3.) The fix to correct escaping problems is believed to be
On Fri, 11 Dec 2009, Michal Zalewski wrote:
1) IFRAME semantics make it exceedingly cumbersome to sandbox short
snippets of text, and this task is perhaps the most common and pressing
XSS-related challenge. Unless the document is constructed on client side
by JavaScript, sites would need
On Sun, Jan 24, 2010 at 11:52 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Dec 2009, Michal Zalewski wrote:
2.1) The ability to disable loading of external resources (images,
scripts, etc) in the sandboxed document. The common usage scenario is
when you do not want the displayed document to
On Sun, 24 Jan 2010, Adam Barth wrote:
On Sun, Jan 24, 2010 at 11:52 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Dec 2009, Michal Zalewski wrote:
2.1) The ability to disable loading of external resources (images,
scripts, etc) in the sandboxed document. The common usage scenario is
On Sun, Jan 24, 2010 at 5:52 AM, Ian Hickson i...@hixie.ch wrote:
What would the sandbox do, other than require one level of escaping?
i.e. what is it protecting against?
span sandbox$something/sandbox was meant to be more or less the
same as iframe sandbox srcdoc=$something. The latter
On Fri, Dec 11, 2009 at 10:18 PM, Michal Zalewski lcam...@coredump.cx wrote:
1) IFRAME semantics make it exceedingly cumbersome to sandbox short
snippets of text, and this task is perhaps the most common and
pressing XSS-related challenge. Unless the document is constructed on
client side by
I believe that the @doc attribute, discussed in the original threads
about @sandbox, will be introduced to deal with that. It'll take
plain html as a string, avoiding the opaqueness and larger escaping
requirements of a data:// url, as the only thing you'll have to escape
is whichever quote
Nah, token-guarding is no good. [...] More importantly, though,
it puts a significant burden on authors to generate unpredictable
tokens.
Btw, just to clarify - I am not proposing this instead of the current
method; we could very well allow token-guarded sandboxing on divs /
spans, and
On Sun, Dec 13, 2009 at 11:02 AM, Michal Zalewski lcam...@coredump.cx wrote:
More importantly, though, it puts a significant burden on authors to
generate unpredictable tokens. Is this difficult? No, of course not.
But people *will* do it badly, copypasting a single token in all
their
The @sandbox seems like a better fit for the advertising use case.
I am not contesting this, to be clear - I am aware of many cases where
it would be very useful - but gadgets are a fairly small part of the
Internet, and seems like a unified solution would be more desirable
than several very
On Sun, Dec 13, 2009 at 1:30 PM, Michal Zalewski lcam...@coredump.cx wrote:
I haven't really seen a compelling argument why all these can't be
unified without a significant increase in code or spec complexity -
maybe one exists.
That seems like a backwards way of proceeding. Do you have a
[...sorry for splitting the response...]
People screw up CSRF tokens all the time. The closing tag nonce
design has been floating around for years. The earliest variant I
could find is Brendan's jail tag.
Sure, I hinted it not as a brilliant new idea, but as a possibilty.
I do think giving
How do I use the jail tag to sandbox advertisements?
Huh? But that's not the point I am making... I am not arguing that
iframe sandbox should be abandoned as a bad idea - quite the opposite.
I was merely suggesting that we *expand* the same logic, and the same
excellent security control
On Sun, Dec 13, 2009 at 2:00 PM, Adam Barth wha...@adambarth.com wrote:
The sandbox tag is great at addressing that use case. I don't see why
we should delay it in the hopes that the jail tag comes back to
life.
And Adam - as you know, I have deep respect for your expertise and
contributions
On Sun, Dec 13, 2009 at 2:13 PM, Michal Zalewski lcam...@coredump.cx wrote:
How do I use the jail tag to sandbox advertisements?
Huh? But that's not the point I am making... I am not arguing that
iframe sandbox should be abandoned as a bad idea - quite the opposite.
I was merely suggesting
On Fri, Dec 11, 2009 at 11:18 PM, Michal Zalewski lcam...@coredump.cx wrote:
The ability to sandbox SPANs or DIVs using a token-guarded approach
(span sandbox=random_token/span sandbox=same_token) is, on the
other hand, considerably easier on the developer, and probably has a
very similar
span sandboxlt;spangt;But this span will have another span as its
child, sandboxed. The regular parser sees no entities here, only a
nested span!lt;/spangt;/span
That's a pretty reasonable variant for lightweight sandboxes, IMO. It
does not have the explicit assurance of a token-based
Hi folks,
So, we were having some internal discussions about the IFRAME sandbox
attribute; Adam Barth suggested it would be more productive to bring
some of the points I was making on the mailing list instead.
I think the attribute is an excellent idea, and close to the dream
design we talked
36 matches
Mail list logo
