Potential vulnerability to timing attacks in OAuth2 access token and invite/selfservice/signup/confirmation link verification
Throughout the codebase we verify secrets using database functions like Query.get
or Query.filter_by
. E.g. invite.use
verifies the user-supplied token with:
invite = Invite.query.filter_by(token=token).first_or_404()
While this avoids having to deal with some corner-cases, it essentially asks the database to do a string comparison on every invite link's secret token with a user-supplied value. SQL databases don't guarantee that string comparions run in constant-time, so this opens up the possibility of timing attacks. (Side note: In this case it is also very inefficient. Creating an index for the token
field would help with that.) In cases where we use the secret as the primary key (e.g. password reset), it is likely that the database uses an index and this might make timing attacks more difficult or impossible. However there is still no guarantee for that and I would argue that we should consider uffd to be potentionally vulnerable.
The best-practice for python seems to be to embed both object id and secret token in links. We can then do the query with the id alone and then use secrets.compare_digest
(does constant-time string comparison) to verify the secret token. Of course this approach changes the URL schema.