- Регистрация
- 24.11.2016
- Сообщения
- 704
- Репутация
С помощью этой инструкции вы сможете без труда вычислить точный адрес (улица, номер дома, номер квартиры) любого человека, который пользуется услугами интернет-провайдера InterZet (или DomRU).
Предыстория
8-го декабря 2017-го года была выпущена новая версия приложения для iOS. В ней обновили дизайн, поправили мелкие недоработки и т.д. и т.п. Скачав приложение на телефон, я столкнулся с проблемой: не получалось пройти процедуру аутентификации. Пытался вводить в поле логина и номер договора, и номер телефона, и почту – ничего не помогало, все попытки оканчивались фиаско.
Проблема наблюдалась только в приложении, сайт же работал (да и работает) безупречно – пускает меня полностью. Сообщение об ошибке не очень-то и информативно. Что же пошло не так?
Анализ трафика приложения
Для того, чтобы установить, почему же наш пациент не хочет жить, воспользуемся программой mitmproxy. Она позволит нам посмотреть коммуникацию между приложением и сервером.
Попробуем аутентифицироваться, чтобы получить запрос клиента и ответ сервера.
Судя по ответу, передается невалидный timestamp:
Взглянем на запрос:
В поле «timestamp$c» передаётся время отправления запроса. Не понимаю, зачем доверять клиенту в таких вопросах?
Решение проблемы
Разработчики не учли то, что люди используют разные форматы времени; timestamp формируется неправильно, если стоит 12-и часовой формат (как в моём случае), поэтому запрос не может пройти проверку на сервере. Меняем формат отображения времени в настройках телефона на 24-х часовой и успешно проходим аутентификацию. Отличие запросов лишь в том, что в 24-х часовом формате в timestamp нет AM/PM.
Корректный запрос выглядит так:
Вычисляем пользователя по номеру телефона или адресу электронной почты:
Во время анализа трафика приложения на этапе аутентификации, я наткнулся на одну весьма интересную недоработку системы. Некорректное поведение функции «восстановить пароль». Она отдаёт очень интересную информацию.
Запрос выглядит следующим образом:
Нас интересует параметр "param_values_arr$c".
Видим точный адрес своей квартиры, понимаем, что это фиаско, а так же улыбаемся и машем!
P.S: на сайте всё работает корректно, вроде бы, адрес звездочками закрывают :)
К слову, судя по ошибкам, которые выдаёт сервер в случае отсутствия пользователя в базе, на сервере включен режим отладки. Не понимаю, зачем?
Как повторить?
У каждого города, я подозреваю, своя БД и URL. Ниже приведен пример для города Санкт-Петербург.
Простой запрос через cURL:
Меняем habr@example.com на необходимый номер телефона или адрес электронной почты.
Вся информация предоставлена исключительно в ознакомительных целях. Я не несу ответственность за любой возможный вред или ущерб, причиненный материалами данной статьи.
Оригинал:
Предыстория
8-го декабря 2017-го года была выпущена новая версия приложения для iOS. В ней обновили дизайн, поправили мелкие недоработки и т.д. и т.п. Скачав приложение на телефон, я столкнулся с проблемой: не получалось пройти процедуру аутентификации. Пытался вводить в поле логина и номер договора, и номер телефона, и почту – ничего не помогало, все попытки оканчивались фиаско.
Проблема наблюдалась только в приложении, сайт же работал (да и работает) безупречно – пускает меня полностью. Сообщение об ошибке не очень-то и информативно. Что же пошло не так?
Анализ трафика приложения
Для того, чтобы установить, почему же наш пациент не хочет жить, воспользуемся программой mitmproxy. Она позволит нам посмотреть коммуникацию между приложением и сервером.
Попробуем аутентифицироваться, чтобы получить запрос клиента и ответ сервера.
Судя по ответу, передается невалидный timestamp:
Взглянем на запрос:
В поле «timestamp$c» передаётся время отправления запроса. Не понимаю, зачем доверять клиенту в таких вопросах?
Решение проблемы
Разработчики не учли то, что люди используют разные форматы времени; timestamp формируется неправильно, если стоит 12-и часовой формат (как в моём случае), поэтому запрос не может пройти проверку на сервере. Меняем формат отображения времени в настройках телефона на 24-х часовой и успешно проходим аутентификацию. Отличие запросов лишь в том, что в 24-х часовом формате в timestamp нет AM/PM.
Корректный запрос выглядит так:
Вычисляем пользователя по номеру телефона или адресу электронной почты:
Во время анализа трафика приложения на этапе аутентификации, я наткнулся на одну весьма интересную недоработку системы. Некорректное поведение функции «восстановить пароль». Она отдаёт очень интересную информацию.
Запрос выглядит следующим образом:
Нас интересует параметр "param_values_arr$c".
- Если в нём передать номер договора пользователя услуг Interzet/DomRU, то мы получим привязанные к договору контактные данные: номер телефона, адрес электронной почты.
- Если передать в нём номер телефона или адрес электронной почты, то в ответе мы увидим точный адрес пользователя.
Видим точный адрес своей квартиры, понимаем, что это фиаско, а так же улыбаемся и машем!
P.S: на сайте всё работает корректно, вроде бы, адрес звездочками закрывают :)
К слову, судя по ошибкам, которые выдаёт сервер в случае отсутствия пользователя в базе, на сервере включен режим отладки. Не понимаю, зачем?
Код:
<![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 ]]>Как повторить?
У каждого города, я подозреваю, своя БД и URL. Ниже приведен пример для города Санкт-Петербург.
Простой запрос через 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"Меняем habr@example.com на необходимый номер телефона или адрес электронной почты.
Вся информация предоставлена исключительно в ознакомительных целях. Я не несу ответственность за любой возможный вред или ущерб, причиненный материалами данной статьи.
Оригинал:
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Последнее редактирование:
