CSRF Security Errors with the jetty-based .deb package

[pdicresc]

Hello, Subsonic experts - hoping you can point me to the right changes I need to make.

I'm running Subsonic on Ubuntu 13.10, using the .deb package, with Apache in front of it as a reverse-proxy, so that I can map /subsonic under my hostname, and lock it to https access. I started running this on 13.04, but once I'd upgraded and reapplied my mod_security rules, I started seeing the CSRF security error warnings.

Reading up on the pages in this forum, I tried to update the version of the dwr jar file to the 3.0 RC 2 version, which made the error go away, but took the player with it.

I'm guessing I can apply a useHttpOnly attribute somewhere - but I'm not familiar with where the context file is for this version of Subsonic, which bundles the Jetty app container.

What do I need to do to fix this?

[pdicresc]

Hey, looka that. doahh's post from November 2012 addressed the CSRF when you run Subsonic as a WARfile inside of Tomcat - but the approach works.

Here's what I figured out - Subsonic 4.8 is still using a version of DWR (Direct Web Remoting) that throws CSRF errors when (if I get this right) you try to get at the app over https://. doahh's post says to do this in Tomcat, adding this stanza to web.xml:

Code: Select all

<init-param>
    <param-name>crossDomainSessionSecurity</param-name>
    <param-value>false</param-value>
</init-param>


Which is great, if you know where. I'm going to try to spell it out for other users of the Debian package version of Subsonic.

If you:

(1) installed Subsonic from a .deb package,
(2) don't have your firewall opening that port up for direct access,
(3) and instead are front-ending Subsonic with a web server
(4) with https:// turned on to protect usernames and passwords,

then you want to do this to turn off CSRF errors. I'll write the instructions I used to solve it on my server.

(1) first, navigate to the directory it should be installed in, and find your way to the WEB-INF folder for the Subsonic app.

Code: Select all

cd /var/subsonic/jetty/3434/webapp/WEB-INF

This directory and the subdirectory contain the actual Subsonic software package that gets propped up on top of the jetty application server that gets run when you install the Debian package. We're going to change a file called web.xml, which tells jetty how to start the app up, what URLs to listen for, and what parts of the software to send requests for those URLs.

(2) start editing the web.xml file.

Code: Select all

pdicresc@jukebox:/var/subsonic/jetty/3434/webapp/WEB-INF$ sudo nano web.xml

Our problem is with the direct web remoting (read: AJAX) part of the software. It gets registered in Subsonic as a servlet named dwr-invoker, which has a friendly name of DWR Servlet.

(3) look for this block in the web.xml file:

Code: Select all

    <servlet>
        <display-name>DWR Servlet</display-name>
        <servlet-name>dwr-invoker</servlet-name>
        <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
    </servlet>


We're going to change the configuration so that when dwr-invoker gets started, we tell it to ignore cross-domain session security checking.

(4) change add the <init-param> lines in, so that the block reads like this:

Code: Select all

    <servlet>
        <display-name>DWR Servlet</display-name>
        <servlet-name>dwr-invoker</servlet-name>
        <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
        <init-param>
            <param-name>crossDomainSessionSecurity</param-name>
            <param-value>false</param-value>
        </init-param>
    </servlet>


(5) save the file and exit (using the nano editor, that's control-O to write the file back, then control-X to exit the editor).

(6) stop and restart Subsonic.

Code: Select all

pdicresc@jukebox:/var/subsonic/jetty/3434/webapp/WEB-INF$ sudo service subsonic stop
pdicresc@jukebox:/var/subsonic/jetty/3434/webapp/WEB-INF$ sudo service subsonic start


It takes a moment or two for the Subsonic application to start running again; but once you've got it back, you should be able to open the music server in a web browser, over https://, without incident.