• vbadhwar
  • NEWBIE
  • 205 Points
  • Member since 2009

  • Chatter
    Feed
  • 8
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 7
    Questions
  • 21
    Replies

Hi Guys,

 

I need some help. We developed a Composite (Hosted) application that integrates with Salesforce. It's time for security review submission. We went through the requirements - http://wiki.developerforce.com/index.php/Security_Review. OWASP Top Ten Checklist and Requirements Checklist evaluated. We have followd the policies described on the page as closely as possible but we do not meet all of them a 100 %. For example we do not have a company wide security policy.

We have also run the Burp scanner.

 

Is there anything else that we should do?

 

Does Salesforce require a minimum unit tests code coverage for Composite (Hosted) applications? Does Salesforce require any information about our security policies prior to security review and if so, what kind of information?

 

Thank you in advance!

Hi guys,

We are developing a managed package which we would like to prepare for a security review.

In the package we have logic in a one VF page's controller which returns a PageReference object and redirects to another VF page. We want to be able to pass the record id from the first page to the second page and we are currently doing that by adding the id to the url as a parameter string.

We have a problem with security review with this approach. I wandered what would you recommend to make that more secure.Probably a session inside of SalesForce or encrypt the id or how?

 

Thanks,

Kos

  • December 02, 2010
  • Like
  • 0

Hi,

 

I have an application in Japanese AppExchange. I want to list the application in the English AppExchange. Fo this I will build the same application in a separate Salesforce account and submit it Salesforce security review. I have following set of questions on this issue.

 

Will I automatically pass the security review because same application is listed in Japanese AppExchange (passed security review)?

Is there a special process for this kind of listings?

Do I have to pay again for the security review for the English AppExchange ?

Are there any other additional fees involved this process ?

 

Thanks

Viraj

 

 

  • June 15, 2010
  • Like
  • 0

Is it safe to store Credit Card information in an org?  I have created a Payment object and want to capture credit card information (i.e., CC number, expiration date, etc.).  I know that I can secure these fields within Salesforce, but are there any other security issues that I should be concerned with?  Eventually, we will use some type of online credit card processing but was wondering if this would work until then.

 

Thanks,

Barb

  • April 26, 2010
  • Like
  • 0

In my apex code am catching page paremeter using  System.currentPageReference() Like that

 

System.currentPageReference().getParameters().get('Id'); every thing works fine for me,but when i run forc.com security on this code i got security report i have some security loop holes.how to handle this type of issue.

 

thanks

Gopi

  • April 01, 2010
  • Like
  • 0

We ran into a cross site scripting vulnerability and found out it was a problem caused by a bug in the Microsoft ASP.net Ajax Control Toolkit <http://www.asp.net/(S(vovsvx454o5rex452c4ypcy3))/ajax/>.  We were able to implement and verify a fix since this is an open source project.
 
We realize this security bug will potentially affect other Salesforce AppExchange applications that use the Microsoft ASP.net Control Toolkit hence this post.

 

Here are the details from the Burp scanning report

 

The value of the _TSM_HiddenField_ request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6b05b\'%3balert(1)//508e8ca2e0a was submitted in the _TSM_HiddenField_ parameter. This input was echoed as 6b05b\\';alert(1)//508e8ca2e0a in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.

 

The mitigation is two fold:
1) Encapsulate the request parameter in double quotation marks
2) Validate the request parameter and trim any potential malicious data

 

The patch is available at http://ajax.codeplex.com/Project/Download/FileDownload.aspx?DownloadId=108879

 

Thanks,

Frederic de Vedrines

 

http://www.nirvaha.com

As an application developer, you may run into a use-case where the application must run in system context ("without sharing"), thereby bypassing org sharing rules. You must ensure that the org administrator explicitly approves any such behavior. 


The recommended way of achieving this is by using the Force.com ESAPI: http://code.google.com/p/force-dot-com-esapi/  


You must first create a custom field (preferably boolean) only accessible by an Admin user that stores the preference (Bypass Sharing: Yes/No). Then at runtime, call one of the following functions to set with/without sharing based on that setting.
 
http://force-dot-com-esapi.googlecode.com/svn/trunk/doc/SFDCAccessController.html#setSharingMode%28SFDCAccessController.SharingMode%29
http://force-dot-com-esapi.googlecode.com/svn/trunk/doc/SFDCAccessController.html#SFDCAccessController%28SFDCAccessController.SharingMode,%20SFDCAccessController.OperationMode%29


The first approach is to set the sharing mode on an existing SFDCAccessController object. (such as used with the ESAPI.accessController() - this function returns a static SFDCAccessController object)


If (org admin setting is with sharing)

     ESAPI.accessController().setSharingMode(SFDCAccessController.SharingMode.WITH);

else

     ESAPI.accessController().setSharingMode(SFDCAccessController.SharingMode.WITHOUT);


// later in the code

ESAPI.accessController().updateAsUser(c, new List<Schema.SObjectField>{Contact.LastName});



The second approach is to use the constructor that allows setting the sharing mode. In this approach, create a SFDCAccessController object and set it to whatever sharing mode the org admin wants. 


SFDCAccessController ac = null;

If (org admin setting is with sharing)  

     ac = new SFDCAccessController(SFDCAccessController.SharingMode.WITH, SFDCAccessController.OperationMode.ALL_OR_NONE);

else

    ac = new SFDCAccessController(SFDCAccessController.SharingMode.WITHOUT, SFDCAccessController.OperationMode.ALL_OR_NONE);


// later in the code

ac.updateAsUser(c, new List< Schema.SObjectField>{Contact.LastName});


Note that in both cases you can also allow for inherit sharing.







 

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something.

 

Unfortunately, not too many automated web-application testing tools are effective in identifying CSRF vulnerabilities. A new "tool" for creating proof-of-concept CSRF attacks was released recently called Pinata. It is written in Python and designed to take a HTTP request for the vulnerable Web page and turn it into a HTML file containing the CSRF attack. It works for both GET and POSTs and can be helpful during testing. 

Some web-applications require the ability to make persistent connections with salesforce.com (SFDC) for scheduling batch updates, data processing, etc. In such cases, authenticating with the SFDC Session ID will not work, because sessions expire after a period of inactivity.

 

The legacy method to overcome this challenge was to store SFDC usernamespasswords and security tokens within the web-application integrating with SFDC. However, there are many reasons why users should not share their private credentials. Giving your SFDC username and password to a third-party for accessing data is the same thing as going to dinner and giving your ATM card and PIN code to the waiter when its time to pay. Additionally, if you want to revoke access from one of the applications, you will need to change your password, which may break other integrations.

 

 

SFDC now supports OAuth to provide a secure method for SFDC customers to grant third-party applications delegated access without sharing their passwords.  This is done usingtwo sets of credentials: the Consumer (web-application) identifies itself using its Consumer Key and Consumer Secret, while the User (SFDC user) is identified by a Token and Token Secret. Each setConsumer Key-Secret and Token-Secretcan be thought of as a username-password pair (one for the application and onefor the end-user). But while the Consumer credentials work much like a username and password, the User is represented by a Token which is different than their actual username and password. This allows the Service Provider and User greater control and flexibility in granting Consumer access. For example, the User can revoke a Token without having to change passwords and break other applications.The decoupling of the Users username and password from the Token is one of the most fundamental aspects of the OAuth architectureA general overview of OAuth is available athttp://hueniverse.com/oauth/. SFDC specific implementation guidance is available within the 'Help' documentation once you are signed into your SFDC account (search for keyword "oauth" ).

 

As an ISV ("customer" ), here are some key items to be aware of:

 - A consumer key and secret created in an org are global .i.e. they could be used by a user to negotiate access for that consumer to any Org, as long as the user has credentials

- A consumer key / secret can only be included in a managed package (no unmanaged package support)

- When a consumer key / secret is packaged, it can only be used with an org that has that managed package installed

- At runtime, when an access token is negotiated for a consumer that belongs to a managed package, the access token is scoped to the user's Org, with the CRUD/FLS permissions of the user as well as the package access permissions granted upon installation being enforced.

Some applications may require storage of sensitive data within Force.com. This includes usernames, passwords, authentication keys, credit card numbers, social security numbers, etc. Hiding these fields from specific page layouts does not provide adequate protection since these fields remain accessible via the API, unless otherwise protected using CRUD & FLS settings.

There are two ways to protect sensitive data within Force.com:

 

Custom Settings (Preferred): 
Custom settings are similar to custom objects and enable application developers to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. However, setting the visibility of the Custom Setting Definition to “Protected” and including it in a managed package ensures that it’s only accessible programmatically via Apex code that exists within your package. 

In order to allow authorized users to create and update sensitive information, create a Visualforce page that only accepts input and does not render the value back on the page. The “transient” keyword should be used to declare instance variables within Visualforce controllers to ensure they are not transmitted as part of the view state. Please refer to the following link for details: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_keywords_transient.htm
Finally, configure the security settings for this page to ensure it’s only accessible by limited profiles on an as needed basis.

For more information, search for "Custom Settings" under Help & Training within any Salesforce org.
 
Encrypted Custom Fields:
Encrypted custom fields are text fields that can contain letters, numbers, or symbols but are encrypted with 128-bit keys and use the AES algorithm. The value of an encrypted field is only visible to users that have the “View Encrypted Data” permission.

The disadvantage of this method to protect data is that you must request salesforce.com to enable encrypted fields on a per-org basis. Additionally, such fields are always accessible by administrative users.

 

If your web-application allows users to upload custom HTML and Javascript content (email templates, custom sites, attachments, etc.), you must ensure that adequate protections are in place to prevent users from launching XSS attacks (privilege escalation, data-leakage, cookie theft, etc.) against other users of the application. Additionally, if your application is vulnerable to CSRF, the attacks can be carried out by malicious (unauthenticated) users. 


There's a number of different approaches that be taken to address this security concern:


1) Alternate domain (Recommended)
Let’s say cookies are scoped to
https://app.site.com.  Even if customers can upload arbitrary content, you can always serve the content from an alternate domain that is outside of the scoping of any trusted cookies (session cookies and other sensitive information).  As an example, pages on https://app.site.com would reference customer-uploaded HTML templates as IFRAMES using a link to https://content.site.com/cust1/templates?templId=13&auth=someRandomAuthenticationToken

The authentication token would substitute for the session cookie since sessions scoped to app.site.com would not be sent to content.site.com.  This is exactly the method that salesforce.com uses for our content product.

2) Alternate syntax
Some products, like wiki’s, have an alternate syntax that can be used by clients to indicate particular markup and formatting.  This allows clients to format content without directly using HTML.  Server-side rendering is done to translate the non-HTML markup into safe HTML.  Many WYSIWYG editors support such alternate markup syntax.

3) Whitelisting
The last option that I’m aware of is to “sanitize” HTML input from users.  Basically, you maintain a whitelist of allowed tags, the allowed attributes for each tag, and validation/transform routines for each attribute and each tag.  HTML sanitization can be very complicated and this technique becomes heavily browser dependent.   You also have other practical problems like the handling of invalid and unparsable HTML.

The best example of this technique in the wild is Gmail.  I’d suggest sending an HTML email containing every possible HTML tag, each with every possible HTML attribute, to a Gmail account and reviewing the changes that Gmail makes on the HTML delivered to the user.   You’ll see that there is a significant amount of logic that goes into sanitizing HTML.  It is a hard problem to fix correctly.


 

If you are integrating external (composite) apps with the Force.com platform, be sure to validate legitimate salesforce.com SOAP servers. Below is the regex to effectively implement this:
 
https://[^/?]+\\.(sales|visual\\.)force\\.com/services/(S|s)(O|o)(A|a)(P|p)/(u|c)/.*

Basically, this will ensure that the URL must start with ‘https://’, followed by a character other than ‘/‘ or '?' for 1 or more times, followed by a ‘.’, followed by ‘sales’ or ‘visual.’, followed by ‘force.com/services/SOAP/’, followed by ‘u’ or ‘c’, followed by ‘/’

It whitelists the following domains:

https://*.salesforce.com/services/SOAP/u
https://*.salesforce.com/services/SOAP/c
https://*.visual.force.com/services/SOAP/u
https://*.visual.force.com/services/SOAP/c
 
If you have any questions about this, please do not hesitate to contact me.

 

Varun Badhwar

Force.com Security Manager 

Message Edited by vbadhwar on 05-15-2009 10:07 AM
Message Edited by vbadhwar on 09-28-2009 10:20 AM
Message Edited by vbadhwar on 09-28-2009 10:21 AM

Hi Guys,

 

I need some help. We developed a Composite (Hosted) application that integrates with Salesforce. It's time for security review submission. We went through the requirements - http://wiki.developerforce.com/index.php/Security_Review. OWASP Top Ten Checklist and Requirements Checklist evaluated. We have followd the policies described on the page as closely as possible but we do not meet all of them a 100 %. For example we do not have a company wide security policy.

We have also run the Burp scanner.

 

Is there anything else that we should do?

 

Does Salesforce require a minimum unit tests code coverage for Composite (Hosted) applications? Does Salesforce require any information about our security policies prior to security review and if so, what kind of information?

 

Thank you in advance!

Hi guys,

We are developing a managed package which we would like to prepare for a security review.

In the package we have logic in a one VF page's controller which returns a PageReference object and redirects to another VF page. We want to be able to pass the record id from the first page to the second page and we are currently doing that by adding the id to the url as a parameter string.

We have a problem with security review with this approach. I wandered what would you recommend to make that more secure.Probably a session inside of SalesForce or encrypt the id or how?

 

Thanks,

Kos

  • December 02, 2010
  • Like
  • 0

I try to enter to vf page as Administrator and I can.

 

When I try to enter as Standard User I get this message:

 

sObject type 'RevokeEvent__c' is not supported.

 

Can someone help me?

  • November 24, 2010
  • Like
  • 0

Salesforce made this big to-do about the "Hack into Dreamforce" contest, which stipulated that you needed to submit your app between x and x dates, and that the app with the most downloads would win.  So...what they didn't say, is how long the security reviews are taking.  I submitted one a week ago, for a package that has less than 500 lines of code.  Still waiting.  So can someone on the review team post the average turnaround time?  Yes this was submitted during the window, but it can't get onto the AppExchange until you're done, and thus the number of downloads is limited every day it's sitting there...

As an application developer, you may run into a use-case where the application must run in system context ("without sharing"), thereby bypassing org sharing rules. You must ensure that the org administrator explicitly approves any such behavior. 


The recommended way of achieving this is by using the Force.com ESAPI: http://code.google.com/p/force-dot-com-esapi/  


You must first create a custom field (preferably boolean) only accessible by an Admin user that stores the preference (Bypass Sharing: Yes/No). Then at runtime, call one of the following functions to set with/without sharing based on that setting.
 
http://force-dot-com-esapi.googlecode.com/svn/trunk/doc/SFDCAccessController.html#setSharingMode%28SFDCAccessController.SharingMode%29
http://force-dot-com-esapi.googlecode.com/svn/trunk/doc/SFDCAccessController.html#SFDCAccessController%28SFDCAccessController.SharingMode,%20SFDCAccessController.OperationMode%29


The first approach is to set the sharing mode on an existing SFDCAccessController object. (such as used with the ESAPI.accessController() - this function returns a static SFDCAccessController object)


If (org admin setting is with sharing)

     ESAPI.accessController().setSharingMode(SFDCAccessController.SharingMode.WITH);

else

     ESAPI.accessController().setSharingMode(SFDCAccessController.SharingMode.WITHOUT);


// later in the code

ESAPI.accessController().updateAsUser(c, new List<Schema.SObjectField>{Contact.LastName});



The second approach is to use the constructor that allows setting the sharing mode. In this approach, create a SFDCAccessController object and set it to whatever sharing mode the org admin wants. 


SFDCAccessController ac = null;

If (org admin setting is with sharing)  

     ac = new SFDCAccessController(SFDCAccessController.SharingMode.WITH, SFDCAccessController.OperationMode.ALL_OR_NONE);

else

    ac = new SFDCAccessController(SFDCAccessController.SharingMode.WITHOUT, SFDCAccessController.OperationMode.ALL_OR_NONE);


// later in the code

ac.updateAsUser(c, new List< Schema.SObjectField>{Contact.LastName});


Note that in both cases you can also allow for inherit sharing.







 

Hi,

 

We have a application built in Asp.Net which we are planning to display inside salesforce in Tab.

do we require to do Security Review for this application if keep it private and do not Publish it on Appexchange?

 

 

Any help will be appreciated ..

 

Thanks

Anand 

 

Hi,

 

I have an application in Japanese AppExchange. I want to list the application in the English AppExchange. Fo this I will build the same application in a separate Salesforce account and submit it Salesforce security review. I have following set of questions on this issue.

 

Will I automatically pass the security review because same application is listed in Japanese AppExchange (passed security review)?

Is there a special process for this kind of listings?

Do I have to pay again for the security review for the English AppExchange ?

Are there any other additional fees involved this process ?

 

Thanks

Viraj

 

 

  • June 15, 2010
  • Like
  • 0

I need to find a way to monitor / stop my users data exports. We work in a sales environment where staff could leave and take their customer list with them when joining a competitor. Currently salesforce has no way to allow me to track who has exported what and recover it. Does anyone have any recommendations of add ons from appexchange or other companies that I could look at? I have found a company called "Outprotect" which could fit the bill. All suggestions and comments welcomed.

 

Paul

Is it safe to store Credit Card information in an org?  I have created a Payment object and want to capture credit card information (i.e., CC number, expiration date, etc.).  I know that I can secure these fields within Salesforce, but are there any other security issues that I should be concerned with?  Eventually, we will use some type of online credit card processing but was wondering if this would work until then.

 

Thanks,

Barb

  • April 26, 2010
  • Like
  • 0

In my apex code am catching page paremeter using  System.currentPageReference() Like that

 

System.currentPageReference().getParameters().get('Id'); every thing works fine for me,but when i run forc.com security on this code i got security report i have some security loop holes.how to handle this type of issue.

 

thanks

Gopi

  • April 01, 2010
  • Like
  • 0

Is there any setting that allows you to disable the Identity Confirmation  (the email activation link) sent to a user when logging in from a new computer?

 

thanks! 

  • March 17, 2010
  • Like
  • 0

We submitted an application for security test we are getting different time different results from the tool.Some day back we passed test ,now it shows some minor fixes .How any ISV can follow inconsistent security test tool.

  • March 11, 2010
  • Like
  • 0

We ran into a cross site scripting vulnerability and found out it was a problem caused by a bug in the Microsoft ASP.net Ajax Control Toolkit <http://www.asp.net/(S(vovsvx454o5rex452c4ypcy3))/ajax/>.  We were able to implement and verify a fix since this is an open source project.
 
We realize this security bug will potentially affect other Salesforce AppExchange applications that use the Microsoft ASP.net Control Toolkit hence this post.

 

Here are the details from the Burp scanning report

 

The value of the _TSM_HiddenField_ request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6b05b\'%3balert(1)//508e8ca2e0a was submitted in the _TSM_HiddenField_ parameter. This input was echoed as 6b05b\\';alert(1)//508e8ca2e0a in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.

 

The mitigation is two fold:
1) Encapsulate the request parameter in double quotation marks
2) Validate the request parameter and trim any potential malicious data

 

The patch is available at http://ajax.codeplex.com/Project/Download/FileDownload.aspx?DownloadId=108879

 

Thanks,

Frederic de Vedrines

 

http://www.nirvaha.com