Fixazione della sessione OpenID con CSRF

3

Questa risposta descrive una situazione in cui CSRF può essere utilizzato per ingannare un utente finale per inserire una carta di credito nell'account Paypal di un'altra persona. Evidenzia anche il fatto che le richieste GET che cambiano lo stato sono altrettanto brutte delle richieste POST.

Questo è abbastanza semplice da capire quando si ha a che fare con un'autenticazione basata su un singolo modulo. Ma se introduciamo un sistema di autenticazione basato su GET e POST su domini diversi che non "possediamo", non sono sicuro di come prevenire CSRF in quella situazione.

If I were to extend this to OpenID, does this mean that a user could inject their OpenID credentials into my session?

Qual è il modo giusto per affrontare questo problema?

    
posta random65537 08.11.2011 - 17:50
fonte

1 risposta

2

Risponderò alla mia domanda poiché non ho visto questa pratica essere incoraggiata in varie SDK e esempi di codice . Ecco la mia teoria:

Facendo clic sul pulsante "accedi" su Relying Party (RP), dovrebbero verificarsi due cose:

  1. Scrivi un valore casuale su un SECURE HTTPOnly cookie di dominio

  2. Quindi reindirizza IDP al link  dove "myrandom" è uguale al valore all'interno del cookie.

  3. Quando il processo OpenID ti registra, allora POST l'URL sopra, puoi quindi prendere la stringa CSRF e confrontarla con il cookie.

Fammi sapere se vedi qualche difetto in questo approccio

    
risposta data 08.11.2011 - 18:02
fonte

Leggi altre domande sui tag