1. 5
  1.  

  2. 11

    Can’t speak for the functionality but it’s a contender for worst package name ever.

    1. 5

      In the security world, the only thing that matters is marketing. Most customers have no clue of what you’re talking about, either way. And most people are selling “the feeling of safety” more than real security.

    2. 6

      IMO a honking great mistake to turn on Strict-Transport-Security by default with a max-age of 2 years. People will drop this in and break their systems and that makes this a footgun. No one should deploy HSTS like that that seems to me to be the consensus among HSTS advocates.

      And why is HTTP caching getting disabled? What does that have to do with security for a website?

      1. 1

        And why is HTTP caching getting disabled? What does that have to do with security for a website?

        it shouldn’t be disabled for all routes, but it minimizes data exposure (1, 2). Basically, if you have anything cached by proxies or in browser, an attacker with something like Local access can steal that data (3).

        1. 2

          X-Frame-Options: SAMEORIGIN is a sane default. Mucking around with cache settings in the abstract with no particular threat model in mind just feels like random, uninformed changes to me.

          How many sites/apis have you personally worked on where there was been serious consideration about how to defend a users local HTTP cache from an attacker on the same machine? I think for me the number is 1, in 10 years, and we weren’t outsourcing it to a third party library.

          1. 1

            How many sites/apis have you personally worked on where there was been serious consideration about how to defend a users local HTTP cache from an attacker on the same machine?

            There are two things to consider really:

            1. that caching isn’t just about the local machine, since depending on the cache control instructions and the path to the end user, it could be cached by other caches, such as proxies
            2. that you only consider the risk of the data being exposed, not that we are defending users from all attacks with Local position

            However, I would say quite a few, esp in the mobile space; lots of mobile applications used to cache all sorts of sensitive data, which could then be exposed by backups or the like. Is this a huge concern for security teams? Generally no, nor should it be; an attacker would need sufficient position, &c. to actually impact incorrect caching, so the Likelihood is low or even very low. That still has worked out to a few hundred reports in my career.

            On the flip side, the Impact could be High or Very High based on the data cached; I’ve seen everything from PANs to user’s PII or other sensitive data to passwords. Again, it depends on the sensitivity of the data being cached, and should be applied selectively. It’s not something you can just scan and hand over, but rather something you work with a system’s actual data to determine.

            Lastly, remember that browser Cache Control nuance led Twitter to have to disclose a DM privacy exposure bug just last year.

      2. 5

        For flask, flask-talisman already exists and in Django has quite a few security headers which can be easily configured through standard settings.

        1. 1

          I agree, however, if you need to secure multiple frameworks within an enterprise, it is nice to have one solution that can be applied across frameworks in a standardized way. For example, at my previous company, we had a client with ~350 python web applications across frameworks, versions, and even versions of python. So it would be nice to have one security framework to be applied regardless of if it were Django, Flask, Bottle, CherryPy, &c.

        2. 2

          I was going to say it’s missing Feature-Policy , but alas it seems they killed that one and replaced it with ’Permissions-Policy`.

          looks like there is a whole slew of new ones coming, not included in secure.py:

          Expect-CT Expect-CT allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their CT policy. Cross-Origin-Embedder-Policy Cross-Origin Embedder Policy allows a site to prevent assets being loaded that do not grant permission to load them via CORS or CORP. Cross-Origin-Opener-Policy Cross-Origin Opener Policy allows a site to opt-in to Cross-Origin Isolation in the browser. Cross-Origin-Resource-Policy

          great.

          Also it’s not even “secure” by default since CSP isn’t included, which is arguably the most important. Of course the default policy that’s “secure” will break 99.999% of all websites on the planet, but you know.. whatever.

          1. 2

            There may be an argument over whether or not it’s worth adding them anyway, but X-Frame-Options and X-Xss-Protection are both obsolete and either unsupported or deprecated in most browsers.

            By default this package doesn’t seem to do very much of anything, although an easy way to write CSP rules is nice.