Don't Get Stung

The OWasp Top Ten, how to recognize, avoid, and fix them.

Transcript

1. DON’T GET STUNG THE OWASP TOP TEN, AVOIDING THEM
2. WHOAMI ▸ Shawn Campbell <jaegerpicker@gmail.com> ▸ @jaegerpicker ▸ Full Stack Security Engineer @ Vox Media Inc ▸ https://github.com/jaegerpicker ▸ https://jaegerpicker.github.io
3. WHY YOU ARE HERE WHAT’S THIS ABOUT ▸ Webapp Security and how not to be bad at it ▸ The Owasp(Open Web Application Security project) is an organization dedicated to providing education to developers about web app sec ▸ They publish a list of the 10 most common and dangerous vulnerabilities for web apps ▸ This is a explanation of what the top 10 are and how to fix them
4. THE DEETS THE SETUP ▸ https://github.com/owasp/railsgoat ▸ That is a sample educational rails web app with the top 10 vulnerabilities baked in, plus some fun extras. ▸ I’ll also show a brief demo of how easy it is to find these bugs.
5. OWASP TOP 10 THE LIST ▸ Injection ▸ Broken Auth and Session Management ▸ XSS ▸ Insecure Direct Object Ref ▸ Misconfiguration ▸ Data Exposure ▸ Missing Function level access Control ▸ Cross Site Request Forgery ▸ Using components with Know Vulnerabilities ▸ Unvalidated Redirects and Forwards
6. THE METHODS THAT WILL MOST EFFECTIVELY MINIMIZE THE ABILITY OF INTRUDERS TO COMPROMISE INFORMATION SECURITY ARE COMPREHENSIVE USER TRAINING AND EDUCATION. ENACTING POLICIES AND PROCEDURES SIMPLY WON'T SUFFICE. EVEN WITH OVERSIGHT THE POLICIES AND PROCEDURES MAY NOT BE EFFECTIVE MY ACCESS TO MOTOROLA, NOKIA, ATT, SUN DEPENDED UPON THE WILLINGNESS OF PEOPLE TO BYPASS POLICIES AND PROCEDURES THAT WERE IN PLACE FOR YEARS BEFORE I COMPROMISED THEM SUCCESSFULLY Kevin Mitnick SHOULD ALL DEVS LEARN ABOUT THIS?
7. INJECTION THREE MAIN TYPES ▸ Can be targeted at SQL, LDAP, No-SQL, Search Indices, OS, and Other DB/APPs ▸ Injection Concatenation ▸ Injection Interpolation ▸ Command Injection
8. INJECTION CONCATENATION ▸ Most famous and well known type ▸ Happens when untrusted data is sent to a Query interpreter or command processor ▸ Never trust user input ▸ NEVER TRUST USER INPUT!!!! ▸ Common ways to mitigate the issue include escaping the user input, casting it to a strongly type variable (ie an int for int lookups), and parameterizing your query ▸ Example: user = User.where(email = #{param.email}).first ') OR admin = 't' --'")&user[password]=testtest1&user[p assword_confirmation]=testtest1
9. Solution: Vulnerable Code:
11. INJECTION STRING INTERPOLATION ▸ Includes attacks where your are generating fields in the select clause, where conditions, or other query features based on user input ▸ Leads to information leakage and other issues
12. Vulnerable Code: Solution:
13. INJECTION COMMAND INJECTION ▸ When user input is passed to an OS command execution ▸ Typical trouble areas include image processing, log file querying, and uploading files but it is not limited to these areas.
14. Vulnerable Code: Solution:
15. AUTH/SESSION BROKEN AUTH AND SESSION MANAGEMENT ▸ Credential Enumeration ▸ Lack of Password Complexity ▸ Insecure Compare and Timing Attacks ▸ Lack of HttpOnly Flag
16. AUTH/SESSION CREDENTIAL ENUMERATION ▸ Simply stated it’s leaking information about existing user accounts ▸ Happens when the user is presented with a message detailing user information ▸ Example: the user is presented with a message when unsuccessfully attempting to login “User jaegerpicker@gmail.com doesn’t exist in our user database” ▸ Dangerous because it narrows the attackers vector, instead of guessing a username and password they only need to crack the password
18. AUTH/SESSION LACK OF PASSWORD COMPLEXITY ▸ Simple passwords are bad m’kay? ▸ Entropy is the real key measurement, passphrases are often better than passwords even random long passwords ▸ Example: ocean conduct people alpha 1972, that’s a strong example password and takes a lot longer to crack than a random 40 character password using CUDA or other GPU based attacks
20. AUTH/SESSION INSECURE COMPARE AND/OR TIMING ATTACKS ▸ Is really related to enumeration attacks and information leaking ▸ If there is a pause, even if it’s a short pause, after a username is found in the user db doing the hash to compare passwords, an attacker can use that to find all the valid usernames in a database. ▸ A good way around this is to create a blank user with a random password and compare that hash if the email passed in is not found.
22. AUTH/SESSION LACK OF HTTPONLY FLAG ON COOKIES ▸ The HttpOnly header prevents javascript access to the cookies stored on the browser ▸ Setting this flag prevents session hijacking attacks via XSS and/or CSRF ▸ Most frameworks set this for you by default, LEAVE IT ON!
24. XSS CROSS-SITE SCRIPTING ▸ XSS - Server Side ▸ XSS - DOM/Browser side
25. XSS XSS - SERVER SIDE ▸ Attack is based on unescaped user input (Once again NEVER TRUST THE USER) ▸ Example: enter <script>alert(“broken website”)</script> during registration on the home page the site displays <h1>Welcome <%= current_user.first_name.html_safe %> and an alert saying broken website will be displayed. ▸ Escape your users input, all of it. Most frameworks help you with this.
26. XSS XSS - DOM/BROWSER BASED ▸ An attack targeting JavaScript and does not change the content of the response from the server but only on the client side ▸ Common types of issues relate to information that is planned to be hidden based on permission but are sent to the end user, this can be used to allow users to access data that is restricted.
27. DIRECT OBJECT REF INSECURE DIRECT OBJECT REFERENCE ▸ Related to allowing users having access to objects that they may not have access to. ▸ Common example: on the profile page of an app load the user based on the user id param passed in as opposed the currently logged in user
29. SECURITY MISCONFIG SECURITY MISCONFIGURATION ▸ This relates configuration of the web server and firewalls surrounding the application, not much to say here because it’s dependent on the server software being used. ▸ Read up on best practices and follow them for your software, don’t allow directory listing, direct downloads of files via ftp, etc….
30. SENSITIVE DATA SENSITIVE DATA EXPOSURE ▸ Insecure password storage ▸ Clear-text storage of PII ▸ Model attributes exposure
31. SENSITIVE DATA INSECURE PASSWORD STORAGE ▸ In case of the password leakage or against automated brute force attacks, passwords should be stored in a secure format. ▸ MD5 is not secure, a gpu can brute force an md5 quite quickly ▸ A one way hash is recommended not encryption. They are different encryption is reversible, hashing is not. Encryption is not recommended because if an attacker gets your keys they have the keys to the kingdom. Hashed passwords should be still secure if someone obtains them. ▸ bcrypt/scrypt with salts are recommended for hashing
33. SENSITIVE DATA CLEARTEXT STORAGE OF PII ▸ Plan as if your data will land in the hands of attackers ▸ If you would be upset if your personal information would be leaked then your users data SHOULD be encrypted while at rest in the db
35. SENSITIVE DATA MODEL ATTRIBUTES EXPOSURE ▸ The bug is returning an entire model and all of it’s attributes exposing sensitive data ▸ Example: a json api the serializes a user model returning password, ssn, email, date of birth, etc…
37. FUNCTION LEVEL ACCESS MISSING FUNCTIONAL LEVEL ACCESS CONTROLS ▸ The practice of hiding url links based on permissions but not checking permissions on the page themselves. This allows attackers to forge the restricted urls.
38. CSRF CROSS SITE REQUEST FORGERY ▸ Attacks forging attacks requests from another user ▸ Example: attacker steals a currently logged in user’s cookie and sends an order using that customer’s credit card. ▸ Best protection is a server side encrypted token that is generated with each request that the server can use to validate the request.
40. DEPENDENCIES USING KNOWN VULNERABLE COMPONENTS/LIBS ▸ You are only as secure as your weakest link ▸ Libs and components have a published list of vulnerabilities, attackers watch these lists. So should you ▸ I recommend using a service like synk.io that will check your dependency files (Gemfile, requirements.txt, package.json etc…) ▸ You an practice assuming code habits for your code and if you don’t follow this simple step it can matter at all.
41. UNVALIDATED REDIRECTS INVALIDATED REDIRECTS AND FORWARDS ▸ Its the practice of redirecting a user based on a unvalidated param. ▸ This can easily expose restricted pages and/or admin access level pages. ▸ Example: redirect_to params[:url] ▸ Again NEVER TRUST THE USER ▸ Always check permissions for that currently logged in user
43. FINIE SHAWN CAMPBELL ▸ Thanks to Vox Media Inc. my current employer where I’m a Full Stack Security Engineer ▸ Thanks to CashStar for sponsoring this meetup. ▸ jaegerpicker@gmail.com ▸ @jaegerpicker ▸ https://github.com/jaegerpicker ▸ https://github.com/OWASP/railsgoat/wiki/Rails-5-Tutorials