Re:# of days since the last alg=none JWT vulnerability
by jimktrains2 on Tuesday September 01, 2020 @07:23PM
(#24348276)
Yes, some libraries provide a key callback function where the unauthenticated token is provided for this type of thing, but the result of the function is supposed to be the key used to verify the token and nothing else is supposed to happen as a side effect.
Re:# of days since the last alg=none JWT vulnerability
by hinkley on Tuesday September 01, 2020 @07:41PM
(#24348411)
Oh good, that's what I hoped.
Yes, you could have side effects, but it's pretty damned obvious you're being naughty. That's mostly what I want. The obviousness of the cheating makes people think twice, ask questions. Slow down.
Are you essentially talking about having different strategies to verify the token? Would it make sense to provide some sort of filter function as a parameter that the library can call to clarify what operations need to be performed?
That would allow you to peek at the records in a context where your role is clear, and where the code flow makes it awkward to take the data and run with it. If the code feels wrong enough, it's hard for the developer to claim ignorance, and if it's clear from the outset that ignorance is not an explanation, that leaves malice and stupidity. Most developers won't admit to either, but if forced they'd rather be seen as malicious than stupid, and malicious gets you a meeting with HR.