Un alias di dominio fornisce protezione contro gli hacker?

2

Abbiamo un'app che funziona con un'API privata. Abbiamo un server che ospita l'API, oltre a un pannello di amministrazione in cui il personale può accedere e apportare modifiche al contenuto dell'app. L'API e il pannello di amministrazione vengono eseguiti sullo stesso dominio web. Supponiamo che il dominio sia appname.com e che gli URL siano appname.com/api e appname.com/admin

In origine, non c'erano pagine Web pubbliche sul server o sul dominio. Tuttavia, abbiamo aggiunto una pagina di reimpostazione della password a appname.com/resetpassword in modo che gli utenti di app che hanno dimenticato la password possano richiedere un'email di reimpostazione della password.

Subito dopo aver aggiunto la pagina di reimpostazione della password, il responsabile del progetto (che non è una persona tecnica) si è preoccupato che l'inserimento della pagina di reimpostazione della password nello stesso dominio dell'API e del sito di amministrazione potesse esporre il server agli hacker, che potrebbero altrimenti non essere a conoscenza del dominio poiché non ha altre pagine pubbliche. Hanno chiesto di inserire la pagina di reimpostazione della password su un dominio diverso in modo che gli hacker non sapessero come trovare il dominio principale.

Questa logica non ha senso per me, per diversi motivi:

  1. Non ho mai visto nessun altro fare qualcosa di simile a questo, anche se è difficile pensare a paralleli diretti
  2. Il nome di dominio del back-end non è difficile da indovinare anche quando non ci sono pagine pubbliche sul sito
  3. Se aggiungiamo un sito Web pubblico in futuro, verrebbe trovato logicamente nello stesso dominio, a quel punto il dominio non sarebbe più un segreto comunque
  4. Qualsiasi hacker abbastanza sofisticato da superare le misure di sicurezza sul server potrebbe facilmente trovare l'URL dell'API, e quindi il dominio del sito, seguendo i pacchetti inviati dall'app.

Tuttavia, il responsabile del progetto è fermamente convinto che la pagina di reimpostazione della password non può essere nel dominio principale. Ciò che mi colpisce è che la soluzione più semplice è impostare un alias di dominio, qualcosa come appname-passwordreset.com , che punta direttamente ed esclusivamente alla pagina di reimpostazione della password. Tuttavia, ci acquisterà qualcosa? appname.com e appname-passwordreset.com avrebbero lo stesso indirizzo IP. L'utilizzo di quest'ultimo alias avrebbe realisticamente impedito a un hacker di trovare o irrompere nel server?

Nota: mi rendo conto che un'alternativa è lasciare che l'utente richieda la reimpostazione della password dall'app. Tuttavia, l'e-mail di reimpostazione della password deve avere un link a una pagina web, riportandoci così al problema originale

    
posta Kevin 18.01.2018 - 00:04
fonte

2 risposte

3

È assolutamente banale per un utente malintenzionato (o ricercatore di sicurezza o hacker) scoprire quale sia il nome host per le richieste che vanno all'API per la tua app. Esistono diverse tecniche che possono essere utilizzate per capirlo.

  1. Decompila l'applicazione e cerca il nome host nell'origine. Forse offuschi l'app e tutte le stringhe?
  2. MITM il traffico tra il loro dispositivo e la tua API e guarda le richieste. Ma forse fai TLS con il pinning del certificato?
  3. Annota passivamente il traffico e osserva il valore SNI in ClientHello . Ok, potresti configurare la libreria SSL per non usare SNI.
  4. Il nome host è nel certificato che viene restituito in chiaro. Ma immagino che potresti falsificarlo se stai facendo la tua verifica del nome host.
  5. Annota passivamente il traffico DNS quando l'app inizia a stabilire una connessione.

A questo punto, potresti diventare sciocco e usare IP hardcoded, o DNSCrypt o altre tecniche, ma l'utente malintenzionato può anche utilizzare un dispositivo rooted e scaricare la memoria della tua applicazione, o solo capire i nomi degli host da IP in base al traffico che stai inviando.

Se nascondere il tuo nome host è la differenza tra essere compromessi e non, hai già perso e semplicemente non lo sai. Pensare che nascondere l'hostname sia utile è solo cullare la testa del tuo progetto in un falso senso di sicurezza.

    
risposta data 18.01.2018 - 01:32
fonte
0

Il punto della tua testa non ha molto senso per me. Basta spiegargli che, dal momento che la tua app funziona su un'API, il suo server è stato esposto anche quando non c'erano pagine pubbliche su di esso. Qualsiasi utente malintenzionato avrebbe potuto eseguire un attacco MITM per vedere da dove l'app richiede i dati, quindi il server sarebbe stato comunque esposto. Non è tanto un affare per un utente malintenzionato scoprire dove si trova l'API, sia che si tratti di una pagina pubblica nel server o nell'app. Se un hacker vuole invertire il motore, capire che l'uscita dell'API è quasi banale con gli strumenti appropriati (vedi mitmproxy ). Piuttosto che concentrare la sicurezza sul tentativo di nascondere il tuo hostname, che è una perdita di tempo, sarebbe molto meglio progettare un'API sicura che possa essere utilizzata solo con un'autenticazione corretta (es. OAuth )

    
risposta data 18.01.2018 - 02:30
fonte

Leggi altre domande sui tag