Common WebApp Vulnerabilities and What to Do About Them
3 likes1,397 views
This document discusses common web security threats and how to defend against them. It begins by introducing common threats like injection attacks, authentication issues, and sensitive data exposure. It then details the OWASP Top 10 list of most critical web application security risks, which include injection, cross-site scripting, insecure object references, and more. The document recommends defenses like input validation, access control, encryption, and keeping systems up to date. It emphasizes that attacks usually combine multiple vulnerabilities and simplicity is key to security. Useful tools for analyzing threats are also presented.
Common WebApp Vulnerabilities and What to Do About Them
- 1. QUALITY. PRODUCTIVITY. INNOVATION. endava.com Common Web Security Threats ⊠and what to do about them Eoin Woods Endava
- 2. 3 3 Introductions Eoin Woods âą CTO at Endava âą Career has spanned products and applications âą Architecture and software engineering âą Bull, Sybase, InterTrust âą BGI (Barclays) and UBS âą Long time security dabbler âą Increasingly concerned at cyber threat for ânormalâ systems
- 5. 6 6 Web Security Threats We need systems that are dependable in the face of âą Malice âą Error âą Mischance People are sometimes bad, stupid or just unlucky System security aims to mitigate these situations
- 6. 7 7 Web Security Threats System threats are similar to real-world threats: âą Theft âą Fraud âą Destruction âą Disruption Anything of value may attract unwelcome attention âI rob banks because thatâs where the money isâ â Willie Sutton
- 7. 8 8 Web Security Threats Why do we care about these threats? âą A threat is a risk of a loss of some sort Common types of loss are: âą Time âą Money âą Privacy âą Reputation âą Advantage
- 8. 9 Web Security Threats Security today mitigates tomorrowâs threat Digital channels demand web security âą System interfaces on the Internet âą Introspection of APIs âą Attacks being âweaponisedâ âą Todayâs internal app is tomorrowâs âdigital channelâ
- 9. 10 10 Who are OWASP? The Open Web Application Security Project âą Largely volunteer organisation, largely online Exists to improve the state of software security âą Research, tools, guidance, standards âą Runs local chapters for face to face meetings (UK has 10+) âOWASP Top 10â project lists top application security risks âą Referenced widely by MITRE, PCI DSS and similar âą Updated every few years (2003, 2004, 2007, 2010, 2013)
- 10. 11 11 Other Selected Security Organisations MITRE Corporation âą Common Vulnerabilities and Exposures (CVE) âą Common Weaknesses Enumeration (CWE) SAFECode âą Fundamental Practices for Secure Software Development âą Training There are a lot of others too (CPNI, CERT, CIS, ISSA, âŠ)
- 13. 14 14 #1 Injection Attacks Unvalidated input passed to an interpreter âą Operating system and SQL are most common Defences include âescapingâ inputs, bind variables, using white lists, ⊠SELECT * from table1 where name = â%1â Set â%1â to â OR 1=1 -- ⊠this results in this query: SELECT * FROM table1 WHERE name = â â OR 1=1 --
- 14. 15 15 #2 Broken Authentication or Session Management âą HTTP is stateless - some sort of credential sent every time âą Credential on non-TLS connection can be tampered with âą Session ID often displayed but can be used as login details âą Defences are strong authentication and session management controls a5f3dd56ff32 a5f3dd56ee33
- 15. 16 16 #3 Cross Site Scripting âą Occurs when script is injected into a userâs web page âą Reflected attack â crafted link in email ⊠⹠Persistent attack - database records, site postings, activity listings âą Allows redirection, session data stealing, page corruption, ⊠⹠Defences include validation and escaping on the server-side http://www.veracode.com/security/xss
- 16. 17 17 #4 Insecure Direct Object Refs Directly referencing filenames, IDs and similar in requests ⹠Not authenticating access to each on the server ⹠e.g. relying on limited list of options returned to client ⹠Client can modify request and gain access to other objects Defences include using pseudo references on client and authenticating all object accesses http://mysite.com/view?id=file1.txt ⊠how about: http://mysite.com/view?id=../robots.txt ??
- 17. 18 18 #5 Security Misconfiguration Security configuration is often complicated âą Many different places to put it, complex semantics âą Layers from OS to application all need to be consistent It is easy to accidentally miss an important part âą OS file permissions? âą .htaccess files? âą Shared credentials in test and production? Allows accidental access to resources or even site modification Mitigation via scanning, standardisation, simplicity and automation
- 19. 20 20 #7 Function Level Access Control Relying on information sent to the client for access control âą e.g. page menu omitting âupdateâ and âdeleteâ option for a record âą Not checking the action (function) being performed on the server Client can guess the right request form for the other actions âą Bypassed security model - also see #4 Insecure Object References Never trust the client - check authorisation for every request http://www.example.com/gettxn?txnid=4567 Ă http://www.example.com/updttxn?tid=4567&value=100.00
- 20. 21 21 #8 Cross Site Request Forgery User triggers malicious code that submits fraudulent request using browser security context âą e.g. click a link => run JavaScript => change Github password Various subtle variations on this make defence quite difficult âą How you do you know it is the user? Primary defence is the âchallenge valueâ in pages âą Check for the latest challenge value in requests âą Add authentication steps for sensitive operations âą Keep short sessions with real logout process
- 22. 23 23 #9 Known Vulnerable Components Many commonly used components have vulnerabilities âą See weekly US-CERT list for a frightening reality check! âą Much OSS doesnât have well researched vulnerabilities Few teams consider security of their 3rd party components âą And keeping everything up to date is disruptive Consider automated scanning of 3rd party components, actively review vulnerability lists, keep components patched
- 23. 24 24 #10 Unvalidated Redirects and Forwards Redirecting or forwarding to targets based on parameters Avoid using parameters for redirect or forward targets Where parameter is needed use a key and map on server http://www.mysite.com/selectpage?pageid=emea_home.html -> http://âŠ/selectpage?pageid=pishinghome.com (Without careful validation this redirects user to malicious page)
- 24. 25 25 Summary of Attack Vector Types Interpreter injections ⹠Operating System, SQL, ⊠Page injections ⹠HTML, XSS (JavaScript) Lack of Validation ⹠trusting client side restrictions ⹠allowing session IDs and cookies to be reused, ⹠not checking input fields thoroughly ⹠parameter values directly in pages and links Missing data protection ⹠data loss, spoofing, man in the middle, ⊠Platform ⹠configuration mistakes, vulnerabilities, complexity
- 25. Useful Tools
- 26. 27 âą Deliberately insecure LAMP web application âą So run in a VM! âą Provides examples of the OWASP Top 10 in action âą Use it to explore and understand them Mutillidae www.irongeek.com http://sourceforge.net/projects/mutillidae/
- 27. 28 ⹠Commercial proxy, scanning, pentest tool ⹠Very capable free version available ⹠Inspect traffic, manipulate headers and content, ⊠⹠Made in Knutsford! BurpSuite http://portswigger.net/burp
- 28. 29 âą Chrome and SwitchySharp or other similar pairing âą Allows easy switching of proxy server to BurpSuite Browser and Proxy Switcher
- 29. 30 âą Automated SQL injection and database pentest tool âą Open source Python based command line tool âą Frighteningly effective! SQLMap http://sqlmap.org
- 30. 31 âą Commercial tool suite with online database âą Scans build pipelines for component security vulnerabilities âą Alerts and dashboards for monitoring Sonatype Component Lifecycle Manager http://www.sonatype.com/nexus
- 31. 32 32 BlackDuck Hub âą Commercial tool and database for open source security, audit & compliance âą Scans build pipelines looking for open source with known vulnerabilities âą Alerts and dashboards for monitoring https://www.blackducksoftware.com
- 32. Demonstrations
- 36. 37 37 Key Web Vulnerability Defences Donât trust clients (browsers) âą Validation, authorisation, ⊠Identify âinterpretersâ, escape inputs, use bind variables, ⊠⹠Command lines, web pages, database queries, ⊠Protect valuable information at rest and in transit âą Use encryption judiciously Simplicity âą Verify configuration and correctness Standardise and Automate âą Force consistency, avoid configuration errors
- 37. 38 38 Donât Trust Clients Be wary when trusting anything from a browser âą You donât control it âą Sophisticated code execution (& injection) platform âą Output can be manipulated Assume or prevent tampering âą TLS connections to avoid 3rd party interception âą Short lived sessions âą Reauthenticate regularly & before sensitive operations âą Consider multi-factor authentication âą Use opaque tokens not real object references for params âą Validate everything
- 38. 39 39 Watch out for injection Many pieces of software act as interpreters âą Browser for HTML and JavaScript âą Operating system shells â system(âmv $1 $2â) âą Databases â query languages âą Configuration files Assume that someone will work it out! âą Avoid creating commands using string manipulation âą Use libraries and bind variables âą Escape all strings being passed to an âinterpreterâ âą Use a third party âescapingâ library (e.g. OWASP) âą Reject excessively long strings (e.g. username > 30 char)
- 39. 40 40 Protect Valuable Information Defence in depth â assume perimeter breach âą Encrypt messaging as standard âą Consider database encryption âą Consider file or filesystem encryption However encryption complicates using the data âą Slows everything down âą Can you query while encrypted? âą Message routing on sensitive fields (in headers) âą How do you manage and rotate the keys? âą What about restore on disaster recovery? http://getacoder.com http://slate.com
- 40. 41 41 Simplicity & Standardisation Complexity is the enemy of security âą âYou canât secure what you donât understandâ - Schneier âą Special cases will be forgotten Simplify, Standardise and Automate âą Simpler things are easier to check and secure âą Standardising an approach means there are no special cases to forget to handle âą Automation eliminates human inconsistencies from the process so avoiding a type of risk http://innovationmanagement.se/
- 41. Summary
- 42. 43 43 Summary Much of the technology we use is inherently insecure ⹠Mitigation needs to be part of application development Attacking systems is becoming industrialised ⹠Digital transformation is providing more valuable, insecure targets Fundamental attack vectors appear again and again ⹠Injection, interception, page manipulation, validation, configuration, ⊠Most real attacks exploit a series of vulnerabilities ⹠Each vulnerability may not look serious, the combination is Most mitigations not difficult but need to be applied consistently ⹠⊠and may conflict with other desirable qualities
- 43. 44 44 Books