Re: Content Security Policy - Relaxed Restrictions Mode(s)
On Jul 1, 5:20 pm, Jonas Sicking jo...@sicking.cc wrote:
myForm.addEventListener(submit, function(event) {
if (!checkform()) {
event.preventDefault();
}
}, false);
That did work, I had a typo was all.
Good enough for now, for IE - I'll deal with it later.
Thank you.
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
Server Side CSP
Hi - I've been working on a php class that implements CSP as an output filter on the web server before the content is ever sent to the requesting browser. That way browsers that don't support CSP still can have some measure of protection when a website decides to implement CSP (and utilizes my class). The class homepage is here: http://www.clfsrpm.net/xss/ It's still highly experimental but it is both working as I need for the web app I'm developing (not live) and can be played with via a test page that has a textarea input that is (mostly) unfiltered straight into the DOM before being run through the output filter (I say mostly unfiltered because I use DOMDocument loadHTML() to eat the input and it does some minor filtering of it's own) http://www.clfsrpm.net/xss/dom_script_test.php There are currently a few things about CSP that I am a little confused about though - 1) if style-src does not contain the host the page is being served from, do in-line style need to be blocked? 2) Does the host expression list limit a wildcard to the beginning of a host expression? Obviously ending in a * (unless you intend to allow all hosts and just have a *) is kind of worthless, but does it allow, say, images.*.somewhere.net? Right now I assume that it does not. 3) Does CSP really block all event attributes? The wiki page doesn't cover event attributes, but the (seems to be a little out of date) http://people.mozilla.org/~bsterne/content-security-policy/details.html page states that Script called using event-handling attributes is not executed. The way I'm handling that in my class is to blacklist all event attributes but allow a whitelist of event attributes that are allowed, however, any event attributes in the whitelist can only call functions without arguments. 4) It looks to me like frame-ancestors is something that can only be enforced client side. Is that correct? ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy questions / thoughts
OK - I really do need to be able to define a function in the head and call a function with an argument. The form allows for uploading files. Thus I set a random upload identifier so that when submit is pressed and the form client side validates, a new window pops up with the upload identifies so get the progress of the upload from my server. The only way to move that to an external js file is to make the external js file dynamic and pass the upload identifier to it as a get variable. If that's what has to be done I suppose it has to be done, but there really should be a way to white list inline javascript functions - allow them if defined in the document head, and allow calling functions with arguments - since the policy restricts where external js can come from, the only functions that could be called are either standard javascript functions or functions defined in an allowed js file or the document head. Perhaps you could disallow javascript arguments that call a url not in an allowed domain (but you probably need to allow a url in the argument for things like opening up an upload progress window) ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: script execution header
On Feb 14, 1:00 pm, FunkyRes funky...@gmail.com wrote: Yes! That looks exactly like what I want to see. Hopefully something comes of it. I played with it a little bit and it does exactly what I want it to do (and more). Only hitch is - the addon to test it does not seem to be able to turn it off by clicking on the icon. Disabling it / enabling it demonstrates that it works though. Anyway, I hope this is something that is implemented by the browsers out there, it would make me feel safer to know web developers are implementing it and it would be nice to know I can give users of my website (once browsers implement it) some added protection against bugs that *hopefully* are not in my code. I like it. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Content Security Policy questions / thoughts
I've read through the previous discussion at http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/d3147f8a4d6b792c# I'm a little bit confused about inline scripting. If I understand things correctly, the policy is designed to have some protection against inline scripts which currently are not implemented in the demonstrative proof of concept add-on that I'm playing with to test my site. I have some confusion though about how that is going to be implemented. The site I am developing uses very little JavaScript, only the forms use JavaScript (I server side validate as well). Most of the functions are defined in an external js file. One of the functions is dynamically generated when the page is requested, and put into a CDATA chunk in the head element of the resulting xhtml. It's my form page, and the form page actually can generate 4 different types of forms that have many fields in common, the generated function is the validation script that calls externally defined functions for the various fields on submit. I suppose it would be possible to just put four different validation functions that are very similar in an external file but it made more sense at the time I wrote it to just dynamically generate the validation script. Does CSP allow functions to be defined in the head section of an xhtml page? Something else that struck out at me from that discussion was this: -- Perhaps you should allow something like a single parameter-less function invocation inside handlers, e.g. allow this: img id=img123 onClick=onclickhandlerfoo() Obviously you can't allow parameterized functions, as this will open up security holes, e.g. eval(something bad) or innocent_function(123,eval(bad stuff here),456) -- Almost all of my form fields have onchange=somefunction() for pre post validation purposes. Most of the time I don't pass any parameters but in some cases, I do pass a parameter - the id of the field calling the function. The parameter is hard coded, not variable (I don't even do this.id - I put the actual element id in when the page is generated). IE - I have fields for air temperature, surface temperature, water temperature, body temperature - it makes sense to use the same validation function for each one since each one has the same validation parameters - and pass the id field to the function rather than having several functions with the input id in the function. Further down in the body I have a cdata section that does not define functions but calls some functions with parameters (the form has a select menu that is too big, people with javascript enabled get it replaced with one menu that dynamically generates a second menu). I can do it without using arguments, it will bloat the external js file somewhat but it is doable. Maybe for the form I shouldn't use CSP - the form does not display any user input data, it just eats user input data, but if I can use CSP on every page (once it is finalized) I would like to. I'm not personally *that* worried about XSS in the site I'm putting together since I designed the site using the php DOMDocument class for every page (which does a good job of turning malicious input into a proper xml text node) but I suppose any software has the potential of being tricked. Anyway, if the CSP is going to filter out inline JS that calls an argument, it would be nice IMHO to be able to turn that policy off for a specific page, such as a form. It sure would make it easier to implement - and I suspect it will be better received by web devs if it isn't a complete royal pain to port existing sites to use it. I do as a user really appreciate that something like this is being done, I always thought it strange that we freak about executing e-mail attachments yet the web almost requires you to run scripts in your browser from unknown sources. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: script execution header
On Feb 12, 7:16 am, Johnathan Nightingale john...@mozilla.com wrote: You may be interested in the Content Security Policy work, described here: http://people.mozilla.org/~bsterne/content-security-policy/ Cheers, Johnathan Yes! That looks exactly like what I want to see. Hopefully something comes of it. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
script execution header
Since so many sites are dynamically generated and can create their own headers, and since so many of these sites have XSS vulnerabilities, how about a header that tells the browser the domain scope for scripts? IE - the header could tell the browser that the page does not use any scripts, only uses scripts served from the same host, or only uses scripts served from the same domain (those who use scripts from other domains could just not send the header). That way if a web developer wants to inform the users client that the page does not use any third party scripts, and his app has an XSS vulnerability, the browser can refuse to execute the code. I know about (and use) NoScript but I still think the ability of web developers to send a header for those who don't have something like NoScript installed would be a good idea. Even with NoScript it would be a good idea - IE a site I'm currently working on uses JS for form validation, but doesn't use it anywhere else, including pages that display data users submitted. The ability to have those pages send a header saying no scripts should be processed for those pages would be a good thing (IMHO). Just a thought. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
