These are my slides for my workshop at the Booster conference 2013.

1. SECURING YOUR WEB APPLICATION THROUGH
HTTP HEADERS
Booster — 14. March 2013
André N. Klingsheim (@klingsen)
AppSec AS
1

2. OUTLINE
• HTTP headers
• Attacks and security headers
• Cross site scripting (XSS) — Content Security Policy
• Clickjacking — X-Frame-options
• SSL stripping++ — HTTP Strict Transport Security
• Session hijacking — Cookie security settings
• MIME type attacks — X-Download-Options, X-Content-Type-options
2

3. DEMO
3

4. HYGIENE: VERSION HEADERS
• Web servers and web application frameworks tend to include version headers in the HTTP responses
• There really is no reason to leak this information to an attacker
• Get rid of them and save the bandwith!
• Demo
4

5. Cross site scripting (XSS)
CONTENT SECURITY POLICY
5

6. CROSS SITE SCRIPTING (XSS)
• Reflected
• User controlled data from the request is included in the response
• Persistent
• Attacker is able to store the attack server side, the stored attack is later included in response(s)
• DOM based
• Does not involve the server, happens on the client side
- XSS (Cross Site Scripting) Prevention Cheat Sheet
- OWASP Top 10 for JavaScript – A2: Cross Site Scripting – XSS 6

7. DEMO
7

8. CONTENT SECURITY POLICY (CSP)
• Lets you specify a policy for where content in your webpages can be loaded from
• Lets you put restrictions on script execution
• Headers
• Content-Security-Policy – Chrome 25
• X-Content-Security-Policy – Firefox 4+
• X-WebKit-Csp – WebKit browsers (Chrome/Safari)
• W3C Candidate recommendation
• Will end up being a proper standard!
8

9. CSP DIRECTIVES
• default-src — Specifies the default for other sources
• script-src
• style-src
• object-src — plugins
• img-src
• media-src — video/audio
• frame-src
• font-src
• connect-src
• report-uri — Specifies where CSP violations can be reported
9

10. CSP SOURCES (FOR THE DIRECTIVES)
• 'none' — No content of this type is allowed (All directives)
• 'self' — Content of this type can only be loaded from the same origin (no content from other sites) (All directives)
• 'unsafe-inline' — Allows unsafe inline content.
• Supported by style-src (inline css) and script-src (inline script)
• 'unsafe-eval' — Allows script functions considered unsafe (such as eval())
• Supported by script-src
• And you can specify custom sources:
• * — Allow content from anywhere
• https: — Scheme only, load only content served over https
• *.nwebsec.com — Wildcard host, allow content from any nwebsec.com sub-domain.
• www.nwebsec.com:81 — You can specify a port number
• https://www.nwebsec.com — You can of specify an absolute URI for a host (path has no effect though)
10

11. AND THEN IT ALL COMES TOGETHER
• Content-Security-Policy: default-src 'self'; script-src 'self' scripts.nwebsec.codeplex.com
• This policy sets a default source of 'self' for all directives.
• script-src defines its own sources, replacing the default (hence the inclusion of 'self')
• In effect, scripts, stylesheets, images, flash animations, Java applets etc can only be loaded from the same origin as the
page
• Scripts can also be loaded from scripts.nwebsec.codeplex.com
• This policy denies inline scripts and CSS!
11

12. THE "SPECIAL" SOURCES
• 'unsafe-inline' can allow inline scripts (script-src) and styles (style-src)
• 'unsafe-eval' allows certain JavaScript functions considered high risk (eval())
• Use these special sources with care
12

13. CSP REPORTING
• You can specify a "report-uri" in the CSP header
• Must be a relative URI
• Will post violation reports as JSON back to the web application
• Content-Security-Policy-Report-Only
• Will not block scripts or resources violating the policy
• Will report them to the web application
13

14. XSS SUMMARIZED
• Make sure you validate your inputs
• Make sure you encode everything you output
• Input to the web application
• Data from backend systems
• EVERYTHING!
• Use CSP as an extra level of defense, it's not the cure!
14

15. X-Frame-Options
CLICKJACKING
15

16. CLICKJACKING
• A malicious site loads the vulnerable site in an iframe
• The iframe is invisible, and positioned in front of something the user is likely to click on
• The user clicks on what appears to be an element on the malicious site
• The user really clicks in the iframe, triggering some operation on the vulnerable site
16

17. CLICKJACKING DEMO
Vulnerable site Evil site
Delete
something!
Click me!
17

18. FRAMESNIFFING
• You can specify an URL with an anchor when loading an iFrame
• Browsers would scroll to the anchor tag, or the html element with the relevant id attribute
• This scrolling can be detected with JavaScript
• Note: Vulnerability has been fixed in latest versions of browsers
18

19. X-FRAME-OPTIONS
• X-Frame-Options: Deny | SameOrigin
• Instructs the browser to not display the page in a frame
• When the page isn’t displayed, there’s nothing to click on!
• Browser support: Opera 10.5, Chrome 4.1, IE 8, Firefox 3.6.9, Safari 4
• Remember: The request is still sent to — and prosessed by — the web server!
19

20. X-FRAME-OPTIONS SEQUENCE DIAGRAM
Attacker
Target
20

21. Strict-Transport-Security
HTTPS STRIPPING
21

22. HTTPS STRIPPING EXPLAINED
• "Secure" websites use SSL/TLS to preserve the confidentiality and integrity of the communication with a browser
• For usability, "secure" websites are still accessible through insecure channels (HTTP on port 80)
• They’ll redirect the user to HTTPS
• User enters www.onlinebank.com — and is redirected to https://www.onlinebank.com
• The very first request is insecure, and open to attack!
• SSL stripping is a middleperson attack
• Attacker keeps the victim on HTTP, but passes requests on over HTTPS to the target website
• Practical attack demoed at Black Hat in 2009 (sslstrip)
http://www.thoughtcrime.org/software/sslstrip/ 22

23. HOW "SECURE BROWSING" USUALLY WORKS
www.onlinebank.com (unprotected)
Redirect: https://www.onlinebank.com (unprotected)
https://www.onlinebank.com (protected)
Online bank
23

24. HTTPS STRIPPING
www.onlinebank.com (unprotected) https://www.onlinebank.com (protected)
Response (unprotected) Response (protected)
http://www.onlinebank.com (unprotected) https://www.onlinebank.com (protected)
Attacker Online bank
Response (unprotected) Response (protected)
24

25. DEMO
25

26. HTTP STRICT TRANSPORT SECURITY
• Strict-Transport-Security: max-age=31536000; includeSubDomains
• Max-age specifies for how many seconds the policy should be in effect
• includeSubDomains — optional
• Instructs the browser to only communicate to that hostname over SSL/TLS
• Fails hard on certificate errors
• The user does not have the option to click through certificate warnings
• Browser support: Chrome 4+, Firefox 4+, Opera 12
26

27. Securing cookies
SESSION HIJACKING
27

28. SESSION HIJACKING EXPLAINED
• Means getting access to a user's privileged session -> steal session tokens
• On the web, session tokens mean cookies
• Protect the cookies!
• Cookies can be marked with the "httpOnly" flag -> makes them inaccessible to JS, they won't be included in requests from
applets.
• Cookies can be marked with the "secure" flag -> instructs the browser to only send them with HTTPS requests
28

29. DEMO
29

30. X-Content-Type-Options: nosniff
IE MIME SNIFFING
30

31. IE MIME SNIFFING
• HTTP responses include a header stating what type of content is included
• E.g. Content-Type: text/html; charset=utf-8
• To compensate for misconfigured servers and bad programming, IE introduced MIME sniffing back in the days (IE4)
• Some undesires side effects when IE guesses wrong
• They introduced the "X-Content-Type-Options: nosniff " header in IE9 to disable the behaviour
• Always serve your content with the correct content type, and the "X-Content-Type-Options" header
• Demo!
31

32. COST/BENEFIT OF SECURITY HEADERS
32

33. ADDING HEADERS IS EASY
• Benefits
• Usually a single line of code in any "webpage"
• Can often be added through config
• Prevents well known attacks
• Cost
• Low
• CSP can be expensive, might require rewrite of existing applications
33

34. SOME REFERENCES
• Blog: Security through HTTP response headers
• http://www.dotnetnoob.com/2012/09/security-through-http-response-headers.html
• The NWebsec security library for ASP.NET
• http://nwebsec.codeplex.com/
• The NWebsec demo site
• http://www.nwebsec.com/
• The application used for demo here
• https://github.com/klings/Booster2013
34

35. @klingsen
THANK YOU!
35