Forum Discussion

daboochmeister's avatar
Aug 31, 2018

Any experience with ASM policy affecting response stream (with no vulnerability/attack signature noted)?

Env: LTM 11.5.2, physical appliance (4200), no resource issues

 

We are experiencing cases where the presence of an ASM security policy is affecting the response to clients, even though the event log shows the access involved as successful, with no attack signatures/violations noted, and even though the response log shows the response content body being sent back. It is demonstrably the security policy that's the cause, though - when the policy is removed from the virtual server, the issue goes away, and vice versa.

 

Casting a wide net - has anyone experienced anything similar, and what was the cause? Any tips on how to debug this (other than the obvious tcpdump capture, which we are pursuing)? Any hypotheses on a possible cause?

 

If it helps, it may be related to the size of the response - there's a loose association, with bigger responses triggering it more often, we think. (problem with chunked encoding? Hmm, may try a re-encode strategy)

 

Any thoughts appreciated, thx!

 

2 Replies

  • I should have clarified - the clients seem to receive the response headers, but then no response content, not even a single byte. Still working on tcpdumps on both sides, but via e.g. curl access, the headers stream back (the last header being "Transfer-Encoding: chunked", followed by two carriage returns) - then nothing else.

     

  • It depends on your ASM Policy. Several features in ASM depend on things like injecting JavaScript into responses which may potentially break the content from rendering in the browser (should not affect the tcpdump though).

     

    Such features include Web Scraping, CSRF protection, device fingerprinting, Bot Defense / Client-Side Human User Indicator /CAPTCHA etc...

     

    So instead of removing the ASM policy completely the recommendation is to switch off off the features and violations which may interfere with response first.

     

    Also try your application with the most basic policy such as Rapid Deployment Template.

     

    Also check Support Knowledge base, for example this article:

     

    K11040: Certain HTTP profile Response Chunking settings interfere with BIG-IP ASM and BIG-IP WebAccelerator processing