Security Headers + Extras Project

[Caleb]

👋 All, I would appreciate any feedback on a lightweight security headers and cookie attribute project for Python web frameworks (including Pyramid) called Secure 🔒. Secure lets developers easily set security headers and secure cookies with recommended values. The repo is:
https://github.com/cakinney/secure. 🙏

[Mike Orr]

On Fri, Dec 7, 2018 at 2:25 AM Caleb <caki...@gmail.com> wrote:

👋 All, I would appreciate any feedback on a lightweight security headers and cookie attribute project for Python web frameworks (including Pyramid) called Secure 🔒. Secure lets developers easily set security headers and secure cookies with recommended values. The repo is:
https://github.com/cakinney/secure. 🙏

It's a great concept. My IT department requires web apps to go through a checklist of OWASP and other security recommendations, and I had to write custom code to implement some of them like X-Frame-Options and the cookie headers because there wasn't a library like Secure available. On the other hand, Strict-Transport-Security is handled server-wide on all servers so it didn't need to be in the application.

I reviewed the docs and Pyramid configuration and glanced at the code. My impressions:

- The header options look convenient enough.

- Could 'max_age' be an integer? It looks like not because it's embedded in a larger string. Perhaps those suboptions should have separate arguments?

- For Pyramid applications it would be most convenient to have a Pyramid include that parses the config settings for you. I understand that Secure may not want to include boilerplate code for that because it would imply a nominal Pyramid dependency. I think that could best be incorporated into Pyramid itself or a 'pyramid_secure' package. The latter would be ridiculously small though.

- It would be helpful in the documentation to have a link at each option pointing to the recommendations on how to decide what settings you want. For instance, I had to study Cache-Control to decide which settings to implement, and I haven't seen the Feature settings before and don't know what all the options mean. (Magnetometer, what's that?) There is a link to the OWASP Cheat Sheet at the bottom, but I didn't see this until I got to the end of the doc, and it still would be more convenient to have a setting-specific link at each setting.

[Jonathan Vanasco]

I may have missed something, but it looks like the 'secure' bit of the cookie is in the settings, but not the value.

From a pyramid standpoint, this would be a step backwards - as the default policy is a signed cookie.

My 2¢: your package should implement signed cookies by default... and support plaintext and encrypted cookies as options.

[Bert JW Regeer]

Pyramid also by default supports all of the "secure" parts of the cookie. There are no extra flags that can't already be set using Pyramid.

Using the Secure package for cookies is unnecessary.

Bert

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/c1de437b-35e6-4ab6-8858-6c85a027c6af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Merickel]

On Mon, Dec 10, 2018 at 12:21 PM Bert JW Regeer <xist...@0x58.com> wrote:

Pyramid also by default supports all of the "secure" parts of the cookie. There are no extra flags that can't already be set using Pyramid.

Using the Secure package for cookies is unnecessary.

I imagine the benefit is less for Pyramid's builtin sessions and auth tokens but for other arbitrary cookies a user may set where right now you must remember/pass in all the options to `response.set_cookie`. If I were doing this myself I'd probably use `config.set_response_factory` to define a custom response subclass that contains some form of `response.set_secure_cookie(key, value, **kwargs)` that had signing built into it, or even just define some more purpose-built functions for the different types of cookies I want to set. Fortunately most of my apps don't set cookies other than auth/session so I don't really care. :-)

To summarize above, my main feedback would be that I'm a little surprised the library doesn't provide some way to define a context object that can be passed around with pre-configured settings. That way at the call-site where I want to set the cookie I can just grab some object and use my key/value without needing to think about the actual cookie properties. That would be an improvement Pyramid's current `response.set_cookie` which is pretty feature-complete with the SecureCookie offering in secure.

Imagine at config-time you define something like `remember_me_cookie = SecureCookie(...)` and then later on in your code you can set/grab the value for that cookie via `request.registry.remember_me_cookie.get_value(request)` and `request.registry.remember_me_cookie.set_value(response, value)`. This makes consuming the cookie super easy and secure by default because all the settings are configured at config-time.

I'd argue for and define similar apis for SecureHeaders etc.

- Michael

[Michael Merickel]

I should note that the API I proposed is pretty similar to the current API we already use in webob.cookies.CookieProfile if you wanted to see some prior art there. There is a SignedCookieProfile subclass which does signing, and all the settings are defined once and then the profile is re-used across requests.

[Mike Orr]

On Mon, Dec 10, 2018 at 12:56 PM Michael Merickel <mmer...@gmail.com> wrote:
>
> On Mon, Dec 10, 2018 at 12:21 PM Bert JW Regeer <xist...@0x58.com> wrote:
>>
>> Pyramid also by default supports all of the "secure" parts of the cookie. There are no extra flags that can't already be set using Pyramid.
>>
>> Using the Secure package for cookies is unnecessary.
>
>
> I imagine the benefit is less for Pyramid's builtin sessions and auth tokens but for other arbitrary cookies a user may set where right now you must remember/pass in all the options to `response.set_cookie`. If I were doing this myself I'd probably use `config.set_response_factory` to define a custom response subclass that contains some form of `response.set_secure_cookie(key, value, **kwargs)` that had signing built into it, or even just define some more purpose-built functions for the different types of cookies I want to set. Fortunately most of my apps don't set cookies other than auth/session so I don't really care. :-)

Ah yes, for the cookies I found the 'secure' and 'httponly' settings
in 'pyramid_redis_sessions' and used those. For the other headers I
made a NewResponse event listener and set them there.