[
https://issues.apache.org/jira/browse/AMQ-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torbjørn Skyberg Knutsen updated AMQ-4173:
------------------------------------------
Description:
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 messages. 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 messages
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 it works.
After consulting with a colleague, we couldn't reach any other conclusion than
that this is a bug in AMQ.
So, here is what I did (changes in browser.jsp):
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 secret
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:
{noformat}
<a href="#"
onclick="openInNewWindow('deleteMessage.action?JMSDestination=<c:out
value="${requestContext.queueBrowser.JMSDestination}"/>&messageId=${row.JMSMessageID}&secret=<c:out
value='${sessionScope["secret"]}'/>')">Delete</a>
{noformat}
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) {
var newWindow= 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 window,
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) {
var newWindow= 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 messages, no
stack traces in activemq.log. Which is really strange, because the URLs sent to
the javascript function contain the same secret key for multiple messages,
which should make it fail due the "Possible CSRF attack".
Next, I tried this:
{noformat}
function openInNewWindow(url) {
var newWindow= 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.
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 messages. 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 messages
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 it works.
After consulting with a colleague, we couldn't reach any other conclusion than
that this is a bug in AMQ.
So, here is what I did (changes in browser.jsp):
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 secret
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="#"
onclick="openInNewWindow('deleteMessage.action?JMSDestination=<c:out
value="${requestContext.queueBrowser.JMSDestination}"/>&messageId=${row.JMSMessageID}&secret=<c:out
value='${sessionScope["secret"]}'/>')">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) {
var newWindow= 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 window,
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) {
var newWindow= 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 messages, no
stack traces in activemq.log. Which is really strange, because the URLs sent to
the javascript function contain the same secret key for multiple messages,
which should make it fail due the "Possible CSRF attack".
Next, I tried this:
{noformat}
function openInNewWindow(url) {
var newWindow= 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.
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.
> CSRF protection not working properly
> ------------------------------------
>
> Key: AMQ-4173
> URL: https://issues.apache.org/jira/browse/AMQ-4173
> Project: ActiveMQ
> Issue Type: Bug
> Reporter: Torbjørn Skyberg Knutsen
>
> 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
> messages. 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
> messages 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
> it works. After consulting with a colleague, we couldn't reach any other
> conclusion than that this is a bug in AMQ.
> So, here is what I did (changes in browser.jsp):
> 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 secret
> 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:
> {noformat}
> <a href="#"
> onclick="openInNewWindow('deleteMessage.action?JMSDestination=<c:out
> value="${requestContext.queueBrowser.JMSDestination}"/>&messageId=${row.JMSMessageID}&secret=<c:out
> value='${sessionScope["secret"]}'/>')">Delete</a>
> {noformat}
> 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) {
> var newWindow= 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
> window, 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) {
> var newWindow= 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 messages,
> no stack traces in activemq.log. Which is really strange, because the URLs
> sent to the javascript function contain the same secret key for multiple
> messages, which should make it fail due the "Possible CSRF attack".
> Next, I tried this:
> {noformat}
> function openInNewWindow(url) {
> var newWindow= 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.
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
