* Sid Stamm:
> It's my belief that CSP will generally make attacks more difficult and
> vulnerabilities harder to come by, not just different. In order to
> get the on-click event handler to work, for instance, the developer
> has to place an event handler function somewhere in the white-listed
> script file and use JavaScript to attach it to DOM.
Okay, let's try to make this more concrete. Suppose I've got a web
form, and want to add some client-side validation to it. With CSP,
the HTML will look a bit like this:
<form method="POT">
<input type=text" name="user" />
[more fields, some of them dynamically generated]
<input type="submit"/>
</form>
<script src="/js/lib.js" />
<script src="/js/dyn/Rjw7KbMX2sodKxXetyTSNugzJ" />
The first <script> is some library and is expected to be cached. The
second <script> installs the Javascript validation code. Given that
the form is dynamically generated, a static Javascript file won't do
it, especially if eval and textual event handlers are forbidden.
Maybe it's technically possible to create something which extracts a
description of the event handlers to attach from the contents of a
hidden input field in the form, but I don't think this will be the
approach preferred by developers.
Instead, Javascript will be generated by the same mechanisms that now
generate HTML. With a lot of work, you might be able to create a
validation library which is entirely guided by JSON (see above), but
again, I think this won't be the most favored approach. So we end up
with dynamically generated Javascript, and attackers will inject
Javascript directly, instead of injecting Javascript-carrying HTML
code into HTML documents.
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
