protecting web app users in today’s hostile environment
TRANSCRIPT
Say I operate website www.verysecurebank.comand I have made sure it doesn’t have any vulnerability (I am kidding, but lets assume)
Does that make it safe for my customers to use it?
Browser Network Internet Infra Web Server/App
Web App Access Echo System
CDN
CA
Under user’s control Under app owner’s controlHostile
Images for various sources from the internet
• What if environment between the browser and webapp gets compromised?
– Network, wifi hotspots
– CDN
– Trusted CA
– …
What if my customer is using my site from public wifi hotspot?
A bad guy may have compromised the networkto perform MITM.
I use strong SSL security for https://www.verysecurebank.com to avoid MITM.
My users can still frequently shoot themselves in foot by…
The request goes to
http://www.mysecurebank.com (plain text)
and is wide open for MITM
HTTP Strict Transport Security: HSTS
HTTP response header:Strict-Transport-Security: max-age=31536000
Tells browsers to use only https for the future requests to the domain (no more http requests, no more MITM).
Strict certificate checks without user override
Domains can be preloaded in browsers– To eliminate Trust On First Use (TOFU)
HSTS Prevents
Unintentional access to website over HTTP
Hijacking of HTTP links unintentionally remaining on HTTPS website.
MITM attack redirect using invalid certificates
HSTS: Caution
User is still vulnerable to MITM on the first contact
HSTS setting is at domain level and can be extended to all the subdomains as well (using includeSubDomains).
Using ‘includeSubDomains’ on mydomain.com ? Beware
– It turns HSTS ON for *.mydomain.com e.g. images.mydomain.com, js. mydomain.com which is good (provided the subdomains are running HTTPS with valid cert).
– But also turns it ON for intranet.mydomain.com. Are you sure ‘intranet.mydomain.com’ is running HTTPS with a valid cert?
HSTS preloading is hard to undo, be sure before submitting your domain for preloading.
I am using CDN for fast loading of sub resource javascript, css on my site.e.g. page source for https://www.verysecurebank.com
<HTML>
…
<SCRIPT SRC="https://veryfastcdn.com/jquery.js"></SCRIPT>
…
</HTML>
My web server is secure but what if the CDNgets compromised?
Sub Resource Integrity (SRI)
<script src="https://veryfastcdn.com/jquery.js"
integrity="sha384-
R4/ztc4ZlRqWjqIuvf6RX5yb/v90qNGx6fS48N0tRxiGkqveZETq72KgDVJCp2TC"
crossorigin="anonymous"></script>
Load JS, CSS from CDN but ask browser to check it’s integrity using pre computed hash.
Currently only supported for scripts and CSS
SRI: Caution
Better suited for static resources, frequently changing ones would be problematic
Updating content of SRI protected resource needs planning1. First change webpage to add HASH for the new version of the
resource, along with the old one (multiple hashes are supported).
2. Then update the resource on CDN to new version
3. After new resources propagates to all CDNs, the old hash can be removed from the webpage
MITM and CDN are taken care of
but what if a trusted CA gets compromised?
Hackers can now create valid looking fraudulent cert for my website.
HTTP Public Key Pinning (HPKP)
Public-Key-Pins:
pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=";
pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=";
max-age=5184000; includeSubDomains; report-
uri=https://www.example.net/hpkp-report
Uses HTTP header to tell the browser to ‘pin’ a domain to certain public key.
Pins can also be preloaded in browsers
HPKP: Caution
It is complicated, procced with extreme caution– Used mainly for extreme high security websites– If you need it, start with ‘Public-Key-Pins-Report-Only’ followed by ‘Public-Key-Pins’ with
short ‘max-age’ and increase it incrementally– Carefully decide which keys to pin
HPKP suicide: If you loose control of your pined keys.
Cert renewal/rotation needs to be managed correctly using a backup pin.
HSTS validation is bypassed for user installed root CA- To support corporate proxies, AVs, Fiddler- Risky: Superfish/Lenovo, eDellRoot/Dell
Read: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead
I want to embed 3rd party components on my website like CDN, google analytics, ads, social media widgets.
How can I do it securely?
CSP
Allows whitelist controlled external resources on your page:
– Tell the browser to load resources to load on the page only from the trusted sources. Scripts, images, media, styles, frames, fonts, plugins etc.
– Provides protection against attacker injecting harmful resources, script on the page.
CSP: Caution
• Excessively tight CSP could break websites functionality. E.g. Security zealous engineer might add ‘Content-Security-Policy: default-src'self';’. It might work well in dev environment but in production 3rd
party analytics, ads, social media widgets would be broken.
• CSP is complex, needs correct configuration to get desired protection.
• Read: CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content
Security Policy
(https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.
pdf)
Few more protection mechanisms
X-XSS-Protection Force XSS protection (useful if XSS protection was disabled by the user)
X-Frame-Options Dis-allow framing at a page level and avoid click jacking.
CORS Allow controlled cross domain access to partner websites
General precautions• Check browser support
– All browsers may not support all the security mechanisms fully.
– Pay special attention to mobile browsers
• Weigh-in security vs availability
– Most of the new mechanisms are complex
– HPKP/CSP/HSTS misconfiguration can make your website inaccessible for your customers
– ‘one-size-fits-all’ doesn’t work.
– Central security design is needed, fragmented control would lead to misconfigurations
• Browser bugs
– Advisable to wait till browser implementations mature
• Adhere strictly to the specifications
– Invalid settings means no security. e.g.
• Valid: X-Frame-Options: DENY
• Invalid (with quotes): X-Frame-Options: 'DENY‘
• Test thoroughly to ensure the desired security is achieved and there is no undesired loss of availability