Advertisement
Check these out next
DefCamp 2013 - Http header analysis
Dec. 18, 2013•0 likes•2,423 views
2 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Technology
DefCampFollow
DefCampAdvertisement
Advertisement
Advertisement
Recommended
Build A Killer Client For Your REST+JSON APIStormpath
Case Study of Django: Web Frameworks that are Secure by DefaultMohammed ALDOUB
Build a Node.js Client for Your REST+JSON APIStormpath
XSS Magic tricksGarethHeyes
Top Ten Web Application Defenses v12Jim Manico
Django (Web Applications that are Secure by Default )Kishor Kumar
DefCamp 2013 - Http header analysis
- HTTP Header Analysis @httphacker httphacker.com
- Agenda • Why are headers important to us?
- Agenda • Why are headers important to us? • What Checks are in AppSec Scanners?
- Agenda • Why are headers important to us? • What Checks are in AppSec Scanners? • Review of Header Attributes
- Agenda • Why are headers important to us? • What Checks are in AppSec Scanners? • Review of Header Attributes • Demo of gethead.py
- Why are headers important to us?
- Why are headers important to us? Input&Parameter&Coverage&in&Web&Applica6on& Scanners& Non$Coverage$Rate$of$Input$Vectors$ 60" 50" GET$ 40" No"Coverage" 30" Coverage" 20" 10" 0" GET" POST" HTTP"Cookie" HTTP"Header" Reference: Data compiled from InfoSec Institute 2012 study It’s the least protected area... POST$ HTTP$Cookie$ HTTP$Header$
- Opportunity POST /.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/boot.ini&url=httphacker.com HTTP/1.0 Referer: domain.com/external.xml Accept: */* User-Agent: Mozilla/5.0 Gecko/20110614 Firefox/3.6.18 Host: domain.com Connection: Keep-Alive Cookie: oAuth[access_token]=%31%33%33%37%22%3e%3c%73%43%72%49%70%54%3e%61%6c %65%72%74%28%68 %74%74%70%68%61%63%6b%65%72%29%3c%2f %73%43%72%49%70%54%3e;PHPSESSID=k04mk749i6cur91k; ! <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd"> ]><REQUEST><FROM>null</ FROM><METHOD>SEND</METHOD><MESSAGE type=”MSG”><HEAD><ID>612117752013</ ID><FROM>null</FROM><DESTINATION>UserManagerService&xxe;</ DESTINATION><ACTION>logout</ACTION><EVENT>null</EVENT></HEAD><BODY /></ MESSAGE></REQUEST> ! username:http&password=hacker
- What Checks are in AppSec Scanners?
- What Checks are in AppSec Scanners?
- What is missing in AppSec Scanners?
- Let’s review some of these headers...
- Content Security Policy (CSP)
- Content Security Policy (CSP) • Lets you specify a policy for where content in your webpages can be loaded from
- 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
- 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 (Firefox nightlies) • • X-Content-Security-Policy - Firefox 4+ X-WebKit-CSP - WebKit browsers (Chrome/Safari)
- 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
- CSP Sources (for the directives) • ‘none’ - No content of this type is allowed (All directives)
- 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)
- 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)
- 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’ - Allow script functions considered unsafe (such as eval()) • Supported by script-src
- CSP Sources (for the directives) • And you can specify custom sources: • • * - Allow content from anywhere • *.domain.com - Wildcard host, allow content from any domain.com sub-domain • • www.domain.com:81 - You can specify a port number https: - Scheme only, load only content served over https https://www.domain.com - You can specify an absolute URI for a host (path has no effect though)
- And then it all comes together • Content-Security-Policy: default-src ‘self’; script-src ‘self’ scripts.domain.com • • • This policy sets a default source of ‘self’ for all directives • • Scripts can also be loaded from scripts.domain.com script-src defines its own sources, replacing the default In effect, scripts, stylesheets, images, flash animations, Java applets, etc., can only be loaded from the same origin as the page This policy denies inline scripts and CSS!
- 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
- CSP Reporting • You can specify a “report-uri” in the CSP header
- CSP Reporting • • You can specify a “report-uri” in the CSP header Must be a relative URI
- 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
- CSP Reporting • • • You can specify a “report-uri” in the CSP header • Content-Security-Policy-Report-Only Must be a relative URI Will post violation reports as JSON back to the web application • Will not block scripts or resources violating the policy • Will report them to the web application
- XSS Protection
- XSS Protection • X-XSS-Protection: 1; mode=block • Enables XSS Filter built into most recent web browsers • Role is to re-enable for a particular website if it was disabled by the user
- XSS summarized • • • Make sure you validate your inputs Make sure you encode everything you output • • • Input to the web application Data from backend system EVERYTHING! Use CSP and XSS-Protection as an extra level of defense, it’s not the cure!
- X-Frame-Options (Click-jacking)
- Click-jacking • A malicious site loads the vulnerable site in an iframe
- Click-jacking • 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
- Click-jacking • 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
- 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 processed by - the web server!
- X-Frame-Options Client Message
- HTTP Strict Transport Security (HTTPS stripping)
- HTTPS stripping explained • “Secure” websites use SSL/TLS to preserve the confidentiality and integrity of the communication with a browser
- 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 • The very first request is insecure, and open to attack! User enters www.onlinebank.com - and is redirected to https://www.onlinebank.com
- HTTPS stripping explained • SSL stripping is a MiTM attack • Attacker keeps the victim on HTTP, but passes requests on over HTTPS to the target website • Practical attack demoed at BlackHat in 2009 (sslstrip)
- HTTPS stripping scenario An attacker sitting in the middle of a HTTPS session
- HTTPS stripping scenario An attacker sitting in the middle of a HTTPS session An attacker performing a HTTPS stripping attack
- 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
- Session hijacking Securing Cookies
- Session hijacking explained • Means getting access to a user’s privileged session > steal session tokens
- Session hijacking explained • Means getting access to a user’s privileged session > steal session tokens • Session tokens mean cookies
- Session hijacking explained • Means getting access to a user’s privileged session > steal session tokens • • Session tokens mean cookies Protect the cookies!
- Session hijacking explained • Means getting access to a user’s privileged session > steal session tokens • • • 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
- Session hijacking explained • Means getting access to a user’s privileged session > steal session tokens • • • Session tokens mean cookies • Cookies can be marked with the “secure” flag > instructs the browser to only send them with HTTPS requests 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
- IE MIME sniffing (Content-Type Options)
- IE MIME Sniffing • HTTP responses include a header stating what type of content is included
- IE MIME Sniffing • HTTP responses include a header stating what type of content is included • To compensate for misconfigured servers and bad programming, IE introduced MIME sniffing back in the days (IE4)
- IE MIME Sniffing • HTTP responses include a header stating what type of content is included • To compensate for misconfigured servers and bad programming, IE introduced MIME sniffing back in the days (IE4) • They introduced the “X-Content-Type-Options: nosniff” header in IE9 to disable the behavior
- IE MIME Sniffing • HTTP responses include a header stating what type of content is included • To compensate for misconfigured servers and bad programming, IE introduced MIME sniffing back in the days (IE4) • They introduced the “X-Content-Type-Options: nosniff” header in IE9 to disable the behavior • Always serve your content with the correct content type, and the “X-Content-Type-Options” header
- In Summary...we need more header detection and protection!
- gethead Project https://github.com/httphacker
- gethead Current Features • Written in Python 2.7.5 • Performs HTTP Header Analysis • Reports Header Vulnerabilities • Open Source
- gethead December Features • • • • • Support for git updates • Export with multi-format options (XML, HTML, TXT) Support for Python 3.x Complete Header Analysis Rank Vulnerabilities by Severity Export Findings with Description, Impact, Execution, Fix, and References
- gethead February Features • Replay & Inline Upstream Proxy Support to import into WebInspect • • • • Scan domains, sub-domains, and multi-services Header Injection & Fuzzing functionality HTTP Header Policy Bypassing Modularize and port to more platforms (e.g. gMinor, Kali, Burp Extension, Metasploit, Chrome)
- Thank you.
Advertisement