Owasp top10salesforce
- 1. Salesforce.com, the OWASP Top 10 and You! What do the OWASP Top 10 vulnerabilities look like on Force.com?
- 2. About me What I do: Senior Technical Consultant at Extentor 6 years working on Force.com Certs: Admin 201 and 301 Dev 401 and 501 Sales & Service Cloud Consultant
- 3. What is OWASP? Open Web Application Security Project “… an online community dedicated to web application security” (Wikipedia, http://en.wikipedia.org/wiki/OWASP) They have many projects, whose aim is to improve the security of software applications built, or, in their words: “…enable organisations to conceive, develop, acquire, operate and maintain applications that can be trusted.” (About OWASP, https://www.owasp.org/index.php/About_OWASP)
- 4. What is the OWASP Top 10? Every year, OWASP list the top 10 most critical web application security flaws. The list for 2013 can be found here: https://www.owasp.org/index.php/Top_10_201 3-Top_10
- 5. Why is this relevant to Force.com? • No platform can stop you from doing things you shouldn’t do • Alternatively: Force.com cannot stop you from making mistakes (but in some cases, it will help avoid them) • So: These flaws can exist in code you write Think about the types of app you can build – internal apps, but also customer-facing apps (e.g. Sites-based), and AppExchange apps. Knowing these flaws can help you avoid them (But don’t treat this as a list of the only things to look for)
- 6. Example code • This presentation was originally given at the August 2014 Sydney Salesforce Developers User Group • The talk included demonstrations of (most of) the vulnerabilities • I can’t demo them to you if you’re reading this, but you can find the code for the demo and install them in your org in this GitHub repo: https://github.com/gbreavin/owasp-top10-salesforce
- 7. The Top 10
- 8. 5. Security Misconfiguration • Out of date software • Unnecessary features enabled Examples • Incorrect OWDs • Remote site settings Prevention • Security setup • Don’t forget libraries, apps, etc. • Rely on the database to determine visibility
- 9. 9. Using Components with Known Vulnerabilities • Using software components that have known flaws Examples • JSONP Prevention • Keep any libraries, apps etc. up to date • Read release notes and other Salesforce material for security best practices
- 10. 7. Missing Function Level Access Control • Lack of checks on access to code functions (rather than data). • Remember “System Mode” Examples • Visualforce page access • Web Service access Prevention • Profile permissions for Pages & Classes • Don’t forget Javascript!
- 11. 2. Authentication & Session Management • Insecure ways of authenticating users • This means during initial auth, and subsequent accesses Examples: • Storing user credentials insecurely • Session IDs in the URL • Session IDs don’t timeout Prevention: • Let the platform do this for you
- 12. 1. Injection • Unsafe use of user provided (or user modifiable) input, that affects queries against a Database. Examples: • Use of Database.query() • Modifying URL parameters that are used in a query Prevention: • Avoid dynamic SOQL where possible • If using dynamic SOQL, limit anything that is provided or modifiable by a user – parse input and select appropriate action rather than plugging it straight into a dynamic SOQL query • Sharing and security setup
- 13. 3. Cross Site Scripting (XSS) • Web applications (usually) present pages to users based on logic we control. • XSS exploits ways of malicious parties smuggling their code into the page that will do their bidding • A common proof of XSS vulnerabilities is to cause a Javascript alert to pop-up (i.e. an alert that is not triggered by the web application)
- 14. 3. Cross Site Scripting (XSS) Examples: • Non-persistent – e.g. URL Parameters • Persistent – e.g. message boards Prevention: • Visualforce has some built in protections • Escape input that could be included in a page, preferably as data enters the system, or before it is displayed • Play a game: https://xss-game.appspot.com • Read up on these attack vectors
- 15. 4. Insecure Direct Object References • Failing to check that a user is allowed to access a resource Examples • Failing to check resource (e.g. record) access • Sensitive information visible by admins • ‘Hackable’ URL Parameters Prevention • Sharing and security, use “with sharing” • Rely on the database to determine visibility • Encrypted fields Example Casualty
- 16. 6. Sensitive Data Exposure • Inadvertent exposure of sensitive data (duh) Examples • Transmitting data in the clear e.g. non-SSL, URLs, Login forms over http • Unencrypted credit card info • Incorrect encryption (e.g. hand-rolled methods, unsalted hash) • Logging Prevention • Use platform encryption methods • Identify sensitive data and how it is used, where it comes from and goes to, and assess for risks. Work out suitable encryption method • If possible - don’t store sensitive data (e.g. credit cards)
- 17. 8. Cross Site Request Forgery (CSRF) • Accessing resources that make changes to data without a user intending it Examples: • Visualforce pages with action and auto-redirect Prevention: • Force.com has an anti-CSRF token protection for POST requests – so use POST requests. • Use pages that require manual action before changing data.
- 18. 10. Unvalidated Redirects and Forwards • Re-directions to pages where either you don’t want users to go, or where they don’t want to go Examples • Spoof URL parameter e.g. url=evil.com • Malicious attempts to access pages e.g. url=admin Prevention • Avoid doing it • Value look-ups e.g. simple values are accepted, and they are mapped to approved URL targets, with a sensible default