The OWASP team recently released the 2017 revised version of the ten most critical web application security risks. This presentation brief the OWASP Top 10 - 2017 for you to learn more about these important security issues.

1. OWASP Top 10 - 2017
Kun-Da Wu
2017.12.20

2. Outline
● Background
● What are changed?
● What are remainings?
● Observations

3. What is
OWASP?

4. Open Web Application Security Project (OWASP)
● International non-profit
Project to make web
applications more secure
● Independent, reputable
● Key goals
○ Awareness
○ Testing
○ Training

5. OWASP Top 10 Project
● One important output of OWASP
● An awareness document focus on identifying
most serious risks for a wide range of
organizations
2013/06/12
OWASP Top 10 - 2013 Final
Release
2017/05/20
OWASP Top 10 -2017
Data Call Announced
2017/10/20
OWASP Top 10 -2017
RC2 Published
2017/11/20
OWASP Top 10 -2017
Final Release

6. What changed from
2013 to 2017?
3 New Issues
1 Merged Issues
2 Retired Issues

7. What Changed from 2013 to 2017? - New Issues

8. What Changed from 2013 to 2017? - New Issues
Allows attackers to exploit vulnerable
XML processors

9. What Changed from 2013 to 2017? - New Issues
Allows attackers to exploit vulnerable
XML processors

10. How To Prevent XML External Entities?
● Use less complex data format such as JSON
● Patch all XML processors and libraries in use
○ Update SOAP to SOAP 1.2 or higher
● Disable XML external entity and DTD processin
● Whitelist server-side input validation
● Verify XML or XSL file upload functionality
● SAST tools can help detect XXE in source code

11. What Changed from 2013 to 2017? - New Issues
Permits remote code execution or
sensitive object manipulation on
affected platforms

12. What Changed from 2013 to 2017? - New Issues
Permits remote code execution or
sensitive object manipulation on
affected platforms

13. How To Prevent Insecure Deserialization?
● Not to accept serialized objects from untrusted sources
● Check integrity on any serialized objects
● Enforce strict type constraints during deserialization
● Isolate to run the deserialized code in low privilege
● Log deserialization exceptions and failures
● Restrict network connectivity from servers that deserialize

14. What Changed from 2013 to 2017? - New Issues
Lack of which can prevent or
significantly delay malicious activity and
breach detection, incident response,
and digital forensics

15. What Changed from 2013 to 2017? - New Issues
Lack of which can prevent or
significantly delay malicious activity and
breach detection, incident response,
and digital forensics
An attacker uses scans for users
using a common password. They can
take over all accounts using this
password.
For all other users, this scan leaves
only one false login behind. After
some days, this may be repeated
with a different password.

16. How To Prevent Insufficient Logging & Monitoring?
● Ensure all access failures can be logged
● Ensure logs are generated in a format that can be easily
consumed
● Ensure high-value transactions have an audit trail
● Establish effective alerting to respond in a timely
fashion
● Establish an incident response process such as NIST 800-
61 rev 2 or later

17. What Changed from 2013 to 2017? - Merged Issues

18. What Changed from 2013 to 2017? - Merged Issues
Considering a SQL call to access
account information
pstmt.setString(1, request.getParameter(“acct”));
ResultSet results = pstmt.executeQuery();
Attacker may simply modifies ‘acct’ in
the browser to send whatever account
number they want.
http://example.com/app/accountinfo?acct=notmyacct

19. How To Prevent Broken Access Control?
● With the exception of public resources, deny by default
● Re-use access control mechanism throughout the application
● Model access controls should enforce record ownership
● Unique business limit requirements should be enforced by domain models
● Disable web server directory listing
● Ensure file metadata, backup files are not presented within web roots
● Log access control failures, alert admins when necessary
● Rate limit API to minimize the harm from auto attack
● JWT tokens should be invalidated after logout

20. What Changed from 2013 to 2017? - Retired Issues
Many frameworks include CSRF
defenses, it was found in only 5%
applications

21. What Changed from 2013 to 2017? - Retired Issues
It was found in < 8% of
applications and edged out of
overall XXE

22. How About
Remainings?

23. NO.1 and NO.2 are Remaining

24. Injection Vulnerability
Occurs when untrusted data is sent to an
interpreter as part of command or query.
The attackers can trick the interpreter into
executing unintended commands

25. Injection Vulnerability
Occurs when untrusted data is sent to an
interpreter as part of command or query.
The attackers can trick the interpreter into
executing unintended commands

26. How To Prevent Injection?
● Keeping data separated from
commands and queries
○ Use a safe API
○ “Whitelist” server-side input
validation
○ Escape special characters using
specific escape syntax for the
interpreter
○ Use LIMIT and other SQL
controls within queries to
prevent mass disclosure of
records

27. Broken Authentication
Application functions related to
authentication and session management
are often implemented incorrectly,
allowing attackers to compromise
passwords, keys or session tokens.

28. Broken Authentication
Application functions related to
authentication and session management
are often implemented incorrectly,
allowing attackers to compromise
passwords, keys or session tokens.

29. How To Prevent Broken Authentication?
● Multi-factor authentication
● DO NOT ship any default
credentials
● Weak password check
● Harden registration,
credential recovery
● Limite or delay failed login
● Not to use Session IDs in
URL

30. Sensitive Data Exposure
Many web apps and APIs do not properly
protect sensitive data. Attackers may steal
or modify such weakly protected data to
conduct credit card fraud, identity theft or
other crimes.

31. Sensitive Data Exposure
Many web apps and APIs do not properly
protect sensitive data. Attackers may steal
or modify such weakly protected data to
conduct credit card fraud, identity theft or
other crimes.

32. How To Prevent Sensitive Data Exposure?
● Classify data processed, stored, or
transmitted by any application
● Apply controls per classification
● Don’t store unnecessary sensitive data
● Encrypt all sensitive data
● Ensure up-to-date and strong standard
algorithms, protocols, and keys are in
place
● Encrypt all data in transit with secure
protocols such as TLS with perfect
forward secrecy (PFS): HSTS
● Disable caching sensitive data
● Store password using strong adaptive
hashing functions such as Argon2,
scrypt, bcrypt, or PBKDF2

33. Security Misconfiguration
Security misconfiguration is commonly a
result of insecure default configurations,
incomplete or ad hoc configurations, open
cloud storage, misconfigured HTTP
headers and verbose error messages
containing sensitive data.

34. Security Misconfiguration
Security misconfiguration is commonly a
result of insecure default configurations,
incomplete or ad hoc configurations, open
cloud storage, misconfigured HTTP
headers and verbose error messages
containing sensitive data.
The application server comes with
sample applications that are not
removed from the production server.
These sample applications have known
security flaws, ex. default accounts
weren’t changed. Attackers may log in
with default passwords and takes over.

35. How To Prevent Security Misconfiguration?
● A repeatable hardening process that make it
fast and easy to deploy another environment
● Development, QA and production environment
should be configured identically with different
credentials used in each environment
● A minimal platform without unnecessary
features, components and samples
● A task to review and update configurations
appropriate to all security updates and patches
as part of patch management process
● A segmented application architecture that
provides effective, secure separations between
components
● An automated process to verify effectiveness of
configurations and settings in all environments

36. Cross-Site Scripting (XSS)
XSS occurs when an application includes
untrusted data in a new web page without
proper validation or escaping, or updates
an existing web page with user-supplied
data using a browser API that can create
HTML or Javascript.

37. Cross-Site Scripting (XSS)
XSS occurs when an application includes
untrusted data in a new web page without
proper validation or escaping, or updates
an existing web page with user-supplied
data using a browser API that can create
HTML or Javascript.

38. How To Prevent Cross-Site Scripting?
● Separate untrusted data from active
browser content
○ Using frameworks that automatically
escape XSS by design such as Ruby on
Rails, React JS
○ Escape untrusted HTTP request data based
on the context in HTML output
○ Enable a Content Security Policy is a
defense-in-depth mitigating control
against XSS

39. Using Components with Known Vulnerabilities
Components such as libraries,
frameworks, and other software modules,
run the same privileges as the
application.If a vulnerable component is
exploited, such an attack can facilitate
serious data loss or server takeover.

40. How To Prevent Using Components with Known Vulnerabilities?
● There should be a patch management
process
○ Remove unused dependencies, features,
components, files and doc
○ Continuously inventory the version of both
client and server components using tools
like versions, DependencyCheck, retire.js
○ Continuously monitor sources like CVE and
NVD for vulnerabilities in components
○ Only obtain components from official
sources over secure links
○ Monitor libraries and components that are
unmaintained or do not create security
patches for older versions

41. Observations ● Observation 1 Tainted data
remains a huge problem, as
we see in A1:Injection
● Observation 2 A3:Sensitive
Data Exposure is a great
place to start
○ For EU GDPR.
○ For any requirements around
privacy like PCI-DSS and
HIPAA.

42. ~ Thank you ~
Q&A