edgescan 2014 vulnerability stats report december 2014 owasp version)
TRANSCRIPT
edgescan™ 2014 Vulnerability Stats Report
Eoin KearyCTO with BCC Risk Advisorywww.bccriskadvisory.com
OWASP Global Board Member & Global Vice Chair
OWASP Testing GuideOWASP Code Review GuideOWASP Irish chapter founderOWASP SAMM
Application Developer & Application Security: 14 Years
Rahim JinaDirector with BCC Risk Advisorywww.bccriskadvisory.com
OWASP Leader
OWASP Code Review GuideOWASP Ex-Irish chapter leaderOWASP SAMM
Application Security &Application Developer : 9 Years
Why“You cant measure what you cant improve”
What is most effective at reducing Risk?
What is the major Root Cause?
Are most Risks at the Application layer?
Are most Risks at the Server Layer*?
Quick wins to be more secure?
Average time to fix a high risk?
What does improvement look like?
* “Server Layer” is also software!!
How?
edgescan analytics and metrics
Track improvement
Delta Analysis
Continuous/Unlimited Assessments
Layer 7 and below – WebApps and Servers
Manual Verification of all discovered vulnerabilities
Sample Space
The vulnerability statistics shown are the result of the last 12 months (November 2014): • Assessing 000’s of web applications and
hosting environments across the globe (assets)
• Various industry verticals from media to finance to software development to pharmaceuticals and medical research.
2014 - year in review
• Many large breaches:
“Cyberdemics” – (another word to hate!!)
Security by Numbers
⅓• The most common root cause of vulnerabilities – poor patching /
maintenance!!
FULL-STACK!
• 34% of the vulnerabilities could have been avoided• This included many vulnerability types:
– SQLI, CMDI, BuffOverFl, XSS, PrivEscl, DoS– Over 20% of the vulnerabilities were Critical
• Patching vulnerabilities were in relation to both operating system and software frameworks such as:
• OpenSSL, PHP, Spring, Struts, Apache Server, MySQL, Linux, Windows etc
The Year of Crappy Crypto – 2014
• The most common vulnerability on hosting servers (Layer 6 and below) was in relation to SSL/Crypto, protection of data in transit.
CVE-2014-3568CVE-2014-3567CVE-2014-3513CVE-2014-3566CVE-2014-3511CVE-2014-5139CVE-2014-3512CVE-2014-3510CVE-2014-3509CVE-2014-3508
1 in 10
• 10% of all vulnerabilities discovered in 2014 are deemed high/critical risk.
– Easily exploitable– Remote– #PCIFail– Application and Network Layers combined.
WebApps• 59% of the vulnerabilities discovered are application layer
– Mobile– Sites– Web applications– Web services
Old Reliable
• The king of application layer vulnerabilities is our dear old friend Cross-Site-Scripting (XSS) with every application assessed by edgescan having an average XSS density of 2.4 per application.
The Most vulnerable application had
220 instances of XSS
Lets Talk about XSS
Afraid of Needles?
• A surprising metric from 2014 – frequency of occurrence Remote code Execution,
SQL Injection, Buffer Overflow, Command Injection vulnerabilities discovered.
– On average: for every 2 assets (applications or hosting servers) assessed 1 such vulnerability was discovered.
HTTP Security Headers
• Lack of Security headers is interesting given how easy they are to implement.
• Circa 16% of application layer vulnerabilities discovered (including some SSL issues) could have been mitigated / risk reduced by using HTTP Security headers.
• Only 1% of HTTP systems assessed by edgescan had at least one HTTP Security header.
Remember – Headers, Headers, remember
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.
WHAT ARE HTTP RESPONSE HEADERS?
HTTP headers are components of the message header of HTTP Responses.
HTTP headers define different aspects of an HTTP transaction.
HTTP headers are colon-separated name-value pairs in clear-text string format, terminated by a carriage return (\r) and line feed (\n) character sequence.
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.
HTTP RESPONSE SECURITYHEADERS SUMMARY
X-Frame-OptionsX-Xss-ProtectionX-Content-Type-Options Content Security PolicyAccess-Control-Allow-OriginHTTPS Strict Transport
SecurityCache-Control / Pragma
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.
HTTP RESPONSE SECURITY HEADERSX-Frame-Options Set to "SAMEORIGIN" to allow framing on same
domain. Set to "DENY" to deny framing at all Set to "ALLOWALL" if you want to allow framing for all
websiteX-XSS-Protection Set to "1; mode=block" to use XSS Auditor and block
page if XSS attack is detected. Set to "0;" if you want to switch XSS Auditor off. This
is useful if response contents scripts from request parameters
X-Content-Type-Options
Set to "nosniff" to stop the browser from guessing the MIME type of a file.
X-Content-Security-Policy
A powerful mechanism for controlling which sites certain content types can be loaded from
Access-Control-Allow-Origin
Used to control which sites are allowed to bypass same origin policies and send cross-origin requests.
Strict-Transport-Security
Used to control if the browser is allowed to only access a site over a secure connection
Cache-Control Used to control mandatory content caching rules
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.
HTTP RESPONSE HEADER:X-Frame-Options
Protects you from most classes of Clickjacking
X-Frame-Options: DENYX-Frame-Options:
SAMEORIGINX-Frame-Options: ALLOW
FROM example.com
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.
HTTP RESPONSE HEADER:X-Xss-Protection
X-Xss-Protection: 0;
Use the browser’s built-in XSS auditor:
X-Xss-Protection: 1; mode=block
Disable the browser’s built-in XSS auditor:
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.
CONTENT SECURITY POLICY
Move all inline script and style into separate files
Add the X-Content-Security-Policy response header to instruct the browser that CSP is in use
Define a policy for the site regarding loading of content Anti-XSS W3C standard
http://www.w3.org/TR/CSP/
CSP Support Statisticshttp://caniuse.com/
#feat=contentsecuritypolicy
CSP Example Usagehttp://content-security-policy.com/
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved. 2424
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.
HTTP RESPONSE HEADER:Strict-Transport-Security
Forces your browser to always use HTTPS
Strict-transport-security: max-age=10000000; includeSubdomains
Base case:
Strict-transport-security: max-age=10000000
Do all of your subdomains support SSL?
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.
DISABLING THE BROWSER CACHE
Add the following as part of your HTTP Response:
Cache-Control: no-store, no-cache, must-revalidateExpires: -1
Eoin Keary & Jim Manico Copyright 2014 – all rights reserved.
APPLY ALL THE HEADERS!
strict-transport-security: max-age=631138519\r\nversion: HTTP/1.1\r\nx-frame-options: SAMEORIGIN\r\nx-gitsha: d814fdf74482e7b82c1d9f0344a59dd1d6a700a6\r\nx-rack-cache: miss\r\nx-request-id: 746d48ca76dc0766ac24e74fa905be11\r\nx-runtime: 0.023473\r\nx-ua-compatible: IE=Edge,chrome=1\r\nx-webkit-csp-report-only: default-src 'none'; script-src 'self'; connect-src 'self';
img-src 'self'; style-src 'self’\r\ncontent-security-policy-report-only: default-src 'none'; script-src 'self';
connect-src 'self'; img-src 'self'; style-src 'self’\r\nx-content-security-policy-report-only: default-src 'none'; script-src 'self';
connect-src 'self'; img-src 'self'; style-src 'self’\r\n
Continuous Threat
• continuous assessment• continuous maintenance• continuous patching• continuous monitoringOR• continuous #FAIL
Conclusion
• There will always be bugs!• Full-Stack Patching! (not just OS)• 2014 – “Crypto’mageddon” --- • Metrics• Security needs to be more than point-in-time• Vuln Management is one (large) piece of the
puzzle
www.bccriskadvisory.com
© BCC Risk Advisory Ltd 2014. All rights reserved.
Thanks
[email protected]@bccriskadvisory.com
edgescan™ 2014 Vulnerability Stats Report:
http://www.bccriskadvisory.com/wp-content/uploads/Edgescan-Stats-Report.pdf