New Vulnerabilities introduced in OWASP Top 10 2017. Cover Broken Access Control , XML External Entities (XXE), Insecure Deserialization, and Insufficient Logging & Monitoring, as well as solutions

1. Dilum Bandara, PhD
Some content extracted from “OWASP Top 10 - 2017: The Ten
Most Critical Web Application Security Risks” by https://owasp.org

2.  Open Web Application Security Project
 OWASP Top 10 is an awareness document for:
 Web application security
 Mobile app security
 Represents broad consensus about the most critical security
risks
 Based on feedback from security experts around the world
 Adopting OWASP Top 10 reduces most of your security
headaches
 Effective 1st step towards a secure software development culture
2

3. 3

4. 4
Source: http://dunnesec.com

5. 5

6. When authentication is broken
Authentication used but not properly implemented
or enforced
2 types
Insecure Direct Object References
Missing Function Level Access Control
6

7. 7
Source:
http://lazarusalliance.com/test
-your-owasp-knowledge/

8. http://webapp.com/app/accountInfo?acct=admin
String sqlquery = "SELECT * FROM useraccounts WHERE
account = ?";
PreparedStatement st =
connection.prepareStatement(sqlquery , � );
st.setString(1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );
When developer exposes a reference to an internal implementation
object, such as a file, account no, directory, or database key without
any validation 8

9.  Check access control – even at record level
 Use only one user or session for indirect object references
 Hash map of objects, e.g., account ID
 Disable web server directory listing
 JSON Web Token (JWT) should be invalidated after logout
 Resources
 Example
 http://www.tutorialspoint.com/security_testing/insecure_direct_object_reference.htm
 Top 10 2007-Insecure Direct Object Reference
 https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference
 Testing for Insecure Direct Object References
 https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_%28OTG
-AUTHZ-004%29
9

10.  Due to improper authorization
10Source: www.slideshare.net/appsec/19-owasp-top-10-a7missing-function-level-access-control

11.  Authenticate & authorize every form/request
 Deny everything else
 Implement access control in one place, then reuse
 Rate limit API calls
 Resources
 Example
 http://www.tutorialspoint.com/security_testing/missing_function_level_access_con
trol.htm
 Failure to Restrict URL Access
 https://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access
 Guide to Authorization
 https://www.owasp.org/index.php/Guide_to_Authorization
11

12. Exploiting vulnerable XML processors by uploading XML
or including hostile content in an XML document
 When invalidated data is used to form an XML
Applicable to XML-based Web-Services or Integrations
Exploited via Document Type Definitions (DTDs)
Can be used to extract data, execute remote requests on
server, scan internal systems, perform DoS, etc.
12

13. <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >
]>
<foo>&xxe;</foo>
13
<!ENTITY xxe SYSTEM "https://192.168.1.1/private">
<!ENTITY xxe SYSTEM "file:///dev/random">

14.  Use less complex data formats such as JSON
 Avoiding serialization of sensitive data
 Patch or upgrade all XML processors
 Update SOAP to v1.2 or higher
 Disable XML external entity and DTD processing
 Java XML parsers typically have XXE enabled, but .Net ones not
 Server-side input validation, filtering, or sanitization
 Verify XML or XSL file upload functionality validates incoming XML
 Resources
 https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_
Sheet
14

15. Exploiting vulnerable Application & APIs by deserializing
hostile or tampered objects
Attack is bit difficult to execute though deserialization is
common
Once executed, cloud lead to
 Data tampering attacks
 Remote code execution (high impact)
15

16. Super cookie, containing user ID, role, password hash, &
other state
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Attacker changes serialized object to get admin privileges
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
16

17.  Validate all inputs
 Don't accept serialized objects from untrusted sources
 Serialize mediums that only permit primitive data types
 Enforcing strict type constraints
 Use integrity checks such as digital signatures on serialized objects
 Isolate & run code that deserializes in low privilege environments
 Log deserialization exceptions & failures
 Resources
 https://www.owasp.org/index.php/Deserialization_Cheat_Sheet
17

18. Attackers rely on lack of monitoring & timely response to
achieve their goals
 In 2016, identifying a breach took an average of 191 days
Successful attacks start with vulnerability probing
 E.g., repeatedly trying passwords
Allowing probes to continue raise likelihood of successful
exploit
18

19.  Auditable events, e.g., logins, failed logins, & high-value transactions aren't
logged
 Warnings & errors generate no, inadequate, or unclear log messages
 Logs of applications & APIs aren't monitored for suspicious activity
 Logs are only stored locally
 Alerting thresholds & response escalation processes aren't in place or
effective
 Penetration testing and scans by DAST tools don't trigger alerts
 Application is unable to detect, escalate, or alert for active attacks in (real)
time
 Information leakage, if you make logging & alerting events visible to users
19

20. Ensure all login, access, & server-side input validation
failures are logged with sufficient user context
 Enable identifying suspicious/malicious accounts
 Held for sufficient time to allow delayed forensic analysis
All logs should be generated in a common format
 Use an extensible logging framework
 Support a centralized log management solution
High-value transactions need audit trail with integrity
controls
 Prevent tampering or deletion, e.g., append-only database tables
Not to log too much, or too little
 Log timestamp, source IP, user ID 20

21. Examine logs following penetration testing
Establish effective monitoring & alerting respond timely
 Automatic account lockout after multiple failures
Establish or adopt an incident response and recovery plan
Use a Web Application Firewall (WAF)
Resources
 https://www.owasp.org/images/9/9b/OWASP_Top_10_Proactive_Control
s_V2.pdf
21

22. 22
•Misuse of platform security controls, keychainM1 - Improper Platform Usage
•Insecure data storage & unintended data leakageM2 - Insecure Data Storage
•Poor handshaking, incorrect SSL versions/use, & weak
negotiation
M3 - Insecure Communication
•Bad authentication & session managementM4 - Insecure Authentication
•Cryptography used, but not implemented correctlyM5 -Insufficient Cryptography
•Insufficient authorization on client sideM6- Insecure Authorization
•Untrusted inputs, buffer overflows (iOS), format string
vulnerabilities, & code-level mistakes
M7 - Client Code Quality
•Binary patching, resource modification, method
hooking/swizzling, & memory modification
M8- Code Tampering
•Analysis of binary to determine code, libraries, algorithms,
& keys
M9 - Reverse Engineering
•Backdoors, commented passwords, & disabling of 2-factor
authentication for testing
M10 - Extraneous Functionality

23. dilumb@99x.lk