[Owasp-modsecurity-core-rule-set] Proposal for another language for CRS

Walter Hop modsec at spam.lifeforms.nl
Thu May 24 14:30:11 UTC 2018

Hi Mirko,

This is very interesting!

We have had no formal project going on, but it’s always a personal interest of mine, since I’ve always felt some friction with the ModSec rule language, and the large amount of boilerplate that we have to include in the CRS. In the past, I’ve dreamt about simpler rule syntaxes to facilitate CRS development. I’ve once put up a ramble and sketch inspired on a Python-like syntax, which can be found here: https://gist.github.com/lifeforms/28086fbdd17a2504faf488fe217380ea <https://gist.github.com/lifeforms/28086fbdd17a2504faf488fe217380ea>

For instance (from the above gist), I would love to write CRS rules like this:

rule 933110:
	if lowercase(UPLOAD_FILENAMES) rx '.*\.(?:php\d*|phtml)\.*$':
		msg 'PHP Injection Attack: PHP Script File Upload Found'
		block_anomaly critical php_injection

However, at the time, I hadn’t considered the use case of systems automatically generating rules or exclusions. For such a case, a JSON or YAML based serialization would be more useful, as it would not require parsing, evades problems with quoting, etc. I like how you have thought about data types.

I am currently looking at lua-resty-waf, which uses JSON to describe rules. If you are thinking of a new rule syntax in a JSON or YAML like exchange format, it might be useful to see how this was done:
https://github.com/p0pr0ck5/lua-resty-waf/blob/master/rules/41000_sqli.json <https://github.com/p0pr0ck5/lua-resty-waf/blob/master/rules/41000_sqli.json>
I have to try converting CRS 3.1-dev to lua-resty-waf format to see how that ends up.

I have to say, as a human, I find writing JSON or YAML to be not the greatest experience, but at this point in time, one of these serialization formats is a must have for integration. I agree with you that the language should be declarative, but the WAF engine will in reality still be running its phases and rules sequentially, making ordering/state relevant etc, hence why I was thinking more of code than a JSON dump. (Of course you can achieve the same things with both)

It would be amazing to have a universal “Rosetta stone” which has possible YAML, JSON, and even simple code syntaxes as frontends, as long as it can output a ModSec .conf file. It would be a useful sandbox for experimenting with various ideas. And it would also help make supporting other WAFs easier.

Anyway, I would be very interested to chat about these things at AppSecEU :)


> On 24 May 2018, at 15:39, Mirko Dziadzka <mirko.dziadzka at gmail.com> wrote:
> Hello
> Let me introduce myself first. I’m working in the realm of developing Web Application Firewalls for more than 13 years now. 
> Currently I’m working for a company which is using modsecurity and the CRS as one component of the WAF part of their product.
> In this role, we are thinking about how we can improve and develop the language, especially the language in which the CRS rules are described.
> I wrote down some first thoughts about this here:
> https://github.com/avinetworks/owasp-crs-technical-discussion/blob/master/language-draft.md <https://github.com/avinetworks/owasp-crs-technical-discussion/blob/master/language-draft.md>
> More detailed specification and code will follow in the next couple of weeks, but I would like to have
> this development as public as possible and start the discussion as soon as possible.
> I would like to get feedback about these ideas from the community, so please feel free to comment.
> I will be on the AppSec EU in July in London and would like to discuss the ideas in more details there.
> Greetings
> Mirko Dziadzka
> https://www.owasp.org/index.php/User:Mirko_Dziadzka <https://www.owasp.org/index.php/User:Mirko_Dziadzka>
> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-set at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

Псы Всегда Попадают В Рай

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/attachments/20180524/a435b61a/attachment-0001.html>

More information about the Owasp-modsecurity-core-rule-set mailing list