Rule 920420: POST with Content-type application/octet-stream is not allowed

[tomsommer]

POST with Content-type application/octet-stream is not allowed by Rule 920420?

--32be427d-B--
POST /processwire/page/edit/?id=1195 HTTP/1.1
Host: xxxxx
Connection: keep-alive
Content-Length: 177070
X-FIELDNAME: posting_attachment
Origin: https://xxxxx
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36
X-TOKEN590891166X1479990682: F0RGmVptrIG79P4WJi16mLzSvHxYcO4E1
Content-Type: application/octet-stream
X-REQUESTED-WITH: XMLHttpRequest
X-FILENAME: Sxxxxxxxx6.pdf
Accept: */*
Referer: https://www.xxxxxx/processwire/page/edit/?id=1195&s=1
Accept-Encoding: gzip, deflate, br
Accept-Language: da-DK,da;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: WireTabs=; _gat=1; _ga=GA1.2.1635540034.1420445779; wire=o7j66sap28bhhrabpfrjl7reh74v1tur; wire_challenge=vfybhnScgOzxmiOoWn4LshNkJK4IMEyy1

---

Message: Access denied with code 406 (phase 2). Match of "rx ^%{tx.allowed_request_content_type}$" against "TX:0" required. [file "/usr/local/apache2/conf/crs-rules/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "995"] [id "920420"] [rev "2"] [msg "Request content type is not allowed by policy"] [data "application/octet-stream"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "unoeuro"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"]

[csanders-git]

This can be easily added via the crs-seutp.conf file specifically ( https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0/master/crs-setup.conf.example#L332 ). octet-stream is an interesting choice for consideration by default. It is essentially the lack of any other content-type usually. What is odd is that in this case the browser didn't pick application/pdf as the MIME type. Very strange behavior.

[csanders-git]

What application was this generated by, just for my own information (if you can share)

[tomsommer]

Something called 'Processwire', I think :)

[dune73]

I am not sure that octet-stream is a good addition to the defaults. Maybe for Paranoia Level 1 it would be. But I really want to avoid it in higher PLs, namely PL3, certainly PL4. Maybe we could add a rule that triggers on the use of octet-stream in PL3.

[csanders-git]

@dune73 there are some interesting aspects here... the first being that it is the default if no content-type can be determined. I don't know, it's not that common and the lack of knowing what the data is makes it suspicious also.

[dune73]

It's really this "we do not know" about the frequency of this Content-Type. Maybe we wait for more reports before we add it to the default.

[dune73]

Talked about this with @franbuehler. Here is our proposed resolution:

• Octet-Stream should be OK for PL1, but not for PL2 and higher.
• We want to stick to a single variable defining the tx.allowed_request_content_type allowed mime-types. This rules out defining multiple variables for various PLs and it also rules out rewriting the variable via ModSec in higher PLs.
• The solution is thus to include octet-stream in the default value. Then there is a new rule at PL2 (PL3?) that triggers an alert on Content-Type: application/octet-stream.
• A comment near the definition of tx.allowed_request_content_type indicates that octet-stream is included, but that there is a separate rule prohibiting it at higher PLs.
• There also has to be an commented out example showing how to circumvent the alert.

Feedback welcome.

Open question: Is this a 3.0.1 thing, or should we wait for 3.1.0?

[dune73]

OK, taking the pragmatic approach here.

• PR #708 adds this to the tx.allowed_request_content_type as explained above.
• Issue #709 keeps this open for 3.1

[dune73]

Fix has been merged. Closing this issue here. #709 remains open for 3.1.

Thank you for reporting @tomsommer and sorry for taking so long.

[intelbg]

I had the same issue with CRS3 and modsecV3 as Joomla administration was not working until I added POST. I think that POST should be allowed by default.

[csanders-git]

@intelbg can you elaborate a bit more on what you mean?