Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Salesforce.com, the OWASP
Top 10 and You!
What do the OWASP Top 10
vulnerabilities look like on
Force.com?
About me
What I do:
Senior Technical Consultant at Extentor
6 years working on Force.com
Certs:
Admin 201 and 301
Dev 401 ...
What is OWASP?
Open Web Application Security Project
“… an online community dedicated to web application
security” (Wikipe...
What is the OWASP Top 10?
Every year, OWASP list the top 10 most critical web application
security flaws. The list for 201...
Why is this relevant to Force.com?
• No platform can stop you from doing things you shouldn’t
do
• Alternatively: Force.co...
Example code
• This presentation was originally given at the
August 2014 Sydney Salesforce Developers User
Group
• The tal...
The Top 10
5. Security Misconfiguration
• Out of date software
• Unnecessary features enabled
Examples
• Incorrect OWDs
• Remote site...
9. Using Components with Known
Vulnerabilities
• Using software components that have known
flaws
Examples
• JSONP
Preventi...
7. Missing Function Level Access
Control
• Lack of checks on access to code functions (rather than
data).
• Remember “Syst...
2. Authentication & Session
Management
• Insecure ways of authenticating users
• This means during initial auth, and subse...
1. Injection
• Unsafe use of user provided (or user modifiable) input, that affects
queries against a Database.
Examples:
...
3. Cross Site Scripting (XSS)
• Web applications (usually) present pages to
users based on logic we control.
• XSS exploit...
3. Cross Site Scripting (XSS)
Examples:
• Non-persistent – e.g. URL Parameters
• Persistent – e.g. message boards
Preventi...
4. Insecure Direct Object References
• Failing to check that a user is allowed to access a resource
Examples
• Failing to ...
6. Sensitive Data Exposure
• Inadvertent exposure of sensitive data (duh)
Examples
• Transmitting data in the clear e.g. n...
8. Cross Site Request Forgery (CSRF)
• Accessing resources that make changes to data without
a user intending it
Examples:...
10. Unvalidated Redirects and
Forwards
• Re-directions to pages where either you don’t want users
to go, or where they don...
Upcoming SlideShare
Loading in …5
×

Owasp top10salesforce

3,550 views

Published on

Presentation given at the August 2014 Sydney Salesforce Developers Group. It looks at the OWASP Top 10 project, and how the vulnerabilities in that list can manifest themselves on the Force.com platform.

See the GitHub repo at the following link for the accompanying code: https://github.com/gbreavin/owasp-top10-salesforce

Published in: Software
  • Be the first to comment

Owasp top10salesforce

  1. 1. Salesforce.com, the OWASP Top 10 and You! What do the OWASP Top 10 vulnerabilities look like on Force.com?
  2. 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. 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. 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. 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. 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. 7. The Top 10
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×