Pagina 2 di 2 primaprima 1 2
Visualizzazione dei risultati da 11 a 15 su 15
  1. #11
    Grazie mille! Mi rimangio tutto quello che ho scritto e chiedo scusa.
    Ho letto quello che mi avete inviato ma ho ancora quattro domande.
    1) Per accedere alla pagina di login devo conoscere il codice casuale prodotto dalla stessa pagina di login. In teoria posso fare la login anche da un sito maligno, basta copiare il codice casuale da login.jsp e poi fare la richiesta dal sito maligno. In buona sostanza non vedo molta utilità in questo tag.
    2) Perché nella pagina di registrazione manca il codice casuale?
    3) Meglio json-web-token oppure spring-boot-starter-security, oppure ancora entrambi ai fini della sicurezza?
    4) Una vera banca oltre a
    json-web-token, a spring-boot-starter-security quali altri strumenti utilizza?

    Più pratica in futuro...

  2. #12
    Quote Originariamente inviata da giannino1995 Visualizza il messaggio
    1) Per accedere alla pagina di login devo conoscere il codice casuale prodotto dalla stessa pagina di login. In teoria posso fare la login anche da un sito maligno, basta copiare il codice casuale da login.jsp e poi fare la richiesta dal sito maligno. In buona sostanza non vedo molta utilità in questo tag.
    La difesa contro il CSRF attack SERVE in questo scenario: tu sei l'utente "lecito" di unabanca.xyz, vai sul sito, fai login e il sito manda al TUO browser un cookie per la sessione utente associato al dominio unabanca.xyz (quindi viene re-inviato solo verso unabanca.xyz). Se non ci fosse il token CSRF, allora MENTRE sei ancora loggato (quindi hai quel cookie) tu potresti malauguratamente cliccare su un link/form (da mail malevola, sito malevolo ecc.) che fa compiere operazioni illecite verso unabanca.xyz perché è come se le facessi proprio tu, dato che vengono fatte appunto dal TUO browser che ha quel cookie di unabanca.xyz.

    Con il token random anti CSRF, se unabanca.xyz è stato fatto "ragionevolmente" bene, PRIMA di fare operazioni "sensibili" ti fa andare su una pagina dove genera il token e lo associa alla sessione. E la operazione "sensibile" la esegue solo se riceve il token "giusto" associato alla sessione. E quindi un attaccante non ti può comporre una mail/pagina malevola perché il token NON lo può (non dovrebbe riuscire a) saperlo. A questo serve la misura anti CSRF.

    In effetti questo NON impedisce ad un attaccante di fare lui una request ad una pagina di login, prendere il token (e il cookie) e poi "girare" a te una pagina farlocca in cui ti chiede di mettere username/password che poi malevolmente usa insieme a token e cookie per fare il login.
    Questa sarebbe tutta un'altra questione ....

    Non sono esperto di queste cose e spero di non aver detto cavolate (data l'ora ...). Ci ripenso su domani ..
    AndreaSenior Java developerSCJP 5 (91%) – SCWCD 5 (94%)
    Il mio nuovo sito-blog italiano sulla programmazione: andbin.it

  3. #13
    Ci penso ma non ho ben capito quello che scrivi. Un codice anche se random è pur sempre visibile nel file html.
    Più pratica in futuro...

  4. #14
    Quote Originariamente inviata da giannino1995 Visualizza il messaggio
    Ci penso ma non ho ben capito quello che scrivi. Un codice anche se random è pur sempre visibile nel file html.
    Certo, TU lo puoi vedere (tu che stai navigando sul sito unabanca.xyz).
    Ma se mentre fai "altro" (E sei ancora "loggato" su unabanca.xyz) malauguratamente clicchi su un link/form "malevolo" contenuto in una email o un pagina che stai guardando, l' "attaccante" che vuole sfruttare unabanca.xyz e che ha predisposto quel link/form NON potrebbe certo sapere quale è il token e quindi non può spacciarti un link/form per fare una richiesta tecnicamente valida per compiere l'illecito ...
    AndreaSenior Java developerSCJP 5 (91%) – SCWCD 5 (94%)
    Il mio nuovo sito-blog italiano sulla programmazione: andbin.it

  5. #15
    Mille grazie, ho capito ma ti faccio ancora qualche domanda per comprendere i limiti del plugin:

    Se il malintenzionato ruba il cookie relativo alla pagina protetta welcome.jsp può usarlo per accedere alla stessa pagina welcome.jsp dal proprio computer?

    Ogni volta che cambio pagina il cookie cambia?
    Ultima modifica di giannino1995; 26-09-2019 a 00:40
    Più pratica in futuro...

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.