A good defense against insecure code requires understanding the mechanics behind how attackers exploit simple programming mistakes. Developers today face a massive onslaught of new and old attack vectors in both the code they write and the open source they use.

1. OWASP 1
Agenda
● Introduction to OWASP (Open Web Application Security Project) &
Web application security Overview
● Review of OWASP Top 10 Web Application Security Vulnerabilities
○ Description and Affected Environments
○ Detection and Protection
○ Code Example (Where possible/applicable)
○ Defense Mechanisms

2. OWASP
About Me
Bruce Mayhew
Director of Data Research at Sonatype
Project Lead and co-author of WebGoat
Me: webgoat@owasp.org
WebGoat List: owasp-webgoat@lists.owasp.org
Slack: https://owasp.slack.com/messages/project-webgoat
2

3. OWASP 3
Introduction to OWASP
● Open Web Application Security Project
Ref: www.owasp.org
● Workshop partially driven by OWASP
Education material

4. OWASP
Risk Ratings
Ref: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
4
What is the risk if I steal your password?
What is the risk of an asteroid hitting earth?
What is the risk of another Equifax ?

5. OWASP
What are power law distributions?
5

6. OWASP 6
Deadliest Earthquakes since 1900

7. OWASP
Japan Earthquakes
7

8. OWASP
Fukushima Reactor Fit
8

9. OWASP
Reality
9

10. OWASP
Terrorism
10

11. OWASP
Applicable to Security Breaches?
11
Power Law

12. OWASP
So what can we do?
12
Inevitability

13. OWASP 13
Web application security Overview
● Application level attacks occur on Port 80/443, used for legitimate web
traffic
● Secure Socket Layer (SSL) does not protect against application level
attacks.
○ SSL only encrypts the tunnel
● Hardening (Web Server and OS) does not prevent Port 80/443 attacks
● WAF/IDS
○ Only detect known holes, don’t have signatures that match these attacks
○ Hard to configure
● Secure coding and component management– the only way to prevent
application level attacks
○ Unit test attacks are often not included

14. OWASP
OWASP Top 10 Risk Rating Key
14
Easy is “bad”
How difficult is
this to exploit
in the wild
Widespread is
“bad”
How often is
this seen
Easy is “bad”
How easy is
this to find
Severe is
“bad”
How much
damage can
this cause

15. OWASP 15
OWASP Top 10 - 2017
A1 - Injection
A2 - Broken Authentication and Session Management
A3 - Sensitive Data Exposure
A4 - XML External Entities
A5 - Broken Access Control
A6 - Security Misconfiguration
A7 - Cross-Site Scripting (XSS)
A8 - Insecure Deserialization
A9 - Using Components with Known Vulnerabilities
A10 - Insufficient Logging & Monitoring
https://www.owasp.org/images/7/72/OWASP_Top_10-2017.pdf

16. OWASP 16
A1 - Injection Flaws
Occurs when an attacker relays malicious code through an
application to another system

17. OWASP 17
A1 - Injection Flaws
● Description
○ Injection occurs when user-supplied data is sent
to an interpreter as part of a command or query
○ SQL injection is the most common
● Affected Environments
○ All web application frameworks that use
interpreters are vulnerable to injection attacks.

18. OWASP 18
A1 - Injection Flaws
● Detection
○ Verify that the user cannot modify commands or queries sent to
any interpreter used by the application
○ Code Reviews are useful to detect
■ Difficult to definitively detect with penetration testing
● Protection
○ User input validation using whitelists
○ Avoid interpreters where possible
○ Parameterized queries
○ Enforce least privilege

19. OWASP
A1 Injection Flaws Summary
● Attacks are performed by
hackers benefitting from
YOUR mistakes
● All sources of data are
vulnerable to injection;
the environment,
variables, parameters,
external/internal web
services etc.
● Minimal tools and skill set
needed to perform these
attacks
● Injection vulnerabilities usually
found in SQL, LDAP, XPATH, XXE,
XML, etc.
● Scanners and fuzzers help one find
injection flaws (attackers and
defenders)
● Injection can result in
data loss, corruption, or
disclosure to
unauthorized parties,
loss of accountability, or
denial of access.
Injection can sometimes
lead to complete host
takeover
19

20. OWASP 20
A1 - Injection Flaws
● Vulnerabilities
○ SQL Injection
○ Command Injection
○ XXE Injection
○ XML Injection
○ LDAP Injection
○ RCE Injection

21. OWASP 21
SQL Injection
● Dynamic query in application
○ “select * from users where name = ‘” + userName + “ ’”
○ “select * from users where employee_id = ” + userID
● Attacker supplies unexpected text
○ userName = Bruce’ or ‘1’=‘1
○ userID = 1234567 or 1=1
● Application executes query
○ select * from users where name = ‘Bruce’ or ‘1’ = ‘1’
■ select * from users where name = Bruce or TRUE
■ All records are returned from database
○ select * from users where employee_id = 1234567 or 1=1

22. OWASP 22
A1 - SQL Injection - Try It

23. OWASP
SQL Injection Defense Mechanisms
● Input validation
○ Prevents other attacks from being stored
○ All data acted on by SQL commands should be escaped for
meta-characters
● Parameterized queries and parameterized stored procedures
● Connecting with least privilege
○ Limits damage if SQL injection occurs
23

24. OWASP 24
A4 - XML External Entities (XXE)
A type of injection attack which parses XML Input

25. OWASP
A4 - XML External Entities
● Description
○ An injection type of attack which occurs
when XML input containing a reference to
an external entity is processed by a
weakly configured XML parser
● Affected Environments
○ Any web application framework containing
weak XML Parsers
25

26. OWASP
A4 - XML External Entities
● Exploitation of
vulnerable XML
Processors can only
happen under specific
conditions
○ Upload XML or
include hostile
content in an
XML Document
○ Exploit code,
dependencies, or
integrations
● Using older XML Processors is
not advised as they allow a
specification of an external entity
● SAST tools can discover this
issue by inspecting
dependencies and configuration
● DAST tools will work as well but
require additional manual steps
to detect the issue
● Flaws can be used to;
extract data, execute a
remote request from
the server, scan
internal systems,
perform a
denial-of-service
attack, etc.
● Business impacts vary
on the protection needs
of affected applications
and data
26

27. OWASP
A4 - XML External Entities
● Vulnerabilities
○ Application accepts XML directly
○ XML Processors in application have DTDs
(document type definitions) enabled
○ If your application uses SAML for identity
processing within single sign on purposes
27

28. OWASP
A4 - XML External Entities - Application
Accepts XML Directly
● Since the server accepts XML directly, the attacker can
upload malicious XML.
● For example, this attacker attempts to extract data from the
server using this source code
○ <?xml version=”.-”encoding=”ISO-8859-1”?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM “file:///etc/passwd” >]>
<foo>&XXE;</foo>
● While this source code may not work on every application, it
is an example of how easy it is for an attacker to upload
malicious code when application accept XML directly
28

29. OWASP 29
A4 - XXE - Try It

30. OWASP
A4 - XML External Entities - DTDs
● DTDs are a template that set out the format and tag structure of an XML compliant document
● DTDs can allow DOS attacks such as Billion Laughs/XML Bomb
● For example, Billion Laughs would look something like this
○ <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE lolz[
<!ENTITY lol "lol">
<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>
● When an XML parser loads this attack, it sees the one element “lolz”, that contains the text “&lol9”, which is an
expansion of “&lol8”, which is an expansion of “&lol7”, so on and so forth
● This block of XML actually contains 10⁹ “lol’s” (or one billion) and takes over 10 GB of memory 30

31. OWASP
A4 - XML External Entities - Defense
Mechanisms
● Use less complex data formats such as JSON, whenever
possible
● Upgrade or patch all XML processors and libraries being
used by the application or on the underlying OS
● Disable XXE and DTD processing in all XML Parsers being
used by the application
● Whitelisting
○ server-side input validation, filtering, or sanitization to
prevent hostile data within XML documents, headers, or
nodes.
● Use SAST tools to help detect XXE in source code
31

32. OWASP
A9 - Using Components with
known Vulnerabilities
32
Older versions of components tend to have more known vulnerabilities. These
vulnerabilities can easily be taken advantage of by an attacker

33. OWASP 33
A9 - Using Components with known Vulnerabilities
● Obviously, it’s very easy
to find already-written
exploits, but finding other
vulnerabilities requires
concentrated effort
● Component heavy development
patterns can lead to teams not
understanding which
components they use in their
application/API
● Some scanners (such as
retire.js) help in detection but one
cannot rely on this. Teams must
have full information on what
components and version number
they are using for said project
● The impacts will vary.
Some vulnerabilities
will lead to minor
impacts and some
have the largest
breaches to date
● The risk can jump to
the top of the list
depending on the
assets one is
protecting

34. OWASP
● Vulnerabilities
○ All of them (XSS, XXE, RCE, Buffer Overflow…… )
○ Lack of a Bill of Materials for application components
○ Lack of risk re-evaluations; new risk discovered every day
● The underlying vulnerability is a general lack of a component
management strategy.
A9 - Using Components with known Vulnerabilities
3434

35. OWASP
● There are many components whose older versions have blatant
vulnerabilities
○ CVE-2017-5638, CVSS 10 - Struts (Equifax ) - RCE.
■ 20% of organizations are actively using it
○ CVE-2010-1632 - CVSS 7 - Axis2 - DoS
■ 50% of organizations are actively using it
● Components age like milk; not wine
A9 - Using Components with known Vulnerabilities - Example
35

36. OWASP
A9 - Components Age Like Milk
36
● Components older than 2 years:
● Account for 62% of all components
● Account for 77% of the security risk
● Are likely inactive
● Application vulnerability density is 6.8 %

37. OWASP
A9 - The Developer Ask
37

38. OWASP
A9 - Vulnerable Components - Try It
38

39. OWASP
● Ways of defending include
○ Removing unused dependencies, unnecessary features, components, files, and
documentation
○ Continuously inventory the versions of both client-side and server-side components
(e.g. frameworks, libraries) and their dependencies
■ You can use tools such as versions, DependencyCheck, retire.js, to complete
this process.
○ Only obtain components from official sources over secure links.
● Every organization must ensure that there is an ongoing plan for monitoring, triaging, and
applying updates or configuration changes for the lifetime of the application.
A9 - Using Components with known Vulnerabilities - Defense Mechanisms
39