Re: [Broker-J] Http management interface should ignore OPTIONS method
> We will look into adding corresponding changes into version 8.0.6. Thanks Alex, great to hear. We have to remediate this for our security people so getting this in the next release will be very helpful. -- Tom From: Oleksandr Rudyy Reply-To: "users@qpid.apache.org" Date: Monday, July 19, 2021 at 4:24 AM To: "users@qpid.apache.org" Subject: Re: [Broker-J] Http management interface should ignore OPTIONS method Hi Tom, The Qpid Broker-J supports configuring CORS settings to allow access to REST API from different origins. This can be done via HTTP management attributes (corsAllowOrigins,corsAllowMethods,corsAllowHeaders,corsAllowCredentials). Though, by default, the origin(s), allowed headers and methods are not set. Thus, it is actually safe to disable the OPTIONS method when no original related attribute is set. We will look into adding corresponding changes into version 8.0.6. Kind Regards, Alex On Thu, 15 Jul 2021 at 15:47, Tom Jordahl mailto:tjord...@adobe.com.invalid>> wrote: Hello Devs, In our environment we run security scanning tools. They flag any HTTP port that supports the OPTIONS method as a problem: “Web servers that respond to the OPTIONS HTTP method expose what other methods are supported by the web server, allowing attackers to narrow and intensify their efforts.” I don’t see Qpid having any need to support this method, so I have filed a bug with a patch that blocks the OPTIONS method: https://issues.apache.org/jira/browse/QPID-8552. I would love to have this patch in the next 8.x release of Broker-J. Thoughts? -- Tom - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org<mailto:users-unsubscr...@qpid.apache.org> For additional commands, e-mail: users-h...@qpid.apache.org<mailto:users-h...@qpid.apache.org>
Re: [Broker-J] Http management interface should ignore OPTIONS method
Hi Tom, The Qpid Broker-J supports configuring CORS settings to allow access to REST API from different origins. This can be done via HTTP management attributes (corsAllowOrigins,corsAllowMethods,corsAllowHeaders,corsAllowCredentials). Though, by default, the origin(s), allowed headers and methods are not set. Thus, it is actually safe to disable the OPTIONS method when no original related attribute is set. We will look into adding corresponding changes into version 8.0.6. Kind Regards, Alex On Thu, 15 Jul 2021 at 15:47, Tom Jordahl wrote: > > Hello Devs, > > In our environment we run security scanning tools. They flag any HTTP port > that supports the OPTIONS method as a problem: > “Web servers that respond to the OPTIONS HTTP method expose what other > methods are supported by the web server, allowing attackers to narrow and > intensify their efforts.” > > I don’t see Qpid having any need to support this method, so I have filed a > bug with a patch that blocks the OPTIONS method: > https://issues.apache.org/jira/browse/QPID-8552. I would love to have this > patch in the next 8.x release of Broker-J. > > Thoughts? > -- > Tom - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [Broker-J] Http management interface should ignore OPTIONS method
I am not really sure myself. Just threw that out as something that might break. On Thu, Jul 15, 2021, 20:34 Tom Jordahl wrote: > Hi Mantas, > > I assume you are referring to CORS as described here ( > https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS). > Does the Qpid web console actually do any cross-origin requests that would > require a pre-flight request ( > https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request)? > > I didn’t think it did, but I certainly could be wrong. > > -- > Tom > > From: Mantas Gridinas > Reply-To: "users@qpid.apache.org" > Date: Thursday, July 15, 2021 at 10:50 AM > To: "users@qpid.apache.org" > Subject: Re: [Broker-J] Http management interface should ignore OPTIONS > method > > Sadly options request is necessary for browsers to assert whether or not > the result of a request should be exposed to caller, isn't it? > > On Thu, Jul 15, 2021, 17:47 Tom Jordahl <mailto:tjord...@adobe.com.invalid>> wrote: > > Hello Devs, > > In our environment we run security scanning tools. They flag any HTTP > port that supports the OPTIONS method as a problem: >“Web servers that respond to the OPTIONS HTTP method expose what other > methods are supported by the web server, allowing attackers to narrow and > intensify their efforts.” > > I don’t see Qpid having any need to support this method, so I have filed a > bug with a patch that blocks the OPTIONS method: > https://issues.apache.org/jira/browse/QPID-8552. I would love to have > this patch in the next 8.x release of Broker-J. > > Thoughts? > -- > Tom > > >
Re: [Broker-J] Http management interface should ignore OPTIONS method
Hi Mantas, I assume you are referring to CORS as described here (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS). Does the Qpid web console actually do any cross-origin requests that would require a pre-flight request (https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request)? I didn’t think it did, but I certainly could be wrong. -- Tom From: Mantas Gridinas Reply-To: "users@qpid.apache.org" Date: Thursday, July 15, 2021 at 10:50 AM To: "users@qpid.apache.org" Subject: Re: [Broker-J] Http management interface should ignore OPTIONS method Sadly options request is necessary for browsers to assert whether or not the result of a request should be exposed to caller, isn't it? On Thu, Jul 15, 2021, 17:47 Tom Jordahl mailto:tjord...@adobe.com.invalid>> wrote: Hello Devs, In our environment we run security scanning tools. They flag any HTTP port that supports the OPTIONS method as a problem: “Web servers that respond to the OPTIONS HTTP method expose what other methods are supported by the web server, allowing attackers to narrow and intensify their efforts.” I don’t see Qpid having any need to support this method, so I have filed a bug with a patch that blocks the OPTIONS method: https://issues.apache.org/jira/browse/QPID-8552. I would love to have this patch in the next 8.x release of Broker-J. Thoughts? -- Tom
Re: [Broker-J] Http management interface should ignore OPTIONS method
Sadly options request is necessary for browsers to assert whether or not the result of a request should be exposed to caller, isn't it? On Thu, Jul 15, 2021, 17:47 Tom Jordahl wrote: > Hello Devs, > > In our environment we run security scanning tools. They flag any HTTP > port that supports the OPTIONS method as a problem: > “Web servers that respond to the OPTIONS HTTP method expose what other > methods are supported by the web server, allowing attackers to narrow and > intensify their efforts.” > > I don’t see Qpid having any need to support this method, so I have filed a > bug with a patch that blocks the OPTIONS method: > https://issues.apache.org/jira/browse/QPID-8552. I would love to have > this patch in the next 8.x release of Broker-J. > > Thoughts? > -- > Tom >
[Broker-J] Http management interface should ignore OPTIONS method
Hello Devs, In our environment we run security scanning tools. They flag any HTTP port that supports the OPTIONS method as a problem: “Web servers that respond to the OPTIONS HTTP method expose what other methods are supported by the web server, allowing attackers to narrow and intensify their efforts.” I don’t see Qpid having any need to support this method, so I have filed a bug with a patch that blocks the OPTIONS method: https://issues.apache.org/jira/browse/QPID-8552. I would love to have this patch in the next 8.x release of Broker-J. Thoughts? -- Tom
Re: [Broker-J] HTTP management
Hi Olivier,
Please note, that JIRA [1] was raised to track issue with bindings
using invalid selectors.
The fix is scheduled for inclusion into 7.1.
Please fill free to contribute a code for the fix.
As for returning 400 instead of 404 when exchange does not exist for a
requested operation, you can raise an improvement JIRA for the issue.
I do not feel strongly that 400 should be returned instead of 404. As
exchange does not exist, the operation does not exist as well. Thus,
returning 404 here does not look wrong to me.
Kind Regards,
Alex
[1] https://issues.apache.org/jira/browse/QPID-7642
On Thu, 30 Aug 2018 at 10:02, VERMEULEN Olivier
wrote:
>
> Hello Rob,
>
> Regarding the first scenario it just feels weird that a POST returns a 404
> NOT_FOUND... I think 400 would indeed make more sense.
> I'll have a look at the last scenario as soon as I have some time.
>
> Thanks,
> Olivier
>
> -Original Message-
> From: Rob Godfrey
> Sent: mercredi 29 août 2018 17:58
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] HTTP management
>
> On Wed, 29 Aug 2018 at 17:21, VERMEULEN Olivier
> wrote:
>
> > Hello,
> >
> > While working with the Broker-J HTTP management I found some strange
> > behaviors, especially while binding a queue to an exchange.
> >
> > * If the exchange does not exist the creation of the binding returns
> > 404 where I would expect a 5XX
> >
>
> I think 404 is reasonable here - the binding is data in the exchange object
> - if the exchange does not exist then there is no resource to be modified.
> The error here is certainly client side, error code 400 would also make sense.
>
>
> > * If the queue does not exist the creation of the binding returns 422
> > where I would also expect a 5XX
> >
>
> Again there hasn't been an internal server error, the client has just asked
> for something that is not "correct". I think here it would probably be
> better just to use error code 400 than 422.
>
>
> > * If the "x-filter-jms-selector" has an incorrect value (for example
> > "*") I get an HttpServerErrorException (and not a
> > HttpClientErrorException like the other ones) and the binding is
> > actually created even though this exception is raised...
> >
> > For the last one:
> > POST
> > http;//localhost:8080/api/latest/exchange/default/default/myTopic/bind
> > {
> > "destination":"myQueue",
> > "bindingKey":"#",
> > "arguments": {
> > "x-filter-jms-selector":"*"
> > }
> > }
> >
>
> OK - this is incorrect, the request is bad (because the filter is
> malformed) and so it should return a 4xx error - again 400 is probably the
> most appropriate. Also the binding should not be created.
>
>
>
> >
> > If you confirm these are not expected I can try to fix them
> >
> >
> If you want to provide a patch for the last one, which is definitely a bug,
> that would be great - thanks
>
> -- Rob
>
>
>
> > Regards,
> > Olivier
> >
> > ***
> >
> > This e-mail contains information for the intended recipient only. It
> > may contain proprietary material or confidential information. If you
> > are not the intended recipient you are not authorised to distribute,
> > copy or use this e-mail or any attachment to it. Murex cannot
> > guarantee that it is virus free and accepts no responsibility for any
> > loss or damage arising from its use. If you have received this e-mail
> > in error please notify immediately the sender and delete the original
> > email received, any attachments and all copies from your system.
> >
> ***
>
> This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not the
> intended recipient you are not authorised to distribute, copy or use this
> e-mail or any attachment to it. Murex cannot guarantee that it is virus free
> and accepts no responsibility for any loss or damage arising from its use. If
> you have received this e-mail in error please notify immediately the sender
> and delete the original email received, any attachments and all copies from
> your system.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
RE: [Broker-J] HTTP management
Hello Rob,
Regarding the first scenario it just feels weird that a POST returns a 404
NOT_FOUND... I think 400 would indeed make more sense.
I'll have a look at the last scenario as soon as I have some time.
Thanks,
Olivier
-Original Message-
From: Rob Godfrey
Sent: mercredi 29 août 2018 17:58
To: users@qpid.apache.org
Subject: Re: [Broker-J] HTTP management
On Wed, 29 Aug 2018 at 17:21, VERMEULEN Olivier
wrote:
> Hello,
>
> While working with the Broker-J HTTP management I found some strange
> behaviors, especially while binding a queue to an exchange.
>
> * If the exchange does not exist the creation of the binding returns
> 404 where I would expect a 5XX
>
I think 404 is reasonable here - the binding is data in the exchange object
- if the exchange does not exist then there is no resource to be modified.
The error here is certainly client side, error code 400 would also make sense.
> * If the queue does not exist the creation of the binding returns 422
> where I would also expect a 5XX
>
Again there hasn't been an internal server error, the client has just asked for
something that is not "correct". I think here it would probably be better just
to use error code 400 than 422.
> * If the "x-filter-jms-selector" has an incorrect value (for example
> "*") I get an HttpServerErrorException (and not a
> HttpClientErrorException like the other ones) and the binding is
> actually created even though this exception is raised...
>
> For the last one:
> POST
> http;//localhost:8080/api/latest/exchange/default/default/myTopic/bind
> {
> "destination":"myQueue",
> "bindingKey":"#",
> "arguments": {
> "x-filter-jms-selector":"*"
> }
> }
>
OK - this is incorrect, the request is bad (because the filter is
malformed) and so it should return a 4xx error - again 400 is probably the most
appropriate. Also the binding should not be created.
>
> If you confirm these are not expected I can try to fix them
>
>
If you want to provide a patch for the last one, which is definitely a bug,
that would be great - thanks
-- Rob
> Regards,
> Olivier
>
> ***
>
> This e-mail contains information for the intended recipient only. It
> may contain proprietary material or confidential information. If you
> are not the intended recipient you are not authorised to distribute,
> copy or use this e-mail or any attachment to it. Murex cannot
> guarantee that it is virus free and accepts no responsibility for any
> loss or damage arising from its use. If you have received this e-mail
> in error please notify immediately the sender and delete the original
> email received, any attachments and all copies from your system.
>
***
This e-mail contains information for the intended recipient only. It may
contain proprietary material or confidential information. If you are not the
intended recipient you are not authorised to distribute, copy or use this
e-mail or any attachment to it. Murex cannot guarantee that it is virus free
and accepts no responsibility for any loss or damage arising from its use. If
you have received this e-mail in error please notify immediately the sender and
delete the original email received, any attachments and all copies from your
system.
Re: [Broker-J] HTTP management
On Wed, 29 Aug 2018 at 17:21, VERMEULEN Olivier
wrote:
> Hello,
>
> While working with the Broker-J HTTP management I found some strange
> behaviors, especially while binding a queue to an exchange.
>
> * If the exchange does not exist the creation of the binding returns
> 404 where I would expect a 5XX
>
I think 404 is reasonable here - the binding is data in the exchange object
- if the exchange does not exist then there is no resource to be modified.
The error here is certainly client side, error code 400 would also make
sense.
> * If the queue does not exist the creation of the binding returns 422
> where I would also expect a 5XX
>
Again there hasn't been an internal server error, the client has just asked
for something that is not "correct". I think here it would probably be
better just to use error code 400 than 422.
> * If the "x-filter-jms-selector" has an incorrect value (for example
> "*") I get an HttpServerErrorException (and not a HttpClientErrorException
> like the other ones) and the binding is actually created even though this
> exception is raised...
>
> For the last one:
> POST http;//localhost:8080/api/latest/exchange/default/default/myTopic/bind
> {
> "destination":"myQueue",
> "bindingKey":"#",
> "arguments": {
> "x-filter-jms-selector":"*"
> }
> }
>
OK - this is incorrect, the request is bad (because the filter is
malformed) and so it should return a 4xx error - again 400 is probably the
most appropriate. Also the binding should not be created.
>
> If you confirm these are not expected I can try to fix them
>
>
If you want to provide a patch for the last one, which is definitely a bug,
that would be great - thanks
-- Rob
> Regards,
> Olivier
>
> ***
>
> This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not
> the intended recipient you are not authorised to distribute, copy or use
> this e-mail or any attachment to it. Murex cannot guarantee that it is
> virus free and accepts no responsibility for any loss or damage arising
> from its use. If you have received this e-mail in error please notify
> immediately the sender and delete the original email received, any
> attachments and all copies from your system.
>
[Broker-J] HTTP management
Hello,
While working with the Broker-J HTTP management I found some strange behaviors,
especially while binding a queue to an exchange.
* If the exchange does not exist the creation of the binding returns 404
where I would expect a 5XX
* If the queue does not exist the creation of the binding returns 422 where
I would also expect a 5XX
* If the "x-filter-jms-selector" has an incorrect value (for example "*") I
get an HttpServerErrorException (and not a HttpClientErrorException like the
other ones) and the binding is actually created even though this exception is
raised...
For the last one:
POST http;//localhost:8080/api/latest/exchange/default/default/myTopic/bind
{
"destination":"myQueue",
"bindingKey":"#",
"arguments": {
"x-filter-jms-selector":"*"
}
}
If you confirm these are not expected I can try to fix them
Regards,
Olivier
***
This e-mail contains information for the intended recipient only. It may
contain proprietary material or confidential information. If you are not the
intended recipient you are not authorised to distribute, copy or use this
e-mail or any attachment to it. Murex cannot guarantee that it is virus free
and accepts no responsibility for any loss or damage arising from its use. If
you have received this e-mail in error please notify immediately the sender and
delete the original email received, any attachments and all copies from your
system.
