asf-tooling opened a new issue, #1040:
URL: https://github.com/apache/tooling-trusted-releases/issues/1040
**ASVS Level(s):** [L1]
**Description:**
### Summary
The POST blueprint automatically calls `check_access(project_key)` when a
`project_key` parameter is detected in the route signature, providing
centralized project-level authorization. The GET blueprint has no equivalent
mechanism, requiring each GET handler to manually call
`session.check_access(project_key)`. This architectural asymmetry creates
inconsistency risk — developers adding new GET routes with project parameters
may omit the authorization check, and the authorization documentation does not
explain this difference.
### Details
Affected locations:
- `atr/blueprints/get.py`: No centralized authorization
- `atr/get/distribution.py`: Manual check_access() calls required
- `atr/get/file.py`: Manual check_access() calls required
- `atr/get/report.py`: Manual check_access() calls required
- `atr/get/checks.py`: Manual check_access() calls required
The POST blueprint provides automatic authorization but GET blueprint
requires manual checks, creating inconsistency.
### Recommended Remediation
**Option A (Preferred):** Add automatic authorization to GET Blueprint by
detecting `project_key` parameters and calling `check_access()` automatically,
mirroring POST blueprint behavior:
```python
# In atr/blueprints/get.py
@_BLUEPRINT.before_request
async def _auto_check_project_access():
"""Automatically check project access for routes with project_key
parameter."""
if 'project_key' in quart.request.view_args:
session = await common.authenticate()
project_key = quart.request.view_args['project_key']
await session.check_access(project_key)
```
**Option B:** Document the requirement in authorization-security.md with
explicit guidance that GET endpoints with `project_key` parameters MUST
explicitly call `check_access()`. Add linting rule to detect missing checks.
Audit all existing GET endpoints with `project_key` parameters. Add integration
tests for each endpoint verifying authorization. Add developer documentation to
developer-guide.md.
### Acceptance Criteria
- [ ] GET blueprint has centralized authorization or documented requirements
- [ ] Authorization is consistent between GET and POST blueprints
- [ ] Linting or automation prevents missing checks
- [ ] Test cases verify authorization
- [ ] Unit test verifying the fix
### References
- Source reports: L1:8.1.1.md
- Related findings: FINDING-141
- ASVS sections: 8.1.1
### Priority
Medium
---
---
### Consolidated: FINDING-141 - API Blueprint Lacks Centralized
Authentication Hook
**ASVS Level(s):** [L1]
**Description:**
### Summary
The admin blueprint enforces authentication via a centralized
`before_request` hook that verifies admin status for all routes. The API
blueprint only implements a rate-limiting hook, requiring each API endpoint to
individually apply `@jwtoken.require` decorators. Without centralized
enforcement or comprehensive documentation mapping endpoints to authentication
requirements, new API endpoints could be added without proper authentication.
### Details
Affected locations:
- `atr/blueprints/api.py`: No centralized authentication hook
- `atr/api/__init__.py`: Individual decorator application required
The API blueprint has no centralized authentication enforcement, relying on
developers to remember to apply `@jwtoken.require` decorator to each endpoint.
### Recommended Remediation
**Option A:** Add centralized authentication hook to API blueprint if all
API endpoints require auth, performing JWT validation in `before_request` and
storing payload in request context:
```python
@_BLUEPRINT.before_request
async def _require_authentication():
"""Require JWT authentication for all API endpoints."""
# Perform JWT validation
token = quart.request.headers.get('Authorization', '').replace('Bearer
', '')
if not token:
return quart.jsonify({"error": "Authentication required"}), 401
try:
claims = jwtoken.verify(token)
quart.g.jwt_claims = claims
except JWTError as e:
return quart.jsonify({"error": str(e)}), 401
```
**Option B:** Create comprehensive documentation in
authorization-security.md with API endpoint authorization matrix including
authentication requirements, authorization levels, and rate limits. Add
developer checklist for new API endpoints.
**Option C:** Add linting rule to detect API endpoint functions without
`@jwtoken.require` decorator. Audit all existing API endpoints for
authentication status. Add integration tests verifying authentication for each
endpoint.
### Acceptance Criteria
- [ ] API blueprint has centralized authentication or documented requirements
- [ ] Authentication is enforced consistently
- [ ] Linting or automation prevents missing authentication
- [ ] Test cases verify authentication
- [ ] Unit test verifying the fix
### References
- Source reports: L1:8.1.1.md
- Related findings: FINDING-140
- ASVS sections: 8.1.1
### Priority
Medium
---
---
**Triage notes:** audit_guidance - add in-line comment on the get routes,
@sbp - possibly rename the function, add blueprint for token roots
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
