Skip to content

Instantly share code, notes, and snippets.

@paragonie-scott
Last active September 22, 2016 20:18
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save paragonie-scott/d5fa1d432acc0342ba7c88686b0c9236 to your computer and use it in GitHub Desktop.
Save paragonie-scott/d5fa1d432acc0342ba7c88686b0c9236 to your computer and use it in GitHub Desktop.

Via Twitter

Authors consider SQLi as main attack vector. Hashed token mitigate r/o SQLi, encrypted mitigate r/w SQLi

That actually doesn't buy you anything. Consider the following table schema:

CREATE TABLE reset_tokens (
    tokenid BIGSERIAL PRIMARY KEY,
    selector TEXT,
    verifier TEXT,
    user BIGINT REFERENCES users (userid),
    expires TIMESTAMP
);

We recommended hashing the verifier. You might think encryption would mitigate against read/write SQLi, but you can do this:

  1. Issue a reset for an unprivileged user.
  2. UPDATE reset_tokens SET user = {$target} WHERE selector = {$knownToAttacker}
  3. Access the URL.

That works even if you can't just break out of the database, into the filesystem, and exfiltrate their encryption keys.

@paragonie-scott
Copy link
Author

Yes, that's a good point. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment