Closed jordangov closed 6 years ago
I added "X-Frame-Options=DENY" to all the cloudfront distributions. I don't think I can do anything for the raw s3 access, but in the end I'm not too worried about this :-/
I created an invalidation on cloudfront, but I'm still not seeing this header on the live site.
Apparently, the setting I changed sends info to the origin not from the origin :-P
There isn't an easy way to do this for static S3 sites apparently, we'd need to add lambda as a passthrough. I don't think it's worth it
With no data collection, I'm inclined to agree. That said, if we add the project entry form, we may need to do this. I don't think we can ignore it then, soooo...?
Whatever hosts the project entry form would be dynamic, and could do this individually. That said, the project entry form might not need iframe prevention. I mean, google forms can be embedded right?
Can you run this following command grep -ri "X-Frame-Options" /var/www
where /var/www is folder where your website code reside. If it responds yes it is set, if not you should fix.
Hi @BalajiJBcs! We’re using static hosting vis AWS (S3 + CloudFront) right now, which doesn’t seem to allow a way to set the header at all, unless we also add Lambda functions into the mix
@arichiv ok I got it. Ok for this kind of static site why not you use CSP as a security measure to prevent clickjacking, It can be implemented in the header like this
<meta http-equiv="Content-Security-Policy" content="frame-ancestors 'self'">
Hope this solves the issue.
I didn’t know about that tag, thanks!
Bug / Vulnerability
This was reported through the DoD VDP. Basically someone could load our site in an iFrame and then inject JS into it.
Page(s) Affected
https://code.mil/
One mitigation would be to add the
X-Frame-Options
header toDENY
(See the Code.mil channel in Slack if you want to see the original report)