Visualizzazione dei risultati da 1 a 8 su 8

Discussione: urlReferrer

Visualizzazione discussione

  1. #4
    Utente di HTML.it L'avatar di U235
    Registrato dal
    Mar 2006
    Messaggi
    1,539
    Sarebbe cosa buona e giusta sapere meglio nello specifico il passaggio.
    Supponendo che il client (da ora C) fa richiesta al primo server (da ora A) per poi essere indirizzato al server (da ora B) che deve identificarlo come proveniente da A, quindi il giro sarebbe:
    C chiede ad A, A decide che C deve essere indirizzato a B, quindi (A) pu� crittografare le informazioni (ad esempio l'IP ed altre eventuali info) per B con la chiave di codifica condivisa (A-B) e consegnarle a C, che a sua volta le allegher� nella richiesta per B, B a quel punto decripta le info crittografate consegnate da C (e ad esempio controlla l'IP) e determina se � l'amicotuo o un sedicente. Oppure se vuoi aggiungere un passaggio e rendere monouso (anche senza crittografia nel caso) un codice random, puoi fare in modo che quando C fa richiesta ad A, A faccia una richiesta a B (in background) B li rilascia un codice, a quel punto A consegna il codice ad C che lo allegher� alla richiesta per B, quindi B controller� se il codice allegato sia il codice consegnato ad A (nella richiesta in background), se � lo stesso (e magari controlla anche se � scaduto) accetta la richiesta.
    Nel primo caso non avresti bisogno di salvare nulla sui server (ovviamente condividono la chiave di codifica), in quanto A cripta le info che viaggiano con C, mentre B non deve far altro che decriptarle ed eventualmente controllarle (tipo confrontare l'IP crittografato con quello passato dal client), mentre nel secondo caso B dovr� conservare i dati inviati in precedenza ad A e consegnati da C in modo da trovare l'eventuale correttezza. Ovviamente in tutto questo C non potr� manipolare la richiesta in quanto o non conosce il codice dato da A a B, oppure non conosce la chiave di crittografia usata per criptare le info seppure le conosce (sa il suo ip ad esempio).
    Poi da qui puoi fare tutta una serie di cose per migliorare la sicurezza, tipo far scambiare un codice monouso e crittografarlo (in pratica entrambe le soluzioni sopra descritte), oppure stabilire un codice giornaliero scambiato tra A e B e crittografarlo ecc.

    In tutto questo c'è una possibile falla, ovvero se in qualche modo si arriva al config (vedi generare errori, cattiva configurazione, amministratore del server che ha accesso al config ecc.) si leggerà la chiave di codifica, quindi a quel punto le info se le può creare da solo il client, ergo non ci sarebbe garanzia che C provenga da B, ecco perché in quel caso sarebbe utile avere anche il codice random generato da B e consegnato ad A. A quel punto anche conoscendo la chiave di crittografia, C non conoscerebbe il codice random.
    Ovviamente non è l'unico pericolo...
    Ultima modifica di U235; 06-09-2022 a 15:18

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 © 2025 vBulletin Solutions, Inc. All rights reserved.