Security Issue - state was removed and generated randomly , which exposes CSRF attack .

The state was removed and generated randomly, which exposes CSRF attack.

previously state was an optional field and was entirely removed on this commit 4274b93?short_path=b335630#r58595171

with the removal, it makes it impossible for the backend server to generate a state for that user and validate it .

the state should be brought back as optional. since most of us where already passing the state as a prop. which are validated at the backend , generating a random state exposes a security issue .

Kindly check out linked auth documentation

https://docs.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow?context=linkedin%2Fconsumer%2Fcontext&tabs=HTTPS

@donprecious Thanks for your suggestion. Can you explain a scenario that can lead to a CSRF attack? I don't see why we need backend to generate the state for the client. Since the randomly generated state will be tied to per-user browser, I cannot see how attacker can perform a CSRF attack. Am I missing something?

Reference: https://stackoverflow.com/questions/35985551/how-does-csrf-work-without-state-parameter-in-oauth2-0

@nvh95 thanks for your response.

since the randomly generated state will be tied to a user per browser, it should be validated,
that state should be validated,
because it is randomly generated and attached to the URL generated it can't be validated, after receiving an auth code,

here is a reference to why the state should be validated and generated by the server
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

@donprecious

that state should be validated
because it is randomly generated and attached to the URL generated it can't be validated, after receiving an auth code

The state actually is validated after the Authorization Server redirect us back to the app again (callbackUrl)

react-linkedin-login-oauth2/src/LinkedIn.js

Lines 62 to 66 in 9cec702

    
           // Prevent CSRF attack by testing state 
        
           if (event.data.state !== state) { 
        
             this.popup && this.popup.close(); 
        
             return; 
        
           }

Can you provide an example/ scenario of how attacker can perform a CSRF attack?

You can refer to how to prevent CSRF attack when using Oauth2 flow here: https://auth0.com/docs/configure/attack-protection/state-parameters

I'm closing this issue for now. Please let me know if there is a scenario when CSRF attack might be performed. However, I think it's fair to let users choose their own state, if users don't specify, it will be ramdomly generate for them. This property will be added again in 2.x (currently in progress #50)

	// Prevent CSRF attack by testing state
	if (event.data.state !== state) {
	this.popup && this.popup.close();
	return;
	}