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
We identified an issue with the parser for data files from OWASP CRS that we upgraded to and have been testing. It seems that comments at the top of the file aren't actually ignored and actually submitted to matching.
I think the issue is with ac.cc, the phrase match operator. All .data files are converted into ac objs. It doesn't handle #https://github.com/Edgio/waflz/blob/master/src/op/ac.cc#L774C8-L774C8. The way I always used data files from owasp was to remove any comments from data files. A simple oneliner in bash for i in $(ls *.data); do sed -i '/^\s*#.*$/d' $i; done. I think a comment block can be handled in the code, to simply ignore it.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We identified an issue with the parser for data files from OWASP CRS that we upgraded to and have been testing. It seems that comments at the top of the file aren't actually ignored and actually submitted to matching.
For example here is the newest version of java-classes.data file:
https://github.com/coreruleset/coreruleset/blob/v4.0/dev/rules/java-classes.data
When we launched the newer version of rule 944130: https://github.com/coreruleset/coreruleset/blob/v4.0/dev/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf#L123
It was matching requests with
#
in it and not any java classes but when we removed the preamble the erroneous matches went awayBeta Was this translation helpful? Give feedback.
All reactions