Recommended
More Related Content
What's hot
Similar to Lightning talk owasp_top10in10
Similar to Lightning talk owasp_top10in10 (20)
Recently uploaded
Recently uploaded (20)
Lightning talk owasp_top10in10
- 1. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 1 Agility. Security. Delivered. How to test for (the new) OWASP Top 10 in 10 Minutes? An all out sprint by Ben Pick
- 2. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 2
- 3. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 3 A1 - Injection Username: Password: admin myPassword select * from Users where user_id = ‘admin’ and password = ‘myPassword’ Username: Password: ‘ OR 1=1; -- myPassword select * from Users where user_id = ‘’ OR 1=1; -- and password = ‘myPassword’ <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>
- 4. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 4 A1 - Injection, tools
- 5. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 5 A2 - Broken Authentication and Session Management • http://example.com/sale/mycart?sessionid=abcd • http://internalcompanyHRservice.com/search?role=user • Cookie replay from valid session
- 6. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 6 A3 - Cross Site Scripting (XSS) • Client-side scripts interpreted by the end user <script>alert(‘Label XSSed’)</script> <script>alert(123)</script> <script>alert(document.cookie)</script>
- 7. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 7 A3 – XSS, Tools
- 8. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 8 A4 - Broken Access Controls • http://example.com/app/accountInfo?acct=notmyacct • https://example.com/auth • https://example.com/myprofile?action=updatepassword • https://example.com/admin
- 9. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 9 A5 - Security Misconfigurations • Look for default passwords!
- 10. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 10 A6 - Sensitive Data Exposure • Look for stacktraces, relative or absolute directory structures, listings of running software and versions • User objects that include name, SSN, DoB, address… • IP addresses, usernames, and os information in source code • View page source
- 11. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 11 A7 – Insufficient Attack Protections • Detect • Prevent • Patch
- 12. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 12 A8 - Cross Site Request Forgery • www.bank.com/transfermymoney=-1000&toaccount=maliciousBen
- 13. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 13 A9 - Using issues with known vulnerabilities • Vulnerable components = vulnerable application
- 14. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 14 A10 – Underprotected APIs • http://www.example.com/supersecretendpoint?internalfile=notmine • http://www.example.com/deleteaccount?acct=12345
- 15. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 15 Summary – Good Security Testing • Send garbage input • Malicious content • Attempt to obfuscate to avoid detection • Try to break frameworks and processes • Do the unexpected • Play “What if” with the application • Assume a service or server is compromised and determine the impact
- 16. © COPYRIGHT 2017 COVEROS, INC. ALL RIGHTS RESERVED. 16 Supplemental Notes: Tools Mentioned • Static Analysis • SonarQube • HP Fortify • Sonatype CLM • OWASP Dependency Check • Dynamic Analysis: • sqlmap • Wfuzz • w3af • Burp Suite (Free or Professional) • OWASP Zed Attack Proxy • SOAP UI • ModSecurity • Wireshark • Contrast RASP
Editor's Notes
- * The tools and processes I recommend are simply things which I have used on my projects or personal research which worked for me. There are many additional alternatives out there and I try to include both open source and commercial products. Intro into Coveros -> local software company who specializes in creating secure code and DevOps solutions Focus on tools, less on techniques. Not in depth -> list tools instead Ending -> now here is another related talk (Coveros presents) I will be available after the talk to answer some questions. And If you like what you heard here, please attend the talk X about Y… Before leaving for Japan, drop presentation onto Google drive in case Gene needs to take care of anything
- What is the OWASP Top 10? It is a list of vulnerabilities created by security professionals to define the most critical security risks. There are multiple top 10 OWASP lists, but their flagship list is the OWASP Top 10 Most Critical Web Application Security Risks. This talk highlights the release candidate for 2017. Although this candidate was recently rejected, the vulnerabilities have not changed drastically throughout the years and the methods of detection and the tools used will provide a stronger security posture for your applications
- Yeah. This slide is a little light. I’ve found a lot of issues with scanning tools and determining correctly if sql injection is possible and if so, how or what may be gained. Manual testing is important and you need to understand how SQL injection works, but the initial steps may be automated with a tool, such as Sqlmap. As the name implies, sqlmap focuses on sql injection attempts. To expand on the security tests performed, why not also use Wfuzz, a web application bruteforcing tool which attempts to find and exploit various known issues. In terms of xxe, that really requires an in depth knowledge of how data is stored and passed within the application.
- The OWASP Zed Attack Proxy, or ZAP for short, and Burp Suite Professional will attempt to find available web pages and fuzz data entry points. However, a tool can only take you so far. You can also use Wfuzz or a similar tool. However, these are only an initial step. The tester must attempt to break the business logic of an application. Meaning the responsibility for testing this should fall on someone very familiar with the target application. Running a blind scan may be as detrimental as not running a scan at all. Manual testing scenarios: attempt to break password reset functions. Or login as an administrator, record the pages traversed and attempt to reach them as a lower privileged user
- Mention obfuscation
- This is the fist slide where I really highlight ZAP and Burp because it’s the first slide where they tend to do well. These tools attempt to find where injection may be possible, but I have found those instances to be full of false positives in identifying a legitimate SQL injection vulnerability as opposed to just a part of the application which interacts with the database. Likewise for broken authentication, I have found these tools can quickly iterate through known or common authentication issues, but that they are incapable of a deep dive into an underlying business logic flaw. These tools to tend to do a great job at identifying XSS instances and in iterating through a wide library of vulnerabilities to verify if they vulnerability is exploitable.
- Formerly Insecure Direct Object References and Missing Function Level Access Control Much like authentication, tools, such as Burp and Zap attempt to break or identify weak access controls. These must also be supplemented with manual testing. Manual testing: I like running through 4 different steps to test access. Login as an administrator and browse to a critical file and perform an admin function Login as a regular user and attempt to access the file and admin function. Browse around to find a personal file for this account and perform a process unique to this user Login as another regular user, preferably with different credentials or access rights, and attempt to access the other regular user’s personal file and perform the process unique to that user. Also attempt to perform previously identified admin functions Access web app as an unauthenticated user. Attempt to reach and perform all of the above files and functions.
- Use Nessus to check for default configurations For those familiar with the recent Equifax compromise, it came to light that in Argentina, their privileges accounts used admin/admin as its username/password.
- It may not be returned in the gui, but review requests and responses to ensure data is not bleeding unnecessarily. Multipronged approach: static – sonarqube and fortify Dynamic – burp and zap and nikto and wireshark (bleeding sensitive data) Logging – splunk, This may be addressed by a two pronged approach. Review source code for objects containing sensitive data and check dynamically for sensitive data being used. Static analysis tools, such as SonarQube and HP Fortify will search within the code for potential vulnerabilities. Dynamic tools, such as Burp or ZAP will check for sensitive exposures in the deployed application. A logging or monitoring tool, such as Splunk, will alert on strings which appear to contain sensitive data based on regular expressions.
- “Detection is ideal, but prevention is a must” There are countless Host and Network Intrusion Detection services. My only recommendation is to read all of the fine print of every contract and I’m not going down that rabbit hole right now. Since this is the OWASP talk, I’ll mention one of their flagship projects, ModSecurity. This is a versatile and useful method of detecting and preventing when malicious activity is detected. That being said, all you need is a simple network monitoring tool such as wireshark to review communication across your network and gain an understanding of what is expected. This can help you create a baseline and identify when any anomalous traffic is generated.
- Blocked by using randomized tokens within body of request Burp and Zap can check for CSRF weaknesses. However, full exploitation and vulnerability assessments require manual review and testing. Issues I have observed which tools have failed to detect: csrf being constant throughout a session or the same for repeated sessions. Most tools will only check that a CSRF token exists. They do not track this value by default or perform sufficient testing to prove its predictability.
- Sonatype CLM OWASP Dependency Check Contrast’s RASP Equifax with struts2 Wannacry and its many variations ransomware attacks through samba
- New Category. This was rejected, but I have included it here because I routinely find this as a valid finding. Also, this is, in many ways, an extension of the old finding: Failure to restrict URL access. sSome of the endpoints I test have no validation performed on the passed user input. Not to be paranoid, but everything is connected. Soap UI