Perché i token di sincronizzazione e i pattern da cookie a intestazione non sono naturali per le API Web?

0

Ho sentito che le tecniche di prevenzione CSRF non sono naturali per le API Web.

Ad esempio, potremmo avere un'applicazione client su domainA che implementa sia il il Pattern token di sincronizzazione che il Cookie-to -Disegno della persona . Quando i client POST al server di risorse al dominio B, il server di risorse deve convalidare tali valori di sicurezza e poiché il server di risorse non saprebbe quale valore di token di sincronizzazione né quale valore di cookie-to-header deve aspettarsi, avrà difficoltà convalidare quelli.

Detto questo, il server delle risorse potrebbe convalidare il token di sincronizzazione e / o il valore da cookie a header usando la stessa tecnica che usa per convalidare il token di accesso. Detto questo, perché queste due tecniche sono considerate inappropriate per un'API Web?

    
posta Shaun Luttin 29.09.2016 - 19:40
fonte

1 risposta

1

In un flusso CSRF Web, il server invia il token come parte della risposta che serve la pagina Web, quindi il token viene consegnato "gratuitamente". In genere, lo stesso server è anche l'obiettivo per quelle richieste POST in modo che possa facilmente convalidare i token.

Quando chiami un'API Web, la destinazione è probabilmente un server diverso, quindi il token dovrà essere comunicato fuori banda o il client dovrà inviare una richiesta solo per il token da utilizzare in una richiesta successiva . In entrambi i casi, il server API Web gestisce il doppio del numero di richieste, che è uno spreco.

Buone alternative sono schemi di firma digitale o metodi / intestazioni HTTP non consentiti dai browser.

    
risposta data 29.09.2016 - 20:56
fonte

Leggi altre domande sui tag