Bugzilla – Bug 758
CSRF vulnerabilities in Web UI, non-Referer test needed
Last modified: 2008-09-15 14:37:04 UTC
SlimServer 5.3.0 introduced some Referer tests to protect against some Cross Site Request Forgery vulnerablities in the web interface's /setup.html functionality. Similar problems exist in other web interface features, including the documented /status.html and /status.xml features. These vulnerabilities make it relatively easy for an attacker to trick a SlimServer user into misconfiguring or otherwise wreaking havoc on their SlimServer system. One apparent goal of the Web interface is to allow users to bookmark URLs, which is fundamentally incompatible with a Referer requirement. A fundamentally different CSRF authorization mechanism is needed. I will add to this ticket a patch against CVS (as of 30 Dec 2004) that implements a "cauth" URL parameter test such that SlimServer will accept any web request that *EITHER* 1) has a valid referer (i.e. is following a link from the web UI) *OR* 2) contains a special ;cauth=$CODE (where $CODE is a 32-hex-char-string) phrase in the URI If a request is rejected, SlimServer will display a clickable link to a URL that contains a valid "cauth" parameter. The "cauth" parameter is based on an installation-specific "securitySecret", so that the cauth value will differ on each different SlimServer installation. By default, the same "cauth" parameter will work for any URI, to make it easier for users to programatically use the HTTP interface, while providing some protection. Another server preference is added, "csrfProtectionLevel", default value "MEDIUM" -- which specifies that the same cauth value should work for any URL. By changing the csrfProtectionLevel to "HIGH", a user can enable a higher level of protection -- in HIGH mode, each unique URI requires a different cauth code, so the code for querying a setting (as with a "?" argument) will differ from the code required for, say, starting a rescan of the library. Also, some users have reported trouble using the web interface starting with version 5.3.0, apparently because their web browser software omits the Referer header (https://bugs-archive.lyrion.org/show_bug.cgi?id=620). These users can set csrfProtectionLevel to "NONE" to completely disable the Referer and cauth tests.
Created attachment 235 [details] gzipped patch from `cvs diff -u` This patch implements the logic needed for "HIGH", "MEDIUM", and "NONE" options for csrfProtectionLevel, but does not provide code for changing the csrfProtectionLevel through the web interface. -Peter
*** Bug 756 has been marked as a duplicate of this bug. ***
peter, can you send me a raw diff to slim-mail@deane-freeman.com. for some reason, I'm not having any success grabbing a gz from this interface. I'll test it and merge.
Created attachment 246 [details] patch for 756 and 758 (cvs diff -u) Uploading an uncompressed patch this time. Regarding 756: we'll always have something of a Referer test on "dangerous" URIs/commands, so resolving 756 is important. I tweaked the https://bugs-archive.lyrion.org/attachment.cgi?id=234&action=view patch for 756 to make it more thorough, so SlimServer will not accept a referer on an alternate port if SlimServer is running on port 80. I'm afraid that *might* not be the end of bug 756: if somebody's using a reverse proxy in front the SlimServer HTTP interface, then the Referer might not match the Host in port or hostname. Maybe it should be the reverse proxy's job to solve such a mess. Also this patch corrects a flaw in the earlier patch's isCsrfAuthCodeValid() logic -- isCsrfAuthCodeValid() should always return 1 (true) if csrfProtectionLevel is NONE.
Thanks Peter. I'll merge all this in soon.
I notice that the only way to change this new pref is by manually editting the pref file. There is a 'security' tab under server settings where I could place a pulldown for this pref, or is a UI accessible pref not recommended for this type of protection?
Making this pref UI-accessible would be great. I'd like that. That would also make it easier for customers dealing with https://bugs-archive.lyrion.org/show_bug.cgi?id=620. As I understand it, those folks generally were using browsers that don't ever send Referer headers, so they'd want to choose the "NONE" level to make their web interface usable.
I'll work on that. To make it easier, the pref will change to the typical numberic, but will be mapped in the UI to the text (which we can localise). 0=NONE, 1=MEDIUM, 2=HIGH
*** Bug 620 has been marked as a duplicate of this bug. ***
Created attachment 247 [details] patch for localisation and settings UI This diff goes on AFTER attachment 246 [details]. I've moved the strings so we can translate them later, and I've added a setting ui at the bottom of server settings->security
I've tried this out using port 80 and it seems to let me into settings. I've tried a setup bookmark and I get properly redirected. I dont have any sort of proxy setup that I can test for the forwarding problem, so I'll have to leave that to someone else. I'll mark this fixed when I've done the merge, but it can be reopened if later testing shows there is still a problem.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.