class: center, middle # OWASP Top 10 for 2013 --- # [OWASP](http://www.owasp.org/) > The Open Web Application Security Project is worldwide not-for-profit charitable organization focused on improving the security of software. > The OWASP Top Ten is a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most ciritcal web application security flaws are. Project members include a variety of security expert from arwond the world. Top 10 is determined based upon: 1. Likelihood of an Application having the Vulnerablity (Prevalence) 2. Likelihood of an Attacker discovering the Vulnerability (Detectability) 3. Likelihood of an Attacker exploiting the Vulnerability (Exploitability) 4. Impact if the Vulnerability is successfully Exploited (Impact) --- ## 10 - Unvalidated Redirects and Forwards 1. Attacker will redirect your users to a site under their control. 2. Attacker will manually construct a redirect or forward that gives them access to a page with elevated permissions. ### Solution 1. Don't allow redirects or forwards 2. Don't use any user (browser) supplied information to determine destination page 3. Validate destination page for the current user. --- ## 9 - Using Known Vulnerable Components > If I have seen further it is by standing on the shoulders of giants. > > *- Isaac Newton* Modern practice is to build our applications on top of 3rd party components. This allows us to leverage the work of other developers. It also allows attackers to leverage the security holes of other developers. ### Solution 1. Know what components you're using 2. Have a process to constantly monitor, upgrade and validate component releases 1. Stay up to date - most projects only develop security patches for the current release. 2. Make sure your components belong to an active community --- ## 8 - Cross-Site Request Forgery (CSRF) Attacker gets user to open a page while connected to your site and executes a POST to your site using the pre-existing session. ### Solution Add a hidden CSRF token (psuedo-random number tied to the session) to all forms and validate the token on POST. --- ## 7 - Missing Function Level Access Control Assumption that people behave themselves - i.e. do not: 1. Use developer tools or proxy to examine traffic 2. Use tools to create arbitrary POSTs against URLs ### Solution Validate both Authentication and Authorization on all privileged operations. * Authentication = They are who you think they are * Authorization = They are allowed to perform the operation --- ## 6 - Sensitive Data Exposure 1. Data backed up to insecure site 2. Laptop lost/stolen 3. Sensitive data in log messages 4. Sensitive data not encrypted over network 4. ... ### Solution 1. Know what data is sensitive (personal identifying information) 2. Store passwords with algorithms designed for password protection (bcrypt, PBKDF2, script) 3. Encrypt sensitive data until it needs to be used * clear un-encrypted data as soon as you are done using it 4. Don't store sensitive data unless you have to 5. Store decryption keys separately from encrypted data 6. Limit access to sensitive data --- ## 5 - Security Misconfiguration It would have been secure if you had only: 1. Used a current release 2. Updated the default password 3. Disabled the "feature" 4. ... ### Solution 1. Keep It Simple Stupid - the more complicated the process, the more likely it is done wrong 2. Keep checklists of correct configuration 3. Have a process to keep checklists up to date, to follow checklists on deploy, to validate existing configurations --- ## 4 - Insecure Direct Object References Primary key or systemic indirect key included in request ## Solution 1. Check authentication and authorization on all privileged actions 2. Use indirect keys tied to the user or session --- ## 3 - Cross-Site Scripting (XSS) Client side injection attack via dynamically added data 1. Stored or Persistent XSS - user provided content stored in your system 2. Reflected XSS - user provided input reflected to user (sent as link) 3. DOM XSS - input inserted into the DOM via javascript (sent as link) ## Solution 1. HTML encode everything sent to the browser 2. Validate stored data with white lists. Your data may be coming from: 1. Users 2. Temp in data entry 3. Disgruntled employee on a plan 3. Use safe javascript (manipulate DOM, don't insert into DOM) --- ## 2 - Broken Authentication and Session Management 1. Credentials exposed 2. Session IDs exposed, vulnerable to session fixation, don't timeout, don't rotate, ... ### Solution 1. Pick or write a strong authentication and session management framework. 2. Ensure that all developers know how to use it 3. Validate that you're using it --- ## 1 - Injection Server side injection attack (anything that executes user supplied input - SQL, LDAP, perl) ### Solution 1. Use parameterized API 2. Escape user input with parser specific escape syntax 3. White list input --- # Other OWASP Projects * [OWASP Mobile Top 10 Risks](https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Top_Ten_Mobile_Risks) * [OWASP Top 10 Cheat Sheet](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet) * [Top 10 Proactive Controls](https://www.owasp.org/index.php/OWASP_Proactive_Controls) * [OWASP TOp 10 Mapped to the Web Hacking Incident Database](https://www.owasp.org/index.php/OWASP_Top_10/Mapping_to_WHID)