TL;DR We probably need to re-do our authentication.
Look at the implementation section for how we could implement it
https://fastapi.tiangolo.com/advanced/security/oauth2-scopes/
https://www.rfc-editor.org/rfc/rfc7519#section-10.1
https://www.rfc-editor.org/rfc/rfc8725
Description
I think our backend should be frontend agnostic, which means we should probably improve how we handle sessions. We could also share sessions between different applications across the CSSS. This will require us to rewrite how our authentication flow works. Since we rely on SFU's CAS system, we would just need to adapt how our sessions are managed.
Problems and Solution
There are a number of problems with our current implementation.
1. Strings are handled poorly
We need to check things are encoded properly and that the POST body from login is not malicious.
Solutions
2. Cleaning up expired sessions from the database is reliant on logins
If someone's session expires then it sits in the database until someone else logs in and the sessions are checked.
Solutions
3. Site user pics are vulnerable to XSS
People could upload pictures that is actually malicious code.
Solution
4. Logging in invalidates previous sessions
That means if someone has multiple tabs open they could be logged out of their session on certain tabs.
Solution
5. Session IDs are way too big
It's 256 bytes right now, which is apparently way too big.
Solution
6. No rate-limiting to our login endpoint
Our web server could be used to DoS the SFU CAS servers. This will probably need to be handled on Nginx.
Solution
TL;DR We probably need to re-do our authentication.
Look at the implementation section for how we could implement it
https://fastapi.tiangolo.com/advanced/security/oauth2-scopes/
https://www.rfc-editor.org/rfc/rfc7519#section-10.1
https://www.rfc-editor.org/rfc/rfc8725
Description
I think our backend should be frontend agnostic, which means we should probably improve how we handle sessions. We could also share sessions between different applications across the CSSS. This will require us to rewrite how our authentication flow works. Since we rely on SFU's CAS system, we would just need to adapt how our sessions are managed.
Problems and Solution
There are a number of problems with our current implementation.
1. Strings are handled poorly
We need to check things are encoded properly and that the POST body from login is not malicious.
Solutions
login_user) Removeredirect_url, just redirect to thehttps://admin.sfucsss.orgfor now,login_user)urllib.parse.quote(body.ticket)as well, just likeservice2. Cleaning up expired sessions from the database is reliant on logins
If someone's session expires then it sits in the database until someone else logs in and the sessions are checked.
Solutions
user_sessiontable regularly #1523. Site user pics are vulnerable to XSS
People could upload pictures that is actually malicious code.
Solution
4. Logging in invalidates previous sessions
That means if someone has multiple tabs open they could be logged out of their session on certain tabs.
Solution
5. Session IDs are way too big
It's 256 bytes right now, which is apparently way too big.
Solution
6. No rate-limiting to our
loginendpointOur web server could be used to DoS the SFU CAS servers. This will probably need to be handled on Nginx.
Solution