## Basic information **Project name:** Eclipse BaSyx **Project id:** dt.basyx ## What are the affected versions? BaSyx Go Components v1.0.0 and earlier are affected. The issue is fixed by: https://github.com/eclipse-basyx/basyx-go-components/pull/442 The fix is included in v1.0.1: https://github.com/eclipse-basyx/basyx-go-components/releases/tag/v1.0.1 ## Details of the issue BaSyx Go Components had an authorization bypass in ABAC-enabled deployments caused by inconsistent handling of trailing slashes in HTTP routes. In affected versions, the shared router setup used Chi's `middleware.StripSlashes`, so a request such as: `GET /shells/` was internally dispatched to the registered route: `GET /shells` However, the ABAC middleware evaluated the original request path, including the trailing slash. If the ABAC route lookup did not find a matching route for the slash-suffixed path, it passed the request onward to the router. The router then stripped the slash and executed the protected handler without the intended ABAC authorization decision and without the expected ABAC query filters. This can allow an unauthenticated or unauthorized network user to access protected endpoints by appending a trailing slash. Depending on the exposed component and HTTP method, this may allow unauthorized read, create, update, delete, or upload operations. Examples of affected route classes include collection and resource routes in AAS Repository, Submodel Repository, AAS Registry, Submodel Registry, Concept Description Repository, Discovery, AAS Environment upload, and related services that use the shared router and ABAC middleware. The issue is not specific to a database backend. It affects deployments where ABAC authorization is enabled. Weaknesses: - CWE-863: Incorrect Authorization - CWE-284: Improper Access Control - CWE-180: Incorrect Behavior Order: Validate Before Canonicalize The fix removes global trailing-slash stripping, rejects non-root trailing-slash paths during ABAC route mapping, and returns the proper router error instead of passing unmatched ABAC routes through to handlers. ## Steps to reproduce Prerequisites: - Run BaSyx Go Components v1.0.0 with ABAC enabled. - Use a policy where anonymous users are not allowed to read AAS Repository data. - Ensure at least one AAS exists. 1. Confirm that the protected route is denied without authorization: ```sh curl -i http://localhost:6004/shells ``` Expected result: ```text HTTP/1.1 403 Forbidden ``` 2. Add a trailing slash: ```sh curl -i http://localhost:6004/shells/ ``` Vulnerable result in v1.0.0 and earlier: ```text HTTP/1.1 200 OK ``` The protected collection route is reached despite the missing authorization. Fixed result in v1.0.1: ```text HTTP/1.1 404 Not Found ``` 3. The same pattern applies to other protected routes. For example: ```text /shells/ /submodels/ /concept-descriptions/ /shell-descriptors/ /submodel-descriptors/ /lookup/shells/ /upload/ ``` For methods such as `POST`, `PUT`, `PATCH`, or `DELETE`, the impact depends on whether the normalized route supports that method and what the deployed ABAC policy is intended to deny. ## Do you know any mitigations of the issue? Upgrade to BaSyx Go Components v1.0.1 or later. Temporary mitigations for deployments that cannot upgrade immediately: - Reject non-root API paths ending in `/` at a reverse proxy or gateway before they reach BaSyx Go. - Alternatively, rewrite such paths to their canonical non-trailing-slash form before they reach the application, so ABAC and routing evaluate the same path. - Restrict network access to ABAC-enabled BaSyx Go services until the fixed version is deployed.