Altostratus
EmployeeThe 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).
AltostratusI'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?
EmployeeHello 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
EmployeeYou 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.
AltostratusI 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.