SecurityHeaders - Improve EWL security

1

A security blog brought me to https://securityheaders.com. I ran info.redstapler.biz through it, and we only passed 2/10 tests. A few of them I’ve known about for a while and only have done for certain projects, such as removing the Server header and X-Powered-By, which basically scream “Here’s the exact version of software I use so go searching for vulnerabilities against this version”.

1 Like
2

Thanks for looking into this! If you put together a list of the headers we need, I’ll put them into EwfPage or EwfApp, provided they are just simple hard-coded strings. If there’s anything more complex, I might not be able to do that right away.

We’ve already talked about X-Frame-Options and I think I have an implementation plan written up for that.

1 Like
3

Here is the raw report: https://www.dropbox.com/s/nk8507ma8idpkc2/redstapler%20biz%20security%20headers.pdf

4

I have a few sites (like Todd) that contain some secure pages and some non-secure pages, so I don’t think we should add this header globally.

How likely is it that the XSS filter is going to find a false positive (i.e. a good script that for some reason looks like XSS)? That scenario would be bad for EWL developers.

I agree we shouldn’t do this now, but based on how much EwfPage knows about a page’s content before it’s sent down, this might not be as hard as you think to implement. For example, we already know exactly which CSS files we’re going to include.

This one seems to be the equivalent of X-Frame-Options for Flash/PDF. It seems like a good idea. My only concern is what affect this will have on EWF apps that are not deployed to root web sites (e.g. example.com) but to virtual directories (e.g. example.com/myapp). I think the “master” policy file would be expected at the domain root, which means we wouldn’t have control over it.

The rest of this looks good. Let me know if you have further comments or if you agree with everything I wrote. I’ll implement this when I hear back.