nlf / blankie Goto Github PK

https://content-security-policy.com/

http://i.imgur.com/jBWEw6A.png

Just to inform you :)

thanks for blankie!

We have registered the plugin following the documentation.
We have our request payload with <script> in it...but blankie is not sanitizing it.
Payload:
fieldName: "<script>alert("hi")</script>"
expected behaviour on sanitization;
fieldName:""
current behaviour:
fieldName: "<script>alert("hi")</script>"

Is this the usual behaviour of blankie or does it sanitize the request payload with inline scripts?
Team, please let me know about the above.

Most CSP libraries, like Helmet for example, set: frame-ancestors 'self'; by default. Can you add that to the default setting for Blankie? And make it clear how to turn that off/change it, if that default isn't desired? I'm using Blankie, with Hapi, and @hapi/scooter if that matters.

I also find it interesting that the default-src tag value is 'none' instead of 'self', which is what I've seen all other default CSP settings to use. Why is 'none' the default-src default for Blankie?

can you please add LICENCE.md file to project

I have an app where I would like to use a nonce for one inline script, but allow inline styles with unsafe-inline. Leaving generateNonces as true for the script usage prevents my ability to allow inline for styles.

For context, this is a universal React app using material-ui, which uses inline styles. The inline script is a simple variable declaration to make the data that was fetched for server rendering available for rehydration on the client. I want to use the nonce for the script since it is safer, but I don't think I can go to that level for the inline styles produced by the react components.

If a nonce was included for the scriptSrc, but not for the styleSrc, I could make this work. I'm also open to other approaches if there is a better option, but this was the best I could figure out from my investigation.

Currently the blankie package puts the generated nonce in request.response.source.context. I'd like to be able to get at this from a non-vision-based context.

It looks to me like an alternate place to put this would be in response.plugins ( https://github.com/hapijs/hapi/blob/master/API.md#response-object ) or perhaps in request.plugins

My suggestion would be for blankie to put the nonce in response.plugins.blankie.nonce.

If you're OK with this, I'll have a PR with this change up for you very quickly.

4.1.1 is now requiring us to explicitly install @hapi/scooter which is a breaking change to anyone depending on ^4.1.0. Is it possible to release this as 5.0.0?

Would love to have exceptions for specific routes, so we can have super locked down security on most pages but slightly relaxed security for pages that absolutely require third-party scripts, etc.

Maybe something like:

{
  // ... all the options
  exceptions: [{
    route: '/somewhere',
    scriptSrc: 'something different from the default scriptSrc'
  }]
}

Upgrading to blankie supporting nonces, since they're emitted by default, this makes unsafe-inline no longer function due to the restrictions on script-src and style-src with nonces present, so upgrading to this version of the module will disable previously working unsafe-inline.

Hi!

Thanks for the great plugin. I've been using blankie/scooter and hapi but for some reason safari never respects what is set.

Safari fails in both hapi 8.x and 9.x.

The error I would see would be something like so:

I was wondering if there is a setting I'm missing?

Hey there,

the latest version of blankie seems to throw on OPTIONS requests:

0|app      | 171016/144200.819, [error] message: Uncaught error: Cannot read property 'nonces' of undefined, stack: TypeError: Uncaught error: Cannot read property 'nonces' of undefined
0|app      |     at internals.directiveNames.forEach (/usr/src/app/node_modules/blankie/lib/index.js:189:50)
0|app      |     at Array.forEach (<anonymous>)
0|app      |     at Object.internals.generatePolicy (/usr/src/app/node_modules/blankie/lib/index.js:169:30)
0|app      |     at internals.addHeaders (/usr/src/app/node_modules/blankie/lib/index.js:278:32)
0|app      |     at each (/usr/src/app/node_modules/hapi/lib/request.js:453:22)
0|app      |     at iterate (/usr/src/app/node_modules/items/lib/index.js:36:13)
0|app      |     at done (/usr/src/app/node_modules/items/lib/index.js:28:25)
0|app      |     at finalize (/usr/src/app/node_modules/hapi/lib/request.js:446:24)
0|app      |     at Function.wrapped [as _next] (/usr/src/app/node_modules/hapi/node_modules/hoek/lib/index.js:875:20)
0|app      |     at Function.internals.continue (/usr/src/app/node_modules/hapi/lib/reply.js:139:10)
0|app      |     at bound (domain.js:303:14)
0|app      |     at Function.runBound [as continue] (domain.js:314:12)
0|app      |     at /usr/src/app/dist/webapp/index.js:129:26
0|app      |     at each (/usr/src/app/node_modules/hapi/lib/request.js:453:22)
0|app      |     at iterate (/usr/src/app/node_modules/items/lib/index.js:36:13)
0|app      |     at Object.exports.serial (/usr/src/app/node_modules/items/lib/index.js:39:9)
0|app      | Debug: internal, implementation, error
0|app      |     TypeError: Uncaught error: Cannot read property 'nonces' of undefined
0|app      |     at internals.directiveNames.forEach (/usr/src/app/node_modules/blankie/lib/index.js:189:50)
0|app      |     at Array.forEach (<anonymous>)
0|app      |     at Object.internals.generatePolicy (/usr/src/app/node_modules/blankie/lib/index.js:169:30)
0|app      |     at internals.addHeaders (/usr/src/app/node_modules/blankie/lib/index.js:278:32)
0|app      |     at each (/usr/src/app/node_modules/hapi/lib/request.js:453:22)
0|app      |     at iterate (/usr/src/app/node_modules/items/lib/index.js:36:13)
0|app      |     at done (/usr/src/app/node_modules/items/lib/index.js:28:25)
0|app      |     at finalize (/usr/src/app/node_modules/hapi/lib/request.js:446:24)
0|app      |     at Function.wrapped [as _next] (/usr/src/app/node_modules/hapi/node_modules/hoek/lib/index.js:875:20)
0|app      |     at Function.internals.continue (/usr/src/app/node_modules/hapi/lib/reply.js:139:10)
0|app      |     at bound (domain.js:303:14)
0|app      |     at Function.runBound [as continue] (domain.js:314:12)
0|app      |     at /usr/src/app/dist/webapp/index.js:129:26
0|app      |     at each (/usr/src/app/node_modules/hapi/lib/request.js:453:22)
0|app      |     at iterate (/usr/src/app/node_modules/items/lib/index.js:36:13)
0|app      |     at Object.exports.serial (/usr/src/app/node_modules/items/lib/index.js:39:9)

"blankie": "3.0.0"
"hapi": "16.6.2"
"scooter": "4.0.0"

Thank you!

Hi there,

I'm trying to load blankie into a project, however I'm getting an issue because Plugin blankie missing dependency scooter.

When I install the dependency scooter it works, however according to the npm scooter itself is deprecated and "This module has moved and is now available at @hapi/scooter".

I went into the blankie/lib/index.js file and changed the dependencies: ['scooter'] in the plugin to be dependencies: ['@hapi/scooter'] and it also successfully loaded.

I am currently using confippet in my project and potentially other packages/configuration that could be interfering with this loading appropriately, however this seems to me like it might be an issue going forward.

It would be nice to have the ability to alter the CSP response at runtime; meaning inside the handler. This use case has a variety of uses, e.g. certain CSP options based upon the auth of the user, etc.

Hi @nlf

This isn't an issue with blankie per-se, more its dependencies but I thought I'd raise it with you and that you'd be interested.

The problem comes from the dependency chain blankie -> @hapi/scooter -> useragent -> semver.

Firstly, the useragent package doesn't look like it is maintained anymore, if fact just a couple of days ago someone began a fork of it.

My problem in using blankie comes from the fact that useragent defines semver as a devDep.
In production, we run npm prune --production. This removes sermver and breaks the application.

There's an open PR for this on the useragent repo from back in 2020.

Anyway, like I say - not an issue with your excellent hapi plugin but a downstream problem but unfortunately means I can't use it.

Best wishes

should also update dependencies, this will also give us the ability to make the error message when 'unsafe-inline' is used with generateNonces a lot more clear

Can Blankie add support for more security headers like Helmet does? https://github.com/helmetjs/helmet

Or, is there a way to use Helmet with the HAPI framework rather than using Blankie, since Helmet seems to have better secure header coverage?

It would be cool if this library includes the license file, but I am not pretty sure if this library/plugin needs the license file.

Linking to lout issue
outmoded/lout#162

There's no support for worker-src CSP directive

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src

Hey there,
I think it would be helpful to be able to set the base-uri. Currently I haven't found a way to do that with blankie. Am I missing something?

As per Google's CSP evaluator:

Missing base-uri allows the injection of base tags. They can be used to set the base URL for all relative (script) URLs to an attacker controlled domain.

Thank you for this plugin!

I think most of the time defaultSrc is set to self. Would it be possible to set its default value as 'self' instead? Thanks!

Content Security Policy seems ideal for browser security to prevent XSS or browser extension manipulation. What are the benefits for a REST API using hapi.js without HTML, CSS, or JS content?

Would be nice to start the discussion around supporting nonce as has been done in other similar projects (https://github.com/twitter/secureheaders)

References

• https://github.com/twitter/secureheaders#csp-level-2-features
• https://w3c.github.io/webappsec/specs/content-security-policy/#script-src-the-nonce-attribute

C:\Users\xmr\Desktop\srihash.org>npm i
npm WARN deprecated @hapi/[email protected]: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).

C:\Users\xmr\Desktop\srihash.org>npm ls @hapi/[email protected]
[email protected] C:\Users\xmr\Desktop\srihash.org
`-- [email protected]
  `-- @hapi/[email protected]

It seems @hapi/hoek is no longer supported and results in an npm warning. Not super important but it'd be nice if deps were updated :)

Overview

If you are not aware yet, Hapi v17 is making the transition from callbacks to async/await, as well as deprecating some other rarely used functionality. This is a breaking change that may make your plugin no longer compatible with the Hapi API.

Changelog

Draft release notes can be found here: hapijs/hapi#3658

Target Release

The target release date for v17 is the beginning of November.

Tasks

• Reply to this to acknowledge that you are actively maintaining this module and are willing to update it
• Update plugin to be fully async/await compatible using the v17 branch from Hapi for testing

  Possible dev flow for updating

  • Clone Hapi
  • npm link within the Hapi repo
  • npm link hapi within your plugin repo
  • Your plugin will now be using v17 of Hapi branch for tests
• Release new major version of your plugin on npm. Please use a major version increment as this will be a breaking change and it would be terrible for it to sneak into current versions of Hapi.

Notes

• Support is being dropped for all versions of Node <8.0.0.
• Hapi v16 will continue to be supported for as long as there exists a Node LTS actively being supported that is not compatible with v17.
• Targeted release date is November 1st, 2017. Please try to have your plugin updated before then.
• This issue is being opened because your plugin is listed on the official hapi website