[Bug]: invalid request body #2363
Description
Steps to reproduce
- Set up a ModSecurity Web Application Firewall with OWASP Core Rule Set and Nextcloud extension
Expected behaviour
The request shall not be detected as invalid body
Actual behaviour
The request is detected as invalid XML
Environment data
iOS version: e.g. iOS 16.3
Nextcloud iOS app version: 4.6.0
Server operating system: Debian, Nextcloud Docker
Web server: Nginx with Modsecurity WAF and OWASP CRS
Nextcloud version: 25.0.3
Description
I got a blocking on my Web Application Firewall for a request from the Nextcloud iOS client. This is the information as logged by ModSecurity:
---dhTKFV0b---A--
[23/Feb/2023:07:52:48 +0100] 167713516875.545573 2409:408c:ae83:4949:8c84:9de9:7cae:75ce 0 10.0.2.100 80
---dhTKFV0b---B--
GET /ocs/v2.php/apps/files_sharing/api/v1/shares?reshares=false&shared_with_me=false&subfiles=false HTTP/1.1
ocs-apirequest: true
accept: */*
X-Real-IP: 2409:408c:ae83:4949:8c84:9de9:7cae:75ce
authorization: Basic **************************
Host: nc1.****.**
X-Forwarded-Proto: https
X-Forwarded-By: ***:****:***:40::64:443
user-agent: Mozilla/5.0 (iOS) Nextcloud-iOS/4.6.0
content-type: application/xml
X-Forwarded-Port: 443
X-Forwarded-For: 2409:408c:ae83:4949:8c84:9de9:7cae:75ce
Forwarded: for=2409:408c:ae83:4949:8c84:9de9:7cae:75ce; proto=https; by=***:***:***:40::64
accept-language: de-CH;q=1.0, en-CH;q=0.9
accept-encoding: br;q=1.0, gzip;q=0.9, deflate;q=0.8
cookie: *********
---dhTKFV0b---E--
<html>\x0d\x0a<head><title>400 Bad Request</title></head>\x0d\x0a<body>\x0d\x0a<center><h1>400 Bad Request</h1></center>\x0d\x0a<hr><center>nginx</center>\x0d\x0a</body>\x0d\x0a</html>\x0d\x0a
---dhTKFV0b---F--
HTTP/1.1 400
X-Frame-Options: SAMEORIGIN
X-Robots-Tag: none
Referrer-Policy: no-referrer
X-Permitted-Cross-Domain-Policies: none
Connection: close
X-Content-Type-Options: nosniff
Content-Type: text/html
X-Download-Options: noopen
Content-Length: 150
Date: Thu, 23 Feb 2023 06:52:48 GMT
Server: nginx
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains
---dhTKFV0b---H--
ModSecurity: Access denied with code 400 (phase 2). Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/modsecurity.d/modsecurity.conf"] [line "75"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "XML parsing error: XML: Failed parsing document."] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [tag "modsecurity"] [hostname "10.0.2.100"] [uri "/ocs/v2.php/apps/files_sharing/api/v1/shares"] [unique_id "167713516875.545573"] [ref "v970,1"]
---dhTKFV0b---I--
---dhTKFV0b---J--
---dhTKFV0b---K--
---dhTKFV0b---Z--
This seems to be a GET request with a XML body.
I haven't an output of the actual request body so I believe this is either a json and the Content-Type of the request is wrong or it is xml and the xml is invalid or the request body is emtpy and the Content-Type is set wrongly.
Access to the same API endpoint with an Android client does not give any error and it is not logged, thus the request headers (and body if existing) are correct for the Android client.
As a general request to the developers
I do love Nextcloud and I value your work. Many thanks for this. I have a small private instance which I use as my cloud storage with calendar and contacts and to auto upload photos.
I have a single web user, six clients on /e/OS (Android), one client on Android (Samsung) and one user with an iOS client.
Running my Nextcloud for a few years I always had trouble with the iOS client with ModSecurity and the OWASP Core Rule Set. There has been nearly zero problems with the Web Interface or Android clients.
All of the problems with the iOS client seems to be related to incorrect values in Content-Type, Encoding or Accept-Headers. What I have seen is many dav requests (which are xml) with content encoding x-www-form-urlencoded. The same for file uploads or chunk uploads.
The WAF relies on the header information for its checks and correctly set headers is crucial for validating the requests.
If the WAF complains possible reasons are:
- a rule is not applicable: in this case it shoud be covered in the Nextcloud exclusions file from OWASP CRS.
- there is an attack and the WAF worked correctly
- there is something wrong with the request or response
I don't know how testing is organized at Nextcloud, but may it be possible to set up a (or one of the) test servers with a ModSecurity WAF with OWASP CRS in logging only mode and cover the output of the WAF for test results?