New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request body disrupted due to issues with 944220 #1185

Open
dune73 opened this Issue Sep 9, 2018 · 7 comments

Comments

Projects
None yet
4 participants
@dune73
Collaborator

dune73 commented Sep 9, 2018

As mentioned during the community chat, I have isolated an issue with the new JAVA rules in connection with chunked JSON payloads that lead to ModSec cutting a response short.

There is a certain chance that special local configuration of when the JSON body processor is called is playing into this.

I am not yet able to reproduce it, but it's definitely there and should be fixed before 3.1. I'm working on this.

Type of Issue

  • Disruption of payload

Description

See above. More information will be added here.

Your Environment

  • CRS version 3.1-RC1
  • ModSecurity version 2.9.2
  • Apache 2.4.34, self compiled
  • RHAT
  • The payload is sent chunked. Thus no content-length is known for the POST request.

@dune73 dune73 self-assigned this Sep 9, 2018

@dune73 dune73 added this to the CRS v3.1.0 milestone Sep 9, 2018

@dune73

This comment has been minimized.

Collaborator

dune73 commented Sep 27, 2018

I am still working on this bug. I was able to confirm it, but I was not able to reproduce it without the help of a commercial user-agent that bumped into the problem first.

@csanders-git

This comment has been minimized.

Collaborator

csanders-git commented Sep 27, 2018

let me know when you track it down a bit more.

@dune73

This comment has been minimized.

Collaborator

dune73 commented Sep 27, 2018

Will do. Keeping my fingers crossed I'll manage. I'm a wee bit desperate here. Can't sniff the traffic so far and audit-log does not show the payload. :(

@dune73

This comment has been minimized.

Collaborator

dune73 commented Oct 2, 2018

Outcome of community chat on slack last night:

@lifeforms feels the first regex in the chained rule could be the reason for the bug. Given the payload, @dune73 supports this idea.

For 3.1, we will drop the rule in favor of 944240 that has a very similar purpose.
@dune73 will handle the PR and @lifeforms will review and merge.

If @dune73 manages to consistently reproduce this, we will contact @victorhora / TW.

@spartantri

This comment has been minimized.

Collaborator

spartantri commented Oct 5, 2018

Hi @dune73,
Have you tried to use burp interception proxy in transparent mode? that way you set burp in a local port and it will forward everything to the modsec server and you get a full capture of the traffic.
What is this issue about?
I have been very busy so got out of the loop.

@dune73

This comment has been minimized.

Collaborator

dune73 commented Oct 5, 2018

The commercial user-agent running into this problem is a Windows fat client. So far we did not manage to get access to the local port in order to dump the traffic. This might be me or the guys running the client, but it's still a roadblock.

We believe this bug is a rare ModSec bug due triggered by a labour-intense rule, 944220, under very rare conditions that we can not reproduce with standard tools.

@dune73

This comment has been minimized.

Collaborator

dune73 commented Oct 5, 2018

This is solved in #1198 as planned above (Removal of rule 944220).

The difference between 944240 and 944220 is the two keywords runtime and processbuilder that are missing in 944240.

@lifeforms lifeforms modified the milestones: CRS v3.1.0, CRS v3.2.0 Oct 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment