You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Torbjørn Skyberg Knutsen (JIRA)" <ji...@apache.org> on 2012/11/14 14:06:12 UTC
[jira] [Created] (AMQ-4173) CSRF protection not working properly
Torbjørn Skyberg Knutsen created AMQ-4173:
---------------------------------------------
Summary: 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:
<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:
function openInNewWindow(url) {
var newWindow= 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 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:
function openInNewWindow(url) {
var newWindow= 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 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:
function openInNewWindow(url) {
var newWindow= 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.
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
[jira] [Updated] (AMQ-4173) CSRF protection not working properly
Posted by "Torbjørn Skyberg Knutsen (JIRA)" <ji...@apache.org>.
[ 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:
<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.
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:
function openInNewWindow(url) {
var newWindow= 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 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:
function openInNewWindow(url) {
var newWindow= 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 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:
function openInNewWindow(url) {
var newWindow= 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.
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:
> <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.
--
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
[jira] [Updated] (AMQ-4173) CSRF protection not working properly
Posted by "Torbjørn Skyberg Knutsen (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (AMQ-4173) CSRF protection not working properly
Posted by "Torbjørn Skyberg Knutsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torbjørn Skyberg Knutsen updated AMQ-4173:
------------------------------------------
Affects Version/s: 5.7.0
> CSRF protection not working properly
> ------------------------------------
>
> Key: AMQ-4173
> URL: https://issues.apache.org/jira/browse/AMQ-4173
> Project: ActiveMQ
> Issue Type: Bug
> 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 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