1) HTTP headers can be used to secure web applications from common attacks like cross-site scripting and clickjacking. Content Security Policy, X-Frame-Options, and HTTP Strict Transport Security are some useful security headers. 2) Content Security Policy allows specifying whitelist sources for things like scripts, stylesheets, and images to load from to prevent XSS. X-Frame-Options prevents clickjacking by not displaying pages within frames. HTTP Strict Transport Security forces HTTPS usage to prevent SSL stripping attacks. 3) Other useful headers include setting secure and HttpOnly flags on cookies to prevent session hijacking, and using X-Content-Type-Options to prevent MIME type sniffing in Internet Explorer. Adding these security

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