Client: Client cannot connect to ownCloud server, if the webserver firewall requires Accept header.

Created on 5 Nov 2016 · 18Comments · Source: owncloud/client

Expected behaviour

Client should be able to connect to server even if the web server firewall requires Accept header.

Actual behaviour

Client is not sending Accept header in it's communication. (For example request to status.php). And IF the web server firewall requires Accept header, the request from client is forbidden. Therefore Client connection fails with "403 Forbidden" error.

Steps to reproduce

Have webserver with firewall that requires Accept header
Try to connect with any version of ownCloud client
Connection fails on 403 Forbidden error.

Client configuration

Client versions tested: 2.1 - 2.2.4
Operating system: Win/Linux
OS language: EN/CZ

Proposed solution

Add "Accept" header into client requests (maybe make it optional via settings).
The firewall should be fine if there is Accept: */* header if the User-Agentheader is present.

Logs

Client log, when it is trying to connect to server protected by such firewall:

08-07 18:35:31:360 0x1294460 "http://www.betanie.cz/owncloud" 
08-07 18:35:37:309 0x1294460 "http://www.betanie.cz/owncloud" 
08-07 18:35:37:412 0x1294460 Object::connect: No such signal QNetworkReplyImpl::encrypted() in /usr/src/packages/BUILD/src/libsync/networkjobs.cpp:371
08-07 18:35:37:412 0x1294460 !!! OCC::CheckServerJob created for "http://www.betanie.cz/owncloud" + "status.php" "OCC::OwncloudSetupWizard" 
08-07 18:35:37:739 0x1294460 void OCC::AbstractNetworkJob::slotFinished() 202 "Error downloading http://www.betanie.cz/owncloud/status.php - server replied: Forbidden" QVariant(int, 403) 
08-07 18:35:37:740 0x1294460 error: status.php replied  403 "<!DOCTYPE html> ....

Enhancement

Source

joseph11

Most helpful comment

@joseph11 Thanks. 2.3.0 will send the Accept header.

ckamm on 8 Nov 2016

👍2

All 18 comments

@guruz @ogoffart Doesn't look harmful to me. What do you think?

@joseph11 Out of curiosity, what kind of firewall is this?

ckamm on 7 Nov 2016

👍1

@ckamm It's ModSecurity 2.6 running on Apache 2.2.

Admin also sent me this log snippet for info:

[05/Nov/2016:20:09:35 +0100] WB4ublOn4fAAACgG2s0AAAAP 127.0.0.1 55628 127.0.0.1 8000
--206cad70-B--
GET /owncloud/status.php HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh) mirall/2.2.4 (build 3709)
Accept-Encoding: gzip, deflate
Accept-Language: sk-SK,en,*
Host: betanie.cz
X-Forwarded-Port: 80
X-Forwarded-For: 46.167.227.24
--206cad70-F--
HTTP/1.1 403 Forbidden
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *
Set-Cookie: ***censored***; path=/owncloud; HttpOnly
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Robots-Tag: none
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1422
Content-Type: text/html; charset=UTF-8
--206cad70-H--
Message: Access denied with code 403 (phase 2). [file "/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line "47"] [id "960015"] [rev "2.2.5"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"]
Action: Intercepted (phase 2)
Apache-Handler: application/x-httpd-suphp
Stopwatch: 1478372974791873 295927 (- - -)
Stopwatch2: 1478372974791873 295927; combined=323, p1=213, p2=84, p3=0, p4=0, p5=25, sr=50, sw=1, l=0, gc=0
Producer: ModSecurity for Apache/2.6.6 (http://www.modsecurity.org/); OWASP_CRS/2.2.5.
Server: Apache

--206cad70-Z--

joseph11 on 8 Nov 2016

@joseph11 Thanks. 2.3.0 will send the Accept header.

ckamm on 8 Nov 2016

👍2

I have the same problem.
My client (Windows&iOS) can't connect to server.

lemoatom on 9 Nov 2016

@LemoAtom If you're brave you could try a nightly build from this morning. https://owncloud.org/install/#testing-development

@nasli @davivel Can we send this for iOS/Android too?

guruz on 9 Nov 2016

Seen, we'll do. Thx.

davivel on 9 Nov 2016

@ckamm @guruz I've set up a server with the same specs (OC 8.2.2 in Apache + ModSecurity) and set in it the Firewall the base_rules including the protocol anomalies which is the one that contains the rule for missing and empty accept headers. Trying with client 2.3.0.3806 I'm still getting the 403: Forbidden.

SamuAlfageme on 9 Nov 2016

@SamuAlfageme Can you give me more details, like log excerpts? I'm not sure whether 2.3.0.3806 includes the patch to send the accept header.

ckamm on 14 Nov 2016

@joseph11 @LemoAtom Did you try with a current nightly build?

guruz on 15 Nov 2016

@ckamm Sure, 2.3.0.3806 was the nightly build from 09/11/2016 so as 90cea69692550eaff05dba091ec565b92d7cb759 was in master, I'm guessing that build contains the fix.

It seems like you need to send the Accept header in all requests, not only in the handshake (prior to 90cea69692550eaff05dba091ec565b92d7cb759 you couldn't even access to the login step, now you can but login is returning a 403). I can provide you guys access to the server I set with the firewall so you can test this condition.

This is a log file created from the startup of the desktop client to the submission of the login form.

SamuAlfageme on 15 Nov 2016

@ckamm Sorry, for not being clear in initial description: Yes, as @SamuAlfageme writes, the Accept header needs to be part of all client requests.

joseph11 on 15 Nov 2016

The patch by @ckamm https://github.com/owncloud/client/commit/90cea69692550eaff05dba091ec565b92d7cb759 however does include it in all requests.

@joseph11 You can try the testpilotcloud client download if you don't want to interfere with your current client and check if that one can connect/sync? http://download.owncloud.com/desktop/daily/

@SamuAlfageme let's check this later.

guruz on 15 Nov 2016

@guruz Thank you for the tip concerning testpilotcloud.
I tested it against server with firewall and it is connecting correctly, so I consider this fixed.

joseph11 on 16 Nov 2016

@SamuAlfageme A test server would be appreciated. I had hoped my change would have added the header to all requests, but maybe a different QNetworkAccessManager is used in some places. I'll investigate.

ckamm on 18 Nov 2016

@ckamm 👌 ping me in private (either email or mattermost) and I'll get you access to the server where I set the firewall.

SamuAlfageme on 18 Nov 2016

@SamuAlfageme I wrote you an email.

But I also routed the communication with a server through mitmproxy while configuring a new account, and all the requests involved had an "Accept" header. We might need more firewall logs.

ckamm on 18 Nov 2016

@SamuAlfageme Thanks for the server, that helped tremendously.

The "Accept: _/_" header is indeed sent everywhere.

The remaining issue was filtering by HTTP method (PROPFIND and PUT are forbidden by default), and filtering by content-type (application/octet-stream is forbidden by default). After adjusting these settings in modsecurity_crs_10_setup.conf client data was synced successfully.

This looks done from my point of view.

ckamm on 18 Nov 2016

@ckamm awesome! working like a charm now. Thanks for the deep explanation.

And it's working on the mobile clients as well.

SamuAlfageme on 18 Nov 2016

Was this page helpful?

0 / 5 - 0 ratings