130 reputation
19
bio website
location
age
visits member for 2 years, 7 months
seen Sep 4 at 17:52

He is Me and I am Yu


Sep
24
awarded  Autobiographer
Jun
3
awarded  Notable Question
May
15
awarded  Commentator
May
15
comment OAuth2 Cross Site Request Forgery, and state parameter
When I say server I mean my server, did we fail to communicate? I thought it's clear what server I mean as I said I store the state on it.
May
15
comment OAuth2 Cross Site Request Forgery, and state parameter
If only the client has to (re)create the state, how the server knows it's right?
May
15
comment OAuth2 Cross Site Request Forgery, and state parameter
I actually use a framework, that saves the state, but I wondered if it's right, hence the question. I also have read some articles about state, and if I remember well, they all showed an implementation that saved state on server. If the state should be recreated on client and server side both, then the hashing algorithm would be known, so all a hacker would need to get is the data that is hashed.
May
15
comment OAuth2 Cross Site Request Forgery, and state parameter
I don't recreate it, I store it on the server.
May
15
comment OAuth2 Cross Site Request Forgery, and state parameter
From what I read, the state should be generated randomly. You suggest something opposite - to generate it from user data. I also don't understand why the hash should be unique - how do one enforce the uniqueness of a hash?
Oct
7
awarded  Popular Question
Oct
4
awarded  Benefactor
Oct
4
accepted OAuth2 Cross Site Request Forgery, and state parameter
Oct
2
comment OAuth2 Cross Site Request Forgery, and state parameter
Thanks. I've done such XSRF (CSRF) attacks (e.g. I sent a link to my friend that made him delete a post on his forum), and I imagine an attack where someone gives you a login URL to a site, where you login as him (victim logs in on attacker's account). It's quite easy to protect against such attack (store state in session), but aren't there more complex hacking techniques than that?
Sep
27
awarded  Promoter
Sep
14
revised OAuth2 Cross Site Request Forgery, and state parameter
updated link to the ietf draft to last version
Sep
14
asked OAuth2 Cross Site Request Forgery, and state parameter
Apr
30
awarded  Supporter
Apr
30
comment Injecting ampersand to the url
With this repeated keys i was meaning a specific situation when I already set all keys that the API reads, and the API could just check if keys aren't repeated. But indeed, it looks like I can just inject everything in one key, and then put %23 (#) on end of it. It will make everything next to parse not as keys. In some situations that would bypass the multikey checking protection, and in PHP it would always made the injected params treated as most (only) important. But my current point is, how the API can protect a developer, and looks like there's no general solution.
Apr
29
comment Injecting ampersand to the url
I wrote that the API server could check if a key is repeated, but now I think, could the hacker inject such characters, to make real ampersand become part of the previous value, and so, making the whole key-value pair 'swallowed' by previous value?
Apr
29
awarded  Scholar
Apr
29
accepted Injecting ampersand to the url