Web app security essentials

Süddeutsche Zeitung
 German for South German Newspaper
 One of the largest german daily newspapers
 Created in 1945
 In early 2015 they received ~ 2.6TB dataset. After over one year of research first
stories was published and scandal was named Panama Papers

Panama papers leak
 Leaked from Mossack Fonseca
 11.5 million documents dated back as far as 1970s
 Over 200 000 offshore entities
 Researched by 107 media organizations in 80 countries
 Hundreds of famous names appeared in leak (ie. Donald Trump, Emma Watson,
Stanley Kubrick, Willian Borges da Silva, Jackie Chan)
 Over 1 200 000 000 USD recouped after 3 years
 Investigations started in over 80 countries

Known vulnerabilities
 Three year old, vulnerable version of Drupal
 Oracle fork of Apache which allowed to access directory structure by default
 Insecure network architecture
 Some part of site was running on Wordpress with vulnerable plugin
 Part of CMS was vulnerable to SQL Injection

Essential Security Measures in Web
Applications

Rafał Hryniewski
@r_hryniewski
fb.me/hryniewskinet
.NET Dev
Blogger
Speaker
Community leader
https://hryniewski.net
rafal@hryniewski.net

Agenda
 What could happen if you’re careless
 Most common vulnerabilities
 Some easy ways to defend your applications
 Web application security FAQ

OWASP Top 10 - 2017
1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with Known Vulnerabilities
10. Insufficient Logging & Monitoring

Injection – Are you vulnerable?
 Do you concatenate strings in order to build database queries or OS commands?
 Does your ORM protect you from injection?
 Do you validate internal and external inputs?

Broken authentication – are you
vulnerable?
 Do you have any brute force protection on sign in form?
 Do you indicate that account exists while someone post wrong password?
 Is it possible to steal your session token? Does EVERY request goes through
HTTPS?
 Are your session cookies protected with secure flag?
 Do you use multi factor authentication?
 How long is your session timeout?

Sensitive Data Exposure – are you
vulnerable?
 Can any request be made without encryption?
 Do you store any sensitive and not encrypted data?
 Do you use obsolete and weak cryptography algorithms?

Sensitive Data Exposure – how it
should’ve been done

XML External Entities – are you
vulnerable?
 Do you use XML at all?
 Do you sanitize your inputs?
 Do you use whitelists for input validations?

Broken Access Control – are you
vulnerable?
 Are you checking permissions at all?
 Do you handle permissions on frontend?
 Can you access endpoints you shouldn’t by modifying URLs or cookies?

Security Misconfiguration – are you
vulnerable?
 Do you have any default accounts active?
 Is it possible to see error and stack traces in your application when exception
happen?
 Did you disabled security features because they were annoying and/or
inconvenient?
 Does your application use any security headers?

XSS – are you vulnerable?
 Does your application return values like „Results for phrase X”?
 Do you store text with HTML tags for display purposes?
 Can I upload SVG file to your system and it’ll render it?
 Do you sanitize your inputs?

Insecure Deserialization – are you
vulnerable?
 Can you change sensitive application state or behavior (ie. Authorization) by
sending modified, serialized value?
 Can you modify type in which object will deserialize?
 Do you validate field types after deserialization?

9. Using Components with Known
Vulnerabilities

9. Using Components with Known
Vulnerabilities – are you vulnerable?
 Did you ever check you components against vulnerabilities?
 Do you use updated libraries and frameworks?
 Do you use automated tools for checking components you’re using?
 Do you know EXACTLY what are ALL dependencies of your application?

10. Insufficient Logging & Monitoring

Insufficient Logging & Monitoring – are
you vulnerable?
 Will you know when someone will try to bruteforce your users password?
 Do you use any kind of anomaly detection?
 Do you need to read your logs to know about attempts to breach your security or
you’ll receive instant alert?

OWASP ASVS - Application Security
Verification Standard
 Basically a security requirements checklist
 Divided into 3 levels
 ASVS Level 1 is for low assurance levels, and is completely penetration testable
 ASVS Level 2 is for applications that contain sensitive data, which requires
protection and is the recommended level for most apps
 ASVS Level 3 is for the most critical applications - applications that perform high
value transactions, contain sensitive medical data, or any application that requires
the highest level of trust.
 https://github.com/OWASP/ASVS/raw/master/4.0/OWASP%20Application%20Sec
urity%20Verification%20Standard%204.0-en.pdf

CVE – Common Vulnerabilities and
Exposures
 Knowledge base about common, existing vulnerabilities
 https://cve.mitre.org/
 https://www.cvedetails.com/

If you have HTTPS redirect/rewrite
 All your requests are redirected to secure domain…
 …but first request still doesn’t have SSL

HTTP Strict Transport Security (HSTS)
 There is a preload list present in most browsers
 You can submit to preload list manually on https://hstspreload.org
 All it takes is making your site secure and adding Strict-Transport-Security header

HSTS uses Internal Redirect (307)

CSP – Content Security Policy

Content-Security-Policy
 A lot of various directives ie. Whitelisting script or styles files sources, upgrading
insecure urls, hide referrer etc.
 Allows to report CSP violations by HTTP request
 Directives reference - https://content-security-policy.com

Add CSP header
Content-Security-Policy: default-src 'self'

Add reporting
Content-Security-Policy: default-src 'self'; report-uri https://rhtest.report-
uri.com/r/d/csp/enforce

Add whitelist
Content-Security-Policy: default-src 'self’;
script-src 'self' code.angularjs.org;
style-src 'self' 'unsafe-inline’;
img-src 'self' via.placeholder.com;
connect-src 'self' jsonplaceholder.typicode.com;
report-uri https://rhtest.report-uri.com/r/d/csp/enforce

Report only
Content-Security-Policy-Report-Only: default-src 'self’;
script-src 'self' code.angularjs.org;
style-src 'self' 'unsafe-inline’;
img-src 'self' via.placeholder.com;
connect-src 'self' jsonplaceholder.typicode.com;
report-uri https://rhtest.report-uri.com/r/d/csp/enforce

Auditing npm dependencies
npm audit

Auditing nuget dependencies
Install-Package SafeNuGet

Auditing Container dependencies
Use private registry with automated auditing

Don’t expose info about your system

Some basic tools
 Kali Linux
 W3af
 Zed Attack Proxy
 Sqlmap
 XSS Rays(browser extension)

Resources
 OWASP Top 10 Report
 ASVS
 CWE
 Troy Hunt
 Rozwal.to
 Michał Bentkowski - "XSS - why is it noteworthy? - live hacking“
 Peter Kim - The Hacker Playbook 3: Practical Guide To Penetration Testing

Why would someone attack my website?

When should I worry about security?

Are automated tests good enough?

Should I fix all vulnerabilities?

How to ensure safety of my application
and organization?

@r_hryniewskifb.me/hryniewskinet

Web app security essentials

More Related Content

What's hot (20)

Similar to Web app security essentials (20)

More from Rafał Hryniewski (17)

Recently uploaded (20)

Web app security essentials