HTTP Security Headers Every Java Developer Must Know
52
HTTP Security Headers every Java developer must know Ayoma Wijethunga, WSO2, Platform Security Team.
-
Upload
ayoma-wijethunga -
Category
Technology
-
view
411 -
download
4
Transcript of HTTP Security Headers Every Java Developer Must Know
HTTP Security Headersevery Java developer must know
Ayoma Wijethunga,WSO2, Platform Security Team.
Ayoma Wijethunga
o Software Engineer at WSO2, Platform Security Team.o Get in touch
o Email : [email protected] LinkedIn : https://lk.linkedin.com/in/ayoma o Blog : http://ayomaonline.com o Twitter / Facebook / Github / Hangout : ayomawdb
api android arduino automation building
developing discusses diy electronics
engineering iot jaggery java kali linux
modular osgi prusa reprap security software
ublox web wireshark wso2
“To better defend yourself, think like a hacker”
Contents
o Headerso X-XSS-Protection
o X-Frame-Options
o X-Content-Type-Options
o Content-Security-Policy
o Strict-Transport-Security
o Public-Key-Pins
o Access-Control-Allow-*
o Set-Cookie (security flags)
o Security Threats
o Cross Site Scripting (XSS)
o Clickjacking
o Session Hijacking
o Sensitive Information
Leakage
o Man in the Middle Attacks
o SSL Spoofing
o Future Developments
Storyline
Storyline
AlexResponsible of monitoring and
managing a data center [Operations]
BobBlack hat hacker
Image credit : http://www.kameleon.pics
Storyline - Attack MapAttack 1o Cross Site Scripting (XSS)
o Session Hijacking
o Set-Cookie httpOnly flag
o X-XSS Protection
Attack 4
o Man in the Middle Attacks
o Session Hijacking
o Set-Cookie secure flag
o Strict-Transport-Security
Attack 2o Clickjacking
o X-Frame-OptionsAttack 5
o SSL Spoofing
o Session Hijacking
o Man in the Middle Attacks
o Public-Key-Pins
Attack 3
o Sensitive Information Leakage
o Access-Control-Allow-*
Lab SetupDemonstration
Attack 1 (Demonstration)
Bob get the URL for Alice’s datacenter
monitoring and management control
panel.
http://javacolombo.duckdns.org/server-admin
o Cross Site Scripting (XSS)
o Session Hijacking
o Set-Cookie httpOnly flag
o X-XSS Protection
Attack Demonstration
Session Hijacking
Set-Cookie HttpOnly flag
o Mitigate the risk of client side scripts accessing protected cookies.o Set-Cookie: <name>=<value>[; <Max-Age>=<age>][; expires=<date>] [;
domain=<domain_name>][; path=<some_path>][; secure][; HttpOnly]
o Tomcat 7+ sets HttpOnly flag for session_id by default.
o In Tomcat 6, set useHttpOnly="true" on Context element of context.xml to
enable.
o With Java EE 6+, it is possible to define cookie-config in web.xml<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>
o Cookie cookie = getMyCookie("gxsesmgt"); cookie.setHttpOnly(true);
o More details : https://www.owasp.org/index.php/HttpOnly
Solution Demonstration
Set-Cookie httpOnly flag
Attack Demonstration
Cross Site Scripting (XSS)
X-XSS-Protection
o Request browsers to enable / disable reflected XSS protection
o Chrome / IE8+ - enables XSS protection by default
o Firefox - enables XSS protection on demand
o Available Directives
o0 - Disabled
o1 - Enable and render pages after sanitizing
o1; mode=block - Enable and block pages with XSS
o1; report=http://example.com/report - (chrome / WebKit only)
o Use a Filter and response.addHeader("X-XSS-Protection", "1; mode=block");
o Use Tomcat built in security filter : HttpHeaderSecurityFilterohttps://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#HTTP_Header_Security_Filter
Solution Demonstration
X-XSS Protection
Beyond HTTP Headers
o Use cookies only if there is no other server side option.
o Do not give sensitive names to cookies.
o Do not depend on browser level protection (Filters can be bypassed :
<svg><script>/<1/>alert(document.domain)</script></svg>)
o Validate user input.
o Use proper encoding [ https://github.com/OWASP/owasp-java-encoder ].
o Attention on CSRF protection.
o Renew session ID upon login & logout (session fixation).
Attack 2 (Demonstration)
Alice gets a link from Bob in disguise to
a malicious web application.
o Clickjacking o X-Frame-Options
Attack Demonstration
Clickjacking
X-Frame-Options
o Indicate whether or not a browser should be allowed to render a page in a
<frame> or <iframe>.
o Available Directives
oDENY - prevents any domain from framing the content.
oSAMEORIGIN - only allows the current site to frame the content.
oALLOW-FROM uri - permits the specified 'uri' to frame this page. [this will fail
open if the browser does not support it]
o Use a Filter and response.addHeader("X-Frame-Options", "...");
o Use Tomcat built in security filter : HttpHeaderSecurityFilterohttps://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#HTTP_Header_Security_Filter
o More details : https://www.owasp.org/index.
php/Clickjacking_Defense_Cheat_Sheet
Solution Demonstration
X-Frame-Options
Beyond HTTP Headers
o HTTP GET (incl. links) should only be used for idempotent actions.
o Request secondary user confirmation for critical actions.
o Use frame busting scripts for older browsers.
o Example :
<style>html { display:none }</style><script>
if (self == top) { document.documentElement.style.display = ’block';} else { top.location = self.location;}
</script>o https://www.owasp.
org/images/0/0e/OWASP_AppSec_Research_2010_Busting_Frame_Busti
ng_by_Rydstedt.pdf
Attack 3 (Demonstration)
Alice gets a link from Bob in disguise to
a malicious web application.
o Sensitive Information
Leakage
o Access-Control-Allow-*
Access-Control-Allow-*o Browsers enforce cross domain rules by default (users can loosen security).o Access-Control-Allow-Origin: *
o Allow any external domain to access resource (Never do this in production
unless there is a good reason)
o Access-Control-Allow-Origin: http://example.como Allow only example.com to access resource
o Access-Control-Request-Method: GET, HEAD, POSTo Allow only GET, HEAD and POST requests to access resource
o Access-Control-Request-Headers: X-PINGOTHERo Whitelist headers that browsers are allowed to access
o Access-Control-Max-Age: <delta-seconds>o Number of seconds the preflight request results can be cached
o Access-Control-Allow-Credentials: true | falseo Give permission to include cookies if credentials are enabled in client (Never
set to true in production unless there is a good reason)
o https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Attack & SolutionDemonstration
Sensitive Information Leakage
Attack 4 (Demonstration)
Bob gain access to Alice’s network and
perform a Man in the Middle attack.
o Man in the Middle Attacks
o Session Hijacking
o Set-Cookie secure flag
o Strict-Transport-Security
Man in the Middle Setup
Image credit : https://tails.boum.org/doc/about/warning/index.en.html
o Passive
o Network Hub (L1), Network Taps, Routers with Monitor Port (DD-WRT)
o Active
o DNS Spoofing (spoofing Domain Name to IP mapping)
o ARP Spoofing (spoofing IP to MAC mapping)o Techniques : https://www.blackhat.com/presentations/bh-europe-03/bh-europe-03-valleri.
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443
DNS Spoofing
javacolombo.duckdns.org 192.168.56.1
DNS
javacolombo.duckdns.org 10.10.10.3
Spoofed DNS
ARP Spoofing
javacolombo.duckdns.org 192.168.56.1
54:ee:75:74:85:21DNS ARP
Man in the Middle - VirtualBox Setup
Malicious local DNS entry added to Alice’s PC :o echo 10.10.10.3 javacolombo.duckdns.org | sudo tee -a /etc/hosts
Bob’s iptables rules used to reroute traffic :o iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-
destination 192.168.56.1o iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-
destination 192.168.56.1o iptables -t nat -A POSTROUTING -j MASQUERADE
Attack Demonstration
VirtualBox Man in the Middle Setup
Man in the Middle Attacks
Session Hijacking
Suggest a Solution
Is enabling HTTPS enough?
Attack Demonstrationwith HTTPS enabled.
Man in the Middle Attacks
Session Hijacking
Set-Cookie Secure flag
o Mitigate the risk of sending protected cookies over HTTP.o Set-Cookie: <name>=<value>[; <Max-Age>=<age>][; expires=<date>] [;
domain=<domain_name>][; path=<some_path>][; secure][; HttpOnly]
o Tomcat 6+ sets secure for session_id by default if and only if first request
for session is using https.
o With Java EE 6+, it is possible to define cookie-config in web.xml<session-config>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>
o Cookie cookie = getMyCookie("gxsesmgt"); cookie.setSecure(true);
o More details : https://www.owasp.org/index.php/SecureFlag
Strict-Transport-Security
o Requests supported browsers to communicate with specified
domain only over HTTPS.
o Example : Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
o Use a Filter and response.addHeader("Strict-Transport-Security", "...");
o Use Tomcat built in security filter : HttpHeaderSecurityFilterohttps://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#HTTP_Header_Security_Filter
o HSTS Preload : https://hstspreload.appspot.com
o Browser support : http://caniuse.com/#feat=stricttransportsecurity
o More details : https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
Solution Demonstration
Set-Cookie secure flag
Strict-Transport-Security
Beyond HTTP Headers
o Use HTTPS all the time, if you handle sensitive data.
o Authenticated sessions must use HTTPS to ensure
safety of user session.
o Attention on network, system and physical security.
o Disable HTTP access all together, if that is not required.
Attack 5 (Demonstration)
Bob improves Man in the Middle attack
to bypass HTTPS.
o SSL Spoofing
o Session Hijacking
o Man in the Middle Attacks
o Public-Key-Pins
Attacks on HTTPS
o SSL Strip
o Removes HTTPS protection symbol (lock) in browser.
o SSL Split
o Get Alice to trust a different certificate.
o Compromise Alice’s computer and add a malicious trusted CA.
o Compromise CA.
SSL Attacks
o Start SSLSplit, splitting all HTTP, HTTPS traffic arriving towards 10.10.10.3
and send same towards 192.168.56.1 after logging:
o sslsplit -D -l connections.log -j /tmp/sslsplit/ -S logdir -k evilca.key -c
evilca.crt ssl 10.10.10.3 8444 192.168.56.1 443 tcp 10.10.10.3 8081
192.168.56.1 80
o Flush existing rules and redirect all HTTP and HTTPS traffic to SSLSplit:
o iptables -t nat -F
o iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-
ports 8081
o iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-
ports 8444
Attack Demonstration
SSL Spoofing
Session Hijacking
Man in the Middle Attacks
Public-Key-Pins
o Instructs browser to associate a specific cryptographic public key
with a host.
o Sends sha256 hash of public key in HTTP headers with a expiry.
o Browsers maintain preloaded list of public key pins [https://wiki.mozilla.
org/SecurityEngineering/Public_Key_Pinning]
o Public-Key-Pins:
pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=";
pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=";
max-age=5184000; includeSubdomains;
report-uri="https://www.example.net/hpkp-report"
o Sha256 hashing with key file :
o openssl rsa -in ca.key -outform der -pubout | openssl dgst -sha256 -binary
| openssl enc -base64
Solution Demonstration
Public-Key-Pins
Out of storyline
Content-Security-Policy
o Layer of security that helps to detect and mitigate certain types of attacks, including
Cross-Site Scripting (XSS) and data injection attacks.
o Designed to be fully backward compatible.
o Replace X-XSS-Protection with frame-ancestors directive.
o Content-Security-Policy : frame-ancestors none;
o Replaces X-Frame-Options. with reflected-xss directive.
o Content-Security-Policy : reflected-xss block;
o http://www.html5rocks.com/en/tutorials/security/content-security-policy
o https://developer.mozilla.org/en/docs/Web/Security/CSP/CSP_policy_directives
o http://content-security-policy.com
Content-Security-Policy - Examples
o default-src Default policy for loading content such as JavaScript, Images, CSS
o script-src Defines valid sources of JavaScript.
o style-src Defines valid sources of stylesheets.
o Example : Load content from ‘self’ and cdn.example.com, in addition allow loading
scripts from js.example.com
Content-Security-Policy: default-src 'self' cdn.example.com; script-
src 'self' js.example.com;
o Example : Disallow loading content of current page inside iframes and enable XSS
protectionContent-Security-Policy: frame-ancestors 'none'; reflected-xss
'block';
X-Content-Type-Options
o Used to stop browser from using MIME-sniffing to determine content-type
of a resource.
o Prevent usage of maliciously crafted resources to perform attacks including
XSS.
o Use a Filter and response.addHeader("X-Content-Type-Options",
"nosniff");
o Use Tomcat built in security filter : HttpHeaderSecurityFilter
o https://tomcat.apache.org/tomcat-7.0-doc/config/filter.
html#HTTP_Header_Security_Filter
Tomcat HttpHeaderSecurityFiltero Available with Tomcat 7.0.63, X-XSS-Protection header was added in
7.0.68 <filter>
<filter-name>HttpHeaderSecurityFilter</filter-name><display-name>HttpHeaderSecurityFilter</display-name><filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
</filter><filter-mapping>
<filter-name>HttpHeaderSecurityFilter</filter-name><url-pattern>/*</url-pattern>
</filter-mapping>
o Security headers enabled by default :o X-XSS-Protection: 1; mode=blocko X-Content-Type-Options: nosniffo X-Frame-Options: DENYo Strict-Transport-Security: max-age=0;
o https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#HTTP_Header_Security_Filter o https://github.
com/apache/tomcat/blob/trunk/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
Future Developments IETF Drafts
Cookie Prefixes
o Mechanism of identifying whether a third-party has tampered HTTP
Cookies attributes set by the server.
o Defining security attributes of a cookie in the cookie name.
o Set-Cookie: __Secure-JSESSIONID=12345678901234567890;
Secure; Domain=example.com
o "__Secure-"
o "Secure" attribute & Domain
o "__Host-"
o Secure" attribute & "Path" attribute with a value of "/"
o https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00
Encrypted Content-Encoding for HTTP
o Allows HTTP message payloads to be encrypted.
o Store a file/content on a server without exposing its contents to that server.
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Encoding: aesgcm
Connection: close
Encryption: keyid="http://example.org/bob/keys/123"; salt="XZwpw6o37R-6qoZjw6KwAw"
[encrypted payload]
o https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-01
Q&A
![Remote Application Management over HTTP › specs › GlobalPlatform › 2.2 › GPC_v2.2-B... · The good practice of HTTP [2] for custom headers is to prefix them by “X-“. All](https://static.fdocuments.in/doc/165x107/5f17a971d18d577f027d83e3/remote-application-management-over-a-specs-a-globalplatform-a-22-a-gpcv22-b.jpg)
