Download to read offline
Demystifying Web Application Security - JSFoo 2018
- 1.
- 2. Today’s Agenda • XSS(Cross Site Scripting) • CSRF (Cross Site Request Forgery) • JSON Attacks • Click-jacking • Click-baiting • PTSD • RSS • …
- 4. THIS IS WHYIT IS HARD TO START LEARNING ABOUT (WEB) SECURITY!
- 5. The Real Agenda. •Evolution of security • Understanding the real threat • Attack vectors • Thinking about security
- 6. About Me What IdoWhat I’ve done What I’ve written
- 7. Life before theinternet!
- 8. Web 1.0 • Serversecurity all that mattered • Standards – XSS – CSRF • We just started figuring these out when…
- 9.
- 10. JS Explosion!! • Everythingthat used to be the realm of the server is now being done on the client • Routing • Business Logic • Access Control (Gasp!!)
- 11.
- 12. Whose job isSecurity anyway?
- 13.
- 14.
- 15. Possible security exploits •OWASP Top 10 • But what about the others? • A new exploit almost every other day • So how do you deal with this?
- 16. It starts withtrust
- 17. Would you trusthim?
- 18. Would you trusthim?
- 19.
- 20. Fundamental Rule ofSecurity Be like Mad-Eye Moody!
- 22. Think Attack Vectors! TrustTransmission Storage Cryptography Credentials& Access Outdated / vulnerable libraries Audit logs
- 23. Fundamental rule ofsecurity • Never trust! – Especially the client and user input! • Question every data element – and it’s source – and how it’s transmitted – and how it’s stored – Err on the side of caution • Role / User Based Access Control a must on the server!
- 24. My corollary Convenience /laziness is the simplest path to security hell!
- 25. Convenience – thepathway to hell
- 26. Let’s talk abouttrust TrustTransmission Storage Cryptography Credentials & Access Outdated / vulnerable libraries Audit logs
- 27. Thinking about trust •Source? • Mutable or pristine? • Impact of trusting?
- 28. Identity in WebApps
- 29. Securing Identity inWeb Apps • Login – Only time to ask the client who they are – Even then? • Post that – Trust the server generated session id or token, not the user • Don’t forget – Check Authentication – Check Authorization • Don’t believe the client
- 30.
- 31. Secure transmission inweb apps • Either you reinvent HTTPS on the client and your server – Build your crazy cryptographic solution – That resides on the client… • or just use HTTPS! • And don’t let JS and HTTP read your cookies! – Use secure, httpOnly cookies! Every non-secure transmission is a leak waiting to happen!
- 32.
- 33. Securing data inweb apps • How and what? – Transient or Stored? – Uniquely identifiable? – Needed or convenient? • Where? – On the client – On the server – Impact of leakage of the data? – Not all data is created equal • Access?
- 34.
- 35.
- 36.
- 37. Credentials • Are yourDB / AWS / XYZ credentials – Hard-coded in your code? – Checked in to your version control? – Provided to even the janitor at your company? • You are doing it wrong! • Never checked in! • Rotate credentials! • Need to know basis! – And no one needs to know!
- 38. Updates & Libraries TrustTransmission Storage Cryptography Credentials& Access Outdated / vulnerable libraries Audit logs
- 39. Updates • Don’t waitfor a mandatory, forced upgrade • Make it hygiene • Smaller, regular updates easier than forced, large updates
- 40. Audit Logs TrustTransmission Storage Cryptography Credentials & Access Outdated/ vulnerable libraries Audit logs
- 41. Audit Logs • It’stoo late by the time you need it! • Trustworthy? • Comprehensive?
- 42. Your cheatsheet • Askyourself this – Do I trust this data from the server / client? – Do I need this entire data to be sent to the client or only a part of it? – Can this user actually perform this action on this resource? – Should I persist this data in the client? – Is it being securely transmitted? – Is it stored securely? – Using the right / latest libraries?
- 43.