[
https://issues.apache.org/jira/browse/AMQ-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13902619#comment-13902619
]
Arthur Naseef commented on AMQ-4173:
------------------------------------
I don't believe there is a CSRF protection issue here. However, this is based
on limited understanding of CSRF protection. If an attack can be crafted and
reproduced, let me know and I'll look at it.
Even if there is not a CSRF protection issue here, it would be unwise to rely
on a design that keeps the same secret across multiple page requests.
Can anyone else shed light on this concern?
> CSRF protection not working properly
> ------------------------------------
>
> Key: AMQ-4173
> URL: https://issues.apache.org/jira/browse/AMQ-4173
> Project: ActiveMQ
> Issue Type: Bug
> Components: webconsole
> Affects Versions: 5.7.0
> 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 was sent by Atlassian JIRA
(v6.1.5#6160)
