
Dangerous Web Security Features - based2
https://www.tunetheweb.com/blog/dangerous-web-security-features/
======
ve55
Disagree with HSTS being 'dangerous' in 2019. There are not really any good
excuses left to have any parts of your website (new/different subdomains
included) unable to use https. On the other hand, HPKP is a lot easier to mess
up and is more situational, but HSTS should be standard by now.

The author's recommendations are still good (If everyone tried to set up
strict HPKP+CSP on their websites, I can imagine how many would break), but I
view things like "If you've a sub-site that you never got round to securing
(e.g. [http://blog.example.com](http://blog.example.com)), then you've just
forced yourself to upgrade with this policy." as a positive, not a negative
(hence the word 'upgrade').

~~~
ficklepickle
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://](https://). Including the page with polling location
information.

So any malicious actor in a privileged position, like a public WiFi network
operator, could have effectively prevented people from getting accurate poll
location information, effectively DoSing prospective voters.

I tried to bring this to their attention, but I got a response telling me
their IT guy says it's not a problem because no user data is submitted on
those pages. Never mind that it was probably more work to selectively enable
TLS per URL and leaves important content vulnerable to manipulation.
Incredible!

It's like the old "all of our download links use HTTPS", but the downloads
page is served unencrypted. Frustrating.

~~~
sildur
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.

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

------
geofft
(2015), edited (2018).

I've had week-long HSTS on my personal website for a few years (which is short
enough that most clients ignore it) out of an abundance of caution/FUD, and it
hasn't really been a problem - I _have_ had periods where my cert expired (for
complicated reasons, I renew Let's Encrypt certs manually every three months,
and sometimes I don't get around to it in time), but I didn't remove the
regular HTTP 301 to HTTPS during that time. So I don't think permanent /
preloaded HSTS would have been a problem.

On other sites I've set up since then, I've built them on top of hosting that
assumes reliable HTTPS and renews it for me, e.g., Twisted with txacme or AWS
Cloudfront with Amazon's CA. So I've been able to assume working HTTPS from
day one.

In October 2017, Google announced plans to deprecate self-service HPKP for
exactly the reasons outlined in this article, which took effect in late 2018.
See
[https://developers.google.com/web/updates/2018/04/chrome-67-...](https://developers.google.com/web/updates/2018/04/chrome-67-deps-
rems#deprecate_http-based_public_key_pinning) and the links provided . If
you're a major site and you really, really know what you're doing and you're
confident the risks outlined in this article , you can still get a hard-coded
HPKP entry in the browser source code.

------
tunetheweb
As others have pointed out, this post is from 2015 and a lot has changed since
then. I've added an updated section at the end, to clarify my thoughts since
then (mostly unchanged to be honest, except for CSP):
[https://www.tunetheweb.com/blog/dangerous-web-security-
featu...](https://www.tunetheweb.com/blog/dangerous-web-security-
features/#summary2019)

------
Cpoll
> 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 the other ones, it only affects the resources
it's attached to. It shouldn't be any scarier than making any other change to
your site/app.

Replace with 'the impact of replacing your md5-ed passwords with properly
hashed ones... basically your whole website is broken'. Of course, that's a
reductio ad absurdum in some cases, but if it protects you from XSS it might
be a good analogy.

~~~
tunetheweb
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".

~~~
Cpoll
> 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/

~~~
tunetheweb
> 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...](https://github.com/mikewest/http-state-
tokens/blob/master/README.md)). 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.

------
maletor
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.

~~~
bqe
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](https://pages.nist.gov/800-63-3/sp800-63b.html)

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

------
userbinator
_And then we come to the most dangerous item, because you have least control
over it: preloading HSTS right into the browser._

I can't say specifically why, but there's something about a browser that
treats a certain list of sites specially, by default, that just doesn't sit
well with me. I've had this feeling ever since I heard about the feature. Not
exactly net neutrality, but somewhat reminds me of it.

~~~
defanor
Sounds similar to web browsers coming with their own CA certificates instead
of using system-wide ones, leading to poor integration and inconsistencies.
Though a centralized database of rules for websites sounds awkward on its own.

~~~
tialaramex
> Sounds similar to web browsers coming with their own CA certificates instead
> of using system-wide ones, leading to poor integration and inconsistencies.

Well, the only notable browser which does this is Mozilla's Firefox, and not
coincidentally the only root trust store where you can actually see how the
sausage is made is Mozilla's. All the other big trust stores (Apple,
Microsoft, Google) are black boxes. Presumably they have one or more employees
dedicated to this stuff, but since we're not shown their working it might
equally be the product of an intern throwing darts at a list.

Right now for example Mozilla is discussing Certinomis, a small CA which
doesn't seem to be very good at the technical aspects of their job, issuing
certificates for DNS names with spaces in them, typo'ing dates, filling
parameters out incorrectly, nothing that screams "evil" but certainly more
clumsy than we'd prefer. Are other trust stores thinking about Certinomis?
You'll only find out if one of them announces a change.

------
based2
[https://connect.ed-diamond.com/MISC/MISC-102/L-en-tete-
HPKP-...](https://connect.ed-diamond.com/MISC/MISC-102/L-en-tete-HPKP-pour-
securiser-un-peu-plus-les-connexions-sur-Internet) ?

[https://news.ycombinator.com/item?id=15089513](https://news.ycombinator.com/item?id=15089513)
I'm giving up on HPKP, Aug 24, 2017

------
nokya
This article is probably much more harmful than the security features it
describes as dangerous...

------
MrStonedOne
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.)

~~~
zzo38computer
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).

~~~
sjwright
> 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.

~~~
zzo38computer
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.)

~~~
sjwright
All of the above assumes that the broader population are well informed about
the nuances of digital security. The reality is most people have better things
to do.

As for your third paragraph—I would agree that banks should act more like APIs
and less like their own countries. But that is independent from the use of a
protocol. Arguing between TLS (HTTPS) and SSH borders on bikeshedding.

The reality is more than a billion people are successfully using HTTPS to
safely and securely manage their money, and HSTS is improving the guarantees
around that security. I'm sure you've solved every security and trust risk
with this hypothetical bank-over-IRC-over-SSH protocol with non-mandatory
security... but I'm not yet convinced.

~~~
zzo38computer
You are correct about that; you could do HTTPS (or otherwise TLS) too would
also work, to define such API; it does not have to be SSH.

(Actually, now that I consider, HTTP requests (with HTTPS) might be better
than SSH anyways for many of the things being done, such as downloading a bank
statement. So, it may likely do better. However, the common authentication
protocols are better in SSH, but similar kind of authentication protocols is
probably still possible with HTTPS too, just it does not seem to be as
commonly used, but perhaps it should be.)

