-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Insert Content Security Policy Headers #24
Comments
Hi @rpattcorner . When you deploy the stack you can pass in the HTTP headers as a stack parameter. Among the HTTP headers are the CSP headers, that you can alter (or remove). If you've already deployed the stack, you can redeploy it while specifying a new version for the HTTP headers parameter, the redeploy will then work as an update for your stack. E.g. if you wanna just remove the CSP header for now:
Let me know if that helps. More docs would be great, I agree with you totally! Is it something maybe you wanna help out with, as you are going through "taking the deployed solution to the next step" now? |
Many thanks! Somehow the fact that the CSP was being injected from a visible parm escaped me, and removing the header and updating CFN does indeed remove the failure. Of course now we need to learn enough about CSP to deploy the correct headers rather than none at all, which is just how things go! I notice that the update took a very long time (probably a combination of the CFront deploying to all regions and edge invalidation) and, more to interest, when the stack finally showed UPDATE_COMPLETE a number of individual events continue to show as as UPDATE_IN_PROGRESS, for example (HttpHeadersHandlerCodeUpdate, CheckAuthHandlerCodeUpdate) etc. as well as the event on the stack as a whole (CloudFrontDistribution). That's probably a CFN issue, but thought I'd call it out. You're quite right, I should add to the documentation. At this stage all I have useful to say is how to deploy your own app 'on top of' the full deploy, but even that is probably worth putting in the README, along with your advice on removing CSP headers. Ideally other useful doc might include:
I'd like to see the project become a piece of boilerplate for folks who just want to put some decent authentication in front of a SPA - and see it is close. I've tried a number of other published approaches, which all have not worked, probably because of bitrot. Again, thanks! |
Sounds good. Let's keep this issue open until you've finished your setup, and ran into all the hurdles on your way. Then we can discuss what to add to the docs. |
OK ... I have an update on the README that documents the CSP mod which is trivial, but I can send a PR for just that bit any time if you want. Next comes doc on trying to deploy on an existing bucket. Then ... maybe someday ... manual work we've carried out creating a Cognito Identity Pool so our app can access an AWS Role. I have the manual steps, but the new serverless build framework is new to me, so may take some time. I'm getting doubts about Cognito based on this post but for now it's what we're using ... because you did and your app provides so much value! FUD is ubiquitous but it sounds like the writer had a fair number of concrete instances. |
Sure send me that PR on the CSP mod doc please. The smaller the PR's the better. Regarding deploying to an existing bucket: that's also something I want to make possible in the deployment itself (#20 ) On Cognito: yes it has rough edges - but if you know what you're doing (/have good examples to follow) then you should be good. |
Some progress on controlling the s3 bucket based on the The essence of the question I'm seeing is:
From what I can see the What I'm specifically seeing is:
My goal is to produce a version of The problem seems to be this:
It looks like that kind of code modification is present in the full up template, but that it requires a custom cloudformation resource to alter the HttpHeaders lambda's configuration.txt. Is this correct? If so, do you have any suggestions on how to enhance the So, doing this:
yields this deploy fail:
In the full up template the Handler's CodeUri points to src/..., which makes sense as you're building in SAM. Do you suppose there is a way in the I was stuck awhile because modifying configuration.json had no effect on the deployed app, until I discovered that you have to refresh the trigger, which is nearly invisible in the GUI. But doing so unblocks the desired CSS, so the question comes down to an economical way to enable the |
@ottokruse OK, been quite some time since I've looked at nested stacks and custom resources and much has changed. I think I understand the pattern shown in the main template, where a custom resource hits a special lambda that modifies others of the lambdas based on params, which is what I want. But I'm missing a detail that will probably be obvious. I'm wanting (per above) to modify the HttpHandler for a custom configuration for CSP, but within my own stack that consumes the app. So, I see the app exports the CodeUpdateHandler as well as the HttpHeadersHandler, and I want to do something like this:
Which I'd hoped would use the ServiceToken addtress to invoke the CodeUpdateHandler lambda, telling it to update the HttpHeadersHandler. But there's some kind of permissions problem. Which you'd think would not be an issue since I'm asking the import of the app to update itself. I get the access denied exception below (account number redacted). Can you see where I've gone wrong?
|
Awesome. About the HTTP headers, can you not do it like this?:
If you go the custom resource route (which I hope you do not have to) you need to give the Lambda handler of your custom resource permission to read and update the Lambda you want it to update. Did you do that? |
Ah, so close and yet so far. Never occurred to me to pass the HttpHeaders directly to the app. That seems to be accepted by CFN. So we get a full CFN run, and inspection shows that the HttpHeaders lambda has the correct configuration.json. Yet on run I see:
Which is like nothing I ever saw, and incredibly vague. Any hints? If I have to go back to the (clumsier) custom resource and adjust permissions, it sounds like you're saying I need to give the
|
The 503 looks like this item on the LambdaEdgePr-UserPoolDomainHandler. Never been a problem before. If you've seen it, let me know!
all I can find in the (cfn) doc is this:
|
Sorry mate you run into every corner case possible it seems. Is it an option for you to start development in a brand new stack? I think the errors you get now might be caused by having deployed the same stack several times, using different versions. We should really get the "simple" option working for you, to inject the HTTP headers as app params. That should work - and if it does not, that is a bug we should fix. |
Yes, this is challenging. Help is welcome. I am deploying in a new stack each time ... not solid on stack updates so I've been avoiding them. A new deploy seems to still bring the 503, so no idea how to proceed. The interactions between the CloudFront and Cognito have always been solid until this last injection of a parameter into the the application. Can't imagine what's changing. Probably near the end of your day, but thoughts welcome |
Can you paste your CFN template here? Then I can reproduce |
May or may not be relevant ... I see in logs:
Doublechecking my headers param to be sure I'm not screwing up the JSON |
Yeah, that's it. Many thanks for the direction ... the problem was indeed a bad default in the json parameter that HttpHeaders silently applies to the request to checkAuth, messing it up mightily. Hopefully that will get us doing, and get the team a nice new PR with documentation. The |
OK, PR's in. Thanks for the help! |
Thanks for your help! Closing this one as we have merged #55 |
We're working our way thru adapting this promising approach to securing an Angular JS app. In replacing the sample REACT application we are finding our CSS blocked, and it looks as if it's a problem with content security policy headers. There's good information in adding headers here, but because of the complexity of the authentication solution it's not clear where in the chain of requests and responses to add code to create the headers.
Do you have a suggestion or recommendation?
And a request ... it would be great to have a little documentation on discussion on taking the deployed solution to the next step and using it for an actual app, including issues like this.
Thanks for a promising (if complex) solution!
The text was updated successfully, but these errors were encountered: