Advertisement

Owasp top 10

markstory
Nov. 2, 2012
Advertisement

More Related Content

Advertisement
Advertisement

Owasp top 10

  1. AVOIDING THE OWASP Top 10 security exploits Friday, 2 November, 12
  2. ME Illustrator turned developer Team Lead at FreshBooks Lead developer of CakePHP PHP developer for 7 years Friday, 2 November, 12
  3. SECURITY Friday, 2 November, 12
  4. SECURITY CONTINUUM ( unusable ) unrestricted Friday, 2 November, 12
  5. OWASP Open Web Application Security Project Friday, 2 November, 12
  6. OWASP TOP 10 Friday, 2 November, 12
  7. 1 Friday, 2 November, 12 SQL INJECTION ‘ OR 1=1 ‘--
  8. RISKS Permits query manipulation, and arbitrary SQL. Bad guys can re-write your queries. Friday, 2 November, 12
  9. SQL INJECTION EXAMPLE $username = $_POST[‘username’]; $password = $_POST[‘password’]; $query = “SELECT * FROM user WHERE username = ‘$username’ AND password = ‘$password’”; $user = $db->query($query); Friday, 2 November, 12
  10. USER INPUT $username = “root”; $password = “‘ OR 1 = 1 --”; Friday, 2 November, 12
  11. FINAL QUERY $query = “SELECT * FROM user WHERE username = ‘root’ AND password = ‘‘ OR 1 = 1 --’”; Friday, 2 November, 12
  12. FINAL QUERY $query = “SELECT * FROM user WHERE username = ‘root’ AND password = ‘‘ OR 1 = 1 --’”; Friday, 2 November, 12
  13. PREVENTION Use an ORM or Database abstraction layer that provides escaping. Doctrine, ZendTable, and CakePHP all do this. Use PDO and prepared statements. Never put user data into a query. Never use regular expressions, magic quotes, or addslashes() Friday, 2 November, 12
  14. EXAMPLE (PDO) $query = “SELECT * FROM user WHERE username = ? AND password = ?”; $stmt = $db->prepare($query); $stmt->bindValue($username); $stmt->bindValue($password); $result = $db->execute(); Friday, 2 November, 12
  15. 2 Friday, 2 November, 12 XSS <script>alert(‘cross site scripting’);</script>
  16. RISKS Allows bad guys to do things as the person viewing a page. Steal identities, passwords, credit cards, hijack pages and more. Friday, 2 November, 12
  17. XSS EXAMPLE <p> <?php echo $user[‘bio’]; ?> </p> Friday, 2 November, 12
  18. XSS EXAMPLE <p> <?php echo $user[‘bio’]; ?> </p> Friday, 2 November, 12
  19. You may be thinking, I can use regular expressions to fix this. Friday, 2 November, 12
  20. NO Friday, 2 November, 12
  21. PREVENTION Regular expressions and strip_tags leave you vulnerable. The only solution is output encoding. Friday, 2 November, 12
  22. EXAMPLE <p> <?php echo htmlentities( $user[‘bio’], ENT_QUOTES, ‘UTF-8’ ); ?> </p> Friday, 2 November, 12
  23. DANGERS Manually encoding is error prone, and you will make a mistake. Using a template library like Twig that provides auto- escaping reduces the chances of screwing up. Encoding is dependent on context. Friday, 2 November, 12
  24. 3 BROKEN AUTHENTICATION & SESSION MANAGEMENT Friday, 2 November, 12 /index.php?PHPSESSID=pwned
  25. RISKS Identity theft. Firesheep was an excellent example. Friday, 2 November, 12
  26. SESSION FIXATION EXAMPLE <?php session_start(); if (isset($_GET[‘sessionid’]) { session_id($_GET[‘sessionid’]); } Friday, 2 November, 12
  27. SESSION FIXATION EXAMPLE <?php session_start(); if (isset($_GET[‘sessionid’]) { session_id($_GET[‘sessionid’]); } Friday, 2 November, 12
  28. PREVENTION Rotate session identifiers upon login/logout Set the HttpOnly flag on session cookies. Use well tested / mature libraries for authentication. SSL is always a good idea. Friday, 2 November, 12
  29. 4 INSECURE DIRECT OBJECT Friday, 2 November, 12 REFERENCE
  30. RISKS Bad guys can access information they shouldn’t Bad guys can modify data they shouldn’t. Friday, 2 November, 12
  31. BROKEN PASSWORD UPDATE <form action=”/user/update” method=”post”> <input type=”hidden” name=”userid” value=”4654” /> <input type=”text” name=”new_password” /> <button type=”submit”>Save</button> </form> Friday, 2 November, 12
  32. PREVENTION Remember hidden inputs are not really hidden, and can be changed by users. Validate access to all things, don’t depend on things being hidden/invisible. If you need to refer to the current user, use session data not form inputs. Whitelist properties any form can update. Friday, 2 November, 12
  33. 5 Friday, 2 November, 12 CROSS SITE REQUEST FORGERY (CSRF)
  34. RISKS Evil websites can perform actions for users logged into your site. Side effects on GET can be performed via images or CSS files. Remember the Gmail contact hack. Friday, 2 November, 12
  35. CSRF EXAMPLE Your app Evil site Friday, 2 November, 12
  36. CSRF EXAMPLE Your app Evil site Login Friday, 2 November, 12
  37. CSRF EXAMPLE Your app Evil site Login Accidentally visit Friday, 2 November, 12
  38. CSRF EXAMPLE Your app Submit form for evil Evil site Login Accidentally visit Friday, 2 November, 12
  39. PREVENTION Add opaque expiring tokens to all forms. Requests missing tokens or containing invalid tokens should be rejected. Friday, 2 November, 12
  40. SAMPLE CSRF VALIDATION <?php if (!$this->validCsrfToken($data, ‘csrf’)) { throw new ForbiddenException(); } Friday, 2 November, 12
  41. 6 Friday, 2 November, 12 SECURITY MISCONFIGURATION
  42. RISKS Default settings can be insecure, and intended for development not production. Attackers can use misconfigured software to gain knowledge and access. Friday, 2 November, 12
  43. PREVENTION Know the tools you use, and configure them correctly. Keep up to date on vulnerabilities in the tools you use. Remove/disable any services/features you aren’t using. Friday, 2 November, 12
  44. 7 INSECURE CRYPTOGRAPHIC Friday, 2 November, 12 STORAGE md5(‘password’)
  45. RISKS Weak cryptographic storage can easily be cracked. Keys can be exposed with encrypted data. Backups can contain encrypted data & keys. Compromised passwords can be used to obtain information on other sites. Friday, 2 November, 12
  46. BAD PASSWORD HASHING $password; md5($password); sha1($password); Friday, 2 November, 12
  47. BAD PASSWORD HASHING $password; md5($password); sha1($password); Friday, 2 November, 12
  48. USE BCRYPT FOR PASSWORDS only you can prevent bad hashing Friday, 2 November, 12
  49. PREVENTION Use strong hashing/encryption. Use one way hashing for passwords. Never use symmetric encryption for passwords. Don’t collect data if you don’t need it. Keep keys separate from data. If you’re using symmetric encryption, be able to rotate keys easily. Friday, 2 November, 12
  50. BCRYPT IN PHP // password hashing (bcrypt) $hashed = crypt( $pass, ‘$2a$10$asdkbisloqi.fidsliz.df190.d9f40’); // compare later $hashed = crypt($plaintext, $storedHash); // check for match $hashed === $storedHash Friday, 2 November, 12
  51. BCRYPT IN PHP // password hashing (bcrypt) $hashed = crypt( $pass, ‘$2a$10$asdkbisloqi.fidsliz.df190.d9f40’); // compare later $hashed = crypt($plaintext, $storedHash); // check for match $hashed === $storedHash Friday, 2 November, 12
  52. BCRYPT IN PHP // password hashing (bcrypt) $hashed = crypt( $pass, ‘$2a$10$asdkbisloqi.fidsliz.df190.d9f40’); // compare later $hashed = crypt($plaintext, $storedHash); // check for match $hashed === $storedHash Friday, 2 November, 12
  53. BCRYPT IN PHP // password hashing (bcrypt) $hashed = crypt( $pass, ‘$2a$10$asdkbisloqi.fidsliz.df190.d9f40’); // compare later $hashed = crypt($plaintext, $storedHash); // check for match $hashed === $storedHash Friday, 2 November, 12
  54. USE MCRYPT // encrypt (rijndael) $value = mcrypt_encrypt( ‘rijndael-256’, $secretKey, $ccnumber,‘cbc’, $iv ); // decrypt $value = mcrypt_decrypt( ‘rijndael-256’, $secretKey, $encrypted,‘cbc’, $iv ); Friday, 2 November, 12
  55. 8 FAILURE TO RESTRICT URL Friday, 2 November, 12 ACCESS
  56. RISK Hidden things can easily be found. Creative people will eventually find your hidden URLs Security through obscurity is a terrible idea. Friday, 2 November, 12
  57. PREVENTION Check access to all urls both when you generate links and more importantly when handling requests. Don’t rely on things staying hidden. Friday, 2 November, 12
  58. 9 INSUFFICIENT TRANSPORT Friday, 2 November, 12 LAYER PROTECTION
  59. SSL/TLS Friday, 2 November, 12
  60. 10 UNVALIDATED REDIRECTS & Friday, 2 November, 12 FORWARDS
  61. RISKS Trusting user input for redirects opens phishing attacks. Breach of trust with your users. Friday, 2 November, 12
  62. PREVENTION Don’t trust user data when handling redirects. Friday, 2 November, 12
  63. QUESTIONS? Friday, 2 November, 12
Advertisement