* Posts by ScottHelme

6 publicly visible posts • joined 22 Jan 2014

uBlock Origin ad-blocker knocked for blocking hack attack squawking

ScottHelme

Re: What's the point of CSP anyway?

If websites don't want CSP or reports then they wouldn't enable it, it's an opt-in feature. This means that those who have enabled it wanted to enable it and will also want the reports to fix problems raised.

Showing CSP reports to the user would increase warning fatigue and be detrimental to the user experience. Should we visually display all warnings that appear in the console to the user?

ScottHelme

Re: disagree with Scott and Troy

I'm curious how your privacy is decreased by sending a CSP report, especially if that report is sent back to the same host.

If the site has an XSS vulnerability then the report would inform the site owner who could take action to fix the underlying cause. I'm not really comfortable with the approach of assuming CSP will always save us. It's a bit like the old problem I came across in the financial sector a lot: "Ah we have a SQL injection flaw but don't worry we have a rule in the WAF to stop it". CSP is not a final solution, much like the WAF rule isn't. It's a temporary measure to address the problem while the root cause is identified and fixed. Unlike us easily being able to get reports for WAF blocks we depend on the UA to send reports of CSP blocks.

ScottHelme

Re: Hang on a minute

"So you're saying that anything reported back should be known anyway, then you knock uBlock for not reporting ?"

That particular comment was regarding information about the user and their privacy. Sending a report discloses the user's IP address and User-Agent string for the browser, but the site already knows those so there is no additional privacy concern.

Now you can easily see if a site's HTTP headers are insecure, beams dev

ScottHelme

Re: Very arbitrary definition of "secure" headers

Hey, thanks for the comment, I'd thought I'd cover a few points.

HSTS may have poorer support in older browser, yes, but vendors aren't going to roll support for new security features backwards through their older versions. If you want support for the latest security features, you need to keep your browser up to date! ( http://caniuse.com/#search=hsts )

CSP has many more uses than just mitigating XSS, I've covered a few on my blog if you want to have a look at some more. CSP doesn't ensure security, I don't think anything can, but it's a step in the right direction. ( https://scotthelme.co.uk/tag/csp/ )

PKP is very rare yes and this is largely due to it being the most recently standardised of the headers and its higher complexity to implement. I'm not sure how it factors in to mobile apps, which wouldn't look at HTTP response headers, they'd key pin via other means if they did. As for native browsers on mobile platforms, they either support it or not, but in time all of them will I'm sure. Lastly, certificate renewal has no impact on PKP, you're pinning the Public Key (PK-Pin) and not the certificate. I currently issue the PKP header on my own site and automatically renew my certificate with Let's Encrypt ( https://scotthel.me/le ).

XFO is incredibly simple to deploy and widely supported, why would you not if you wanted to prevent framing? (or allow it from specific origins)

XXSSP, so if the filter is bypassed once we should abandon using it. Or perhaps the filters could be improved and continue to offer more robust protection moving forwards? The fact is that it does offer some protection which is always better than no protection, all for the sake of issuing a simple HTTP response header!

XCTO also helps to mitigate drive-by downloads if that poses a risk to your site, but even if it did only offer a marginal improvement against XSS, it's a very easy way to get it.

As for the other headers, there's a lot more coming but I couldn't get everything in to v1. Alongside Pragma and Cache-Control I'm looking at the Cookie header (httpOnly, secure) and the Access-Control-Allow-Origin header too. Any other suggestions for improvement are welcomed, you can leave a comment on my blog or find my email address and get in touch directly if you wish.

Scott.

https://scotthelme.co.uk

Saving private spying: IETF Draft reveals crypto-busting proxy proposal

ScottHelme

It's already happening you just don't know it.

This form of transparent MiTM on SSL already happens on a large scale and you don't even give your consent. Providers like CloudFlare et al. act as a reverse proxy for some huge websites and actively act as legitimate MiTM for SSL connections for the purposes of caching. I recently wrote a blog covering this and explain it in a little more detail: http://scotthel.me/cfup

When you visit a site you have no idea where the SSL is terminated and your traffic could be travelling half way across the web without encryption. How do you know if a site is hosted on a service like CloudFlare and that there isn't already a MiTM of your SSL?

BT-owned ISP Plusnet fails to plug security hole on its customer signup page

ScottHelme

Whilst you're correct the form could POST to a HTTPS address, the page is still loaded over HTTP. How can you be sure that the form wasn't modified in transit to the user?

https://scotthelme.co.uk/ssl-about-integrity-too/