Jump to content
Welcome to our new Citrix community!

WAF blocks Content-Type


Recommended Posts

Hello,

 

we have a webservice protected with waf 13.0 build 83. Our developer want to send requests with Header Content-Type text/xml but this would be blocked from the waf. If i disable the waf policy from the vserver, the requests works.

If the developer sends the Content-Type "application/x-www-form-urlencoded" then it works also.

 

I found this article https://docs.citrix.com/en-us/citrix-adc/current-release/application-firewall/content-type-protection.html

 

But adding the content-type text/xml to the waf profile with 

 

bind appfw profile profile1 -contentType "text/xml"

doesnt work. Is this known? Or do i something wrong?

 

It is interesting, that i dont see the configuration change in the waf profile. The gui also has no button to change the content-types. Perhaps a bug?

Edited by Stefan Wendrich
Link to comment
Share on other sites

14 hours ago, Rhonda Rowland1709152125 said:

The 3 content types in the default list don't change. Hit the Manage Content-Types button to adjust more. (one section up)

 

Thanks for your support, but which button do you mean? I only see the button "Manage Content-Type for Safe Commerce". But these are only Response Content-Types. The desired button "Manage Content-Type" isnt there. Or i cant see it. Sorry.

Link to comment
Share on other sites

Sorry, I was referring to:  "Manage Content Types of Safe Commerce"

But I missed you were discussing post/requests and was thinking of responses only.

 

Executing the command:

bind appfw profile profile1 -contentType "text/xml"

Will set the "default request" content type and so the "Default Request" field should be filled in under the profile settings > content type section in screenshot above.  

 

If it is in the cli, but not in the GUI it *might* be a GUI display bug that has no impact on functionality (meaning gui isn't rendering field) OR every time you close the profile in the GUI the GUI isn't rendering field and it then "clears" the value from the CLI config again any time profile changes are made.  So you would either need to change builds or work with Support to find out.  In the short term configure setting in cli and don't edit in GUI to see if it makes a difference for this particular test case.

So, not sure if you are seeing a bug or just not the right solution to your scenario.

 

Regardless, you might still need an additional setting to address this (even if the value is in effect):

Alternative configs that might help you get around this behavior (without more information):

1) Configure File Upload Types Relaxation Rule for Text against this URL

2) Try adjusting the malformed request action at the profile level:  from RFC_Block to RFC_Bypass (doesn't mean you'll keep this setting, but it may indicate that there is something non-compliant in the request you are using.)

3) Other option, is to bypass POSTS from inspection (or use content switching to separate these specific requests from appfw while protecting everything else. (Also a profile setting)

 

To investigate the root cause (if it isn't just the setting not being applied)

1) What violation if any is being logged in syslog?

2) Do you have an example of the complete request headers?  If there is something else malformed in the request or multiple headers, then you could be stopped by a different problem.

3)  Finally, enable the nstrace option in the appfw profile and do an app firewall enabled nstrace (there is an appfirewall flag) and see if the block is on a different aspect of the request than what you expect and if there might be a different mime type not included in your list.

 

 

 

Link to comment
Share on other sites

On 12/3/2021 at 4:04 PM, Rhonda Rowland1709152125 said:

Executing the command:

bind appfw profile profile1 -contentType "text/xml"

Will set the "default request" content type and so the "Default Request" field should be filled in under the profile settings > content type section in screenshot above.  

 

This is what i tried first. But it doesnt change anything. The behavior is the same as before. 

 

Strange is, that the blocked request is nowhere logged. Neither in ns.log, syslog, or citrix ADM.

 

If i change the request to GET, the request works, but my webservice needs a POST request. So this is not a solution.

 

 

On 12/3/2021 at 4:04 PM, Rhonda Rowland1709152125 said:

 

2) Try adjusting the malformed request action at the profile level:  from RFC_Block to RFC_Bypass (doesn't mean you'll keep this setting, but it may indicate that there is something non-compliant in the request you are using.)

 

 

This doesnt change the behavior.

 

On 12/3/2021 at 4:04 PM, Rhonda Rowland1709152125 said:

To investigate the root cause (if it isn't just the setting not being applied)

1) What violation if any is being logged in syslog?

2) Do you have an example of the complete request headers?  If there is something else malformed in the request or multiple headers, then you could be stopped by a different problem.

3)  Finally, enable the nstrace option in the appfw profile and do an app firewall enabled nstrace (there is an appfirewall flag) and see if the block is on a different aspect of the request than what you expect and if there might be a different mime type not included in your list.

 

1) not logged anything

 

2)  see here the timeline from Insomnia

POST /apex/rest/vekuw01/export HTTP/1.1
> Host: ws.domain.de
> User-Agent: insomnia/2021.6.0
> Cookie: NSC_TMAS=99bd92c6a80eead8c5f3e95246091e6c; NSC_TMAA=525c75c00d7e7253a7cfe48bceee6116; citrix_ns_id_.domain.de_%2F_wlf=AAAAAAUhB3aT2IDDuYRvQKH0h_mmvDbLtiBmWjlcJ56khSOz6rgT4nPzuIxZOJqPcV7zvkWvSKuO9yHk7W5Dtdsky4sf&; citrix_ns_id=AAE7dsKpYTtuAAAAAAAAADt6OtDYNl3WJSd8O6QEsbXZdWZtjqGjqxrbftt_Qs1uOw==
> Content-Type: text/xml
> Authorization: Basic c3RlQ==
> Accept: */*
> Content-Length: 30

| <test>
| 	<bla>bla</bla>
| </test>

* upload completely sent off: 30 out of 30 bytes
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body

< HTTP/1.0 302 OK
< Pragma: "no-cache"
< Location: /
< Connection: close

 

3) i tried it, but also in the trace file i cannot find any appfw informations. But the documentation says, that only html requests are logged with informations. XML requests not.

Link to comment
Share on other sites

Are you using a Web or Web + XML (former Web 2.0) profile type? (Never mind I saw XML in the original screenshot; are any of the xml security checks enabled for block/log/stats?)  If LOG is enabled, then we should see if any xml violations are occurring.

text/xml is processed by the XML Format Checks (web services checks)

 

Is the client browser reporting the multiuse error OR is the server reporting this after receiving request?   IF its getting to server, then appfw didn't block it, which might explain no logging. There still might be a change to request by the appfw that is happening that is causing the problem.  The error itself indicates a bad "multi-part" formatted request?  Whether that is the original request or the appfw handling of the request making the change...I can't tell. Whether the appfw is blocking the request or the server is, is also I can't tell from here.  

 

You can also supply an XML error response to see if the XML violations are in effect as opposed to a default response. If the XML checks are catching this, then it might give you some information that we haven't looked at.

 

At this point, I don't know why your specific request is being blocked by appfw.  You may need to log a ticket with support to see if it is build specific or see if the behavior is different on a different build.   If this is in fact a by design behavior, then you would need to exempt this particular content from inspection while still protecting the rest of the site.   I wish I had something that would work and sorry that none of the above affected it.

 

Even without the AppFw trace the network trace might still give you more insight into which stream exactly is terminating at the ADC to narrow down the nature of the problem.  Be sure to use the "trace filtered connections peer traffic" to get complete trace of client to adc/adc-to-server and back again.

 

 

Link to comment
Share on other sites

  • 2 weeks later...

I "solved" the issue with citrix support. But i cant really understand it. We removed the XMLContentType .*/xml from global appfw settings. After that it works.

 

The official statement is 

Quote

As we discussed the reason we don't see the log for this request as blocked or not blocked is this needs fine-tuning not from the Security Checks part rather Profile of WAF which is meant to be tuned for big file sizes download uploads not working images not loading. The streaming function is one such config that is enabled for this.

This is not an issue as WAF by design won't log such traffic related to performance.In our case, I have just allowed .*.xml to passthrough in future when you switch WAF to block you will have to deploy learned rules for it.

 

 I find this behavior very intransparent for me as admin. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...