Recommended
More Related Content
What's hot
What's hot (19)
Similar to Application Security and the OWASP Top 10
Similar to Application Security and the OWASP Top 10 (20)
Recently uploaded
Recently uploaded (20)
Application Security and the OWASP Top 10
- 1. Application Security and the OWASP Top 10 2017 Diarmaid McGowan June 9th 2018
- 2. Statistics This presentation includes material from "OWASP Top Ten 2017 Project” by "OWASP", made available under Creative Commons Attribution-ShareAlike License.
- 3. TLA and FLA SAST – Static application security testing (Source Code Analysis) DAST - Dynamic application security testing CVE - Common Vulnerabilities and Exposures CWE - Common Weakness Enumeration NIST - National Institute of Standards and Technology (US) NVD – National Vulnerability Database (NIST) GDPR - General Data Protection Regulation PCI DSS - Payment Card Industry Data Security Standard PII - Personally identifiable information
- 4. “Even without changing a single line of your application's code, you may become vulnerable as new flaws are discovered and attack methods are refined.”
- 5. 2013 to 2017 - What changed
- 6. What are application security risks?
- 10. A3: Sensitive Data Exposure
- 11. A4: XML External Entities (XXE)
- 12. A5: Broken Access Control
- 14. A7: Cross-Site Scripting (XSS)
- 16. A9: Using Components with Known Vulnerabilities
- 17. A10: Insufficient Logging & Monitoring
- 18. Top 10 Risk Factor Summary
- 19. Next steps Don’t stop at Top 10 What’s Next for different users … Cheat Sheets OWASP Education Project ASVS – Application Security Verification Standard
- 20. Tools OWASP ZAP Zed Attack Proxy Project OWASP WebGoat Project OWASP Juice Shop
Editor's Notes
- I work in Allstate Northern Ireland and was part of Allstate’s 1st cohort in CompoZedLabs My background is software Engineering and I moved into Application Security Engineer role toward end of 2017. How many of you have heard of OWASP? or know about OWASP? To get some context. Brilliant
- OWASP stands for Open Web Application Security Project Its a non-profit entity which ensures the project's long-term success. Its not affiliated with any technology company, although they do support the informed use of commercial security technology. The top 10 is a guide for managing software application common security risks This talk is based on the OWASP Top 10 2017 which is published by OWASP and made available under Creative Commons license OWASP provides a lot of free and open resources including: Application security tools and standards. Complete books on application security testing, secure code development, and secure code review. Presentations and videos. Cheat sheets on many common topics including todays topics Standard security controls and libraries. etc. Local chapters worldwide. Cutting edge research. Extensive conferences worldwide. Mailing lists.
- Some of the things that caught me at start were TLA (Three Letter Acronyms) FLA (Four Letter Acronyms) SAST https://www.owasp.org/index.php/Source_Code_Analysis_Tools DAST https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools CVE https://cve.mitre.org/ CWE https://cwe.mitre.org/ NIST https://www.nist.gov/ NVD NIST Vulnerability Repository ICAT (2000) Internet - Categorization of Attacks Toolkit GDPR https://www.eugdpr.org/ Came in last month CVSS - Common Vulnerability Scoring System
- I like this quote (Source: OWASP Top 10) In “Roadmap for future activies” under “Constant Change” Constant change. The OWASP Top 10 will continue to change. Even without changing a single line of your application's code, you may become vulnerable as new flaws are discovered and attack methods are refined. CVE-2017-5638 Struts https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638 “The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via a crafted Content-Type, Content-Disposition, or Content-Length HTTP header, In the wild in March 2017 with a Content-Type header containing a #cmd= string.”
- Original goal: was to raise awareness among developers and managers - however it has become the defacto application security standard However if you need a standard you should look towards ASVS - Application .... Over the last few years, the fundamental technology and architecture of applications has changed significantly: Microservices written in node.js and Spring Boot etc. are replacing traditional monolithic applications. Microservices come with their own security challenges which include establishing trust between microservices, containers, secret management, etc. Old code never expected to be accessible from the Internet is now sitting behind an API or RESTful web service to be consumed by Single Page Applications (SPAs) and mobile applications. Architectural assumptions by the code, such as trusted callers, are no longer valid. Single page applications, written in JavaScript frameworks such as Angular and React (and others), allow the creation of highly modular feature-rich front ends. Client-side functionality that has traditionally been delivered server-side brings its own security challenges. JavaScript is now the primary language of the web with node.js running server side and modern web frameworks such as Bootstrap, Electron, Angular, and React running on the client. A4 and A7 merged to A5 A8 CSRF dropped (17 I think) - ReactJS - Shadow or Virtual dom A10 dropped 3 new - A4 and A8 and a10
- Attack surface of the application There are many potential different paths through your application that may be used to harm your business (That may or may NOT warrant attention). Sometimes these paths are trivial to find and exploit, and sometimes they are extremely difficult. Similarly, the harm that is caused may be of no consequence, or it may put you out of business. To determine the risk to your organization, you can evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to your organization. Together, these factors determine your overall risk.
- OWASP Risk Rating Methodology Full details in https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology OWASP Risk Rating Methodology – now part of new OWASP Testing Guide v4 OWASP uses this to score and rank the Top 10 So with this lets get started …
- Unchanged from #1 – Almost fell from top spot – only for NoSQL DBs (could have been #4) Covers more than SQL injection – also command injection, LDAP injection etc. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. SQL injection impact is huge. Shellshock – bash shells through to 4.3 (CVE-2014-6271).
- Unchanged from #2 Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently. We as humans are really bad at passwords Permits Brute force attacks Credentials stuffing - list valid usernames and passwords Allows weak passwords or uses weak session management No MFA (multi factor auth) Logout not implemented correctly Fix Use Multi factor auth (MFA) Check for Weak Password Limit failed login attempts session management - high entrophy - cleanup
- Up from #6 in 2013 to #3 Determine Protection needs for data at rest and data in transit GDPR, PII - PCI etc. GDPR was a large consideration for this Equifax Ceo sent 23,000 private keys Transport layer security – Use HTTPS enforce TLS for all pages with strong ciphers Look out for weak crypto algorithms – weak ciphers Eg. App used automatic DB encryption - so data is auto decrypted on retrieval - if there is a SQLi flaw all data can be stole. No defence in depth Eg Password DB uses unsalted or simple hashes to store passwords. Soln. Dont store sensitive information unnecessarily - eg payment info - disguard as soon as finished with. Data that is not stored cannot be stole Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
- New category – primarily supported by SAST - source code analysis tools (security testing tools) XML parsers 2014 and before vulnerable Easiest way is to upload a malicious XML file - OWASP have an example in the doc SAST tools (Static application security testing (Source Code Analysis)) can help detect XXE in source Patch - Update - Upgrade - SOAP - update to SOAP 1.2 if you are using SOAP Implement whitelisting Use less complex data formats such as JSON and avoid serialization of sensitive data Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
- New category Created by Merging A4 – Insecure Direct Object References – change the url A7 – Missing Function Level Access Control SAST – Static application security testing (Source Code Analysis) and DAST - Dynamic application security testing can detect absence of access control - but cant determine if its functioning correctly if it does exist. Has to be manual (or show me the AI that can do it?) Bypassing access control Force browsing - directly to page without authentication Allowing primary key to be changed Elevation of privilege Metadata manipulation - JWT or cookie CORS misconfiguration - allows API access Fix: Deny by default (exception public resources) Disable web server directory listing Log Access Control failures Rate limit API Invalidate JWT tokens on logout Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users’ data, change access rights, etc.
- Down from #5 in 2013 Security misconfiguration is the most commonly seen issue. default settings are insecure (certain applications/providers are worse than others at this) Eg App Server comes with sample apps - they are not removed These apps have flaws which attackers use to compromise server If 1 of these apps can provide admin access - game over. Repeatable Hardening process - CI and CD - and tests Remove or dont install unneed features/frameworks/libraries. Use segmented app architecture CSP (Content Security Policy) incorrectly configured HTTP Headers – ensure set correctly Security misconfiguration is the most commonly seen issue. This 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 information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion.
- Down from #3 in 2013 – its thought mainly because of the frameworks protections – Eg. ReactJS and Angular etc. XSS is 2nd most prevalent issue in Top 10. Exists in around 2 thirds of all applications. Three forms Reflected XSS Stored XSS DOM XSS Typically user has to interact with a malicious link provided by the attacker. Fix: Use frameworks that have protection - eg. ReactJS Angular etc. Enable a CSP (Content Security Policy) as defence in depth measure XSS flaws occur whenever 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. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
- New – from Community - included based on industry survey Somewhat difficult to exploit Some tools can detect - however human assistance is required to validate the problem. It can lead to Remote code execution which is one of the most serious attacks possible. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
- Unchanged from 2013 Prevalence is widespread. Most breaches rook cause can be traced back to this. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. Patch, Monitor, Update, Upgrade – repeat Change CI CD pipeline to break the build if a component with a vulnerability exists – eg OWSP Dependancy Check Eg 1 WannaCry ransomware attack was a May 2017 Microsoft had released patches previously to close the exploit, much of WannaCry's spread was from organizations that had not applied these patches, or were using older Windows systems that were past their end-of-life - Windows XP Eg 2 The Struts example at the start - If are still using STRUTS and have not updated the version - you are vulnerable
- New – from Community - included based on industry survey In 2016, identifying a breach took an average of 191 days from when it happened to when it was identified. Can you imagine how much damage can be done in that time? Over half a year. Simply logging and storing logs is not enough. Logs MUST be monitored and alarms raised and notifications occur when required. Ensure Audit trails exist with integrity controls to prevent tampering (especially for high value transactions) Log all failues Have an incident response and recovery plan There are commercial and open source application protection frameworks such as OWASP AppSensor Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
- This is OWASP Risk Factor Summary. To understand these risks for a particular application or organization, you must consider your own specific threat agents and business impacts. My Risks are probably not the same as yours – Allstate Northern Ireland Risks are not the same as Queens University Belfast Risks Even some severe software weaknesses may not present a serious risk if there are no threat agents in a position to perform the necessary attack or if the business impact is negligible for the assets involved. There is no hard and fast rules
- CSRF fell out of top 10 – sits at #17 Injection would have fallen from #1 only for NoSQL DBs OWASP have a range of next steps for different users What’s next for Developers - https://www.owasp.org/index.php/Top_10-2017_What%27s_Next_for_Developers What’s next for Security Testers https://www.owasp.org/index.php/Top_10-2017_What%27s_Next_for_Security_Testers What’s next for Organizations, suitable for CIOs and CISOs - https://www.owasp.org/index.php/Top_10-2017_What%27s_Next_for_Organizations What’s next for Application Managers (anyone responsible for the lifecycle of the application) - https://www.owasp.org/index.php/Top_10-2017_What%27s_Next_for_Application_Managers Cheat sheets - 76 pages on the website ASVS – Application Security Verification Standard https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project https://www.owasp.org/index.php/Category:OWASP_Education_Project OWASP Testing Guide
- ZAP – Interception proxy – DAST capabilities WebGoat – old Juice Shop – new deliberately vulnerable – on github
- https://twitter.com/diarmaidmcgowan https://twitter.com/AllstateNI https://twitter.com/CompozedLabs