Convalida se l'URL (messaggio) proviene da una fonte attendibile

Naviga le tue risposte
1

Stiamo lavorando su una pagina di reindirizzamento per le nostre app mobili.

Gli utenti andrebbero a una pagina come: 

https://mobileredirect.our-app.com?target=https://clientdomain.com/some_resource

Le app mobili su iOS e Adroid possono intercettare il dominio "mobileredirect.our-app.com", se installato. Se non installato, il browser si aprirà e reindirizzerà il browser al dominio client.

Questo contiene un problema ovvio. Chiunque può mettere qualsiasi dominio nello schema e questo diventa un vettore di attacco. Mi piacerebbe essere in grado di verificare se l'URL proviene effettivamente da una fonte attendibile. Dobbiamo farlo in questo modo, poiché non controlliamo quali domini potrebbero utilizzare la nostra app mobile.

Idealmente mi piacerebbe farlo nel browser, senza bisogno di un server.

Stavo pensando di usare una libreria come simple-crypt , usando l'operazione Asymmetric. I server attendibili avrebbero la chiave privata, avrebbero crittografato l'URL e finirebbe così: 

https://mobileredirect.our-app.com?target=ENCRYPTED_URL.

I client (app mobili e il sito Web) conterranno la chiave pubblica per decrittografare l'URL. Ciò significa che la chiave pubblica sarà visibile a tutti.

Ora la mia domanda: è una buona idea? Come può essere rotto? È eccessivo? Ci sono modi più semplici (ad esempio utilizzare un tipo di algoritmo di checksum)?

Questo è un ripubblicazione da Stack Overflow .

    
posta Bert Goethals 04.07.2017 - 10:04
fonte

2 risposte

1

È positivo che tu voglia mantenere privata la chiave privata e consegnarla solo a server fidati, non ai client stessi.

Mentre proponi uno schema che (probabilmente) sarà (ragionevolmente) sicuro, ho un approccio leggermente diverso da considerare quale è meno un abuso di crittografia asimmetrica e consente una migliore trasparenza su ciò che sta accadendo all'utente ricevendo uno di questi link:

Se aggiungi un elemento path all'URL che contiene l'hash firmato dell'URL per inviare l'utente, in questo modo: 

http://a.tgt/?target=sign(privKey, h(https://b.tgt/bla))|https://b.tgt/bla

dove sign() firma un messaggio con una chiave privata e h() hash una stringa, hai

  • una migliore possibilità di rilevare manomissioni,
  • autenticazione solida e
  • non nascondere l'attuale bersaglio in avanti dall'utente.

Mediante la concatenazione della firma e dell'URL di destinazione come indicato nei commenti, si riduce la possibilità che il payload venga elaborato senza elaborare anche la firma.

Tieni presente che la crittografia con la chiave privata viene solitamente definita firma :)

    
risposta data 03.11.2017 - 12:55
fonte
0

Sembra che tu abbia affrontato il semplice Open Redirect, non posso indicarti l'implementazione stessa, ma sembra che tu stia cercando Content Security Policy (CSP) , l'implementazione dipende dalla piattaforma che stai utilizzando. In poche parole questa tecnologia consente (o meno) risorse utilizzate dall'applicazione.

Dal punto di vista del tester di penetrazione è un mal di testa mentre si affronta con CSP. Inoltre, dovresti cercare consigli di base per il tuo caso qui OWASP Reindirizza e inoltra i trucchi foglio

di OWASP non convalidato     
risposta data 06.07.2017 - 11:59
fonte

Leggi altre domande sui tag

Ricerca di revisioni per l'autenticazione e l'approccio di crittografia dei messaggi certificato autofirmato per cifrario AES128-GCM-SHA256