Hot answers tagged

8

I have faced exactly same problem. Salesforce does not clearly tell you what need to scan and as being SFDC developer we go and scan na1.salesforce.com. Which is not required to scan with Burp. Your development on force.com must be scanned with Force.com Security Source Code Scanner If you are calling out any API from force.com then you should scan those ...


7

You can generally ignore informational BURP issues. The TE team should have a list of which BURP issues can be ignored and which need to be addressed. The following issues can be ignored, modulo caveats in comments: Informational issues about crossdomain.xml files/silverlight cross domain sharing or use of HTML 5 CORS. As long as the file/header is not ...


5

I personally didn't find much value in it. It was mostly done to satisfy the certification requirements. Burp as a tool doesn't seem well suited to testing web services vulnerabilities. It is more focused on the web sites/applicaitons. In my case there was a medium level warning about a possible XML injection risk as the web service was sending back a ]]&...


3

There is no specific temple/format as such. You should just make sure you address following points. Issue details why do you think its not issue If you have any other mechanism to handle issue then you should mentioned that in detail with all the code reference. Relevant Screen shots I had created my own temple but can not share due to IP restriction. ...


3

I don't think it's quoted as mandatory anywhere in the documentation but IMO, it's a like a de-facto standard and it's strongly recommended to do so. It is not explicitly mentioned in the Checklist either. There's even a free license available for qualifying partners here. Quoting from the official security documentation page Accuracy of Results ...


3

You do have to run the BURP scanner on 3rd party APIs and provide a report. It is not just limited to code written by you. There's more about how to use BURP in the documentation, including this how-to video. There is an exception. If the 3rd party is something that SFDC has scanned prior, they may not need you to provide a BURP report, so you can check ...


3

Did the Burp Scan report find anything? Either you should fix it and run the test again or provide justification in a false positives document about why you don't think it is a security risk? There is a good description of false positives in the Burp Suite Scanner About page. False Positives A false positive occurs when a bug is flagged as being ...


2

Since you have a some callouts, you should be using burp scan on those callout flows. Ideally that should be enough. As for your question, scan only your vf pages. Also I would suggest that instead of using spider and going for active scanning, go for passive one and do manual scanning since active one takes a lot of time and scans salesforce's components ...


2

Running the BURP report is mandatory if your application makes callouts to other services. When you submit the security review, you will eventually be asked to submit the BURP report along with it. Otherwise, you can save some time by running the BURP report ahead of time and submitting it with your initial submission. Here's another related SFSE post on ...


1

I was told that everything marked as Medium or Low needs to be either a) fixed b) explained So if you think they are false positive, you can upload your ZAP report, and then upload a word doc with an explanation for why they aren't valid errors for this scenario... EDIT - might be worth taking advantage of Security Review Office Hours to get more ...


1

There is an updated documentation on ISV Security guide on how to document the false positives . Check the documentation here .


1

BURP scanning is required for any & all external web components. To use BURP testing on an API/web service, you want to simulate API calls through BURP using SoapUI, Curl, or a similar tool. If you don't have it already you should submit a case through you ISV partner account to get a free BURP scanner license, or go here. Download and Install, then ...


1

There is no scan for the iOS app, but if your iOS app communicates with an external (non-SFDC) webservice, then you should scan the webservice using the iOS app to drive Burp as a proxy. You can do this by configuring your iOS device to connect to Burp as a proxy and then use the iOS app as intended to exercise all the interfaces of your webservice. Note ...


1

A callout in your apex code will go from the Salesforce instance to the endpoint and will not be routed through your browser, therefore setting your browser proxy to be Burp will not catch the endpoint. Rather, assuming that you tested this endpoint with some client -- even if the client is just curl commands, set the test client to use burp as a proxy (e.g....


1

You can use a tool that sends the requests for you. For example you can use cURL to send REST or SOAP requests. Follow the directions on the Cloud Security page in the "Effectively Scanning Applications Using Burp" section (copied here with modifications for cURL): Turn “Intercept” (Proxy->Intercept) off within Burp. Do not change other default ...


1

Your external web application will need to have a valid BURP scan run on it before you will be able to pass the security review process. I would recommend running it (you can request a partner license here) to see what comes up and if you feel you shouldn't need it contact your ISV Partner Account Manager in the background (you should have access to a ...


Only top voted, non community-wiki answers of a minimum length are eligible