In Eclipse BaSyx AAS Web UI versions v2-241220 through releases before v2-260924, the shared request handler attached the selected infrastructures Authorization header to outgoing requests without checking the destination origin. In deployments using authentication, an attacker could induce a user to open a crafted Web UI link whose aas or path query parameter points to an attacker-controlled endpoint. The users browser would then send the configured Basic Authentication credentials, Bearer token, or an available OAuth2 access token to that endpoint. The attacker could reuse the disclosed credential to access protected AAS services with the victims privileges. The issue is fixed in v2-260924.
Weakness
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
Potential Mitigations
- Compartmentalize the system to have “safe” areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Related Attack Patterns
- https://cwe.mitre.org/data/definitions/12.html
- https://cwe.mitre.org/data/definitions/217.html
- https://cwe.mitre.org/data/definitions/612.html
- https://cwe.mitre.org/data/definitions/613.html
- https://cwe.mitre.org/data/definitions/618.html
- https://cwe.mitre.org/data/definitions/619.html
- https://cwe.mitre.org/data/definitions/621.html
- https://cwe.mitre.org/data/definitions/622.html
- https://cwe.mitre.org/data/definitions/623.html