urlReferrer

[supermac]

Carissimi (come esordiva l'apostolo)
mi trovo nella seguente situazione: su un sito terzo, in hosting su un server esterno, ho un bottone che manda alla pagina di login sul mio server inviando dei parametri in post.

Vorrei fare in modo che alla mia pagina di login arrivassero richieste solo ed esclusivamente da quel dominio terzo.

Per un certo periodo sono riuscito a fare questa cosa controllando (nel codebehind della mia pagina) che la proprietà Host dell'URI restituito da Request.UrlReferrer contenesse un determinato dominio
BUT
da qualche giorno a questa parte, per motivi che ignoro ma che suppongo siano legati a router/firewall/proxy/centrifughe che non trasmettono più l'informazione, il Request.UrlReferrer ha smesso di restituirmi qualcosa e mi ritorna sempre nothing perciò non riesco più a controllare un tubo.

C'è modo di verificare serverside sulla mia pagina da chi arrivano le richieste in post?

[U235]

Figliolo (come esordiva il capo dell'apostolo ) il discorso è un po' piu' complesso di quel che sembra inizialmente. Il referer viene trasmesso dal client che può riempirlo con dati arbitrari, per cui non hai mai avuto una certezza in tal senso, sarebbe bastato che qualcuno mandasse i dati che ti aspetti nel referer per bypassare tale controllo.
Alla luce di questo verrebbe da pensare che ti possa bastare applicare le regole CORS per permette ad un solo dominio di accedere a tali dati, il problema che CORS non è molto diverso dal referer, in quanto è una limitazione lato client, infatti è il browser che in base alle regole CORS date dal server inibisce a se stesso la chiamata. Per cui come puoi ben immaginare è sufficiente non usare un browser per accedere lo stesso ai dati "protetti" da CORS.
Ora ti rimane la soluzione più ovvia e più sicura, ovvero usare la crittografia a chiave simmetrica, che nonostante soffra del problema di stoccaggio della chiave stessa*, ti da una certa sicurezza. Oppure potresti creare un token monouso a scadenza ed inviarlo insieme alla richiesta, ovviamente il server che riceve la richiesta dovrà effettuare una richiesta in background al primo server per poter confrontare il token, nel caso ci sia corrispondenza allora concede i dati, diversamente rifiuta la richiesta.

P.S.
Ovviamente il discorso della crittografia lo puoi fare solo se hai possibilità o di metter mano ad entrambe i server, o comunque fare in modo che il server che ti manda dei dati post includa un qualche dato (tipo token) nelle richieste che ti manda e che siano o crittografate o con chiave monouso (possibilmente sempre crittografata).
Qualsiasi altro "metodo" che preveda la possibilità che il client mandi (quindi possa manipolare) la richiesta non è sicura. Tralasciando la sicurezza potresti comunque sempre controllare l'IP di provenienza (anche questo manipolabile dal client)

*la chiave crittografica non è sicura se ovviamente è salvata "male", ovvero accessibile a terzi magari tramite file system sul server, leggasi che l'amministratore potrebbe leggere la chiave se non salvata in sicurezza)

[supermac]

In verità, in verità ti dico che avrei già una chiave crittografica condivisa tra i due server, di partenza e di arrivo, stoccata nel web.config delle mie pagine (che uso per decrittare un codice ricevuto dal server di partenza che identifica l'utente)...
ma come dovrei fare "l'handshaking" -so che il termine è inappropriato ma intendo la verifica iniziale- per vedere se il chiamante è proprio l'amicomìo o è un sedicente?

[U235]

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...

[U235]

Comunque mi rimane il dubbio che mi stia chiedendo altro visto che nel post precedente mi dici che già fai una cosa del genere (già identifichi l'utente)

[supermac]

Si il primo server A invia già al mio server B le credenziali criptate del cliente A (che poi io verifico etc etc)
Però in questo momento chiunque potrebbe inviare a B delle credenziali criptate, e invece io vorrei che B potesse dire "sorry guys io accetto solo richieste che arrivano da A" e rifiutasse quindi tutte le altre richieste.
Mi sarebbe sufficiente sapere che le richieste provengono da un dominio (non vorrei filtrare sugli IP del richiedente ammesso che sia possibile farlo).

PS. che io sappia non c'è modo di arrivare al webconfig.... sbaglio?

[U235]

Mi sa che stai confondendo la crittografia a chiave simmetrica con quella a chiave asimmetrica.
Nella crittografia a chiave simmetrica le due parti sono a conoscenza entrambi della chiave di crittografia, ma la conoscono solo loro, criptano e decriptano entrambi con la stessa, per cui chi non la conosce (la chiave ovviamente) pu� anche inviare dati con una chiave "inventata", ma dall'altra parte se si prova a decriptare con la propria chiave il messaggio non sarebbe leggibile. Per capirci: se io decido che ti devo inviare il mio IP (per esempio) o un messaggio prestabilito e lo cripto con una chiave inventata (sono un furbetto che vuole fregarti) poi tu decripti il messaggio con la chiave "giusta" (la tua che � diversa da quella inventata) il messaggio o l'IP non saranno corretti, ergo non � una persona autorizzata a mandarmi messaggi, diversamente sarebbe in possesso della chiave corretta.
Diverso � il caso della crittografia asimmetrica, come ad esempio ssl. In questo tipo di crittografia esistono due chiavi, una � quella pubblica che tutti possono utilizzare, ma una volta criptato il messaggio non lo si pu� decriptare con la stessa, � necessario avere la chiave privata, per cui anche chi ha criptato il messaggio con chiave pubblica (che tutti conoscono) non sar� in grado di decriptarla senza la chiave privata. Questo meccanismo � necessario per avviare uno scambio di chiave simmetrica che dopo sar� nota solo ai due interlocutori. Per capirci: ti mando la mia chiave simmetrica criptandola con la chiave pubblica, a quel punto solo chi ha la chiave privata pu� decriptare il messaggio con la tua chiave simmetrica, per cui una volta decriptato il messaggio contenente la tua chiave simmetrica posso iniziare uno scambio sicuro con te utilizzando entrambi una chiave simmetrica condivisa.
Nel tuo caso non � necessario fare uno scambio di chiavi con crittografia asimmetrica, in quanto tu sai a priori chi sono i due interlocutori, per cui metti a conoscenza le due parti della chiave che dovranno utilizzare e loro useranno solo quella. Ecco perch� � fondamentale che rimanga segreta, se no chiunque pu� inviarti messaggi. E no... non � sicuro il config come luogo per mantenere la chiave di crittografia, in quanto hanno sicuramente accesso terze parti, come ad esempio chiunque abbia accesso al file system che ha facolt� di leggerla (ad esempio l'amministratore di sistema), in genere si usa DPAPI sia per proteggere la chiave nella memoria della macchina (ProtectedMemory), sia per proteggerla su disco (ProtectedData).
Poi certo, puoi anche metterla nel config, ma devi essere consapevole dei rischi e valutare il livello di sicurezza che desideri.

[U235]

Nella mia immaginazione credo di essere stato abbastanza chiaro nel post precedente, ma preferisco specificare meglio:
A e B (i due server) condividono una chiave simmetrica, quindi posso scambiarsi i messaggi che tutti gli altri non possono leggere, quindi diciamo che stabiliscono per convenzione che quando C fa una richiesta ad A, A rileva il suo IP e lo cripta con la chiave simmetrica (sarebbe molto meglio se fa una richiesta di codice random monouso a B oppure si inventa un codice e poi B fa la richiesta di questo codice ad A, per evitare di risalire alla chiave partendo dal risultato), il messaggio criptato a questo punto viene consegnato a C, quindi se C inoltra la richiesta direttamente a B senza passare per A non possiede questo messaggio criptato, o a limite pu� provare a indovinarlo (praticamente impossibile), ma essendo due chiavi diverse quando A lo decripta non viene fuori l'ip (o comunque il codice monouso), il che significa che la chiave di codifica � sbagliata, ergo se l'� inventata o sta tentando di riutilizzare una vecchia richiesta, in ogni caso non quadra, quindi non � passato per A. Se invece riesci a leggere l'informazione in maniera corretta (ad esempio l'IP, ma lo sconsiglio perch� il furbetto potrebbe anche intuire che si tratta sempre del IP e tentare di ricavare la chiave analizzando il messaggio e sapendo che quel messaggio si tratta del suo IP), allora � certo che chi ha criptato il messaggio era in possesso della chiave (A) e quindi se C � in possesso di questo messaggio criptato (corretto) senza sapere la chiave vuol dire che glielo ha consegnato per forza A.