Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web Application Security - DevFest + GDay George Town 2016


Published on

An introduction to Web Application Security for web application developers (although most principles also apply to mobile and native or embedded apps) at DevFest + GDay George Town 2016. This talk covers the basic principles of infosec (CIA), do's and don't and the top 5 from the OWASP Top 10.

Published in: Technology
  • Login to see the comments

Web Application Security - DevFest + GDay George Town 2016

  1. 1. Web Application Security By Gareth Davies - Mindvalley CTO Founder of Founder of
  2. 2. So, Who am I? • I work at Mindvalley – we hiring! • Ex penetration testing team lead (hacker for hire) • Founder of prominent infosec blog
  3. 3. Darknet – A Brief History • Started in 1999 on EFnet (IRC) by me • Original IRC co-founder from Penang • Website launched in 2000 • Current format launched in 2006 • Top 5 Infosec Blog • 40,000+ RSS Subscribers • Nominated for multiple awards Full History:
  4. 4. – A Brief History • Started in 2002 as the Darknet Forum • Wanted to move away from Usenet • Became the fastest growing infosec forum • Referenced in Microsoft Newsletter • Running phpBB • Sold in 2004 to Visit:
  5. 5. This Talk • This talk covers: • The principle of infosec • The basic do’s and don’ts • OWASP Top 10 Who has been hacked before? Who knows the subject well or has worked in infosec? Who is familiar with OWASP Top 10?
  6. 6. An Introduction To Infosec
  7. 7. What is Information Security? • It is quite a vague phrase – but it can be defined. C AI
  8. 8. The CIA Triad •The basic model for Information Security: •Confidentiality (keeping the data secret) •Integrity (keeping the data unchanged) •Availability (keeping the data accessible)
  9. 9. Confidentiality “ Preventing the unauthorized disclosure of information” • Yahoo Hack exposed 500 Million Accounts • Can lead to legal issues • Hacker only needs ‘read’ access
  10. 10. Integrity “ Guarding against improper information modification or destruction” • Less frequent but more damaging • Can remain undetected for long periods (APT) • Hacker does need ‘write’ access
  11. 11. Availability “Ensuring timely and reliable access to the information” • DDoS attacks can be extremely damaging • Very hard to prevent and protect against • Hacker needs NO access
  12. 12. Web App Do’s & Don’ts
  13. 13. NEVER Trust User Input • Validate type, length, format, range • Use regex, JavaScript form validation + Back-end checks • Always whitelist, not blacklist
  14. 14. ALWAYS Protect Data in Transit • Use HTTPS/TLS for EVERYTHING • Use HSTS To Enforce it • Redirect all HTTP users to HTTPS • Make sure your app to DB connections are encrypted
  15. 15. ALWAYS Hash & Salt User Passwords • Hash ALL stored user passwords • Salt all Hashes (globally unique for each user) • Use bcrypt NOT md5 or SHA-1 • Use a validated library, don’t implement yourself
  16. 16. ALWAYS Authenticate Users Safely • Use an existing, mature framework • Consider SSO (login via Facebook/Twitter etc) • Use 2FA for important access (admins/super-users) • Re-authenticate for important actions (like Github/Gmail) • Hide user existence (don’t show ID doesn’t exist error) • Prevent brute forcing with CAPTCHA, rate-limiting etc
  17. 17. OWASP Top 10
  18. 18. A1- Injection • NEVER trust user input! • Separate interpreters from command or query • For SQL this means binding calls in prepared statements • Static analysis tools can scan for this
  19. 19. A2- Broken Auth & Sessions • NEVER store plain-text passwords ANYWHERE • Don’t expose Session IDs • Make sure sessions time-out • Rotate Session IDs properly • Don’t send passwords/sessions over unencrypted lines
  20. 20. A3- Cross-site Scripting (XSS) • NEVER trust user input! • These attacks focus on the browser as the interpreter • Properly escape all untrusted data • Whitelist server-side validation (Second layer) • There are specific auto-sanitization libraries (AntiSamy)
  21. 21. A4- Insecure Object References • NEVER trust user input! (seeing a pattern yet?) • Don’t use easily guessable resource names • User per session or indirect object references • Check access authorization on every request
  22. 22. A5- Security Misconfiguration • Don’t trust default config EVER (Google MongoDB hacks) • Always change default account credentials • Learn about the tools you use and how to secure them • Don’t expose detailed error messages/debug strings • Don’t leave samples on the servers (like php_info.php)
  23. 23. THE END For Stalkers Twitter/Insta: @ShaolinTiger Blog: Infosec: This presentation: