Owasp-modsecurity-crs: Allow JSON requests

Created on 24 Nov 2016 · 18Comments · Source: SpiderLabs/owasp-modsecurity-crs

Hi there,

I´m using the latest release of crs. My issue is, that requests to our REST API are blocked with the following exception:

ModSecurity: JSON support was not enabled
ModSecurity: Access denied with code 400 (phase 2). Match of "eq 0" against "REQBODY_ERROR" required.

Haven´t found many informations on that topic - can anybody give me a hint?

Thanks a lot :)

Source

synonymous1984

Most helpful comment

Ok - thanks for you help - appreciate it! 👍

synonymous1984 on 24 Nov 2016

👍2

All 18 comments

This is a bit of a ModSecurity question. But all the same :). The issue seems to be that ModSecurity wasn't compiled with LibYAJL. It is an optional library but is required for doing JSON parsing. Hope this helps!

csanders-git on 24 Nov 2016

Hi,
Thanks... It´s not manually compiled - simply installed with apt-get. I will have a look how to manually install it...

synonymous1984 on 24 Nov 2016

hmm... interesting on Debian I assume? what version of Debian? I may have to email the packager about this issue.

csanders-git on 24 Nov 2016

No, you don´t have to.. it´s a staging environment with old wheezy on it. Production is on 8.6, so there should be no issue with that. If so I will let you know.

synonymous1984 on 24 Nov 2016

👍1

Okay, same issue here on Debian 8.6 - installed mod_security two days ago via package manager. This is the exception which is logged in the audit.log:

[24/Nov/2016:18:07:39 +0100] BT 192.168.1.27 39889 172.18.20.10 443
--9f6ca835-B--
PUT /api/articles/12345?useNumberAsId=true? HTTP/1.1
User-Agent: ***********
Host: ***************
Accept: */*
Content-Type: application/json; charset=utf-8
Content-Length: 0

--9f6ca835-C--

--9f6ca835-F--
HTTP/1.1 400 Bad Request
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1

--9f6ca835-E--
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>

--9f6ca835-H--
Message: JSON support was not enabled
Message: Access denied with code 400 (phase 2). Match of "eq 0" against "REQBODY_ERROR" required. [file "/etc/modsecurity/modsecurity.conf"] [line "60"] [id "200002"] [msg "Failed to parse request body."] [data ""] [severity "CRITICAL"]
Action: Intercepted (phase 2)
Stopwatch: 1480007259916820 2234 (- - -)
Stopwatch2: 1480007259916820 2234; combined=704, p1=640, p2=6, p3=0, p4=0, p5=58, sr=63, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.8.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.0.
Server: Apache
Engine-Mode: "ENABLED"

--9f6ca835-Z--

synonymous1984 on 24 Nov 2016

For your edification, here is the source of your problem.
https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended#L29
You can disable this whole rule to get around the issue :)

csanders-git on 24 Nov 2016

Disabling this rule completely disables check of JSON requests?

synonymous1984 on 24 Nov 2016

it just disables trying to parse them as JSON, which isn't supported in your current environment anyway due to lack of YAJL. Hope that helps!

csanders-git on 24 Nov 2016

Sure - thanks a lot for your support... 👍
Is it a big security issue disabling validation as json?

synonymous1984 on 24 Nov 2016

Since YAJL isn't installed already it's not any larger of an issue. However, it may lead to certain FP's or FN's when given actual JSON.

csanders-git on 24 Nov 2016

ok... Do you think YAJL will be part of the debian package in the upcoming releases?

synonymous1984 on 24 Nov 2016

I would hope it is, but I do not know :( sorry.

csanders-git on 24 Nov 2016

Ok - thanks for you help - appreciate it! 👍

synonymous1984 on 24 Nov 2016

👍2

Added a separate issue #659 to put a remark into KNOWN_BUGS.

dune73 on 25 Nov 2016

Hi there,

JSON support was enabled in Debian's package version 2.8.0-4 (Nov 2014). You may use backports.debian.org to install the latest modsecurity release in Jessie.
Just to keep KNOWN_BUGS correct :-)

Regards,

Alberto (Debian maintainer)

inittab on 25 Nov 2016

🎉1

Great to read from you @inittab!

So you have 2.8.0-3 without YAJL/JSON in Debian Jessie and Stretch brings YAJL/JSON?

On some other note, have you looked into packaging CRS3 yet? There are a few decisions to make regarding new features and maybe it would be worth discussing it a bit. Maybe also adding more links in the doc etc.

dune73 on 25 Nov 2016

Yes, Jessie was released without YAJL/JSON support. To fix that, 2.9.1 was backported with YAJL/JSON support. Using backports.debian.org is quite easy, so no excuse not to have YAJL/JSON support in Debian Jessie.

Stretch will come with YAJL/JSON support.
Please, feel free to contact me with any improvements/features that should/could be added to the Debian package. I'll be happy to help with that.

Alberto

inittab on 28 Nov 2016

Thanks @inittab good to know you're on top of this stuff :-D

csanders-git on 28 Nov 2016

Was this page helpful?

0 / 5 - 0 ratings