The base-uri policy is missing at Seckit. Considering the module is exclusively security related, the missing base-uri could be understood as a bug because an attacker could potentially insert a tag, which would prepend an untrusted external domain to all script relative paths.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Securi...
If someone is missing that base-uri policy, I explained at https://www.drupal.org/project/seckit/issues/3052779#comment-13376415 the code to append extra policies to the ones generated by Seckit meanwhile a more flexible version of Seckit appears.
| Comment | File | Size | Author |
|---|---|---|---|
| #37 | 3098417-37.patch | 11.46 KB | leo liao |
| #35 | 3098417-base-uri_policy__missing-35.patch | 11.48 KB | the_g_bomb |
| #27 | 3098417-26.patch | 10.92 KB | pere orga |
| #10 | seckit-7.x-1.x-base-uri-3098417-10.patch | 9.64 KB | jweowu |
| #7 | 3098417.patch | 3.57 KB | pere orga |
Issue fork seckit-3098417
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
cubeinspire commentedComment #3
cubeinspire commentedComment #4
cubeinspire commentedComment #7
pere orgaAttaching patch https://git.drupalcode.org/project/seckit/-/merge_requests/5.diff for easing composer workflows.
Sorry for the noise, I'm sure there must be a better way to get versioned changes from Bitbucket merge requests.
Also, updating issue status and version.
Comment #8
jweowu commentedComment #9
jweowu commentedI'm not sure about Bitbucket (d.o. merge requests are using Gitlab, AFAIK), but I think https://github.com/cweagans/composer-patches/pull/388 is the most recent work on allowing merge request patches to not be a security risk.
See also https://github.com/cweagans/composer-patches/issues/347
In the meantime, traditional patch uploads are still the way to go.
Comment #10
jweowu commented7.x-1.x patch for the testbot.
Comment #11
pere orgaThanks @jweowu! I meant GitLab, indeed.
Patch in #7 works and looks good to me.
Comment #12
jweowu commentedYou can't RTBC your own patch :)
Comment #13
pere orga(as a matter of clarification, I take no credit of patch #7)
Comment #14
jweowu commentedWhoops, I see now. Back to RTBC for #6 / #7.
Comment #15
jweowu commentedIn fact this is Needs Work -- I kicked off a test earlier against 2.x, and I see that it failed.
Comment #16
jweowu commentedYou could refer to #10 (which is for 7.x-1.x) regarding how you might be able to update the existing tests (I'm not sure offhand how similar the the D8+ tests are, though).
Comment #17
pere orgaTrying to fix tests.
Comment #19
pere orgaTrying again
Comment #20
jweowu commentedHuh. That's a bug, isn't it? Or bad test data, at any rate.
AFAIK any 'self' value includes the single quotes, so in code that will be:
"'self'"rather than'self'Perhaps a fix for this should be rolled separately.
Comment #21
pere orgaI'm not sure if it's a bug to be honest, but it's confusing for sure :)
Any
base-uriis being outputted with single quotes, and I think that's fine.However, this is not consistent with
default-src. In the tests, "self" without quotes is being printed, and I'm not sure if that's valid in CSP. But that's unrelated to this patch.Comment #22
jweowu commentedYes, the error is with the default-src code, so I think we're copying a mistake in the patch here.
I suspect there are other lines like that in the existing tests, so it would be good to patch that first.
(But regardless, let's use the correct
"'self'"in the code for base-url.)Comment #23
jweowu commentedAh, no, this is wrong:
You can't single-quote that value. It's a source list, so there may be multiple values, and any quoting needs to be explicit in the individual elements of that list.
https://w3c.github.io/webappsec-csp/#source-lists
Comment #24
pere orgainterdiff.txt is against #7.
Comment #25
pere orgaMissed one.
Comment #27
pere orgaFixing form field description.
Comment #28
pere orgaUnrelated, but as said, we probably want a follow-up issue for the wrong
default-srctest data.Also, I think its current field description is not correct:
> Specify security policy for all types of content, which are not specified further (frame-ancestors excepted). Default is 'self'.
In this module configuration, the default value is empty. If it's not set or empty, this directive is omitted and will not be sent to the browser, and then the browser will not enforce any default restriction for other directives (that is different to setting it to "'self'"). So 'self' is neither the default configuration in this module, nor the default behaviour in CSP: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Securi...
I would change the
default-srcdescription, removing the last sentence ("Default is 'self'.").Comment #29
rajeshreeputraAdding the related issue for the default-src has wrong description.
Comment #30
kleve commentedPatch 3098417-26.patch is partly rejected in current stable release 2.0.1. Looks like rejected code is in /tests/src/Functional/SecKitTestCaseTest.php
Do we have a working patch for 2.0.1?
Rejected code
Comment #34
the_g_bomb commented2.x branch in the fork isn't up to date, I think, so am uploading an updated patch instead.
Comment #35
the_g_bomb commentedFound a typo and updated to include changes to the JS that Adds/removes attributes.
Comment #36
alina.basarabeanu commentedThe patch from #35 is working on Drupal 10.2.2 and Seckit 2.0.1.
Comment #37
leo liao commentedFor 2.0.3
Comment #38
the_g_bomb commentedThanks @leo-liao,
New patch applies cleanly to 2.x
Comment #40
the_g_bomb commentedI was going to add the patch to an MR, but I discovered a failing test and a Syntax error, which are now fixed.
A bit new code, this should probably be reviewed again.