Add backend validation for SSH keys #2258

New issue

Closed

opened 2026-03-04 08:40:37 +00:00 by EricvanSchaik · 3 comments

EricvanSchaik commented

2026-03-04 08:40:37 +00:00

(Migrated from github.com)

Description

As an application owner, I want to be sure that SRAM only forwards legitimate SSH keys so that those keys do not become a security risk.

During a pentest for SRC, it was found that the frontend input field for SSH keys in https://sram.surf.nl/profile/details is validated, but not on the backend. This means that you could manually modify the request to the backend, insert malicious code in place of the SSH key, and send it to the backend. The backend saves it, and blindly forwards it to some application when the user with the malicious SSH key logs in. This needs to be fixed by applying the same validation rules on the backend as on the frontend. We should also check the logs to see if anyone has exploited the vulnaribility in the past.

Task Overview

Add validation to the update_user() method in server/api/user.py:543.
Check the logs / database to check if anyone has exploited the vulnaribility in the past.

Acceptance Criteria

The PUT request /api/users/ is rejected when the payload is not according to the frontend validation rules.
The frontend validation rules use the backend validation rules to inform the user that a key is invalid.

Notes

See https://servicedesk.surf.nl/jira/browse/SD-120320

### Description As an application owner, I want to be sure that SRAM only forwards legitimate SSH keys so that those keys do not become a security risk. During a pentest for SRC, it was found that the frontend input field for SSH keys in https://sram.surf.nl/profile/details is validated, but not on the backend. This means that you could manually modify the request to the backend, insert malicious code in place of the SSH key, and send it to the backend. The backend saves it, and blindly forwards it to some application when the user with the malicious SSH key logs in. This needs to be fixed by applying the same validation rules on the backend as on the frontend. We should also check the logs to see if anyone has exploited the vulnaribility in the past. ### Task Overview - [x] Add validation to the `update_user()` method in `server/api/user.py:543`. - [x] Check the logs / database to check if anyone has exploited the vulnaribility in the past. ### Acceptance Criteria - [x] The PUT request `/api/users/` is rejected when the payload is not according to the frontend validation rules. - [x] The frontend validation rules use the backend validation rules to inform the user that a key is invalid. ### Notes See https://servicedesk.surf.nl/jira/browse/SD-120320

cgociusurf commented

2026-05-12 08:19:58 +00:00

(Migrated from github.com)

Hi, did you find any reasons to believe previous exploitation occurred when you checked the logs/database?

EricvanSchaik commented

2026-05-19 10:25:13 +00:00

(Migrated from github.com)

Verified on acc that I can send the same PUT request to /api/users that the browser sends, but with invalid content. For instance, the following body works: {"ssh_keys":[{"ssh_value":"troep","manual":true,"fileTypeError":false}]}, and I can see it in my profile (using the cookie and csrftoken from my browser, where the token is only included in a header where it is needed, such as when adding another ssh key). Doing the same on test returns a 400 BadRequest: "Invalid ssh_key troep, rejecting update"

Verified on acc that I can send the same PUT request to `/api/users` that the browser sends, but with invalid content. For instance, the following body works: `{"ssh_keys":[{"ssh_value":"troep","manual":true,"fileTypeError":false}]}`, and I can see it in my profile (using the cookie and csrftoken from my browser, where the token is only included in a header where it is needed, such as when adding another ssh key). Doing the same on test returns a 400 BadRequest: "Invalid ssh_key troep, rejecting update"

EricvanSchaik commented

2026-06-05 12:06:23 +00:00

(Migrated from github.com)

Now also working on acc

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

eric/SBS#2258

No description provided.

Rows
Columns