salesforce_security_impl_guide

More documents

Recommendations

Info

Security Tips for Apex and Visualforce Development SOQL Injection } return ; } In this case, the developer has unknowingly bypassed the anti-CSRF controls by developing their own action method. The id parameter is read and used in the code. The anti-CSRF token is never read or validated. An attacker Web page might have sent the user to this page using a CSRF attack and provided any value they wish for the id parameter. There are no built-in defenses for situations like this and developers should be cautious about writing pages that take action based upon a user-supplied parameter like the id variable in the preceding example. A possible work-around is to insert an intermediate confirmation page before taking the action, to make sure the user intended to call the page. Other suggestions include shortening the idle session timeout for the organization and educating users to log out of their active session and not use their browser to visit other sites while authenticated. SOQL Injection In other programming languages, the previous flaw is known as SQL injection. Apex does not use SQL, but uses its own database query language, SOQL. SOQL is much simpler and more limited in functionality than SQL. Therefore, the risks are much lower for SOQL injection than for SQL injection, but the attacks are nearly identical to traditional SQL injection. In summary SQL/SOQL injection involves taking user-supplied input and using those values in a dynamic SOQL query. If the input is not validated, it can include SOQL commands that effectively modify the SOQL statement and trick the application into performing unintended commands. For more information on SQL Injection attacks see: • http://www.owasp.org/index.php/SQL_injection • http://www.owasp.org/index.php/Blind_SQL_Injection • http://www.owasp.org/index.php/Guide_to_SQL_Injection • http://www.google.com/searchq=sql+injection SOQL Injection Vulnerability in Apex Below is a simple example of Apex and Visualforce code vulnerable to SOQL injection.
Security Tips for Apex and Visualforce Development Data Access Control } } This is a very simple example but illustrates the logic. The code is intended to search for contacts that have not been deleted. The user provides one input value called name . The value can be anything provided by the user and it is never validated. The SOQL query is built dynamically and then executed with the Database.query method. If the user provides a legitimate value, the statement executes as expected: // User supplied value: name = Bob // Query string SELECT Id FROM Contact WHERE (IsDeleted = false and Name like '%Bob%') However, what if the user provides unexpected input, such as: // User supplied value for name: test%') OR (Name LIKE ' In that case, the query string becomes: SELECT Id FROM Contact WHERE (IsDeleted = false AND Name LIKE '%test%') OR (Name LIKE '%') Now the results show all contacts, not just the non-deleted ones. A SOQL Injection flaw can be used to modify the intended logic of any vulnerable query. SOQL Injection Defenses To prevent a SOQL injection attack, avoid using dynamic SOQL queries. Instead, use static queries and binding variables. The vulnerable example above can be re-written using static SOQL as follows: public class SOQLController { public String name { get { return name;} set { name = value;} } public PageReference query() { String queryName = '%' + name + '%'; queryResult = [SELECT Id FROM Contact WHERE (IsDeleted = false and Name like :queryName)]; return null; } } If you must use dynamic SOQL, use the escapeSingleQuotes method to sanitize user-supplied input. This method adds the escape character (\) to all single quotation marks in a string that is passed in from a user. The method ensures that all single quotation marks are treated as enclosing strings, instead of database commands. Data Access Control The Force.com platform makes extensive use of data sharing rules. Each object has permissions and may have sharing settings for which users can read, create, edit, and delete. These settings are enforced when using all standard controllers. When using an Apex class, the built-in user permissions and field-level security restrictions are not respected during execution. The default behavior is that an Apex class has the ability to read and update all data within the organization. Because these rules are not enforced, developers who use Apex must take care that they do not inadvertently expose sensitive data that would normally be hidden 105
Page 1 and 2:
Security Implementation Guide Versi
Page 3 and 4:
CONTENTS Chapter 1: Security Overvi
Page 5 and 6:
Contents Editing Lead Sharing Rules
Page 7 and 8:
CHAPTER 1 Security Overview Salesfo
Page 9 and 10:
Security Overview User Security Ove
Page 11 and 12:
Security Overview Custom Permission
Page 13 and 14:
Security Overview CAPTCHA Security
Page 15 and 16:
Security Overview Auditing • Role
Page 17 and 18:
Securing and Sharing Data Revoking
Page 19 and 20:
Securing and Sharing Data Viewing P
Page 21 and 22:
Securing and Sharing Data Cloning P
Page 23 and 24:
Securing and Sharing Data App and S
Page 25 and 26:
Securing and Sharing Data Working w
Page 27 and 28:
Securing and Sharing Data Enable Cu
Page 29 and 30:
Securing and Sharing Data Assigning
Page 31 and 32:
Securing and Sharing Data Creating
Page 33 and 34:
Securing and Sharing Data Editing P
Page 35 and 36:
Securing and Sharing Data Searching
Page 37 and 38:
Securing and Sharing Data Enable Cu
Page 39 and 40:
Securing and Sharing Data Object Pe
Page 41 and 42:
Securing and Sharing Data Comparing
Page 43 and 44:
Securing and Sharing Data Setting F
Page 45 and 46:
Securing and Sharing Data Working w
Page 47 and 48:
Securing and Sharing Data Setting L
Page 49 and 50:
Securing and Sharing Data Restricti
Page 51 and 52:
Securing and Sharing Data Managing
Page 53 and 54:
Securing and Sharing Data External
Page 55 and 56:
Securing and Sharing Data Disabling
Page 57 and 58:
Securing and Sharing Data Creating
Page 59 and 60: Securing and Sharing Data Creating
Page 67 and 68: Securing and Sharing Data Editing L
Page 69 and 70: Securing and Sharing Data Editing C
Page 71 and 72: Securing and Sharing Data Editing C
Page 73 and 74: Securing and Sharing Data Sharing R
Page 75 and 76: Securing and Sharing Data User Shar
Page 77 and 78: Securing and Sharing Data Sharing U
Page 81 and 82: Securing and Sharing Data Viewing A
Page 83 and 84: Securing and Sharing Data Granting
Page 85 and 86: Configuring Salesforce Security Fea
Page 95 and 96: CHAPTER 4 Enabling Single Sign-On S
Page 97 and 98: Enabling Single Sign-On • Before
Page 99 and 100: Monitoring Your Organization's Secu
Page 107 and 108: Security Tips for Apex and Visualfo
Page 109: Security Tips for Apex and Visualfo
Page 113 and 114: INDEX A Access about 10 revoking 11
Page 115 and 116: Index Profiles (continued) object p
show all

salesforce_security_impl_guide

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?