TRANSFORMEZ VOTRE NAVIGATEUR EN PIÈGE À PIRATE AVEC LES EN-TÊTES DE SÉCURITÉ HTTP. @righettod righettod.eu https://github.com/righettod/voxxeddays-lux-2022 #voxxed_lu
one for Safari, are supported by the current version (May 2022) of modern browser including Chrome based ones, Firefox and Safari. - Elements presented are independent of the technologies used on the server side. - All tests and demonstrations were performed using Chrome (latest release in May 2022) because it seems to be the most popular browser even in enterprise environments (Chrome/Edge are often used in companies and Edge is chrome based like Opera): 2 https://gs.statcounter.com/browser-market-share
It’s preventing an attacker, or make it significantly harder for him/her, when possible using HTTP headers to: - Leverage an asset of the application outside the official application domain. - Access to an information transmitted by the browser during the usage of the application. - Access to an information stored by the browser once the usage of the application is finished. - Exfiltrate from the browser an information to a controlled domain. - Infiltrate content from a controlled domain. 3
is just a bug in an application having consequences from a security perspective. What is the exploitation of a vulnerability? It’s the operation of leveraging the bug to get the application act in an unintended way either to do something or to get something from it (information). What is a vulnerability on client side? It’s a bug in the front end (often called client-side) allowing an attacker, to instruct the front-end to perform an action (display something, send HTTP request, modify the DOM and so on). 4
such vulnerability type? Nowadays… 5 Modern applications provide rich frontend mainly based on JavaScript, in which, interesting data is stored in browser’s managed storage. Such attacks extend their perimeter outside the boundaries of the application by targeting the browser. Built-in protections in server-side technologies framework tend to be heterogenous and complete. However, it is not always the same for frontend frameworks.
vulnerability? We can fix it… 6 Option 1: Definitively (vulnerability disappear) Option 2: Temporary (we made it not|hardly exploitable) Option 1 is the recommended one but it’s not always possible…
HTTP security headers, they can allow us to “buy this time” by making the vulnerability (not|hardly) exploitable… Require to analyze and understand it to identify which modification must be performed. Require to modify a feature avoiding any regression or new functional bug (side effect). Need time but sometimes we do not have this time immediately! Behind the scene of fixing a vulnerability…
So, how to obtain a summary of available/supported HTTP security headers? 10 http://www.picturequotes.com/who-are-you-gonna-call-ghostbusters-quote-346897 No, not him !
It’s the goal of the OWASP Secure Headers Project to centralize, gather and continuously search such information to always provide the most accurate information… 11 https://owasp.org/www-project-secure-headers/
Our company website is exposed on the not secure HTTP port 80 on righettod.eu and www.righettod.eu - Our application is exposed on secure HTTP port 443 on myapp.righettod.eu - Both ports are open on web server to our application, so it accepts not secure HTTP calls too Challenge: - How do we ensure that a secure channel is always used to access to our application to prevent an attacker to intercept and see the data exchanged? 12
security header buddy is “Strict-Transport-Security”: - Indicate to the browser to always use a secure channel (HTTPS) to access to the domain on which it was delivered. - Once seen a first time (except if the preload option is used), the browser will remember it (until cache is cleared or max-age expires). It will update the protocol to HTTPS before sending any HTTP call even if the user (or script) use HTTP:// protocol explicitly. Format (parameters in square brackets are optional): Strict-Transport-Security: max-age=(time in seconds to apply the instruction) ; [includeSubDomains] ; [preload] Example: Strict-Transport-Security: max-age=31536000 ; includeSubDomains 13 https://owasp.org/www-project-secure-headers/#http-strict-transport-security
I already visited the site righettod.eu. [1] Now, if the URL http://righettod.eu is typed in the address bar… [2] The browser converts my call to https://righettod.eu prior making any network connection… [3] So, no network call to port 80 is made. 0
site) loads resources (scripts, styles, images) from our domain to mimic our user interface: Challenge: - How do we prevent any site outside our domain / sub domain to load our resources? 4/4 - FOCUS ON SOME CASES: RESTRICT REMOTE LOADING 15
site) loads resources (scripts, styles, images) from our domain to mimic our user interface: Challenge: - How do we prevent any site outside our domain / sub domain to load our resources? 4/4 - FOCUS ON SOME CASES: RESTRICT REMOTE LOADING 16
site) loads resources (scripts, styles, images) from our domain to mimic our user interface: Challenge: - How do we prevent any site outside our domain / sub domain to load our resources? 4/4 - FOCUS ON SOME CASES: RESTRICT REMOTE LOADING 17
site) loads resources (scripts, styles, images) from our domain to mimic our user interface: Challenge: - How do we prevent any site outside our domain / sub domain to load our resources? 4/4 - FOCUS ON SOME CASES: RESTRICT REMOTE LOADING 18
response security header buddy is “Cross-Origin-Resource-Policy” (also called CORP): - Allow defining a policy that let web sites and applications opt-in to protection against certain requests from other origins (such as those issued with elements like script and img tags) Format: Cross-Origin-Resource-Policy: policy Example: Cross-Origin-Resource-Policy: same-origin 19 https://owasp.org/www-project-secure-headers/#cross-origin-resource-policy Policy value Description same-origin Only requests from the same Origin (i.e. scheme + host + port) can read the resource. same-site Only requests from the same Site can read the resource. cross-origin Requests from any Origin (both same-site and cross-site) can read the resource.
20 As the CORP header specifies that, [1] only the same origin can access to this resource (image here), then [2] the browser rejects the access to the image. No CORP header specified, so, the browser allow the access to the image. righettod.local → Phishing site righettod.herokuapp.com → Victim site
We log out a user from an application: Challenge: - How do we ensure that, once the logout is performed, we let the browser without any residual content (that can be access token/secrets) in storage, cookie or cache to prevent any local malicious program to access to this content? 21
security header buddy is “Clear-Site-Data”: - Allow defining which data must be removed for the domain issuing the header. Format: Clear-Site-Data: “data type to remove” Example: Cross-Origin-Resource-Policy: "cache", "cookies", "storage" 22 https://owasp.org/www-project-secure-headers/#clear-site-data Data type value (can be combined) Description cache Indicates that the server wishes to remove locally cached data for the origin of the response URL. cookies Indicates that the server wishes to remove all cookies for the origin of the response URL. storage Indicates that the server wishes to remove all DOM storage (local + session) for the origin of the response URL. Not supported by Safari
- We have a vulnerability allowing an attacker to [1] inject arbitrary JavaScript code and [2] execute it in the browsing context of the targeted user. - It is a Cross-site Scripting (or XSS) category of vulnerability. - We cannot currently modify the app code base and/or redeploy the application for business not negociable reason. Challenge: - How do we ensure that this vulnerability cannot be exploited (or with high difficulty) by an attacker? 25
- We have a vulnerability allowing an attacker to [1] inject arbitrary JavaScript code and [2] execute it in the browsing context of the targeted user. - It is a Cross-site Scripting (or XSS) category of vulnerability. - We cannot currently modify the app code base and/or redeploy the application for business not negociable reason. Challenge: - How do we ensure that this vulnerability cannot be exploited (or with high difficulty) by an attacker? 26
- We have a vulnerability allowing an attacker to [1] inject arbitrary JavaScript code and [2] execute it in the browsing context of the targeted user. - It is a Cross-site Scripting (or XSS) category of vulnerability. - We cannot currently modify the app code base and/or redeploy the application for business not negociable reason. Challenge: - How do we ensure that this vulnerability cannot be exploited (or with high difficulty) by an attacker? 27
response security header buddy is “Content-Security-Policy” (also called CSP): - Allow defining a policy instructing the bowser how it must handle the resources (script, style, image, plugin, framing, network connection and so on) returned in the HTTP response body. - Very powerful (and complex by the way) by proposing a large panel of directives to fine tune the browser behavior. Format: Content-Security-Policy: directive instruction for the current directive ; (N times if needed) 28 https://owasp.org/www-project-secure-headers/#content-security-policy - https://content-security-policy.com/
29 Combination of directives defining a policy What is instruct? default-src 'self'; script-src ‘self’ ‘https://cdn.google.com' Resources can only be loaded from the current domain and script can be loaded from itself as well as specified Google CDN. default-src 'self'; font-src 'self' https://fonts.google.com; frame- ancestors 'self'; sandbox ; Resources can only be loaded from the current domain. Fonts can also be loaded using HTTPS from fonts.google.com. Site can only be framed by itself. All frame/iframe will run in sandboxed mode. https://owasp.org/www-project-secure-headers/#content-security-policy - https://content-security-policy.com/
PRESENTATION TITLE 31 However, our CSP policy did not prevent the attacker to perform action inside the app on behalf of the user: We did not block the updated attack
So, we try the following updated CSP policy: default-src 'self'; script-src 'self' We successfully blocked the updated attack ☺ No call to addUser.php was performed.
of built-in protections that we can leverage. B. HTTP security headers are not a “silver bullet” to make an application any attack proof BUT they significantly help reducing the exploitability of a client-side vulnerability. C. HTTP security headers can help us to “buy time” when facing a client-side vulnerability in a context in which app code base cannot be updated during a timeframe. Other HTTP security headers can be added, look at the OWASP Secure Headers Project to get insights about them. Comment, feedback, suggestion as well as pull requests are warmly welcome.
righettod
iwatatomoya
tomoki10
manfredsteyer
makihiro
orgachem
ivargrimstad
xuwei_k
taiyow
fabpot
yoshifumi_ishikura
yjszk
n3xem
ufuk
holman
garrettdimon
sergeychernyshev
lynnandtonic
scottboms
lauravandoore
destraynor
addyosmani
trallard
![4/4 - FOCUS ON SOME CASES: ENFORCE HTTPS 14 [0]](https://files.speakerdeck.com/presentations/f2e623e5572f4000bef9390739f45133/slide_13.jpg){kind=link}
