Modern day web applications live and operate in a complex eco-system (Browser, Network/wifi, CDN, Cert Authorities, 3rd party sub resources and more). Securing the web server and web application business logic is not sufficient. The eco-system outside your direct control also contribute to the security risk posed to users of web applications. Security weaknesses and compromised elements in the eco-system would make , otherwise secure, applications risky for the users. We need to think of protecting your users in this un-trusted environment. The presentation describes such risks and options available to deal with them.
NOTE: The same talk was presented in Armsec2016 conference (http://armsec.org/) and in OWASP Pune chapter meetup (29th Sep, 2016)
Protecting Web App users in today’s hostile environment
1. Protecting Web App users in
today’s hostile environment
Ajit Dhumale
OWASP Pune meetup
29th Sep 2016
2. Say I operate website www.verysecurebank.com
and 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?
3. • Almost impossible to say my website is
completely secure
• Even if it is it, it’s not enough
4. 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
5. • What if environment between the browser
and webapp gets compromised?
– Network, wifi hotspots
– CDN
– Trusted CA
– …
6. What if my customer is using my site from public
wifi hotspot?
A bad guy may have compromised the network
to perform MITM.
7. 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
8. 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)
9. HSTS Prevents
Unintentional access to website over HTTP
Hijacking of HTTP links unintentionally remaining on
HTTPS website.
MITM attack redirect using invalid certificates
10. 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.
11. 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 CDN
gets compromised?
12. 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
13. SRI: Caution
Better suited for static resources, frequently changing ones
would be problematic
Updating content of SRI protected resource needs planning
1. 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
14. 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.
15. 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
16. 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
17. I want to embed 3rd party components on my
website like CDN, google analytics, ads, social
media widgets.
How can I do it securely?
18. 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.
19. 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)
20. 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
21. 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
