10

Here are your answers: Salesforce has a license to run Checkmarx scanners on premise in order to scan third party code. The code never leaves Salesforce -- it is pulled from the organization in which your code resides to the Checkmarx instances running on our servers. We manage these instances, but it is a Checkmarx scanner engine underneath. Results are ...


7

From my personal experience as an ISV employee, I can say that this is pretty normal during the weeks leading up to a release. Here's the problem: ISVs are given about a month before the release hits to submit bugs, fix their own bugs, scan for security reviews, etc. All those ISVs are busy running scans and so on to make sure their code won't break in the ...


6

Your page's javascript is effectively using the eval style of deserializing JSON which has been frowned upon in general ever since browsers started having pretty widespread support for JSON.parse. If you don't need to support old versions of IE (and if you do there's polyfils) it's really, really a better idea to do something like var recent = JSON.parse('{...


6

You should not fail the security review because of this, as rich text areas are safe types to render unescaped. Other safe types are listed in the secure coding guidelines. However be aware that what determines the safety of the data type is not the input type in the visualforce page but the data type in your object model. Make sure it's really an RTF type. ...


5

Performing any DML during a page's action method is a security concern. This is because people can cause your code to run without the user's consent. For example, consider what happens if someone puts this HTML into an email, or a page on a website, etc: <img src="https://na1.visual.force.com/apex/MyPage?id=12345" /> Even though no image will appear, ...


5

They don't explicitly state what format they run the scanner in, but I would be very surprised if salesforce didn't have their own checkmarx server on their internal network that does the scanning. In other words, it's very likely to be a server under salesforce's control, but running the checkmarx application on it. If you're really worried about where the ...


5

I believe its because you are using an unescaped output in your JS $j('#h{!category}').css("background-color","{!entity.CPHeader__c}"); . Instead use the JSENCODE formula $j('#h{!category}').css("background-color","{!JSENCODE(entity.CPHeader__c)}"); for further details see https://developer.salesforce.com/page/Secure_Coding_Cross_Site_Scripting#S-...


4

The 'Reflected' part of reflected XSS vulnerabilities usually means that a parameter going into the page is being echoed back in the response exactly as is, the issue being that if an attacker were to put JavaScript into the parameter it'd end up on the page and being executed by the user's browser. Given that in this particular case you're outputting a ...


4

You really only have two choices: fix the code so it no longer generates the false positive, or live with it. The first almost always results in suboptimal code changes, such as purposefully calling String.escapeSingleQuotes on a String that's been previously filtered by a regular expression to never include quotes. I believe there are configuration options ...


4

Seems like a false positive. In most cases a method that accepts a single record and performs a DML Operation on it might be called in a loop, and hence be considered non-bulk-safe. However, considering this method is a RemoteAction, that concern seems misplaced.


4

Checkmarx is not "useless," and, in fact, is very good at what it does. However, that's not to say that false positives are not possible. It can make mistakes. However, whenever you get a flag like this, you should check and see if it is a legitimate problem or not. If it is a false positive, document it and go on. Flags are not automatic rejections for ...


4

This is almost certainly a false positive, although it may simply be complaining since your code does not explicitly handle the case where dsamList throws an error. I would advise simply ignoring this warning, or possibly reaching out to Checkmarx Support directly to find out why this error would have been generated. The only change I would recommend is to ...


3

If you are submitting your app for security review ,you will need to enforce CRUD-FLS for all your DML and SOQL since apex does not enforce it automatically. There is a blog post link below that shows how to enforce CRUD FLS https://developer.salesforce.com/page/Enforcing_CRUD_and_FLS You will use describe call to find the access level and prevent the DML ...


3

This looks like a false positive. There are false positives with every query, of course, and we regularly review these queries. Going forward, we are going to remove this query from our security preset.


3

Regardless of the possible effort you may have made already in APEX, in my experience checkmarx is expecting always any {!...} output in visualforce to be escaped using JSENCODE, HTMLENCODE, URLENCODE - that ruleset feels quite simple. So there may be false positives and you should be able to discuss it with the security review guys. Usually I just clamp ...


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

You need to use JSENCODE by itself, without trying to make your own JSON string, or you need to serialize the entire JSON object and use that instead. The reason why stripHtml4 and escapeSingleQuotes won't work is because they are the wrong solution to the problem at hand. If you don't encode the string, you can inject any sort of script you want from the ...


2

You want HTMLENCODE, that's the correct operator for use in CSS.


2

That is a warning rather than a specific error. The impact mostly depends on how the sendEmail method is called. E.g. If it is never called in a loop per Purchase_order__c and/or attachment you should be fine. If this is the case they you can just provide justification to Salesforce along this line. However, if it is call multiple times per transaction then ...


2

The issue is a bit complex. Yes, the path cited is a false positive, however in general Checkmarx will flag these only when there is a real issue. The error is that it is reporting too many paths. Here is what I mean: CSRF generally happens when you have a page action that performs a DML operation. That means you create a page, e.g. saveAccount.page, so ...


2

Checkmarx is going to flag this code for CSRF because the action is performed automatically with a GET Request (page load). The only solution is to move the code out of the page action and into an action triggered via user interaction, such as a form post. There is a suggestion to enabled CSRF protection for visualforce GET request but that's really ...


2

Try doing one thing, maybe it will solve your problem for now - Go to Your VF Page from Setup Click on Edit button Find "Require CSRF protection on GET requests" this option in your Page Information just above your vf code block Make sure you have checked this option to TRUE Save your page. I had faced same issue twice and was able to solve by only doing ...


2

The scanner is correct, a stored XSS attack is possible from that code. I don't believe this can be handled by HTMLENCODE() in your Visualforce. With that in mind, you probably need to use String.escapehtml4() in your controller to close the hole. Using User.Id for the value in your SelectOption isn't an issue, but if you were using a text field, some ...


2

You need to escape the values that you are using to construct the query to prevent an attacker supplying malicious data that would result in unexpected action or returning additional data fields. In your code, it appears you need to escape fmw.LeadFieldName using the String.escapeSingleQuotes() method.


2

Technically, you're at risk for SOQL injection, hence this error. You've mitigated it somewhat by only allowing a single word, but you might still run in problems if someone tries to use an apostrophe ("single quote"), such as 'hello. This would render the query filter as Name LIKE '%'hello%', which would cause an error. You need to remember to use String....


2

Another way to indisputably remove any injection vulnerability is to use a merge variable instead. 'WHERE Id = :originalId'


2

Fields and objects each have their own security. You are expected to check every object and field, e.g. MyCustomObject__c.field1__c.getDescribe().isCreateable(). You can simplify these checks with Security.stripInaccessible.


1

When building a dynamic query, always make sure the user can access the fields, otherwise they may expose data not meant to be seen: Map<String, SOBjectField> fields = SObjectType.Lead.fields.getMap(); for(Wrapper fmw: userSelectedValues) { SObjectField field = fields.get(fmw.LeadFieldName); if(field != null && field.getDescribe()....


1

The Security Scanner tool is not as great when it comes to Apex. I would ignore the reported error and implement the right way logically which is - Don't check Id isCreateable(). Yes, you should validate both isCreatable and isUpdateable for Upsert operation.


1

This is a false positive. In general, Checkmarx is not going to be able to understand patterns like this, given our current queries for CRUD/FLS.


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