OpenStack Dashboard Charm

no rate limiting for incoming requests

Bug #1836514 reported by Xav Paice
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard Charm
Fix Committed
Wishlist
Mert Kirpici
OpenStack HA Cluster Charm
Triaged
Wishlist
Unassigned

Bug Description

Customer has performed a security scan of their deployment, and reported that the Dashboard has no rate limiting in place for the openstack-dashboard application. Their comment:

DESCRIPTION:
The team found that the applications would allow a user to send an unlimited number of requests to
the application without getting blocked or timed out. Allowing unlimited request could be used to
enumerate variables, perform automatic MySQL injection and cross-site scripting attacks or could be
used to perform a denial of service attack on the application. During testing no vulnerability was
found using this issue lowering the risk rating to a low.
EVIDENCE:
The team was able to run multiple scans without getting slowed down or blocked.

Can we go about rate limiting this application via haproxy settings or similar, in a configurable manner?

The URL reported was the standard https port, not the apache port (433).

James Page (james-page)
Changed in charm-openstack-dashboard:
status: New → Triaged
importance: Undecided → Wishlist
information type: Private Security → Public
Revision history for this message
Xav Paice (xavpaice) wrote :

Subscribed field-medium as this is a commercial requirement, for a site running Bionic/queens.

Revision history for this message
Xav Paice (xavpaice) wrote :

Added charm-hacluster as this could be implemented via haproxy and therefore handle rate limiting for multiple openstack applications.

Alex Kavanagh (ajkavanagh)
Changed in charm-hacluster:
status: New → Triaged
importance: Undecided → Wishlist
Alvaro Uria (aluria)
tags: added: bseng-80
Mert Kirpici (mertkirpici)
Changed in charm-openstack-dashboard:
assignee: nobody → Mert Kırpıcı (mertkirpici)
status: Triaged → In Progress
Revision history for this message
James Page (james-page) wrote :

I think this makes a nice security addition to the dashboard charm; it could also apply to API services which also use haproxy as part of their service chain infront of the actual service daemon.

If we do implement this I'd like for it to be disabled by default; enabling should turn on a set of sensible defaults that have been more widely reviewed and we need to make sure sufficient configuration options are exposed to allow tuning.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-openstack-dashboard (master)

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/charm-openstack-dashboard/+/850644

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-openstack-dashboard (master)

Reviewed: https://review.opendev.org/c/openstack/charm-openstack-dashboard/+/850644
Committed: https://opendev.org/openstack/charm-openstack-dashboard/commit/c0f87087615e4744e67c2f6dbda3a6b0ed18d3c5
Submitter: "Zuul (22348)"
Branch: master

commit c0f87087615e4744e67c2f6dbda3a6b0ed18d3c5
Author: Mert Kırpıcı <email address hidden>
Date: Wed Jul 20 13:55:38 2022 +0000

    Introduce source IP based rate limiting

    Since we are running haproxy in L4, we are tracking the incoming
    byte rate from client IPs and rejecting TCP connections in a
    sliding window.

    This approach limits the incoming HTTP requests however image uploading
    through the horizon web app is unaffected.

    Change-Id: Ie40d28acb2dc2983fc9edbbeacfd671b380a8f6d
    Closes-Bug: #1836514
    Signed-off-by: Mert Kırpıcı <email address hidden>

Changed in charm-openstack-dashboard:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.