As HTTP constantly evolves, so do the security concerns around it. I’m compiling a list of resources that I have been using in my study and reiterating some of the key concepts. Forgive the muddle as the organization of this article takes shape.
- Security operates at multiple layers of an app:
– Application code
– Application configuration
– Web Server configuration
– Application Firewall
– Dependent hosts
– Client Side Security Controls ( browser sandboxing? )
– Logging Monitoring Alerting
- Deceptive Defense
2. Client Side Security Control example:
HTTP Response Headers instruct browsers to validate untrusted input, prevent executions and report incidents. Here they are:
– HSTS (RFC 6797) — good reading!!
– Public Key Pinning Extension ( HPKP )
– X-Frame-Options
- X-XSS-Protection
– X-Content-Type-Options
– Content-Security-Policy
– X-Permitted-Cross-Domain-Policies
– Referrer-Policy
– Expect-CT
3. XSS remediation in its entirety is a pipe dream. There are so many JS components that you will be using that can present ways for input to get into the app. This is why CSPs are used.
4. CSPs function is a few ways:
– Only load resources from current origin or domains listed in policy.
– Restrict by protocol, domain and path.
The issue with having a restrictive CSP is that in many cases, your bootstrapped code and javascript libraries are making calls to other sites for their functionality. Setting up a whitelisted CSP can break your site. Are your javascripts loading additional resources? You would need to whitelist them.
Checkout CSPvalidator.org: This is what I pulled back from www.yahoo.com:
content-security-policy: sandbox allow-forms allow-same-origin allow-scripts allow-popups allow-popups-to-escape-sandbox allow-presentation; report-uri https://csp.yahoo.com/beacon/csp?src=frontpage&site=fp®ion=US&lang=en-US&device=desktop&partner=default;
Interesting directives in there: allow-popups-to-esapce-sandbox
I wonder what the ramifications for this could be? Thats an exploration for another day….
5. HSTS: a web security policy mechanism that helps protect websites against protocol downgrade attacks and cookie hijackjing. It automatically turns insecure links into secure ones. If the security of the connection cannot be ensured ( such as the cert is bad ), the connection is terminated. HSTS — jeez.. this could get its own learner section: turns out there is something called a ‘max-age Directive’ which specifies a time limit that the user-agent considers the responding host as a ‘Known HSTS Host’. HSTS has the capacity to fix SSL stripping MITM ( Moxie Marlinspike ).
HSTS headers can be stripped away by an attacker if it is the users first visit to a site. Some browsers have attempted to solve this problem by including a pre-loaded list of HSTS sites but this will not scale to the whole internet. HSTS can also help prevent session hijacking or credential theft by tools such as firesheep.
max-age
includeSubdomains
preload
TOFU problem – trust on first use
https://hstspreload.org/
5. Content Security Policy: A powerful header that aims to prevent XSS and data injection attacks by restricting JS and DOM execution elements. Declared by Content-Security-Policy or Content-Security-Policy-Report-Only .
Requires careful tuning , currently there is v1, v2, and v3.
Directives:
*-src : Define valid source of JS, images, CSS, etc.
nonce-* / sha256- (v3): Only allow is SHA value matches
strict-dynamic: Allow document.createElement(‘script’)
This article will continue to grow in scope and size. Please return on occasion to see how it gets built out.
——————-
——————-
Resources:
1. HTTP RFC: https://www.ietf.org/rfc/rfc2616.txt
2. HTTP Mozilla Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP
3. HTTP Security Talk by Pedram Hayati of Ettlam https://www.youtube.com/watch?v=ZZUvmVkkKu4
4. Web Application Hackers Handbook