a che cosa serve il sale token anti-contraffazione?

Question

In ASP.NET MVC 1.0 è disponibile una nuova funzionalità per la gestione del problema di sicurezza della falsificazione delle richieste tra siti:

 <%= Html.AntiForgeryToken() %>
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
    // ... etc
}

Ho scoperto che il token generato in forma html continua a cambiare ogni volta che viene visualizzato un nuovo modulo.

Voglio sapere come viene generato questo token? E quando si utilizza un software per scansionare questo sito, verrà segnalato un altro problema di sicurezza: Sessione fissa. Perché? Poiché il token viene modificato, come può verificarsi questo problema?

E c'è un'altra funzione, che è "sale". per antiForgeryToken , ma so davvero a cosa serviva, anche se non utilizziamo " salt " per generare il token, il token cambierà continuamente, quindi perché avere tale funzione?

Answer 1

Molte informazioni su AntiForgery prese qui: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Questo serve a prevenire una contraffazione di richieste tra siti (CSRF). È un comportamento piuttosto standard fare clic su "Salva" per sommare un modulo ed eseguire alcune azioni sul server, ovvero salvare i dettagli di un utente. Come fai a sapere che l'utente che invia il modulo è l'utente che dichiara di essere? Nella maggior parte dei casi utilizzeresti qualche cookie o autenticazione basata su Windows.

Cosa succede se un utente malintenzionato ti attira a un sito che invia esattamente lo stesso modulo in un piccolo IFRAME nascosto? I tuoi cookie vengono inviati intatti e il server non vede la richiesta come diversa da una richiesta legittima. (Come ha scoperto gmail: http: //www.gnucitizen. org / blog / google-gmail-e-mail-dirottamento-tecnica / )

Il token anti-contraffazione impedisce questa forma di attacco creando un token cookie aggiuntivo ogni volta che viene generata una pagina. Il token è sia nella forma che nel cookie, se la forma e il cookie non corrispondono, abbiamo un attacco CSRF (poiché l'attaccante non sarebbe in grado di leggere il token anti-contraffazione usando l'attacco descritto sopra).

E cosa fa il sale, dall'articolo sopra:

  

Salt è solo una stringa arbitraria. Un diverso valore di sale indica che verrà generato un diverso token anti-contraffazione. Ciò significa che anche se un utente malintenzionato riesce a ottenere in qualche modo un token valido, non può riutilizzarlo in altre parti dell'applicazione in cui è richiesto un valore salt diverso.

Aggiornamento: come viene generato il token? Scarica il source e dai un'occhiata alle classi AntiForgeryDataSerializer, AntiForgeryData.

Answer 2

Hai chiesto alcuni problemi non correlati:

1. Non so perché il tuo software di sicurezza stia segnalando "sessione risolta". Prova a leggere la documentazione fornita con il rapporto
2. Il token anti-contraffazione:

Questo è usato (presumibilmente) per confermare che ogni richiesta è valida. Quindi considera che qualcuno prova a presentare un link alla pagina ? X = 1 , se anche il token non viene passato, la richiesta verrà rifiutata. Inoltre, può (può) impedire la duplicazione della stessa voce. Se fai clic su "pubblica" due volte, il token probabilmente cambierà (ogni richiesta) e questo caso verrà rilevato tramite qualcosa del tipo:

Session["nextToken"] = token;
WriteToken(token);

...

if( !Request["nextToken"] == Session["nextToken"] ){
    ...
}

// note: order in code is slightly different, you must take the token
// before regenerating it, obviously

Penso che il termine per questo (l'attacco che protegge) sia chiamato " CSRF " (Cross-Site Request Forgery), in questi giorni.