You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 14, 2020. It is now read-only.
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.
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
The text was updated successfully, but these errors were encountered: