Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 14 Nov 2012 13:06:14 +0000 (UTC)
From: =?utf-8?Q?Torbj=C3=B8rn_Skyberg_Knutsen_=28JIRA=29?= <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <1484614751.113661.1352898374134.JavaMail.jiratomcat@arcas>
In-Reply-To: <910442161.113655.1352898372862.JavaMail.jiratomcat@arcas>
Subject: [jira] [Updated] (AMQ-4173) CSRF protection not working properly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/AMQ-4173?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Torbj=C3=B8rn Skyberg Knutsen updated AMQ-4173:
------------------------------------------

    Description:=20
We recently upgraded from AMQ 5.3.0 to AMQ 5.7.0. In the web console of AMQ=
 5.3.0, if we wanted to delete a set of messages from a queue, we did that =
by holding ctrl and then pressing the delete url, to avoid being redirected=
 to the overview, thus minimizing the number of clicks to delete multiple m=
essages. In 5.7.0, this was not possible, due to the added CSRF protection.

I was given the task of trying to enable us to easily delete multiple messa=
ges from the AMQ we console. I actually managed to do this, but I fear that=
 was more on the account of luck than skill, since I really can't see why i=
t works. After consulting with a colleague, we couldn't reach any other con=
clusion than that this is a bug in AMQ.

So, here is what I did (changes in browser.jsp):=20

One of my first thoughts was to use Javascript to enforce a reload of the o=
verview page between each click on delete, in order to regenerate the secre=
t key. Also, to avoid the redirecting, I wanted to open the URL in a new wi=
ndow/tab. So here is what I did:

The url to the delete button:

    <a href=3D"#" onclick=3D"openInNewWindow('deleteMessage.action?JMSDesti=
nation=3D<c:out value=3D"${requestContext.queueBrowser.JMSDestination}"/>&m=
essageId=3D${row.JMSMessageID}&secret=3D<c:out value=3D'${sessionScope["sec=
ret"]}'/>')">Delete</a>

So, basically changed the link to call a javascript function with the URL a=
s a parameter, instead of opening the URL. The Javascript function looked l=
ike this:
{noformat}
function openInNewWindow(url) {
=09var newWindow=3D window.open(url);
        newWindow.close();

        window.location.reload();
}
{noformat}

This did not work, not even for the first request, which had a fresh secret=
 key. I had already tried with just the first line (without closing the win=
dow, and without the window.location.reload() part), and this made it work =
for the first request, but then not for any other.

So, then, I tried this:
{noformat}
function openInNewWindow(url) {
=09var newWindow=3D window.open(url);
        newWindow.close();
}
{noformat}

I was quite suprised to see that this actually worked. I could click delete=
 on multiple messages without reloading, and it actually deleted the messag=
es, no stack traces in activemq.log. Which is really strange, because the U=
RLs sent to the javascript function contain the same secret key for multipl=
e messages, which should make it fail due the "Possible CSRF attack".

Next, I tried this:
{noformat}
function openInNewWindow(url) {
=09var newWindow=3D window.open(url);
        setTimeout(function() {
            newWindow.close();
        }, 1000);
}
{noformat}

Now, it stopped working. The first one worked, but the following showed an =
error page (for the 1 second), and produced a stacktrace in activemq.log.=
=20

I really don't understand all the details of why this works as it does, but=
 it seems that it is possible to circumvent the CSRF protection by closing =
the browser window immediately after the request has been posted.


  was:
We recently upgraded from AMQ 5.3.0 to AMQ 5.7.0. In the web console of AMQ=
 5.3.0, if we wanted to delete a set of messages from a queue, we did that =
by holding ctrl and then pressing the delete url, to avoid being redirected=
 to the overview, thus minimizing the number of clicks to delete multiple m=
essages. In 5.7.0, this was not possible, due to the added CSRF protection.

I was given the task of trying to enable us to easily delete multiple messa=
ges from the AMQ we console. I actually managed to do this, but I fear that=
 was more on the account of luck than skill, since I really can't see why i=
t works. After consulting with a colleague, we couldn't reach any other con=
clusion than that this is a bug in AMQ.

So, here is what I did (changes in browser.jsp):=20

One of my first thoughts was to use Javascript to enforce a reload of the o=
verview page between each click on delete, in order to regenerate the secre=
t key. Also, to avoid the redirecting, I wanted to open the URL in a new wi=
ndow/tab. So here is what I did:

The url to the delete button:

    <a href=3D"#" onclick=3D"openInNewWindow('deleteMessage.action?JMSDesti=
nation=3D<c:out value=3D"${requestContext.queueBrowser.JMSDestination}"/>&m=
essageId=3D${row.JMSMessageID}&secret=3D<c:out value=3D'${sessionScope["sec=
ret"]}'/>')">Delete</a>

So, basically changed the link to call a javascript function with the URL a=
s a parameter, instead of opening the URL. The Javascript function looked l=
ike this:

function openInNewWindow(url) {
=09var newWindow=3D window.open(url);
        newWindow.close();

        window.location.reload();
}

This did not work, not even for the first request, which had a fresh secret=
 key. I had already tried with just the first line (without closing the win=
dow, and without the window.location.reload() part), and this made it work =
for the first request, but then not for any other.

So, then, I tried this:

function openInNewWindow(url) {
=09var newWindow=3D window.open(url);
        newWindow.close();
}

I was quite suprised to see that this actually worked. I could click delete=
 on multiple messages without reloading, and it actually deleted the messag=
es, no stack traces in activemq.log. Which is really strange, because the U=
RLs sent to the javascript function contain the same secret key for multipl=
e messages, which should make it fail due the "Possible CSRF attack".

Next, I tried this:

function openInNewWindow(url) {
=09var newWindow=3D window.open(url);
        setTimeout(function() {
            newWindow.close();
        }, 1000);
}

Now, it stopped working. The first one worked, but the following showed an =
error page (for the 1 second), and produced a stacktrace in activemq.log.=
=20

I really don't understand all the details of why this works as it does, but=
 it seems that it is possible to circumvent the CSRF protection by closing =
the browser window immediately after the request has been posted.


   =20
> CSRF protection not working properly
> ------------------------------------
>
>                 Key: AMQ-4173
>                 URL: https://issues.apache.org/jira/browse/AMQ-4173
>             Project: ActiveMQ
>          Issue Type: Bug
>            Reporter: Torbj=C3=B8rn Skyberg Knutsen
>
> We recently upgraded from AMQ 5.3.0 to AMQ 5.7.0. In the web console of A=
MQ 5.3.0, if we wanted to delete a set of messages from a queue, we did tha=
t by holding ctrl and then pressing the delete url, to avoid being redirect=
ed to the overview, thus minimizing the number of clicks to delete multiple=
 messages. In 5.7.0, this was not possible, due to the added CSRF protectio=
n.
> I was given the task of trying to enable us to easily delete multiple mes=
sages from the AMQ we console. I actually managed to do this, but I fear th=
at was more on the account of luck than skill, since I really can't see why=
 it works. After consulting with a colleague, we couldn't reach any other c=
onclusion than that this is a bug in AMQ.
> So, here is what I did (changes in browser.jsp):=20
> One of my first thoughts was to use Javascript to enforce a reload of the=
 overview page between each click on delete, in order to regenerate the sec=
ret key. Also, to avoid the redirecting, I wanted to open the URL in a new =
window/tab. So here is what I did:
> The url to the delete button:
>     <a href=3D"#" onclick=3D"openInNewWindow('deleteMessage.action?JMSDes=
tination=3D<c:out value=3D"${requestContext.queueBrowser.JMSDestination}"/>=
&messageId=3D${row.JMSMessageID}&secret=3D<c:out value=3D'${sessionScope["s=
ecret"]}'/>')">Delete</a>
> So, basically changed the link to call a javascript function with the URL=
 as a parameter, instead of opening the URL. The Javascript function looked=
 like this:
> {noformat}
> function openInNewWindow(url) {
> =09var newWindow=3D window.open(url);
>         newWindow.close();
>         window.location.reload();
> }
> {noformat}
> This did not work, not even for the first request, which had a fresh secr=
et key. I had already tried with just the first line (without closing the w=
indow, and without the window.location.reload() part), and this made it wor=
k for the first request, but then not for any other.
> So, then, I tried this:
> {noformat}
> function openInNewWindow(url) {
> =09var newWindow=3D window.open(url);
>         newWindow.close();
> }
> {noformat}
> I was quite suprised to see that this actually worked. I could click dele=
te on multiple messages without reloading, and it actually deleted the mess=
ages, no stack traces in activemq.log. Which is really strange, because the=
 URLs sent to the javascript function contain the same secret key for multi=
ple messages, which should make it fail due the "Possible CSRF attack".
> Next, I tried this:
> {noformat}
> function openInNewWindow(url) {
> =09var newWindow=3D window.open(url);
>         setTimeout(function() {
>             newWindow.close();
>         }, 1000);
> }
> {noformat}
> Now, it stopped working. The first one worked, but the following showed a=
n error page (for the 1 second), and produced a stacktrace in activemq.log.=
=20
> I really don't understand all the details of why this works as it does, b=
ut it seems that it is possible to circumvent the CSRF protection by closin=
g the browser window immediately after the request has been posted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira