Calcoliamo l'indirizzo esatto di qualsiasi utente tramite numero di telefono o indirizzo e-mail
Con l'aiuto di queste istruzioni, puoi facilmente calcolare l'indirizzo esatto (via, numero civico, numero di appartamento) di qualsiasi persona che utilizza i servizi del provider Internet InterZet (o DomRU).
Il problema è stato osservato solo nell'applicazione, il sito ha funzionato (e funziona) perfettamente - lasciami andare completamente. Il messaggio di errore non è molto informativo. Che cosa è andato storto?
Proviamo ad autenticarci per ricevere la richiesta del client e la risposta del server.
A giudicare dalla risposta, viene passato un timestamp non valido:
Andiamo a vedere la richiesta:
Il campo "timestamp $ c" contiene l'ora in cui è stata inviata la richiesta. Non capisco perché fidarsi del cliente in queste cose?
Una richiesta valida ha questo aspetto:
Calcolato per numero di telefono o indirizzo e-mail
Analizzando il traffico dell'applicazione in fase di autenticazione, mi sono imbattuto in un difetto molto interessante nel sistema. Comportamento non corretto della funzione "recupera password". Dà informazioni molto interessanti.
La richiesta si presenta così:
Siamo interessati al parametro " param_values_arr $ c ".
Vediamo l'indirizzo esatto del nostro appartamento, capiamo che questo è un fiasco e sorridiamo e salutiamo anche noi!
PS : tutto funziona correttamente sul sito, a quanto pare, l'indirizzo è chiuso con asterischi :)
A proposito, a giudicare dagli errori generati dal server in assenza di un utente nel database, la modalità debug è abilitata sul server. Non capisco perchè?
Sospetto che ogni città abbia il proprio database e URL. Di seguito è riportato un esempio per la città di San Pietroburgo.
Richiesta semplice tramite cURL:
AGGIORNAMENTO: Il problema è stato risolto, ora l'indirizzo è coperto da asterischi.
Tutte le informazioni sono fornite solo a scopo informativo. Non sono responsabile per eventuali danni o danni causati dai materiali in questo articolo.
sfondo
L'8 dicembre 2017 è stata rilasciata una nuova versione dell'app iOS. Il design è stato aggiornato al suo interno, i difetti minori sono stati corretti, ecc. eccetera. Dopo aver scaricato l'applicazione sul mio telefono, ho riscontrato un problema: non è stato possibile superare la procedura di autenticazione. Ho provato a inserire il numero del contratto, il numero di telefono e l'e-mail nel campo di accesso - niente ha aiutato, tutti i tentativi sono falliti.Analisi del traffico delle applicazioni
Per stabilire perché il nostro paziente non vuole vivere, utilizzeremo il programma mitmproxy. Ci permetterà di vedere la comunicazione tra l'applicazione e il server.Proviamo ad autenticarci per ricevere la richiesta del client e la risposta del server.
A giudicare dalla risposta, viene passato un timestamp non valido:
Soluzione al problema
Gli sviluppatori non hanno tenuto conto del fatto che le persone utilizzano formati temporali diversi; timestamp viene generato in modo errato se è impostato il formato a 12 ore (come nel mio caso), quindi la richiesta non può essere verificata sul server. Cambiamo il formato di visualizzazione dell'ora nelle impostazioni del telefono su 24 ore e superiamo con successo l'autenticazione. L'unica differenza tra le richieste è che non c'è AM / PM nel timestamp nel formato 24 ore.Una richiesta valida ha questo aspetto:
Analizzando il traffico dell'applicazione in fase di autenticazione, mi sono imbattuto in un difetto molto interessante nel sistema. Comportamento non corretto della funzione "recupera password". Dà informazioni molto interessanti.
La richiesta si presenta così:
- Se trasferisci il numero dell'accordo dell'utente dei servizi Interzet / DomRU in esso, riceveremo i dati di contatto collegati all'accordo: numero di telefono, indirizzo e-mail.
- Se gli passiamo un numero di telefono o un indirizzo e-mail, nella risposta vedremo l'indirizzo esatto dell'utente.
PS : tutto funziona correttamente sul sito, a quanto pare, l'indirizzo è chiuso con asterischi :)
A proposito, a giudicare dagli errori generati dal server in assenza di un utente nel database, la modalità debug è abilitata sul server. Non capisco perchè?
<debug>
<![CDATA[debug$n=24: exception: ORA-20001: debug=2 backtrace: ORA-06512: at "EXCELLENT3.WEBCAB_XML_PROC", line 6264 ORA-06512: at line 1 ORA-06512: at "EXCELLENT3.WEB_CABINET", line 1064 ]]>
</debug>
Sospetto che ogni città abbia il proprio database e URL. Di seguito è riportato un esempio per la città di San Pietroburgo.
Richiesta semplice tramite cURL:
curl "https://spb.db.ertelecom.ru/cgi-bin/ppo/es_webface/web_cabinet.get_info\
?param_names_arr%24c=client_contact\
¶m_values_arr%24c=habr@example.com\
¶ms=get_agr_list_contact_xml"AGGIORNAMENTO: Il problema è stato risolto, ora l'indirizzo è coperto da asterischi.
Tutte le informazioni sono fornite solo a scopo informativo. Non sono responsabile per eventuali danni o danni causati dai materiali in questo articolo.
