Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dangerous Web Security Features

tunetheweb.com

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Dangerous Web Security Features

#31

Post by tunetheweb »

Cpoll wrote: post #17

> The impact of an incorrect CSP policy, or browser issue could vary from a "Tweet This" button not loading (no big deal), to ads not loading (hurting your income), to stylesheets not loading (basically your whole website is broken). I really don't like the sentiment that you shouldn't add a security feature because it might be difficult. Any change comes with risk of regression, but CSP isn't even domain-level like…

OP here and I disagree. Implementing a CSP for a page is hard (given the many different browsers), implementing it for a site is really hard! And yes it does pretty much need to be "domain level" to be effective.

It's easy to test if a password algorithm change fails, not so much for CSP. And the reporting options are next to useless because they are so noisy.

That's not to say people shouldn't implement CSP - it's a great option (now - less so in 2015 when this post was written). But they shouldn't just copy and paste a CSP policy from a random blog post they found, get an A+ on a security scanning tool and feel proud, without realising that they may have broken part of their website or implemented a pointless CSP. That was intention of this post and apologies if it read as "don't use then cause they are hard".

Re: Dangerous Web Security Features

#32

Post by tpetry »

bqe wrote: post #10
maletor wrote: post #6

Can we add minimum password complexity requirements to this list? There is nothing more annoying than having to adjust my already 128-bits of entropy password because the website feels I need a special character. Plus, now hackers have a guide for what the password looks like.

NIST 800-63b actually recommends against character class requirements[1] in favor of minimum length requirement and blacklists of breached passwords and other obvious passwords. Sites that require special characters are not following the current best practice. [1]: https://pages.nist.gov/800-63-3/sp800-63b.html

Isn‘t any obvious password already in the list of breached passwords? ;)

Re: Dangerous Web Security Features

#33

Post by odensc »

MrStonedOne wrote: post #15

I still very strongly oppose HSTS's "No user recourse" policy, and don't deploy it on my sites purely for that reason. I get the reasoning, but it's still unethical to the user. (as an aside, hsts applies to all ports with no option to disable this, something to keep in mind.)

On Chrome, you can type `thisisunsafe` to skip it.

Re: Dangerous Web Security Features

#34

Post by jeroenhd »

stefan_ wrote: post #16
jeroenhd wrote: post #11

Earlier quoted context omitted.

Netflix can't really be cached anyway because of DRM + rotating keys. You'd need to cache for every device (type/model) and get the big wigs from Hollywood to accept allowing data storage in caches everywhere. Also, I don't want my employer to know what movies I'm watching. I'd personally opt out (or not use Netflix) if this became an option.

Well, I think Netflix has cache/edge servers that they deploy to ISPs instead. That said, last I looked at it, the model described (keys through https, enc. chunks through http) was used by BAMTech for example.

That's true about Netflix, large networks can apply for boxes with Netflix caches for free (or at least they used to be free, maybe there's a small cost today) if they want to reduce load on their peering/network.

Re: Dangerous Web Security Features

#35

Post by DenseComet »

sildur wrote: post #25
ficklepickle wrote: post #7

Earlier quoted context omitted.

I definitely agree there's no excuse not to use TLS anymore. I recently ran into this on a city of Vancouver website for voting information. While any page that had a form used HTTPS, all other pages forced the user to use HTTP. Like, for those pages, it redirected to unencrypted even if you typed in https:// . Including the page with polling location information. So any malicious actor in a privileged position, like…

Maybe all they can afford is a really old or weak server machine, and are afraid of the extra computational power that enabling https on all pages would incur.

Elliptical curve based keys are now supported by all major browsers and require much less processing power and overhead compared to traditional RSA keys.

Re: Dangerous Web Security Features

#36

Post by Cpoll »

tunetheweb wrote: post #31
Cpoll wrote: post #17

> The impact of an incorrect CSP policy, or browser issue could vary from a "Tweet This" button not loading (no big deal), to ads not loading (hurting your income), to stylesheets not loading (basically your whole website is broken). I really don't like the sentiment that you shouldn't add a security feature because it might be difficult. Any change comes with risk of regression, but CSP isn't even domain-level like…

OP here and I disagree. Implementing a CSP for a page is hard (given the many different browsers), implementing it for a site is really hard! And yes it does pretty much need to be "domain level" to be effective. It's easy to test if a password algorithm change fails, not so much for CSP. And the reporting options are next to useless because they are so noisy. That's not to say people shouldn't implement CSP - it's a…

> It's easy to test if a password algorithm change fails, not so much for CSP.

Probably a bad example, because the former is server-side. But why is CSP harder to test than any other client-side change, like rewriting your login page/component?

> And yes it does pretty much need to be "domain level" to be effective.

I meant to say that you can add it as a XSS prevention to example.com/app/ and not worry about example.com/static/ or example.com/blog/

Re: Dangerous Web Security Features

#37

Post by tunetheweb »

Cpoll wrote: post #36
tunetheweb wrote: post #31

Earlier quoted context omitted.

OP here and I disagree. Implementing a CSP for a page is hard (given the many different browsers), implementing it for a site is really hard! And yes it does pretty much need to be "domain level" to be effective. It's easy to test if a password algorithm change fails, not so much for CSP. And the reporting options are next to useless because they are so noisy. That's not to say people shouldn't implement CSP - it's a…

> It's easy to test if a password algorithm change fails, not so much for CSP. Probably a bad example, because the former is server-side. But why is CSP harder to test than any other client-side change, like rewriting your login page/component? > And yes it does pretty much need to be "domain level" to be effective. I meant to say that you can add it as a XSS prevention to example.com/app/ and not worry about example…

> But why is CSP harder to test than any other client-side change, like rewriting your login page/component?

Maybe not so much now. But when I wrote that post there were lots of bugs and missing features across the various browsers (examples in the post). It was early days for CSP and it’s got better since (hence why I now do recommend CSP), but regardless CSP is a complex technology and tough to get right. Each page and each browser might have its own CSP requirements (e.g. when polyfills are included on a bad for example).

> I meant to say that you can add it as a XSS prevention to example.com/app/ and not worry about example.com/static/ or example.com/blog/

Then your cookies are at risk. Yes cookies can be scoped to a path, but few do that. And they can be made HttpOnly which is more common, but still not used anywhere near enough (8.31% of cookies - https://github.com/mikewest/http-state-tokens/blob/master/RE...). Additionally if you have a vulnerability on /static/ then you can hijack the app link or login link to send users to badexample.com or similar when they want to login to the app.

It will still offer some protection if only on /app/ and is better than nothing, but still preferable to have it on the whole domain. It’s like HTTPS - having it on just one page is an anti-pattern that shouldn’t be used anymore.

Re: Dangerous Web Security Features

#38

Post by sjwright »

MrStonedOne wrote: post #26
sjwright wrote: post #24

Earlier quoted context omitted.

How is it unethical to protect your users from MITM attacks? Why would any end user need “recourse” to connect to your server incorrectly? If you’re no longer serving content over HTTP anyway, what opportunity is lost?

I'm not an end user, and I should have the ability to bypass expired/invalid cert errors on both my own sites, as well any other site out of curiosity. Sure, lock it behind a flag or other hidden setting, that even covers enterprise clients because they already disable setting those on their domain computers, but it should be possible nonetheless to bypass the error.

That's an objection to the exposed features in your web browser, not the normal use of HSTS by websites.

Did you even try a Google Search?[0] If you use Firefox (which you should) it is possible to bypass that setting, using a feature locked behind "a flag or other hidden setting." Specifically, it is the about:config setting security.mixed_content.use_hstsc

My suggestion is to use Firefox Developer Edition and modify the security setting there—allowing you to bypass HSTS whenever you like without any accidental security risk for your normal browsing.

[0] https://campus.barracuda.com/product/websecurityagent/doc/73...

Re: Dangerous Web Security Features

#39

Post by sjwright »

zzo38computer wrote: post #29
MrStonedOne wrote: post #15

I still very strongly oppose HSTS's "No user recourse" policy, and don't deploy it on my sites purely for that reason. I get the reasoning, but it's still unethical to the user. (as an aside, hsts applies to all ports with no option to disable this, something to keep in mind.)

I agree with you. That is also why I hate HSTS and will not use it. The user must be given permission to override (for any reason they want to, including one you don't know) anything, and must have enough ropes to hang yourself and also a few more just in case. HSTS is terrible, even if you support HTTPS (which you probably should).

> I hate HSTS and will not use it.

HSTS is just a flag. What you "hate" is that a piece of software under ~YOUR~ control (the web browser) happens to be correctly enforcing the intent of that flag. If you don't like HSTS, it is ~YOUR~ choice whether you use a web browser that will follow your instructions or someone else's. If your web browser does not offer a method to disable HSTS like Firefox does, switch to a browser that is willing to follow your instructions.

> HSTS is terrible

That is an absurd opinion. HSTS makes the internet objectively safer by requiring trust between your web browser and web servers. Who would want optional trust between themselves and their online bank to be the default state of affairs? If a website deals with money (or other items of value) and it is not HSTS preloaded, it is being stupidly and dangerously unsafe.

Re: Dangerous Web Security Features

#40

Post by zzo38computer »

sjwright wrote: post #39
zzo38computer wrote: post #29

Earlier quoted context omitted.

I agree with you. That is also why I hate HSTS and will not use it. The user must be given permission to override (for any reason they want to, including one you don't know) anything, and must have enough ropes to hang yourself and also a few more just in case. HSTS is terrible, even if you support HTTPS (which you probably should).

> I hate HSTS and will not use it. HSTS is just a flag. What you "hate" is that a piece of software under ~YOUR~ control (the web browser) happens to be correctly enforcing the intent of that flag. If you don't like HSTS, it is ~YOUR~ choice whether you use a web browser that will follow your instructions or someone else's. If your web browser does not offer a method to disable HSTS like Firefox does, switch to a bro…

I know that about the flag, and managed to hack Firefox so that HSTS won't work. (Although I wrote a document how to write a better web browser program, but it isn't implemented.)

Trust between whatever (and other options about what features to enable/disable/alter, such as what fonts to use, any kind of URL redirections, etc) should be defined by the user. There are several reasons you may wish to alter the settings. (Anyways, you can configure cookies for secure connections only; the user should also be allowed to configure whether or not to use key pinning for secure cookies (individually per domain).)

(I also think that both HTTP and HTTPS are bad for banking anyways, and that a specialized kind of bank/money protocol that can be worked over SSH might be working better (preferably that can be used with text, so that even without specialized software you can still do some stuff with it; IRC does that too and that is what makes IRC good). This is independent of the above stuff, though.)

Post reply on HN