search

devpunks / snuggsi

snuggsi ツ - Easy Custom Elements in ~1kB
https://snuggsi.com
MIT License
398 stars 17 forks source link

Content security policy #160

Open snuggs opened 6 years ago

snuggs commented 6 years ago

Content Security Policy (MDN)

Middleware used for CSP (Content Security Policy).

Proposals

Specificaions

Services

Links

snuggs commented 6 years ago

@brandondees what did i clobber? didn't force push anything. But can't see what you wrote.

capture d ecran 2018-01-19 a 10 34 26

brandondees commented 6 years ago

it was just an approval. when the code changes, the review becomes obsolete

snuggs commented 6 years ago

capture d ecran 2018-01-21 a 04 22 43

@tmornini @aspleenic perfect example of a conditional expression vs a conditional statement (if).

TL;DR Statements & Expressions both need a predicate. But only one is used (primarily) to return something. And the other is used (primarily) for side effects.

Statements don't return values. Big epiphany for me recently was if statements aren't (or don't have to be) used for control flow at all. Merely used for side effects. (Unless you're programming in Ruby. But even Matz says that's a leaky abstraction). The "control flow" is a bi-product of an if statement. A side effect of THE side effect if you will.

"Hello World" if true # Leaky abstraction. Works in Ruby. Not natural to majority of other languages.

One thing that stands out is the previous statement cannot be composed. Expressions are composable (as in this example within our content negotiation middleware.) I learned this in scheme/LISP programming where I had an "A-ha" moment where even the "if statements" were merely functions themselves. Yes they controlled flow. And yes they (not often) performed side effects (anti-pattern). But were "expressions" because they must return something or purity goes out the window re: flow in functional programming.

#F Sharp / Haskell sheds more clarity and has great examples of the difference and why imperative if statements and loops should be avoided from a functional perspective. However a rubyist would consider everything above asinine because of that one glorious/dreadful bug/feature of an if statement returning a value. Ruby has lots of these bugs/features that we love to hate to love.

To be clear expressions and statements both control flow at the end of the day. I think we all agree on this. All the other stuff is what's debatable. ;-). I can say this though...IF statements are a cesspool for bugs. Another thing I think we all can agree on. ...And the debate goes on (great song by the way)

Feel free to chime in. Shared experience is always enlightening since control-flow effects every programmer ever. Cheers!

/cc @brandondees @btakita @kurtcagle @janz93 @mrbernnz @halorium @johnrlive

image

snuggs commented 6 years ago

@brandondees P.S. WIP is off. As soon as we figure out what to do with ?report we can merge. We can also do the reporting in a later PR. As that may need some insight on how/where the report should go. These are auto-magically POSTed from web browser to endpoint. How that endpoint logs I feel should be left open with a sane default. Currently we are just logging to https://report-uri.com.

Full test coverage ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

We still have work to do after this PR. By default we set everything to 'none'. Perhaps self is a better baseline. However, I prefer everything off in regards to security by default.

See the following images of with report and without report respectively. Notice the without disables EVERYTHING! (Excellent...I think...).

Actually amazing when you have a test suite. Truth be told this was the very first time I opened the browser since starting working on the feature a few days ago. Exactly what we would expect to happen. Tests don't lie unless you tell them to!

capture d ecran 2018-01-21 a 05 02 50 capture d ecran 2018-01-21 a 05 03 04

tmornini commented 6 years ago

Perhaps self is a better baseline. However, I prefer everything off in regards to security by default.

While I generally agree with your statement, I don’t believe it makes any sense to default to off if that means an entity is not allowed to access itself — which I believe is what that means.

snuggs commented 6 years ago

@brandondees @tmornini hmmmm in retrospect you bring up great points. Given some time to rethink what do you feel is the immediate feature to test. We have the (passing) tests that are spec approved. But TOO restrictive. Can't even get the server to show anything locally as is locked down like a fort. Looks like "ON" is/was working lol. At first thought some config file for "settings" but assumed we are smarter than that. @brandondees Define "Batteries included?" for CSP (to the best of your recolleciton). What do we NOT want to think about?

TL;DR; https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Also the de-facto is helmet. However it feels more like the devise of CSP. I'd rather take the meat and throw away the bones. Can always grow into it if we need that much dependency. https://github.com/helmetjs/helmet

As @brandondees would say "Those 'None's ain't gonna un-none themselves" lol.

The patterns i'm picking up on can be solved with a hash map in less than a handful of LOC if we #CATAT (Call A Thing A Thing) However, that's merely an implementation detail. WHAT are the defaults and WHERE do they "go" (pun intended @tmornini)

capture d ecran 2018-06-15 a 23 06 11

capture d ecran 2018-06-15 a 21 09 35

snuggs commented 6 years ago

@brandondees @tmornini policy.json ? Would live quite nicely next to policy.test and policy.es

For a ruby port that would be policy.yml and policy.rb. Funny enough all those files can live harmoniously juxtaposed to one another although different implementations. #ThatsWhatFriendsAndFileNamesAreFor #CATAT

Lastly @brandondees you have that fetish for security....this is your year! Merry Christmas 🎅 Should be ready by then lol. https://github.com/w3c/webappsec#web-application-security-working-group

brandondees commented 6 years ago

as for what's "batteries included" for csp, I am not expert enough to really have a definitive answer to that. rails 5.2 added default CSP headers which might be a good place to look for some "sensible defaults" cues to follow.

As a security wonk, I'd like to say lock it all down by default and require intentional whitelisting, but reality is that may be raising the friction level too high and would lead to folks disabling it altogether instead of making thoughtful and appropriate choices. It should probably let folks do the most basic low-risk things they expect out of the box (careful what you assume is low-risk on the web though), but provide some safety railing to keep folks out of the canyon.

brandondees commented 6 years ago

Happy to talk about the specific options individually if you want @snuggs

snuggs commented 6 years ago

@brandondees pretty good article about CSP and Rails. /cc @janz93 https://bauland42.com/ruby-on-rails-content-security-policy-csp/

snuggs commented 6 years ago

@brandondees @tmornini yup gonna blow the dust off this one and merge this in ASAP!

SUICIDE not having CSP in 2019.

https://medium.com/intrinsic/compromised-npm-package-event-stream-d47d08605502

https://github.com/dominictarr/event-stream/issues/116#issuecomment-441759047

capture d ecran 2018-11-28 a 11 21 30