Booster — 14. March 2013

André N. Klingsheim (@klingsen)

AppSec AS

SECURING YOUR WEB APPLICATION THROUGH

HTTP HEADERS

1

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

DEMO

3

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

CONTENT SECURITY POLICY

Cross site scripting (XSS)

5

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

DEMO

7

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

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

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

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

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

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

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

CLICKJACKING

X-Frame-Options

15

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

CLICKJACKING DEMO

Evil site

Click me!

Vulnerable site

Delete

something!

17

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

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

X-FRAME-OPTIONS SEQUENCE DIAGRAM

Attacker

Target

20

HTTPS STRIPPING

Strict-Transport-Security

21

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

HOW "SECURE BROWSING" USUALLY WORKS

www.onlinebank.com (unprotected)

Redirect: https://www.onlinebank.com (unprotected)

https://www.onlinebank.com (protected)Online bank

23

HTTPS STRIPPING

www.onlinebank.com (unprotected)

Response (unprotected)

https://www.onlinebank.com (protected)

Online bankAttacker

Response (protected)

http://www.onlinebank.com (unprotected) https://www.onlinebank.com (protected)

Response (protected)

Response (unprotected)

24

DEMO

25

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

SESSION HIJACKING

Securing cookies

27

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

DEMO

29

IE MIME SNIFFING

X-Content-Type-Options: nosniff

30

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

COST/BENEFIT OF SECURITY HEADERS

32

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

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

THANK YOU!

@klingsen

35