AntiSamy detection

[simon.mcclenaha2]

How does the Fortify scanner detect AntiSamy is in use? For some issues I see a taint flag ANTISAMY_VALIDATION, when and how is this used?

I have projects that implement AntiSamy to address the XSS:Reflected issues, but they don't go away. I have to use a custom DataCleanse rule to stop them from showing up. It would be nice if Fortify correctly detected AntiSamy so XSS issues would not be created.

[Score]

Hi Simon, I've just had a quick chat with a member of our research team. When we detect AntiSamy is being used we add the ANTISAMY_VALIDATION flag but we also add one of the +VALIDATED_CROSS_SITE_SCRIPTING... variants. As such we'd expect it to show a lower priority XSS:Poor Validation issue. This means that it's protected against XSS depending on the context - which static analysis can't know or at least can only know a small amount.

In this case it's possible that the structure of the code means that we're only triggering a passthrough rule for some reason, or that we're actually missing a rule for this specific API.

I would recommend opening a Support Case for this issue, either through https://support.fortify.com or by dropping an email to fortifytechsupport@hp.com. Including either a code snippet or a code sample showing how AntiSamy is being used. This will allow us to take a much closer look and submit any necessary enhancement/bugfix requests.

[simon.mcclenaha2]

But how is it detected? That is exactly what I want to happen, adding +VALIDATED_CROSS_SITE_SCRIPTING variants to reduce/eliminate false positives for XSS:Reflected, at least Critical severity.

[Score]

Unfortunately I can't post any internals of the Fortify rulepacks as they're confidential. However we detect it in the same way all validation functions are detected by the SCA rules - if the use of an AntiSamy function matches a pattern specified in the rules we should add both the ANTISAMY_VALIDATION and +VALIDATED_CROSS_SITE_SCRIPTING  flags.

In this case it seems something's missing and we're not seeing the behaviour we'd expect. It could potentially be due to some construct in the code or even that SCA is missing an AntiSamy rule to cover the particular API you're using. As such we really need further information showing how you're using AntiSamy, so if you could open a Support case with a snippet or example we'd be able to investigate further.