Analysis of HTTP Security Headers in Turkey

1. Analysis of HTTP
Security Headers in
Turkey
K. Emre KISA & Dr. Emin İslam TATLI
ISC Turkey, 25-26 October 2016

2. ||
Outline
 01 Web Browsers & Same-Origin Policy
 02 OWASP Top 10
 03 HTTP Security Headers
CSP 1.0 – 2.0 & Demo X-XSS Protection
X-Frame-Options & Demo Strict-Transport-Security
Set-Cookie X-Content-Type-Options
X-Download-Options X-Permitted-Cross-Domain-Policies
Public-Key-Pins
 04 Situation in Turkey – Alexa TR Top 500
 05 Further Information
 06 Questions
HTTP Security Headers I 2

3. ||
Web Browsers
01
&
Same-origin policy
Http Security Headers I 3

4. |
The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information
systems
Hyper Text Transfer Protocol
Http Security Headers I 4

5. |
HTTP (Cont.)
Http Security Headers I 5
HTTP
Request
HTTP
Processing
HTTP
Response

6. |
• Scripts contained in a first web page are allowed to access data
in a second web page, but only if both web pages have the same
origin
• Same origin : Same protocol + same host + same port
Same-Origin Policy
Http Security Headers I 6

7. ||
OWASP TOP 10
02
Http Security Headers I 7

8. |
OWASP Top 10
Http Security Headers I 8

9. || Http Security Headers I 9
HTTP Security Headers
03

10. |
• Content Security Policy declarative policy that lets the authors (or server administrators)
of a web application inform the client from where the application expects to load
resources.
Content-Security-Policy 1.0
Http Security Headers I 10
Content-Security-Policy : W3C recommended header supported by;
• Chrome version 25+,
• Firefox version 23+,
• Opera version 19+
• Safari version 7+
• Microsoft Edge 12 build 10240+
X-Content-Security-Policy : Supported by Internet Explorer.
• Internet Explorer 10+,
• Firefox Until version 23
X-WebKit-CSP : Old header used by Chrome
• Chrome version 14-25,
• Safari 6+

11. |
• Supported directives
– default-src :If not specified explicitly in the policy, the directives listed below will use the default sources.
(fallback),
– script-src : restricts which scripts the protected resource can execute.
– object-src : restricts from where the protected resource can load plugins (<object>, <embed> or <applet>)
– style-src :restricts which CSS styles the user applies to the protected resource,
– img-src : restricts from where the protected resource can load images,
– media-src : restricts from where the protected resource can load video and audio (<audio>, <video>)
– frame-src: restricts from where the protected resource can embed frames,
– font-src : restricts from where the protected resource can load fonts,
– connect-src: restricts which URIs the protected resource can load using script interfaces, (XHR, Websocket,
EventSource)
– sandbox : specifies an HTML sandbox policy that the user agent applies to the protected resource (same-origin
policy uygulanması, prevent pop-ups, plugin & script blocking)
– plugin-types: Defines valid MIME types for plugins invoked via <object> and <embed>,
– report-uri :Instructs the browser to POST a reports of policy failures to this URI.
Content-Security-Policy 1.0 (cont.)
Http Security Headers I 11

12. |
CSPHeader Sample;
Content-Security-Policy:
// By setting the default resource to «none», we minimize the chance of any mis-configuration related risks
default-src none;
// «self» we allow scripts loaded from our domain only
// We also allow «Inline javascripts», javascript Eval() function and Google analytics
script-src self unsafe-inline unsafe-eval https://ssl.google-analytics.com;
// We allow plugins from our domain only
object-src self;
// We allow style sheets loaded from our domain only
style-src self;
// We allow images to be loaded from our domain only
img-src self;
// We allow Form actions to be directed only towards our domain
form-action self;
// We allow audio and video files from our domain onlu
media-src self;
// We only allow Ajax XmlHTTPRequests to our domain only
connect-src self;
// We only allow PDF and Flash plugins to be loaded
plugin-types application/pdf application/x-shockwave-flash;
Content-Security-Policy 1.0 (cont.)
Http Security Headers I 12

13. |
Content-Security-Policy 1.0 (cont.)
Http Security Headers I 13
Reference: http://caniuse.com

14. |
CSP 1.0 did not allow us to hand pick individual scripts that are safe to be run. Thus we either had to allow a domain
completely or do not run scripts from that domain at all.
Content-Security-Policy 2.0
Http Security Headers I 14
Implementing a CSP 2.0 Nonce;
Content-Security-Policy: default-src 'self';
script-src 'self' https://example.com 'nonce-$RANDOM'
Sample;
Content-Security-Policy: default-src 'self';
script-src 'self' https://example.com 'nonce-Nc3n83cnSAd3wc3Sasdfn939hc3'
<script>
alert("Blocked because the policy doesn’t have 'unsafe-inline'.")
</script>
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
alert("Still blocked because nonce is wrong.")
</script>
<script nonce="Nc3n83cnSAd3wc3Sasdfn939hc3">
alert("Allowed because nonce is valid.")
</script>
<script src="https://example.com/allowed-because-of-src.js"></script>
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa"
src="https://elsewhere.com/blocked-because-nonce-is-wrong.js"></script>
<script nonce="Nc3n83cnSAd3wc3Sasdfn939hc3"
src="https://elsewhere.com/allowed-because-nonce-is-valid.js"></script>

15. |
Content-Security-Policy 2.0
Http Security Headers I 15

16. |
Content-Security-Policy 2.0
Http Security Headers I 16
Reference: http://caniuse.com

17. |
• Enables Web Browser’s self XSS (Cross-site-scripting) attack protection mechanism
• Aims to prevent Reflected XSS attacks. Browser uses pattern matching in Request and the
Response to be able to detect and prevent XSS payloads.
• x-xss-protection 1 mode=block
Whenever an XSS payload is detected by the browser, default mode only stops individual script to
be run. However, in block mode every script in the page is stopped.
• Web Browser support;
– Internet Explorer 8+ (Active by default in Internet, Trusted and Restricted trust zones.
Must be manually activated for web pages in Local Intranet trust zone.
–Available by default on Chrome version 4+
X-XSS-Protection
Http Security Headers I 17

18. |
• Provides protection against Clickjacking / UI Redress attacks.
• Click + Hijacking = Clickjacking
X-Frame-Options
Http Security Headers I 18
• Same origin : Allow if only iFrame and the web page is on the same domain.
• Deny : Prevents the web page from being displayed in frames on every domain.
• Allow from : Only given domains are allowed to display our website in frames.

19. |
X-Frame-Options : DENY
Http Security Headers I 19

20. |
X-Frame-Options : Web Browser Support
Http Security Headers I 20

21. |
HSTS addresses the following threats:
• User bookmarks or manually types http://example.com and is subject to a man-in-the-middle
attacker
–HSTS automatically redirects HTTP requests to HTTPS for the target domain
• Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves
content over HTTP
–HSTS automatically redirects HTTP requests to HTTPS for the target domain
• A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid
certificate and hopes the user will accept the bad certificate
–HSTS does not allow a user to override the invalid certificate message
HTTP Strict-Transport-Security (HSTS)
Http Security Headers I 21
Sample;
Strict-Transport-Security: max-age=3153600
Simplest use case
Strict-Transport-Security: max-age=3153600; includeSubDomains
HSTS also works on sub-domains
Strict-Transport-Security: max-age=3153600; includeSubDomains; preload
Uses the «Preload» list

22. |
• «Preload» list is hardcoded in web browsers. List is maintained by Chrome.
(https://hstspreload.appspot.com)
HTTP Strict-Transport-Security (cont.)
Http Security Headers I 22
Submission Requirements;
1.Hava a valid certificate
2.Redirect all HTTP Trafic to HTTPS
3.Make all sub-domains HTTPS, (If present in DNS records including the
www subdomain)
4.Serve the HSTS header:
• The max-age must be at least eighteen weeks (10886400 seconds).
• The includeSubDomains directive must be specified.
• The preload directive must be specified.
• If you are serving an additional redirect from your HTTPS site, that redirect must
still have the HSTS header (rather than the page it redirects to).

23. |
Web Browser Support
HTTP Strict-Transport-Security (cont.)
Http Security Headers I 23

24. |
• Set-cookie $RANDOM;
– Mainly used to identify the user
• Set-cookie $RANDOM; HttpOnly;
– Only allows Cookie value to be accessed by HTTP methods.
–Javascript, Flash etc. are not allowed to access the cookie value.
–Cookie value becomes harder to be stolen
• Set-cookie $RANDOM; HttpOnly; Secure;
–Only allows submission of Cookie value over Secure HTTPS channel.
Set-Cookie
Http Security Headers I 24

25. |
• Used to prevent MIME content-sniffing attacks.
• Content Sniffing : In the absence of a MIME type, or in some other cases where a client believes they
are incorrectly set, browsers may conduct MIME sniffing, which is guessing the correct MIME type by
looking at the resource.
• Can be exploited when you are allowed to upload an image, a document etc. to a server and others
can access it.
• Attack scenario;
–An attacker injects HTML code into a GIF file, uploading it to the server by passing upload limitations.
–Victim browsers trying to display the GIF decides to make «content sniffing» because of the MIME-
type and file content mismatch.
– Web Browser concludes that the file is an HTML file, serving malicious HTML content to the victim.
• Sample: X-Content-Type-Options: nosniff
X-Content-Type-Options
Http Security Headers I 25

26. |
• If you download an HTML file from a web page and chooses to "Open" it in browser, it will execute in
the context of the web site. That means that any scripts in that file will also execute with the origin of
the web site.
• «X-Download-Options: noopen» forces browser to download rather than execution of the file
contents.
• HTML files that you «open» instead of «save» can accesss web site cookie value.
X-Download-Options
X-Download-Options: noopen
Http Security Headers I 26

27. |
Sample;
– X-Permitted-Cross-Domain-Policies : none
Cross-domain access is not allowed.
– X-Permitted-Cross-Domain-Policies : master-only
Only our domain is allowed to read cross-domain.xml
X-Permitted-Cross-Domain-Policies
Http Security Headers I 27

28. |
• Certificate Pinning is a security mechanism which allows HTTPS websites to resist impersonation by
attackers using mis-issued or otherwise fraudulent certificates
• The HTTPS web server serves a list of public key hashes, and on subsequent connections clients
expect that server to use one or more of those public keys in its certificate chain.
• = Base64 (sha256(certificate))
• Public-Key-Pins: max-age=3000;
pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
• Browser support
Public-Key-Pins
FootNote Http Security Headers I 28

29. ||
Situation in Turkey
04
Http Security Headers I 29

30. | Http Security Headers I 30
370 (*) of Alexa Turkey Top 500
(*) 130 of popular global websites have been filtered out, unless Turkey is one of their top 5 visitors according to Alexa.
(Facebook.com, Google.com etc. are filtered out)

31. | Http Security Headers I 31

32. | Http Security Headers I 32

33. ||
Further Information
05
Http Security Headers I 33

34. |
https://securityheaders.io/
Grade Your Website
Http Security Headers I 34

35. |
https://github.com/ttemrekisa/securityheaderchecker
SecurityHeaderChecker on Github
Http Security Headers I 35

36. ||
Thank you
Http Security Headers I 36
Questions?