ASM security policy with Atlassian Confluence

[Julie]

Has anybody configured an Atlassian Confluence server behind an F5 with ASM security? I find that it's getting LOTS of false positives that I'm hesitant to accept, mostly of the SQL injection variety (i.e. seeing the words "group" and "by" in a posted paragraph and assuming it's a "group by having" attempt). The method Confluence uses to post messages also makes ASM think it's trying to execute commands like at, ll, eval, etc. I can't set this site up for extended learning because the majority of the users will be external and can't be considered "trusted".

Any thoughts/recommendations?

[Simon_Blakely]

The first thing to check is to make sure that the correct Content Profile is being applied to the POST - usually either an XML or JSON profile. Once you get this right, many of the inappropriate violations get resolved, because ASM is no longer attempting to process XML/JSON as "FormData" (which is the default).

[Julie]

I've made sure that the JSON profile is is first in line, but looking more closely at this, I'm seeing that the problematic POST requests are coming in as

Content-Type: text/plain

with

Accept: application/json, text/javascript, */*; q=0.01

I'm assuming this explains why it's not parsing properly? Or should it be recognizing the content as JSON automatically?

[Ivan_Chernenkii]

Hello Julie,

Could you provide example of failed requests and configuration of "Header-Based Content Profiles" of URL in policy, which this request matches?

Thanks, Ivan

[Simon_Blakely]

You can just apply a JSON profile to a URL, if all the posts to that URL are going to be JSON (without using Header-Based profile selection).

Once the data is being interpreted correctly, the violations should be restricted to the specific parameters that hold text. You can then exclude those parameters from specific Attack signatures without disabling them from the entire policy.

[Julie]

I actually started doing that today, but Confluence is so monolithic, this path will probably be fairly time consuming. I was hoping there was an easier way, but I guess not. Thanks for the input.

[NickAD]

Hey Julie, just curioius as I am building a policy for this as well.. did you end up finding any easier way? Or did it really come down to adding the correct URLs with the associated content profiles. The Content-Type headers is more so what I am curious about... the fact that the I'd expect to see application/json but instead it is text/plain is so weird.

Can't find Atlassian docs that explain why the app behaves in that way. Or if there's a case where I'd see POST data using the text/plain header and the body isn't JSON.