Skip to content
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

Crazy Long Processing time of XML of a certain kinda payload body. #1724

Closed
CRS-migration-bot opened this issue May 13, 2020 · 3 comments
Closed
Labels
🐛 bug Something isn't working ⌛ Stale issue This issue has been open 120 days with no activity.

Comments

@CRS-migration-bot
Copy link

Issue originally created by user jeremyjpj0916 on date 2020-03-18 04:35:02.
Link to original issue: SpiderLabs/owasp-modsecurity-crs#1724.

Describe the bug

Seems an application/xml payload that uses lots of > and < chars in the place of the actual < >'s will cause insane WAF processing time(you end up with one fairly large XML element containing all this data as string in the long running XML one.

With regular < >'s keeping a full XML schema+elements the whole time: 3.7 seconds e2e on a 450kb payload for me.

With the > and < chars in the place of the actual < >'s: 40+ seconds e2e 549kb payload

Unsure currently what rule its hanging on, I suppose DEBUG mode would give us some insight on where eats the most time.

Steps to reproduce

Non-issue case HTTP Post body example:

WorkingPayload.txt

Issue case HTTP Post body example:

ShrektPayload.txt

Expected behaviour

Would have not expected WAF to hang and process on the XML body this long.

Actual behaviour

Additional context

Your Environment

  • CRS version (e.g., v3.2.0): 3.2/master
  • Paranoia level setting: PL 1
  • ModSecurity version (e.g., 2.9.3): 3.0.4
  • Web Server and version (e.g., apache 2.4.41): NGINX
  • Operating System and version: Linux Alpine
@CRS-migration-bot CRS-migration-bot added the 🐛 bug Something isn't working label May 13, 2020
@CRS-migration-bot
Copy link
Author

User jeremyjpj0916 commented on date 2020-03-19 05:15:09:

Update: Did remove 200000 on my test for this call to see if it removed the slowness(ModSec XML Parse rule), and it did not make things faster.

@CRS-migration-bot
Copy link
Author

User jeremyjpj0916 commented on date 2020-03-19 06:30:35:

Ran some more tests tonight, nothing fixed it until I straight up disabled the engine:

# Had to disable to fix the "slow processing" issue.
SecRule REQUEST_URI "@contains /ExampleService/v" \
    "id:14,\
    phase:1,\
    t:none,\
    pass,\
    nolog,\
    ctl:ruleEngine=Off,\
    ctl:ruleRemoveById=920273,\
    ctl:ruleRemoveById=920272,\
    ctl:ruleRemoveById=920260,\
    ctl:ruleRemoveById=920240,\
    ctl:ruleRemoveById=931110,\
    ctl:ruleRemoveById=200000,\
    ctl:ruleRemoveById=920470,\
    ctl:ruleRemoveTargetById=941160;XML:/*"

URI edited for privacy reasons here :P . But yeah unsure where the slowdown is...

@github-actions
Copy link
Contributor

This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days

@github-actions github-actions bot added the ⌛ Stale issue This issue has been open 120 days with no activity. label Sep 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working ⌛ Stale issue This issue has been open 120 days with no activity.
Projects
None yet
Development

No branches or pull requests

1 participant