Desktop- og mobilapps er indlejrede browsere i appen, der hjælper med at gennemføre hele OAuth 2.0-processen
Processen er vist i figuren
OAuth2.0 web
1) Returner authCode til den specificerede Web redirectUri (denne URI konfigureres af app-udvikleren)
2) For at ændre tokenet skal du sende clientId og clientSecret for at verificere klientidentiteten (opnået af applikationens backend-service)
Bemærker de to ovenstående punkter,
1) Fordi ikke webappens redirectUri-detektion er ugyldig
2) Fordi der ikke findes nogen backend-service client, er Secret ikke sikker
Så det angreb, vi kan støde på, er som vist i figuren nedenfor: Der kan være en ondsindet applikation, der opsnapper authCode for at sende en besked til AuthorizationServer for at hente tokenet, så tokenet opnås uden kundens godkendelse til applikationen, men til en anden officiel applikationsautorisation, hvilket opfylder angrebets formål.
Løsning:
1. Klienten genererer en tilfældig streng: code verifier og gemmer denne tilfældige streng
code_challenge = transform(code_verifier, [Plain| S256])
Hvis transformmetoden er plain, er kodeudfordring ækvivalent med kodeverificerer
Hvis transformmetoden er S256, er kodeudfordringen lig med Sha256-hashen for kodeverificereren
2. Bring en kodeudfordring til autorisationskodeanmodningen og hvordan man genererer en kodeudfordring. Disse to er bundet til autorisationskoden udstedt af serveren
3. Efter at have modtaget autorisationskoden medbringer klienten den oprindeligt genererede kodeverifikator, når autorisationskoden udveksles for Access Token. Serveren beregner kodeverificeren i henhold til bound transform-metoden, sammenligner det beregnede resultat med bound code-udfordringen og udsteder en Access Token, hvis den er konsistent. |
Opslået på 28/11/2020 20.51.48
|
|
|
|
