--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
This has recently resurfaced so it’s worth responding to this old thread with an update.
Modern RabbitMQ management UI can be configured to specify CSP headers [1] in its responses,
which limits if/how the page can be embedded [2][3].
So it is possible to set it to
frame-ancestors ‘none’
if your environment requires it. You can set arbitrary headers using Nginx or a similar reverse proxy as well.
If there are reasons for us to change the default value of the header (it is currently ‘self’), let us know with a more detailed justification.
Dear RabbitMQ developers and user,
I'm a DevOps engineer at ING in the Netherlands and we're using RabbitMQ as a message broker between RSA Web Threat Detection and Elastic (logstash to be precise). This whole infrastructure has been penetration tested with a finding on RabbitMQ Web interface. Please add a ticket to the backlog of RabbitMQ development.
Here is the text from the penetration report related to RabbitMQ:
3. Medium Risk Vulnerabilities
A medium risk vulnerability could be expected to have a serious adverse effect on organisational operations, organisational assets, or individuals.
A serious adverse effect means that, for example, the loss of confidentiality, integrity, oravailability might:
· Cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced;
· Result in significant damage to organisational assets;
· Result in significant financial loss; or
· Result in significant harm to individuals that does not involve loss of life or serious life threatening injuries.
3.1 Missing Cross-Frame Scripting Protection
3.1.1 Asset
<Deleted>
3.1.2 Description
A Cross-Frame Scripting (XFS) vulnerability can allow an attacker to load the vulnerable application inside an HTML iframe tag on a malicious page. The attacker could use this weakness to devise a Clickjacking attack to conduct phishing, frame sniffing, social engineering or Cross-Site Request Forgery attacks.
3.1.3 Recommendations
Browser vendors have introduced and adopted a policy-based mitigation technique using the X-Frame-Options header. Developers can use this header to instruct the browser about appropriate actions to perform if their site is included inside an iframe. Developers must set the X-Frame-Options header to one of the following permitted values: · DENY Deny all attempts to frame the page · SAMEORIGIN The page can be framed by another page only if it belongs to the same origin as the page being framed · ALLOW-FROM origin Developers can specify a list of trusted origins in the origin attribute. Only pages in the same origin are permitted to load this page inside an iframe. ""X-Frame-Options"" header should be present in each server response.
3.1.4 Additional information
OWASP: Cross Frame Scripting https://www.owasp.org/index.php/Cross_Frame_Scripting OWASP https://www.owasp.org/index.php/Clickjacking CAPEC-103 http://capec.mitre.org/data/definitions/103.html
3.1.5 Evidences
<Picture of the RabbitMQ login GUI>
Kind regards,
Bernard van der Helm
Mail: bernard.van.der.helm(at)ing.nl
--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
rabbitmq-user...@googlegroups.com.
To post to this group, send email to
rabbitm...@googlegroups.com.