Recommended
More Related Content
What's hot
What's hot (20)
Similar to Web security for developers
Similar to Web security for developers (20)
Recently uploaded
Recently uploaded (20)
Web security for developers
- 1. Web Security for Developers Presented by: Sunny Neo Edgis Member http://edgis-security.org/
- 2. Pen Tester
- 4. Objectives ● Create awareness for web security ● Understand why some web vulnerabilities exist in the first place ● Know how you can prevent and mitigate these vulnerabilities ● Know the best practices for Web Security ● Create Mentorship/Internship/Job Opportunities
- 5. Web Application Security Architecture Common Terms Common Vulnerabilities & Attacks & Prevention ☺ Best Practices - Session Management and Cryptography
- 6. Web Application Architecture (Simplified) Browser (Web Clients) Web Server (Hosting Some Web Applications) Database Server HTTP(s)SQL
- 7. Common Terms ● Server-Side Code (PHP, ASP.NET, Ruby On Rails, Java etc) - Executed on server ● Client-Side Code (HTML, CSS, JavaScript) - Executed on client machine ● HTTP – A stateless protocol for WWW ● HTTP Get Request – Request data for a specified resource ● HTTP Post Request – Submit data to specified resource
- 8. Common Terms ● Structured Query Language (SQL) - Language used to access/query the database system ● Cookie – String stored at Client side to save state ● Session – Information related to client at Server side usually tied to a cookie id
- 9. WARNING Do not attempt to perform any security testing on any machine without permission It is illegal
- 11. Cross Site Request Forgery (CSRF) ● Allows an attacker to perform unintended actions on behalf of the authenticated user on another web application ● User and cookie is sent automatically by default ● Server unable to verify if a request is actually made by Client
- 12. Cross Site Request Forgery (CSRF) Malicious Web Server cecc.xyz cec.xyz (1) Login into cec.xyz (2) Accidentally stumble onto cecc.xyz (3) Serves CSRF attack (4) Performs CSRF request User
- 13. Cross Site Request Forgery (CSRF) Example http://news.softpedia.com/news/csrf-bug-in-verizon-s-api-left-my-fios-accounts-open-to-attacks-49 8723.shtml http://randywestergren.com/hijacking-verizon-fios-accounts/
- 14. Cross Site Request Forgery (CSRF) Prevention ● Require user authentication for sensitive operations ● Generate a random “challenge” token that is associated with the user’s current session ● Check for associated token whenever the user makes a sensitive request ● More at OWASP CSRF Prevention Cheat Sheet
- 15. Insecure Direct Object Reference ● Allows an attacker to manipulate object reference to gain unauthorized access to resources ● Happens because object reference to internal resource is exposed and no verification is performed to check if user is authorized
- 16. Insecure Direct Object Reference Example http://www.theregister.co.uk/2011/06/14/citigroup_website_hack_simple/
- 17. Insecure Direct Object Reference Prevention ● Minimize the use of predictable object reference such as sequential numbers and common names ● Use indirect object reference such as salted hash values or random identifier ● Check for user’s authorization to resource before granting access
- 18. Command Injection ● Allows an attacker to execute unintended command(s) on the server ● Happens because the web application is unable to differentiate between arguments and commands
- 20. Command Injection Prevention ● Avoid direct use of OS commands - Use built-in APIs whenever possible ● Use OS command APIs that separate commands and arguments into different parameters ● Perform input validation and sanitization ○ Whitelisting is usually preferred over Blacklisting
- 21. Cross Site Scripting (XSS) ● Allows an attacker to inject Client-Side scripts ● Happens because Web Browsers are not able to distinguish between legitimate Client-Side scripts and injected scripts ● 2 Main Types of XSS ○ Reflected ○ Stored
- 22. Reflected XSS cec.xyz (1) Access link given by malicious attacker http://cec.xyz?name=<script>alert(“XSS”);</script> (2) Does not sanitize HTTP request and simply echo back the parameter (3) Web Browser renders all <script> tag in HTML
- 23. Stored XSS cec.xyz (1) Attacker enters <script>alert(“XSS”)</script> into cec.xyz guestbook (2) cec.xyz saves Attacker’s guest book entry to database (3) Normal users access cec.xyz guestbook (4) Attacker’s entry <script> …. will be part of the HTML served to all users accessing the guestbookUsers Attacker
- 24. Cross Site Scripting (XSS) Example https://en.wikipedia.org/wiki/2013_Singapore_cyberattacks
- 25. Cross Site Scripting (XSS) Example http://blog.trendmicro.com/trendlabs-security-intelligence/singapore-pmo-website-not-hacked-despite-reports/
- 26. Cross Site Scripting (XSS) Prevention ● Perform validation and sanitization on untrusted inputs ● Use a Security Encoding Library (HTMLPurifier, AntiXSS Library) to perform escaping on untrusted inputs and outputs instead of writing your own ● Use “X-XSS-Protection: 1; mode=block” header ● Use Content Security Policy to whitelist Client-Side resource that the Browser can render ● More at OWASP XSS Prevention Cheat Sheet
- 27. SQL Injection ● Allows an attacker to inject SQL to perform unauthorized access on the database ● Happens because the application is unable to differentiate between SQL codes and parameters
- 28. SQL Injection $id = $_GET['id']; ← Retrieve ID from user $pass = $_GET[‘password’]; $sqlStatement = "SELECT username, password FROM users WHERE username = '1' and password= '$pass'”; $result = mysql_query($sqlStatement) ← Execute SQL Query There is no way to distinguish between SQL code and parameters using above code
- 29. SQL Injection $id = 1 $id = 1’ OR 1<2 # $id = 1’ UNION SELECT user(), version() #
- 30. SQL Injection Prepared statement through PHP Data Object $id = $_GET['id']; $sqlStatement = $dbh->prepare("SELECT first_name, last_name FROM users WHERE user_id = ?”; $sqlStatement->execute($id) *Prepared statement helps with performance as well*
- 32. SQL Injection Prevention ● Use prepared statements ● Perform validation, sanitization and escaping before passing the untrusted input to SQL query ● More at OWASP SQL Injection Prevention Cheat Sheet
- 33. Improper Password Storage ● Password is stored in plaintext ● No / Short Salt applied while hashing the password ● Reuse of Salt
- 34. Improper Password Storage Example http://arstechnica.com/security/2015/09/once-seen-as-bulletproof-11-million-ashley-madison-passwords-already-c racked/
- 35. Improper Password Storage Prevention ● Use long random Salt and do not reuse Salt ● Use a Secret key as well ● Use Key Derivation Function (KDF) such as PBKDF2 / bcrypt with appropriate work factor ● Eg: return salt + KDF(password+ secret key, salt, work factor) More at https://crackstation.net/hashing-security.htm and http://dustwell.com/how-to-handle-passwords-bcrypt.html and https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
- 36. Session and Cookie Management • Every session ID allocated must be unique and random • Session ID length must have enough entropy to make it infeasible to guess/forge • Session should have reasonable expiry duration and manual logout provided • Sensitive information must not be stored in Cookie • Secure and HttpOnly Flag enabled for Cookie
- 37. Cryptography Best Practices • Do not attempt to write your own cryptographic algorithm • Do not reuse Initialization Vector(IV) and nounce • Use only strong cryptographic algorithm with strong key-length and it has to be reviewed from time to time • Use Authenticated Encryption mode (GCM, CCM) for encryption • Use cryptographically secure Pseudo-random number generator/function to generate random number/string - Python random.random is not one of them • Keep your keys safe with key management process
- 38. What’s next? •Check out OWASP Top Ten Project to learn more about the top ten most common web application vulnerabilities •Check out OWASP Broken Web Application Project if you want to practise what I have shown you