Комментарии 300
Оставайтесь на месте. За вами уже выехали ;-)
Он скорее всего в курсе, маршрут-то показывается.
У автора данного поста возможно развитие таксистофобии, каждый таксист подъезжающий к его дому теперь вызывает опасения
Судя по ответу ситимобил, что не показывается маршрут такси с пассажирами, можно отследить момент ухода конкретной машины в «тень» и появление снова в новой точке. Это как минимум будет означать точку старта и финиша.
Вывод — если машина\машины регулярно забирает увозит по определенным точкам, значит можно вычислить и время отсутствия человека. Что так же является относительно важной информацией из серии персональных данных.
Вывод — если машина\машины регулярно забирает увозит по определенным точкам, значит можно вычислить и время отсутствия человека. Что так же является относительно важной информацией из серии персональных данных.
Что не мешает каршерингам в Европе делать так же и не страдать от раскрытия персональных данных.
Если машина в одном месте пропадает, а в другом появляется, то это ли не "Таксипортация"?
А ещё можно посчитать статистику ожидание/работа у водителей, и примерно оценить пробег машин в ожидании и пробег в работе (это можно по первому попавшемуся маршруту от точки старта до точки финиша, выдаваемому любыми навигаторами).
Всегда было любопытно узнать такие цифры
Всегда было любопытно узнать такие цифры
Но, в теории, при параметре «radius»: 5 может получиться существенно меньше 10 водителей? И вообще, может оказаться такое хитрое распределение машин, что в какой-то момент поиск оборвется — в радиусе 5 (км?) от каждого предыдущего водителя не будет найдено ни одного нового, но какие-то машины не попадут в массив?
Как делали визуализацию по координатам?
Крутая дыра, интересно, через сколько исправят.
Думаю, что Zaraza уже получил волшебный пендаль за то, что закрыл репорт без разбора.
забавно то что это судя по всему может быть очень непросто
Вообще я даже не знаю, можно ли это закрыть, и, если закрыть, изменит ли это хоть что-то. По примеру вк у них токены, скорее всего, живущие вечно. То есть если они сделают этот метод доступным только авторизованным пользователям, никто не мешает этим авторизованным пользователям взять токен и шуровать запросы.
Разве что можно сделать какой-то фильтр запросов (типа если с одного пользователя спрашиваются координаты водителей в 100 разных местах — это несколько странно).
Разве что можно сделать какой-то фильтр запросов (типа если с одного пользователя спрашиваются координаты водителей в 100 разных местах — это несколько странно).
Ну, остальные же забанили подобные запросы (например, попробуйте закинуть в гугль больше чем положено запросов геокодирования — вас забанят по IP, или по вашему ID, потому что у авторизованных пользователей тоже есть лимиты, или они платят деньги за запрос)? Почему это у данной компании может не получиться? Не факт что просто — но должно быть вполне решаемо.
А еще проще — вообще не банить, а просто вводить задержку. И на этом тысяча запросов в цикле становится невыгодной.
А еще проще — вообще не банить, а просто вводить задержку. И на этом тысяча запросов в цикле становится невыгодной.
Ну я и говорю: «если с одного пользователя спрашиваются координаты водителей в 100 разных местах — это несколько странно».
Другое дело, что я, например, не знаю, как с этим разобрались, например, в Яндексе, а разбираться сейчас у меня времени нет (предложение автору статьи).
Пример с гуглом чутка неправильный — там геокодирование является частью сервисов, которые можно купить и использовать. А тут с ситимобилом несколько другая ситуация: они же не продают данные о передвижении своих водителей. Поэтому «платят деньги за запрос» — стратегия, которая к ситимобилу не применима.
Мне лично кажется, что флудконтроль бы всех спас. Не выписывать перманентный бан, просто после, скажем, 20 странных запросов блокать на часок.
Другое дело, что я, например, не знаю, как с этим разобрались, например, в Яндексе, а разбираться сейчас у меня времени нет (предложение автору статьи).
Пример с гуглом чутка неправильный — там геокодирование является частью сервисов, которые можно купить и использовать. А тут с ситимобилом несколько другая ситуация: они же не продают данные о передвижении своих водителей. Поэтому «платят деньги за запрос» — стратегия, которая к ситимобилу не применима.
Мне лично кажется, что флудконтроль бы всех спас. Не выписывать перманентный бан, просто после, скажем, 20 странных запросов блокать на часок.
Можно хешировать запрос с солью, которая вшита в приложение и в бекенд, и добавить привязку ко времени, скажем 30 секунд — и пользоваться этой дырой станет значительно сложнее
Ну и SSL pinning не помешал бы. Для усложнения изначального mitm.
Исправлять уязвимость не будем, но сделаем так, чтобы найти ее заняло больше времени :-) Сделаем программу баг-баунти, но сделаем так, чтоб ей было сложнее пользоваться, кабуто у нас нет багов. Ограничим шкалу градусника отметкой 36.6.
При таком подходе как раз хакер-фанат, который делает это для фана и может поделиться информацией — не сможет нарыть дырку и сообщить о ней. Зато конкурент Яндекс, для которого подобная дыра может быть очень выгодный — поручит похачить код приложения в телефоне тому, кому эта задача близка, понятна и проста, и через час (или день, или месяц) SSL pinning в клиенте будет отключен. Это ж клиенская фишка, нельзя безопасность сгружать на клиента.
При таком подходе как раз хакер-фанат, который делает это для фана и может поделиться информацией — не сможет нарыть дырку и сообщить о ней. Зато конкурент Яндекс, для которого подобная дыра может быть очень выгодный — поручит похачить код приложения в телефоне тому, кому эта задача близка, понятна и проста, и через час (или день, или месяц) SSL pinning в клиенте будет отключен. Это ж клиенская фишка, нельзя безопасность сгружать на клиента.
Даже не хакер фанат, а скорее школьник.
Обычный телефон с root-ом (а есть ведь еще эмуляторы) и XPosed уже позволяет снимать sslpin без хаков в самом приложении.
Если приложение обфусцированное — немного сложнее, но через тот-же XPosed можно и это обойти.
Обычный телефон с root-ом (а есть ведь еще эмуляторы) и XPosed уже позволяет снимать sslpin без хаков в самом приложении.
Если приложение обфусцированное — немного сложнее, но через тот-же XPosed можно и это обойти.
Ну это вам легко. Мне, например, сложнее. Вот просниффать трафик (что ТС делал), подать левый сертификат — это то что я умею легко и быстро, что я тысячу раз делал, и если б я заинтересовался приложением сити-мобил я бы нашел этот же баг, как и ТС. Но вот снять SSL pinning, я бы не смог (смог бы если б заморочился, при должной мотивации, но так как мне не платят за это — просто бы зевнул и закрыл). В результате — такси бы не узнала о своем баге.
А вы, возможно, много раз это делали, вам это легко. Поэтому, любая серьезная атака со стороны конкурента или огранизованной группы, где люди — каждый со своей специализации, пройдут эту защиту довольно быстро.
Получается, что такой подход больше мешает тем, кто работает на пользу компании (добровольным аудиторам), чем защищает ее от реальных угроз.
А вы, возможно, много раз это делали, вам это легко. Поэтому, любая серьезная атака со стороны конкурента или огранизованной группы, где люди — каждый со своей специализации, пройдут эту защиту довольно быстро.
Получается, что такой подход больше мешает тем, кто работает на пользу компании (добровольным аудиторам), чем защищает ее от реальных угроз.
Особенно под конец года, у всех годовые и квартальные планы горят, баги фиксить некогда. Астрологи предсказывают увеличение говнокода в проде.
Видимо вопросы на собеседовании в «Ситимобил» на оценку асимптотической сложности алгоритма и ему подобные не помогают защищать свои http-концы.
Про оценку асимптотической сложности алгоритмов на собеседованиях спрашивают обычных разрабов, а про интеграцию компонентов между собой — техлидов и архитекторов. Только когда доходит до проектирования реальной системы, непосредственное участие принимают обычные разрабы, а техлиды (занятые переписками с менеджерами, согласованием трудозатрат и отпусков и другими важными вещами) визируют такие решения по интеграции, практически не глядя, просто потому что времени на нормальное ревью не остается.
Как же красиво всё здесь. От истории до подачи.
Респект
Респект
По данным вики на конец 2018 года в Москве зарегистрировано 100 000 водителей такси. То есть «ситимобил» занимает примерно 5% рынка?
Очевидно, что одновременно все они не работают.
~5000 это число активных таксистов в срезе времени. Я собирал данные примерно сутки. За это время было замечено порядка 10000 уникальных водителей. Думаю, если собирать данные достаточно долго, то можно будет понять, сколько водителей всего, когда они работают, какая у них средняя продолжительность смены и т.п.
какая у них средняя продолжительность смены
Вот об этом бы очень было интересно почитать. Насколько помогают все кнуты и пряники, и как много таксерит по 20 часов выпучив глаза.
По 20 часов он таксерит с трех разных аккаунтов.
В аккаунте разве номер машины не записан?
На одной машине могут ездить разные таксисты, легально. Часто просто работают в несколько смен.
В контексте темы статьи у нас нет доступа к гос. рег. знакам автомобиля. А если бы и были, то что плохого в том, что автомобиль работает 24/7? Аренда машины в Москве сжирает половину дохода таксиста, использовать ее в две смены — благое дело. Я не знаю как в сити, но вот в яндексе аккаунт таксиста блокируется при переработке и вы по id ее не найдете.
Отличная тема для следующей статьи!
Я бы заметил что процент водителей/машин (или, например, магазинов если абстрагироваться от перевозчиков) от общего числа это не доля рынка.
Ну и к тому же таксисты часто работают одновременно на несколько агрегаторов (у какого вылезет заказ пожирнее, у того и возьмет заказ). Видел «иконостасы» из 3-4 мобильников.
Ну и к тому же таксисты часто работают одновременно на несколько агрегаторов (у какого вылезет заказ пожирнее, у того и возьмет заказ). Видел «иконостасы» из 3-4 мобильников.
В статье упоминалось количество водителей онлайн в определённый момент времени. Вероятно, существенная часть зарегистрированных водителей такси проводит на линии очень мало времени. Так что, по всей видимости, Ситимобил занимает больше, чем 5% рынка
Куча водителей берут заказы из разных систем.
В довесок что озвучил автор. Подобная расхлябанность разработчиков позволяет не только отследить регулярные маршруты и время клиентов такси, но и показать отклонения во времени и маршруте лицам которые не должны это знать.
Кажется я начинаю понимать зачем Ситимобил спрашивает про все уровни osi.
Неважно, что спрашивают на собеседованиях, если по факту бизнес требует от разрабов "… уяк-… уяк, и в продакшен"
О, опять бизнес виноват. Нет, ну бизнес конечно виноват, но в каких-то других, глобальных проблемах: но неужели отслеживать частоту запроса с одного IP — это вот прям дико сложная задача, которая оттягивает все ресурсы от разработки и мешает выходу новой версии?
Это основа, блин.
Это при самом тупом моделировании системы на салфетке из кофейни нужно учитывать, прямой путь к ддосу.
Это говорит только о некомпетенции авторов сервера, но не о нехватке времени на правильную реализацию.
"Покатим в прод в виде MVP, а по нормальному сделаем потом (никогда)". Неработающие поля limit и radius как бы на это намекают.
У ситимобил полгода назад была существенно серьезная проблема с сценариями обработки действий пользователя. Там были тупиковые ветки, которые даже звонок в техподдержку не исправлял. Не говорю о том, что постоянно проблема с машинами. Ситимобил, до свидания! Вместо того, чтобы сделать технически конкурентоспособный продукт, вы решили тупо вбухать деньги в рекламу (транспорт, Ютуб, тв) и поэтому клиента в лице меня вы потеряли насовсем.
Настоящая статья — это яркая иллюстрация, что к этому аггрегатору ни в коем случае нельзя идти ни в коем качестве.
Скорее всего они перестали работать когда другие исследователи ухнули радиус в 1000 км и лимит в пару лямов.
Презумпция бритвы Хэнлона утверждает: «Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью».
Поэтому, если бы был нормально устоявшийся и регламентированный процесс разработки, в котором участвовал QA-инженер, то он бы обнаружил такие корнер-кейсы, и тогда разрабам пришлось либо лимитировать сверху входные параметры, либо вводить постраничный отбор.
А тут: что имеем, то и имеем.
Поэтому, если бы был нормально устоявшийся и регламентированный процесс разработки, в котором участвовал QA-инженер, то он бы обнаружил такие корнер-кейсы, и тогда разрабам пришлось либо лимитировать сверху входные параметры, либо вводить постраничный отбор.
А тут: что имеем, то и имеем.
Неработающие поля limit и radius как бы на это намекают.
В API инстаграма тоже полно неработающих полей и эндпойнтов.
Для активно развивающегося сервиса это обычное дело, все не предусмотришь.
Скорее всего было так:
— Вот, я запилил для демки фичу, но нужно будет еще защиту на нее навесить и вообще отладить так как не все параметры работают.
— Зачем это? У нас задача срочная новая горит, потом когда нибудь займешься.
— Вот, я запилил для демки фичу, но нужно будет еще защиту на нее навесить и вообще отладить так как не все параметры работают.
— Зачем это? У нас задача срочная новая горит, потом когда нибудь займешься.
Rate limit делается за 5 минут, и на это не нужно спрашивать разрешения у злого дяди менеджера, это в крови должно быть, руки сами проверку на количество запросов должны набивать.
А еще админы серверов вообще должны fail2ban настраивать во сне. Или облака так расслабили девопсов, что пущай кто угодно к нам стучится, на всех хватит!?
А точно ли по бизнес логике тут именно Rate limit нужен? Вполне возможно что нужна более сложная логика поскольку какие то сценарии где пользователь будет делать частые запросы окажутся валидными. Вы уверены что готовы решать за бизнес что ему нужно?
Не могу представить сценарий, когда пользователь будет опрашивать сервер с частотой более 60 раз за минуту.
Приведите, пожалуйста, пример, может я что-то упускаю?
Да запросто, не просто текущее положение показать, но и движение. Плавно и точно. Ну и как бы 60 раз в минуту для парсинга вполне достаточно, так что дыру не закроет.
Если по IP считать — то легко. Конец рабочего дня в большой конторе, масса народу вызывает такси с мобильников через рабочую вафлю с серым IP.
Не пользуюсь рабочей вайфлей, т.к. там Корп перехват данных. Не говоря уже о том, что
1. Использование Корп вафли в личных целях — атата
2. Зачастую лте работает тупо быстрее, чем Корп вафля
1. Использование Корп вафли в личных целях — атата
2. Зачастую лте работает тупо быстрее, чем Корп вафля
leaky bucket вполне справится с таким. Быстрый всплеск вызовов в 18:00 (все сотрудники госниичтототаммонтаж вызвали такси) и тут же быстрое их падение. А вот кто-то, кто с такой же частотой, но не один залп в сутки на 5 минут, а 24/7 будет слать запросы в систему — будет заблокирован.
Провайдерский NAT. Когда 30к пользователей ходят в интернетик через «пару» IP.
Не за 5 минут всё же. Просто fail2ban — это полдела. Ещё нужно добавить такой ответ в API, задокументировать, протестировать чтобы ограничения были разумными и не сказывались на обычных пользователях, выводить в интерфейсе приложения человекопонятное сообщение «вы слишком часто делаете запросы, отдохните чуток или воспользуйтесь Яндекс.Такси» и наверное я ещё не всё учёл. Довольно часто бывает когда кажется, что работы на 5 минут, а потом одно тянет другое, другое тянет третье, разработчик в пределах своей компетенции задачу полноценно решить не может, нужно подключать других сотрудников — и даже если разработчик добросовестно отрепортит, задача может застрять на уровне выше.
Ну и можно посмотреть предлагаемые варианты решения ниже по ветке, с авторизацией пользователя для запроса, проверке геокоординат пользователя и т.д. Явно не 5 минут времени.
Ну и можно посмотреть предлагаемые варианты решения ниже по ветке, с авторизацией пользователя для запроса, проверке геокоординат пользователя и т.д. Явно не 5 минут времени.
Ааа, классический зеноновский парадокс, где быстроногий Ахиллес никогда не догонит черепаху.
Уверен, как и в многих современных чудо-приложениях, 70 % ошибок на стороне пользователя обрабатываются на стороне пользователя как «Упс, что-то пошло не так, попробуйте через пару минут». Но даже это лучше сотен тысяч данных в открытом доступе.
Уверен, как и в многих современных чудо-приложениях, 70 % ошибок на стороне пользователя обрабатываются на стороне пользователя как «Упс, что-то пошло не так, попробуйте через пару минут». Но даже это лучше сотен тысяч данных в открытом доступе.
А зачем нужен лимит? С нагрузкой сервер пока справляется, а выкачать все данные можно и с лимитом.
Например, чтобы обеспечить качество предоставления услуги. Сэкономить деньги, в конце-концов
Давайте представим некий надуманный пример. Выкатили обновление. Клиент начал генерировать запросы на всю ширину канала клиента. Некоторые клиенты по лте, некоторые — по вайфай. Сами себя заддосили, получается. Был бы рейтлимит на стороне сервера — все было бы сильно лучше )
Т.е. рейтлимит это всего лишь один из инструментов и его можно применять, когда от него есть выгода
Давайте представим некий надуманный пример. Выкатили обновление. Клиент начал генерировать запросы на всю ширину канала клиента. Некоторые клиенты по лте, некоторые — по вайфай. Сами себя заддосили, получается. Был бы рейтлимит на стороне сервера — все было бы сильно лучше )
Т.е. рейтлимит это всего лишь один из инструментов и его можно применять, когда от него есть выгода
отслеживать частоту запроса с одного IP
поможет как лечение подорожником
rotating proxy которые будут отправлять каждый запрос с рандомного IP стоят $50/месяц плюс-минус, в зависимости от объемов траффика
С rotating proxy как раз можно бороться.
А лучше бы сказали о другой проблеме и ее решении.
Очевидно, что такси пользуются только физики. Это означает, что они выходят с вполне понятных пулов адресов, принадлежащих провайдерам. Их динамическим пулам. Не адресам Амазона, Гугла, хостинг-провайдеров и прочего. Единственное, что остаётся — это корпоративщики со своими автономными системами и внутренним вайфаем для сотрудников. Т.е. к чему это я — можно построить алгоритм определения человек ли к нам пришел или парсер и source ip использовать в качестве одного из критериев. Это раз.
Два. Всякие моб клиенты легко скрываются за 1 ip адресом, т.к. провайдер жадный и по сути можно не тратить адреса попусту. В этом случае рейтлимит (глупый рейтлимит, конечно) тупо сломает работу приложения у клиентов, сидящих, скажем, с одного опсоса
А лучше бы сказали о другой проблеме и ее решении.
Очевидно, что такси пользуются только физики. Это означает, что они выходят с вполне понятных пулов адресов, принадлежащих провайдерам. Их динамическим пулам. Не адресам Амазона, Гугла, хостинг-провайдеров и прочего. Единственное, что остаётся — это корпоративщики со своими автономными системами и внутренним вайфаем для сотрудников. Т.е. к чему это я — можно построить алгоритм определения человек ли к нам пришел или парсер и source ip использовать в качестве одного из критериев. Это раз.
Два. Всякие моб клиенты легко скрываются за 1 ip адресом, т.к. провайдер жадный и по сути можно не тратить адреса попусту. В этом случае рейтлимит (глупый рейтлимит, конечно) тупо сломает работу приложения у клиентов, сидящих, скажем, с одного опсоса
Надо вычислять клиентов по ip, чтобы за ними не следили посторонние? Да только как это делать, когда государство всеми силами загоняет их в VPN?
Извините, пожалуйста, совершенно не понял, что Вы хотели сказать. Можете развить свою мысль?
Что есть тенденция из-за наших новых законов и из-за блокировок гнать весь трафик через зарубежный впн. И такие блокировщики по AS доставляют боль. Иногда проще отказать от сервиса чем отключать ради него впн.
Если Вы выходите через VPN, то будьте готовы, что сервисы, которые определяют Ваше местоположение, скажем, по GeoIP — работать не будут. И вообще — я допускаю, что человеку честному нечего скрывать, поэтому он не будет ходить через VPN (на самом деле это не так) и поставщики услуг могут прямо в договоре присоединения к своей услугу писать, что обфускация настоящего IP запрещена.
Скрывать может и нечего (хотя есть чего всем), но доступ к заблокированным ресурсам часто нужен.
Думаю те, кто ходят готовы к этому. Вопрос в том, готов ли бизнес потерять клиента (а значит и деньги) из-за странной политики к пользователям впн.
Скрывать — нечего. А то что заблокировали доступ к совершенно легитимному (и возможно нужному для работы — были ведь случаи с блокировкой гитхаба) сайту.
Поставщику же услуг при наличии вопросов будет так так и сказано что Россия, цензура-которой-нет, вот и приходится так, личность подтвердить — ну давайте как то еще подтвердим. И проходит обычно (Речь НЕ про музыкально-фильмовые сервисы).
Российским же поставщикам(даже финансовых услуг) (опять же речь не про музыкально-фильмовые сервисы) обычно хватает либо просто звонка «вы тут недавно входили — это точно вы? а на контрольные вопросы ответить готовы?» либо прямо слов что используется VPN, да — оно надо, да — если дадите список адресов куда напрямую ходить — поставлю исключение.
А насчет договора — так где вы обфускацию увидели — X-Forwarded-For от прокси приходит с честным IP.
При если договора именно ЧИТАТЬ — иногда возникают вопросы какого черта провайдер сам не соблюдает (в договоре сказано что минимум Андроид 2.3 — в сторе 4., версию под iPad1 предоставить отказались хотя обязаны по договору)
Про ограничения доступа в том же договоре — сказано просто «территория Российской федерации» (про IP ни слова)
Поставщику же услуг при наличии вопросов будет так так и сказано что Россия, цензура-которой-нет, вот и приходится так, личность подтвердить — ну давайте как то еще подтвердим. И проходит обычно (Речь НЕ про музыкально-фильмовые сервисы).
Российским же поставщикам(даже финансовых услуг) (опять же речь не про музыкально-фильмовые сервисы) обычно хватает либо просто звонка «вы тут недавно входили — это точно вы? а на контрольные вопросы ответить готовы?» либо прямо слов что используется VPN, да — оно надо, да — если дадите список адресов куда напрямую ходить — поставлю исключение.
А насчет договора — так где вы обфускацию увидели — X-Forwarded-For от прокси приходит с честным IP.
При если договора именно ЧИТАТЬ — иногда возникают вопросы какого черта провайдер сам не соблюдает (в договоре сказано что минимум Андроид 2.3 — в сторе 4., версию под iPad1 предоставить отказались хотя обязаны по договору)
Про ограничения доступа в том же договоре — сказано просто «территория Российской федерации» (про IP ни слова)
Есть вариант, считать людей людьми, если они заходят не с проксей, а с мтс, билайна или мегафона и делиться с ними урывками «публичной» информации. Но не тут-то было, они придут и с впна, нельзя же их разочаровывать.
Т.е. к чему это я — можно построить алгоритм определения человек ли к нам пришел или парсер и source ip использовать в качестве одного из критериев.
Алгоритм Сергея по косвенным признакам вычисляет траекторию такси, а с ним и пассажира. В ответ, алгоритм Ситимобила пытается по косвенным признакам вычислить Сергея.
Если долго смотришь в бездну, бездна начинает смотреть на тебя.
/* Если вдруг Сергей неосторожно сядет в такси Ситимобила, то произойдёт бесконечная рекурсия и настанет конец Вселенной. */
Есть такая штука — Residential Proxies. В итоге как обычно — защита обходится не так сложно. Но в то же время доставит проблемы легитимным пользователям впн.
я потрачусь на прокси чуть подороже и поставлю в настройках выдавать моему боту IP из пула определенных операторов и соберу данные
или
я попытаюсь заказать такси, когда телефон подключен к wifi и на роутере прописан впн. и останусь без такси
или
я попытаюсь заказать такси, когда телефон подключен к wifi и на роутере прописан впн. и останусь без такси
Знаете, про GeoIP и определение положение абонента на сайтах я уже поел говна, т.к. меня регулярно кидает в другой регион (где куплена SIMка), а не где я фактически нахожусь. Так что да — мифическая забота о пользователе для определенного процента пользователей выходит боком. Зато 99% остальных пользователей довольны…
Очевидно, что такси пользуются только физики.
Нет.
Несколько лет назад у меня была работа с опцией — звониш в конкретный таксопарк, говоришь волшебное слово и едешь на такси домой, утром наоборот. За счет фирмы. Спецтариф какой то. Не верю что сейчас у таксистов нет такой опции. В приложениях может пока еще и нет — пока.
Да, спасибо за уточнение. Под физики — я имел в виду конкретных людей, пускай и работающих в корпорациях и пользующихся такси по служебной необходимости.
Действительно, я видел у Убера корп. тариф, но прошу обратить внимание, что устройство-то скорее всего с которого происходит вызов — обычный телефон (или планшет) с обычным же интернетом (обычный мобильный опсос). А волшебное слово и корп. тариф — это больше про форму оплату (хотя там тоже нюансы )…
Действительно, я видел у Убера корп. тариф, но прошу обратить внимание, что устройство-то скорее всего с которого происходит вызов — обычный телефон (или планшет) с обычным же интернетом (обычный мобильный опсос). А волшебное слово и корп. тариф — это больше про форму оплату (хотя там тоже нюансы )…
Сложная-несложная, но отдельная. Требующая своей аналитики (раз в секунду — это уже слишком часто или ещё нет?), архитектурных решений (информацию о прошлых запросах надо же где-то хранить)… Вполне может оказаться, что защитой от ddos вообще другой подрядчик занимался.
Да у них вообще весьма интересно все. Не совсем понимаю как можно на полном серьезе делать вакансию со словами «Ищем backend с 3+ годами опыта. У нас тут все на php, с удовольствием примем всех желающих переучится на него» и спамить всем у кого в резюме написано слово «разработчик» эту вакансию. Ладно бы они джунов искали, но 3+ это уже человек у которого знания его текущего языка на достаточно глубоком уровне и тут они предлагают все выбросить и пойти изучать другой язык.
Да, было очень интересно!
Ситимобил входит в МРГ, а как мы помним по ВК, они по Bug Bounty ну платят.
«Это так и должно работать», а через неделю фиксят
«Это так и должно работать», а через неделю фиксят
если зайти на страницу компании на hackerone, там написано что через сервис всего уже было выплачено $564,656
Из них
$122,681
Bounties paid in the last 90 days
Из них
$122,681
Bounties paid in the last 90 days
МРГ очень неоднородная структура. Имхо, у самого Mail.ru весьма высокие требования по безопасности, плюс достойная адекватность и готовность общаться у сотрудников (z3apa3a вообще рассказал мне довольно много интересных вещей в рамках репортов), ВК — это нечто крайне странное, безопасники готовы месяцами не исправлять довольно серьезные уязвимости, потом выкатить дырявое решение, а на все вопросы о том, почему бы не сделать безопасно и нормально, заявить, что так оптимальнее.
Закрывший тикет представитель citymobil указал не на то, что данные в приложении секьюрны, а на то, что они сами по себе открыты. Это не уязвимость, не баг и не недоработка, это одна из стандартных функций сервиса, на это указывают и очевидные ограничения АПИ.
Возможно, у ТС не хватает опыта и компетентности в этой области, так как вещи это банальные и представляют собой базис. Их не забывают защищать, ибо их изначально не делают открытыми без надобности.
Эту “проблему” в глобальной перспективе невозможно решить, разве что не показывать этой информации вовсе.
Возможно, у ТС не хватает опыта и компетентности в этой области, так как вещи это банальные и представляют собой базис. Их не забывают защищать, ибо их изначально не делают открытыми без надобности.
Эту “проблему” в глобальной перспективе невозможно решить, разве что не показывать этой информации вовсе.
Почему их нельзя зашифровать?
Зачем шифровать данные, если мы отдаём их юзерам? В каком бы виде данные не передавались, их в любом случае нужно интерпретировать чтобы показать конкретную точку на карте, и ничего не мешает “злоумышленнику” делать это точно так же, как делает приложение.
Возможно, я неправильно понял вопрос?
Возможно, я неправильно понял вопрос?
Я имею в виду почему нельзя передавать координаты в зашифрованном виде и расшифровывать их на стороне пользователя? Где на каждую пользовательскую сессию уникальный ключ-идентификатор
И что это даст?
Зачем шифровать?
Чтобы что? К тому же трафик и так шифруется по https протоколу ;/
Чтобы человек посередине видел не открытый json, а зашифрованные данные, которые расшифровываются в приложении. И надо будет не просто снифать, а лезть в работающее приложение, которое может иметь свои механизмы защиты.
Так как это защитит от того чтобы написать свой клиент для апишки с тем же шифрованием? Можно будет ровно так же собирать данные. Собственно в статье так и было сделано.
Вот этого я как раз и не понимаю. Приходит ему к примеру ответ "car_type":"GhRd35nai7", каким ключем он будет это расшифровывать?
сертификатом/ключом, которые hack0r вытащит из самого приложения. Или Вы думаете, что на каждую сессию будет генерировать сессионный ключ? ну, ок, это все равно не отменяет возможности написания полноценного эмулятора приложения, но это явно будет ТУПО дороже, чем просто сниффать трафик и строчить разгромные статьи на хабр ) И, понятно, что экономической целесообразности в этом уже не будет, т.к. взлом будет стоить дороже, чем защищаемые данные (в общем-то, в этом и есть цель ИБ).
Найдется другой товарищ, который зареверсит само приложение и все равно вытащит нужные уязвимости, это не решение.
Более-менее «защитить» можно элементарно. Запоминать предыдущие точку и время запроса и сравнивать с новой. Если скорость перемещения больше ~250км/ч — клиент на подозрении, если повтор — бан за нарушение условий использования.
Человек не обязательно заказывает такси себе. Зайти в приложение, а затем переместиться на другую точку — вполне нормально. Или например телефон подглючивает и определяет собственные координаты не в том месте. Или например я при повышенном спросе ползаю по карте и смотрю, может с другой точки будет заказать дешевле.
Справедливости ради — ограничить такую возможность все же дешевле, чем выкатывать дыру из поста.
Имею ввиду ограничить радиус скажем в полкилометра от начальной точки.
Имею ввиду ограничить радиус скажем в полкилометра от начальной точки.
Я вызываю такси около стен Кремля… один шажок и я уже во Внуково и забанен. Я вчера вызывал такси в Питере, а сегодня вызываю в Самаре, но вот геодата на старте не подхватилась и я в Питере, хотя в реальности в Самаре, как хорошо, что у меня AGPS+GPS+Glonass ну и чип этого GPS быстрый, всего 30 секунд и я в Самаре… вот только опять бан.
Ещё реальных тесткейсов наплодить?
Ещё реальных тесткейсов наплодить?
Как в потоке запросов выловить предыдущий запрос от этого клиента? По IP не получится, т. к. за одним натом может быть куча телефонов. Куки злоумышленник, скорее всего, догадается выбросить, благо запрос работает без авторизации. Что ещё?
А я всего-навсего случайно включил определение положения по всем источникам для «высокой точности».
Эту проблему можно решить рядом способов:
— показывать данные только авторизованным пользователям (если у человека нет приложения, данные ему не нужны);
— ограничивать количество запросов в единицу времени (чаще чем раз в 10-15 секунд не имеет смысла запрашивать, для практического применения возможно и минуты будет достаточно);
— бить тревогу если запросы начинают идти на локации значительно удаленные от места где находится пользователь приложения;
— не отдавать результат если пользователь находится в поездке (ему это уже или ещё не нужно, пока он не достигнет конечной точки);
— … и ещё можно придумать мониторинг и ограничения, не создающие проблем честным пользователям, но не дающие возможности следить за водителями кому угодно.
Да даже банальный rate-limit на раз в 30 секунд с одного IP существенно сократит (если совсем не уберёт) возможности слежки, уж маршрут-то точно станет тяжко отслеживать.
— показывать данные только авторизованным пользователям (если у человека нет приложения, данные ему не нужны);
— ограничивать количество запросов в единицу времени (чаще чем раз в 10-15 секунд не имеет смысла запрашивать, для практического применения возможно и минуты будет достаточно);
— бить тревогу если запросы начинают идти на локации значительно удаленные от места где находится пользователь приложения;
— не отдавать результат если пользователь находится в поездке (ему это уже или ещё не нужно, пока он не достигнет конечной точки);
— … и ещё можно придумать мониторинг и ограничения, не создающие проблем честным пользователям, но не дающие возможности следить за водителями кому угодно.
Да даже банальный rate-limit на раз в 30 секунд с одного IP существенно сократит (если совсем не уберёт) возможности слежки, уж маршрут-то точно станет тяжко отслеживать.
Я говорил о решении проблемы, а не ограничениях. Можно накатывать сколько угодно условий, скраппить данные это не помешает, но давайте по пунктам.
Вы можете передавать данные авторизации вместе с запросом, серверу глубоко всё равно с приложения или тапка они отправлены, любой user agent можно подменить хотя бы с помощью того же reverse proxy.
Прокси помогут as well.
Невозможно точно установить местоположение пользователя, как вы собираетесь это сделать?
показывать данные только авторизованным пользователям (если у человека нет приложения, данные ему не нужны);
Вы можете передавать данные авторизации вместе с запросом, серверу глубоко всё равно с приложения или тапка они отправлены, любой user agent можно подменить хотя бы с помощью того же reverse proxy.
ограничивать количество запросов в единицу времени (чаще чем раз в 10-15 секунд не имеет смысла запрашивать, для практического применения возможно и минуты будет достаточно);
Прокси помогут as well.
бить тревогу если запросы начинают идти на локации значительно удаленные от места где находится пользователь приложения;
Невозможно точно установить местоположение пользователя, как вы собираетесь это сделать?
Вы можете передавать данные авторизации вместе с запросом, серверу глубоко всё равно с приложения или тапка они отправлены, любой user agent можно подменить хотя бы с помощью того же reverse proxy.
Это смотря как делать авторизацию, не говоря уже о том что пользователю придётся сначала регистрироваться, а это привязка по номеру телефона (подозреваю, что с верификацией).
В токен авторизации можно забить текущие координаты пользователя и ограничить радиус запроса в (скажем) 3 км.
Далее, если мы ограничим выдачу результатов только авторизованным пользователям, то в сочетании с банальным rate-limit не помогут ни прокси, ни что-то ещё, ибо он привязан к пользователю, а не IP.
Вы конечно скажете что можно создать сотню или тысячу пользователей, но их можно быстро вычислить по частоте запросов (тот кто просто ездит не делает запросы даже раз в минуту на протяжении часа), не говоря уже о том что на каждого пользователя потребуется свой номер телефона, а три разных запроса (скажем) в течение минуты с разных IP но от одного пользователя явное свидетельство чего-то «левого».
Конечно, если разбить город сеткой 100x100, в каждый квадрат «посадить» отдельного пользователя (уже 10 тыс. нужно), и каждый из них будет делать запрос раз в минуту — то что-то из этого и получится, но стоимость такого съёма информации будет просто невероятной, причём их всё ещё легко отследить (при желании), ибо они не ездят.
Невозможно точно установить местоположение пользователя, как вы собираетесь это сделать?
Правда? Приложение для вызова такси не использует GPS смартфона для определения положения пользователя? Да, можно подменить данные — но «прыгунов» легко отследить, не думаю что если кто-то реально способный перемещаться со скоростью более км/минуту (и делающий это между запросами) нуждается в такси, в сочетании с ограничением по радиусу поиска это отфильтрует левые запросы.
тот кто просто ездит не делает запросы даже раз в минуту на протяжении часа
Похоже, вы просто напросто забыли что данная возможность предназначена для отслеживания автомобилей (не автомобиля) и их положения в реальном времени. Будет сложновато для обычных пользователей без корыстных намерений сделать это с такими ограничениями.
Не говоря уже о том, что gps технологии поддерживаются не всеми устройствами.
Будет сложновато для обычных пользователей без корыстных намерений сделать это с такими ограничениями.
Для гиков дается burst на 10 запросов и далее rate-limit на 1 запрос/минуту — этого более чем достаточно чтобы насладится видом вокруг несколько раз, вызвать машину, дождаться её и уехать. Среднему пользователю совершенно неважно что машины в районе сместятся на несколько сотен метров (или даже на километр) пока он изучает карту, ему важно (и то вопрос) видеть сколько их рядом.
Если машина заказана и уже едет и хочется знать где она — отдается только её положение, что ещё нужно пользователю для приятного опыта?
В конце концов, подавляющему большинству важно только знать когда будет подана машина, может быть уведомление об опоздании заказанной, но сколько их вокруг и каких именно (особенно после заказа) — это совершенно иррелевантно.
Просто знать положение и количество такси в округе — почти бесполезно, не зная чем они заняты и когда освободятся, их цвет тем более бесполезен (по крайней мере, пока одно из них не едет за вами — но цвет остальных в этом случае тем более неважен).
Не говоря уже о том, что gps технологии поддерживаются не всеми устройствами.
Ок, тогда пользователь сам укажет где он. Но если он будет менять положение каждые 15 секунд со смещением в несколько километров, опрашивая машины в округе — разве это реалистично для того кто просто хочет уехать? Он что, телепортироваться собирается в район где их больше? А если собирается (и может) — то зачем ему, собственно, такси?
Похоже, вы просто напросто забыли что данная возможность предназначена для отслеживания автомобилей (не автомобиля) и их положения в реальном времени.
Нет, её назначение — создать у пользователя впечатление, что он сможет быстро уехать, но при этом не сильно пользователю наврать. Более того, пользователь абсолютно не расстроится, если в момент назначения машины он получит не уже нарисованную на карте, а какую-то новую — главное, что машина есть. Точность местоположения и реальное время здесь не нужны от слова совсем.
И да, вам не нужно делать сто тысяч запросов в секунду, чтобы рисовать машинки на карте — дайте клиенту позицию и направление, пусть экстраполирует, юзеры не будут бегать по улице и сравнивать. Дороги у нас обычно прямые, максимум, что произойдет — машина на карте немного проедет перекресток, а потом прыгнет на перпендикулярную дорогу, будто кому-то на это не побоку. Одного запроса раз в 10-15 секунд вполне хватит.
Расстроится. Неоднократно было — машине в округе есть, но не назначают ни одной, либо назначают самую бальную...
В яндексе же тоже так: вокруг рисуется много машин, а заказ никто не берёт. А через некоторое время берёт машина, которой до тебя ещё минут 10 ехать. И в gett подобное есть.
но при этом не сильно пользователю наврать
Если вы не можете уехать, то очевидно, что ваше впечатление и реальность существенно различаются. Суть моего коммента в том, что реальному юзеру не важно, как эти машинки технически рисуются — ему нужно сесть и уехать. Если получилось — он доволен, не получилось — он недоволен. Реалтайм там или экстраполяция — дело сто первой важности.
В некоторых сервисах такси есть такая штука — вызов такси кому-то в другой части города. Есть например в том же яндексе. И точно так же показываются машины рядом. Удобная штука. А вот вы предложили сделать ее менее удобной.
Нисколько. Это решается уже упомянутым мной выше бурстом. К тому же, я (будучи сервисом) с трудом поверю что пользователь вдруг решил заказать такси десятку разных «других» в разные районы города за короткое время, а если и решил, то вряд-ли будет это делать регулярно и продолжительное время — он что, свой сервис заказов открыл, а у всех без исключения «других» нет смартфонов с приложением? И он готов отвечать каждому водителю «Я тут стою у зелёного киоска, вы где?» вместо этих самых «других», или наоборот, каждому «другому» — «Да едет он к вам, едет, в пробке стоит, опоздает на 10 минут»?
Не в некоторых, а во всех известных мне. И это жизненно необходимая возможность. Например, заказать такси жене/ребенку/теще/другу и т п
Или едешь ты в метро, gps прыгает, а ты хоп — и вызвал такси на конечную метро по адресу )
Шаринговые сервисы типа Share Now показывают машины и без логина, все.
Кстати, интересно было бы поковыряться в их трафике, хотя это мало что даст.
Эту “проблему” в глобальной перспективе невозможно решить, разве что не показывать этой информации вовсе.
А почему нельзя показывать пользователю варианты автомобилей вокруг только после создания заказа? Как это делает тот же Я.Такси. Тогда можно было бы отдавать их не по локации пользователя, а по локации самого заказа, который этот пользователь создал. Локацию заказа поменять у пользователя не получится, не пересоздавая заказ. Как и создавать 100500 заказов в минуту. Вот и решение.
Это не решение проблемы существующей задачи, это другая задача.
Потому, что я не хочу делать заказ, если рядом нет машин?
Достаточно сделать чуть другую систему — делаете заказ, водитель делает преложение — «буду через 20 минут» — вы можете бесплатно отказаться если не устраивает, а если «буду через 3 минуты» — то всё равно сколько машин в округе, вам ведь важно быстро уехать, или нет?
И даже если округа вся занята машинами, у вас всё равно никакой гарантии не будет что кто-то из них уложится в нужное вам время, хотя… если никто не уложится — разве вы будете вызывать вертолёт? В лучшем случае будете заказывать у другой службы, но не факт что ситуация там будет лучше (особенно в час пик), и обозревание количества машин вокруг совершенно на это не может повлиять.
И даже если округа вся занята машинами, у вас всё равно никакой гарантии не будет что кто-то из них уложится в нужное вам время, хотя… если никто не уложится — разве вы будете вызывать вертолёт? В лучшем случае будете заказывать у другой службы, но не факт что ситуация там будет лучше (особенно в час пик), и обозревание количества машин вокруг совершенно на это не может повлиять.
Да 200%. Меня не волнует плотность машин в конкретном районе. Я уже выше писал почему — легко может оказаться, что свободных водителей нет. А машины на карте есть
А интересует меня — среднее время ожидания по конкретному адресу. Если оно больше некой величины, то пора садиться на ОТ или искать каршэринговую тачку
Лишние действия от пользователя вместо нормальной реализации от поставщика услуг.
Мне важно уехать, когда быстро, когда комфортно — зависит.
А идиотские ограничения "не заказал — не покажем машины рядом" автоматически отправляют таких вот оптимизаторов, в лучшем случае, в конец списка сервисов.
Что значит «лишние»? Он заказывать не собирается, что-ли? Тогда зачем полез в приложение? А если собирается, всё равно жмёт кнопку «заказать», и независимо от плотности и количества машин показанных на карте время ожидания его может не устроить (они все могут быть заняты, ехать в другом направлении, etc).
«Правильные» сервисы сами оценивают время ожидания в данной точке с учётом наличия машин, их занятости и среднего времени на подачу для каждого конкретного водителя из каждой конкретной точки, при этом можно ещё учесть и траффик, пробки, вероятность принятия заказа и ещё много всего такого что известно сервису (но не может быть показано на карте).
Пользователю может быть «неудобно» только в одном случае — если карта даёт ему возможность сделать drag & drop конкретной машины, с последующей материализацией этой самой машины там где он стоит через несколько секунд.
За всё время пользования подобными сервисами не могу вспомнить ни одного случая когда информация о машинах хоть как-то была полезна, хотя красиво, да — создает атмосферу «мы заботимся о вас» и «смотрите как у нас круто, сколько машин вокруг».
«Правильные» сервисы сами оценивают время ожидания в данной точке с учётом наличия машин, их занятости и среднего времени на подачу для каждого конкретного водителя из каждой конкретной точки, при этом можно ещё учесть и траффик, пробки, вероятность принятия заказа и ещё много всего такого что известно сервису (но не может быть показано на карте).
Пользователю может быть «неудобно» только в одном случае — если карта даёт ему возможность сделать drag & drop конкретной машины, с последующей материализацией этой самой машины там где он стоит через несколько секунд.
За всё время пользования подобными сервисами не могу вспомнить ни одного случая когда информация о машинах хоть как-то была полезна, хотя красиво, да — создает атмосферу «мы заботимся о вас» и «смотрите как у нас круто, сколько машин вокруг».
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Достаточно убрать id из выдачи. И всё — данные уже не соберёшь, ибо машины двигаются, координаты меняются, сопоставить невозможно. Даже количество машин не оценишь.
Сначала подумал об этом. Но как тогда приложение будет рисовать линейное движение автомобилей на карте? Они же как мошки начнут мерцать.
НЛО прилетело и опубликовало эту надпись здесь
ну, вообще это крутой ui/ux. А еще очень круто наблюдать, когда твоего ребенка/жену/пр. везет такси — ты точно чувствуешь, что контролируешь ситуацию. И можешь выйти к моменту подачи и встретить. А не реагировать пост-фактум на смс со списанием (которой может и не быть).
Или текущее положение машины очень удобно, если экономишь время и можешь пойти (тупо) навстречу водителю, чтобы не стоять в пробке или типа того
Или текущее положение машины очень удобно, если экономишь время и можешь пойти (тупо) навстречу водителю, чтобы не стоять в пробке или типа того
НЛО прилетело и опубликовало эту надпись здесь
Эм, ну, согласен. Прошу прощения, видимо, не совсем понял о каком именно движении Вы говорили. Если речь о движении машин вокруг меня до момента заказа, то, да, соглашусь — для меня как клиента особого толку в нем нет, только аккумулятор сажать, потому что процессор отсчитывает, а экран отображает эти данные )) тем более, что ни разу не было, что я сел в ближайшую машину ) Т.е., повторюсь, мне важно как клиенту:
1. Знать время подачи (реальное)
2. Стоимость поездки
3. После оформления заказа — наблюдать как едет автомобиль (я написал почему).
И ещё — у Яндекса есть, например, очень крутая Ui/Ux штука — когда он предлагает, например, мне перейти через дорогу и сэкономить на поездке сколько-то рублей.
1. Знать время подачи (реальное)
2. Стоимость поездки
3. После оформления заказа — наблюдать как едет автомобиль (я написал почему).
И ещё — у Яндекса есть, например, очень крутая Ui/Ux штука — когда он предлагает, например, мне перейти через дорогу и сэкономить на поездке сколько-то рублей.
Зачем-то всякие Уберы и простые службы рисуют, пользователю дают ощущение участия в процессе.
Во время поиска машины приложение не рисует движение. А в процессе ожидания и поездки логично передавать положение только одной машины.
В процессе движения не вижу логичности в ограничении только одной машиной. Если мне нужно посмотреть что там в точке прибытия с другими машинами.
Например, мне обратно ехать через 10 минут — вариант заплатить текущему водителю за простой или отпустить и не спешить особо вызвав другого.
Кейсов очень много можно найти, если начинать продумывать удобство пользователя.
Например, мне обратно ехать через 10 минут — вариант заплатить текущему водителю за простой или отпустить и не спешить особо вызвав другого.
Кейсов очень много можно найти, если начинать продумывать удобство пользователя.
Задача сервиса — не дать вам возможность сэкономить путем оплаты 10 минут простоя водителя, а слупить с клиента максимально денег. Или окучить Макс количество клиентов
В определенной парадигме — это может быть провокация создания новых заказов.
В определенной парадигме — это может быть провокация создания новых заказов.
Приехал куда-то в жопу мира на 20 минут, варианты:
- Посмотрел, что машин рядом нет и не предвидится, заранее оплатил простой, получено с меня 2X+T денег.
- Вышел, сделал дела, открыл заново, офигел от ситуации, кое-как заказал — получено с меня 2Х денег, я недоволен покрытием, водитель первого захода недоволен, что обратно ехал пустым.
- (как 2, но утрированно)… открыл заново, попытался заказать, десяток раз словил дулю — позвонил в таксопарк и уехал обычным такси, в итоге — получено всего лишь Х денег.
Так что сколько людей, столько и кейсов.
Да, выглядит логично, НО — как Вы посмотрите сколько машин вокруг, если во время заказа отображается (но это не точно) — только текущая машина и ее передвижение по карте? Т.е. получается — смотреть со второго телефона (пока мультиаккаунт на телефонах плохо работает)?
Предположил, что fougasse имел в виду посмотреть перед заказом.
Каждый раз когда я пользовался яндекс-такси и знал, что мне скоро обратно, то просто говорил это водителю и всегда он просто не уезжал.
Иногда кстати они и сами спрашивают «вы обратно скоро?»
Иногда кстати они и сами спрашивают «вы обратно скоро?»
Если машина свободна, то зачем видеть её движение (она, конечно, может двигаться к ближайшей точке притяжения, но часто они просто стоят и ждут следующий заказ)?
То есть это просто запрос на конкретный домен? Можно через браузер всё это провернуть?
Имхо дырка в одном: можно отслеживать, куда едет клиент, если знаешь, где и когда он сел в такси.
А показывается ли положение ЗАНЯТЫХ такси?
Даже если не показывается, то возможно отследить место, в котором машина станет свободной
Тоже думал об этом.
Теоретически — да. А практически, машина может и не освободиться, если водитель решит закончить рабочий день.
Или если он сразу схватит нового пассажира между сканированиями.
Ну и отслеживание онлайн это совсем не то, что ты после поездки выясняешь, куда же человек ездил.
При чём история не ведётся: пропустил момент освобождения такси, и всё, данных нет
POST запрос на /getdrivers
А так пишут?) В смысле, глагол в endpoint'е, POST вместо GET на получение списка и дублирующий `method: getdrivers` в теле запроса.
А так пишут?) В смысле, глагол в endpoint'е, POST вместо GET на получение списка и дублирующий `method: getdrivers` в теле запроса.
Тоже показалось странным
Если я правильно понимаю, в GET запросе параметры можно передавать лишь в query либо в header-ах, при этом в POST (PUT, etc.) доступен «payload» — body. И вот насколько мне известно передача данных в payload-е секьюрнее с точки зрения возможности отследить что ты и куда отправляешь на уровне просмотра твоего трафика. Но это не точно.
Чуточку секурнее. А ещё можно струячить не http, а grpc запросами, которые то же самое, но лучше. А к чему это я. Gprc уже без спец знаний и средств просто так не распарить. А эффективность может быть выше (компактнее хранение)
в GET запросе параметры можно передавать лишь в query либо в header-ах
Вы удивитесь (как удивился в своё время я сам) — в GET можно использовать body, спецификация это не запрещает. Неплохое обсуждение тут.
Проблема может быть только с (кэширующими) прокси, которые используют старую спецификацию (где «смысл» GET запроса определялся исключительно URI, а тело игнорируется).
Это то понятно, но можно много вещей делать игнорируя спецификации. Тем более Вы сами явно выделили причину не использовать этот костыль.
Ещё одна причина почему могут юзать POST вместо GET — возможно большинство ручек подразумевают у них POST запросы, и им просто было проще вообще все запросы делать POST копипастой из других мест в коде. Т.е. внутренние парсеры, кодогенерация, и так далее мб уже были настроены под POST так что их и юзали.
Ещё одна причина почему могут юзать POST вместо GET — возможно большинство ручек подразумевают у них POST запросы, и им просто было проще вообще все запросы делать POST копипастой из других мест в коде. Т.е. внутренние парсеры, кодогенерация, и так далее мб уже были настроены под POST так что их и юзали.
Это не костыль — спецификация как раз это допускает, и старая и новая, просто смысла в те времена в теле не было, всё легко влезало в URI, JSON ещё не было, XML только начинал свой путь. Новая же спецификация явно это поддерживает, поскольку «смысл» запроса уже не определяется только URI.
Посмотрите на банальные гугло-запросы хотя бы, или всякие баннерные URI и прочая (типо OAuth) — там уже доходит до килобайтов, в логи прокси и серверов иногда просто страшно смотреть (причём в большинстве случаев, кроме пожалуй отладки прокси или сервера, это бесполезные записи).
И наконец, иногда всё же хочется скрыть тело запроса (параметры) от случайного (или избыточного) логирования (ясный пень что при желании и тело можно логировать, но это и в случае POST/PUT можно).
Посмотрите на банальные гугло-запросы хотя бы, или всякие баннерные URI и прочая (типо OAuth) — там уже доходит до килобайтов, в логи прокси и серверов иногда просто страшно смотреть (причём в большинстве случаев, кроме пожалуй отладки прокси или сервера, это бесполезные записи).
И наконец, иногда всё же хочется скрыть тело запроса (параметры) от случайного (или избыточного) логирования (ясный пень что при желании и тело можно логировать, но это и в случае POST/PUT можно).
Вы удивитесь (как удивился в своё время я сам) — в GET можно использовать body, спецификация это не запрещает. Неплохое обсуждение тут.
Можно, но сервер не должен читать это тело. Иначе, если он отдает разный ответ в зависимости от тела он нарушает спецификацию:
Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request.
Можно.
В том случае когда query string большой/сложный, это прям в REST написано.
Но в целом да, что то не так с названием.
В том случае когда query string большой/сложный, это прям в REST написано.
Но в целом да, что то не так с названием.
У меня сейчас на столе в разборке приложение, у которого всегда POST /, а глагол и все аргументы в QueryString, запакованном ZIP и загнанном в base64; так что пишут все вообще как хотят
Так делают. Elasticsearch передает запросы в теле методом GET, и он так же позволяет производить поиск методом POST. Его поисковые запросы могут быть внушительными)
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html
https://developer.twitter.com/en/docs/api-reference-index.html
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
https://tools.ietf.org/html/rfc7231#section-4.3.1
«некто «3apa3a»» случаем не автор 3proxy github.com/z3APA3A?
Деанон на Хабре?
Владимир Дубровин имеет профиль на хабре с несколькими публикациями.
habr.com/ru/users/z3apa3a
habr.com/ru/users/z3apa3a
> А то, что данные вроде как важные.
Вроде как да, а вроде и нет.
> можно отследить конкретного таксиста, можно отследить и его клиента
Ну и что? Сомневаюсь что Ситимобил хоть раз гарантировал приватность в этом вопросе.
> Яндекс.Такси, вот вам гора данных
ЯДу бы самому не мешало эти данные раскрыть.
Вроде как да, а вроде и нет.
> можно отследить конкретного таксиста, можно отследить и его клиента
Ну и что? Сомневаюсь что Ситимобил хоть раз гарантировал приватность в этом вопросе.
> Яндекс.Такси, вот вам гора данных
ЯДу бы самому не мешало эти данные раскрыть.
Практически любое моб приложение страдает подобными дырами. Многие прям в лог плюют дебаг информацией. Включая, банковские. Спасает только то, что для реверсинжиниринга моб приложений нужен уровень чуть выше консольки в хроме… Хотя, может быть и не спасает. Просто кому это действительно надо — молча пользуются.
Защитить эти данные и вправду сложно.
Формально любая ручка, отданная юзеру — публичная. Есть телефон с приложением — значит есть и полный доступ, ограничения по лимиту обходятся через прокси.
Единственный способ защитить — это хорошее шифрование и дешифратор в приложении. Есть умельцы которые смогут реверснуть код, против такого — смена соли при каждом обновлении приложения.
Ну это ладно, можно простить, менеджеры напрягают, спринты горят, задачи еще вчера должны были быть в проде.
Но вот POST запрос на getdrivers это реально треш. К тому же вперемешку и snake и camel, неработающие радиус и лимит, еще не пойми зачем они версии каждый раз таскают прямо в теле запроса…
Если я был бы разработчиком там, мне было бы стыдно за такое. Взять 2-3 недели как техдолг и привести в нормальный вид. Самим то не стремно такой шлак изрыгать?
Формально любая ручка, отданная юзеру — публичная. Есть телефон с приложением — значит есть и полный доступ, ограничения по лимиту обходятся через прокси.
Единственный способ защитить — это хорошее шифрование и дешифратор в приложении. Есть умельцы которые смогут реверснуть код, против такого — смена соли при каждом обновлении приложения.
Ну это ладно, можно простить, менеджеры напрягают, спринты горят, задачи еще вчера должны были быть в проде.
Но вот POST запрос на getdrivers это реально треш. К тому же вперемешку и snake и camel, неработающие радиус и лимит, еще не пойми зачем они версии каждый раз таскают прямо в теле запроса…
Если я был бы разработчиком там, мне было бы стыдно за такое. Взять 2-3 недели как техдолг и привести в нормальный вид. Самим то не стремно такой шлак изрыгать?
Единственный способ защитить — это хорошее шифрование и дешифратор в приложении.
Это не защитит данные, а сделает их получение чуть более сложным. Придётся гонять приложение в эмуляторе, подсовывая ему разные данные о местоположении и делая скриншоты, которые потом нужно будет правильно распарсить. Просто будет меньше людей, которым будет не лень это сделать.
Есть телефон с приложением — значит есть и полный доступ, ограничения по лимиту обходятся через прокси.
Только если нет идентификации и аутентификации. Если есть, то привязка ограничений идёт к пользователю, никакие прокси мира не помогут, а создание сотен пользователей может быть сильно затруднено или чрезмерно накладно. Опять-таки, как я уже говорил выше, легко отследить тех кто только спрашивает но никогда (или почти никогда) не заказывает.
Единственный способ защитить — это хорошее шифрование и дешифратор в приложении. Есть умельцы которые смогут реверснуть код, против такого — смена соли при каждом обновлении приложения.
Абсолютной защиты естественно не бывает, но банальные ssl pinning + firebase anonymous auth мигом повысили бы сложность с «я тут за вечерок снял траффик и наклепал скрипт» до «геморройно, ну его нафиг» для большинства любителей пошуршать там, где их не ждут.
Повысили бы сложность незначительно. Собирать собственный андроид с пасьянсом и блудницами для отключения certificate pinning сегодня не обязательно, расковырять javax.net.ssl.SSLContext полгода назад можно было с помощью xposed-модуля github.com/Fuzion24/JustTrustMe, сейчас вроде работает Frida — например, gist.github.com/cubehouse/56797147b5cb22768b500f25d3888a22, для Magisk что-то ещё было.
Можно поставить ограничение на количество запросов на аккаунт. В таком случае прокси не поможет
Не нужно защищать данные.
Нужно отдавать пользователю ровно то, что он попросил — сколько машин рядом, и где эти машины.
Не привязывая к меткам машин какие-то ID.
И обновляя метки при каждом обращении.
А уже после заказа — конкретизировать авто до цвета, марки, модели, номерного знака, ВИН, ИНН водителя… :)
Нужно отдавать пользователю ровно то, что он попросил — сколько машин рядом, и где эти машины.
Не привязывая к меткам машин какие-то ID.
И обновляя метки при каждом обращении.
А уже после заказа — конкретизировать авто до цвета, марки, модели, номерного знака, ВИН, ИНН водителя… :)
Опять хакер в солонку нассал. Мне кажется что точно стоит убрать id машины — уже этого будет достаточно. Но если есть фича с выбором конкретного такси для поездки — она поломается. Как вариант можно наверное после каждой поездки назначать новый ид машины (ид — который отдается в приложение); не показывать машины в поездке.
И случайно так у автора иконка Яндекс-Турбо)
Krupnikas, круто, что у вас не только текстовое описание, а и визуальное.
Когда я нашёл уязвимости в другом сервисе такси (Как ездить на такси за чужой счёт — уязвимости на примере одного сервиса), я видел такую же ситуацию, но не мог так хорошо расписать её. Что ж, попробую сообщить сейчас, с ссылкой на ваш пост, о результатах сообщу ;)
Когда я нашёл уязвимости в другом сервисе такси (Как ездить на такси за чужой счёт — уязвимости на примере одного сервиса), я видел такую же ситуацию, но не мог так хорошо расписать её. Что ж, попробую сообщить сейчас, с ссылкой на ваш пост, о результатах сообщу ;)
Круто, а какими библиотеками пользовались для визуализации всего этого?
Спасибо! Отвечал тут habr.com/ru/post/480956/#comment_21029326
Молодец, классно получилось, ждем еще статей)
Всем привет. Сергей, ещё раз здравствуйте. Ситимобил на связи.
Мы внимательно изучили всю ситуацию, описанную Сергеем Крупником. Мы ожидаем, что все детали найденных дефектов, а также любые вопросы касающиеся уязвимостей, будут сначала заданы нам в тикете на HackerOne (https://hackerone.com/reports/756833). В данной ситуации мы не получили всех тех деталей, которые описаны в статье, и очень ждем от автора, что в будущем вместе с ним лично будем обсуждать любые возникающие вопросы.
Теперь по существу. Отображение доступных машин поблизости без пассажиров — штатная функциональность любого приложения по заказу такси, которую на данный момент нет планов менять. Описанный баг не позволял получить данные водителей Ситимобил с пассажирами и не позволял трэкать их перемешения. В любом случае, у нас есть план технически ограничить получение подобных данных.
По условиям программы Bug Bounty мы не можем можем выплатить вознаграждение после открытой публикации уязвимости. Но от команды Ситимобил считаем важным выдать вознаграждение за сообщение об этой возможности и проделанные усилия для её описании. Мы также готовы предложить Крупнику присоединиться к инженерной команде Ситимобил. Ещё мы призываем всех специалистов, кто занимается безопасностью пользовательских данных, сообщать нам о найденных уязвимостях через сайт HackerOne. Ситимобил очень серьёзно относиться к любым найденным уязвимостям и готов сотрдуничать со всеми, кому не безразлична эта тема. Мы также готовы выплачивать достойные вознаграждения за найденные баги в наших продуктах, но в рамках правил площадки HackerOne.
Мы внимательно изучили всю ситуацию, описанную Сергеем Крупником. Мы ожидаем, что все детали найденных дефектов, а также любые вопросы касающиеся уязвимостей, будут сначала заданы нам в тикете на HackerOne (https://hackerone.com/reports/756833). В данной ситуации мы не получили всех тех деталей, которые описаны в статье, и очень ждем от автора, что в будущем вместе с ним лично будем обсуждать любые возникающие вопросы.
Теперь по существу. Отображение доступных машин поблизости без пассажиров — штатная функциональность любого приложения по заказу такси, которую на данный момент нет планов менять. Описанный баг не позволял получить данные водителей Ситимобил с пассажирами и не позволял трэкать их перемешения. В любом случае, у нас есть план технически ограничить получение подобных данных.
По условиям программы Bug Bounty мы не можем можем выплатить вознаграждение после открытой публикации уязвимости. Но от команды Ситимобил считаем важным выдать вознаграждение за сообщение об этой возможности и проделанные усилия для её описании. Мы также готовы предложить Крупнику присоединиться к инженерной команде Ситимобил. Ещё мы призываем всех специалистов, кто занимается безопасностью пользовательских данных, сообщать нам о найденных уязвимостях через сайт HackerOne. Ситимобил очень серьёзно относиться к любым найденным уязвимостям и готов сотрдуничать со всеми, кому не безразлична эта тема. Мы также готовы выплачивать достойные вознаграждения за найденные баги в наших продуктах, но в рамках правил площадки HackerOne.
Всем привет. Георгий, еще раз здравствуйте. Станислав на связи.
Я внимательно изучил информацию по предоставленной вами ссылке и не нашел там запроса деталей. Просто тикет закрыт и есть отписка. Вам сначала в тикете и написали. И почему вы лично будете обсуждать? Я как пользователь хочу знать о существующих уязвимостях, по которым какой-нибудь псих может за мной следить.
Я внимательно изучил информацию по предоставленной вами ссылке и не нашел там запроса деталей. Просто тикет закрыт и есть отписка. Вам сначала в тикете и написали. И почему вы лично будете обсуждать? Я как пользователь хочу знать о существующих уязвимостях, по которым какой-нибудь псих может за мной следить.
Добрый вечер! Меня зовут Иван, я руководитель серверной разработки в Ситимобил.
Данное поведение не представляет угрозы для пользовательских данных. Через этот API endpoint видны только свободные машины.
Машина пропадает из выдачи в тот момент, когда водитель назначается на заказ. То есть невозможно установить точку подачи такси.
В этом можно убедиться, если обратить внимание на то, что на экране приложения машины исчезают в основном на дорогах, а не во дворах.
Допустим, если машина находится у Кремля, точка начала поездки около метро Маяковская, а точка назначения около метро Войковская,
то машина никогда не будет отображаться около метро Маяковская. Она пропадет около Кремля и появится только около метро Войковская. То есть, невозможно установить точку подачи такси.
Фактически, единственное, что можно получить через это API — местоположение свободных машин, да и то не всех.
Мы все же решили сделать защиту в виде рейтлимитов и закрытия API за авторизацию. Через это API можно собрать аналитику о месторасположении
наших машин. Как это использовать не понятно, но, теоретически, это может представлять угрозу для нашего бизнеса.
Спасибо, что обратили внимание на такое нестандартное использование нашего API.
Данное поведение не представляет угрозы для пользовательских данных. Через этот API endpoint видны только свободные машины.
Машина пропадает из выдачи в тот момент, когда водитель назначается на заказ. То есть невозможно установить точку подачи такси.
В этом можно убедиться, если обратить внимание на то, что на экране приложения машины исчезают в основном на дорогах, а не во дворах.
Допустим, если машина находится у Кремля, точка начала поездки около метро Маяковская, а точка назначения около метро Войковская,
то машина никогда не будет отображаться около метро Маяковская. Она пропадет около Кремля и появится только около метро Войковская. То есть, невозможно установить точку подачи такси.
Фактически, единственное, что можно получить через это API — местоположение свободных машин, да и то не всех.
Мы все же решили сделать защиту в виде рейтлимитов и закрытия API за авторизацию. Через это API можно собрать аналитику о месторасположении
наших машин. Как это использовать не понятно, но, теоретически, это может представлять угрозу для нашего бизнеса.
Спасибо, что обратили внимание на такое нестандартное использование нашего API.
А зачем делать костыль, в виде ограничения рейтлимитов, если при установки приложения сразу запрашивается телефон. значит уже есть авторизация. спрятать API под OAuth2 и поставить райт, это лучшее решение.
1. если мы получаем рейт для акаунта можно поставить капчу…
2. можно отслеживать акаунты который подозрительно себя ведут, и пытаются навредить системе.
я откровенно не понимаю, зачем делать костыль, если это никак не упрощает посадку нового пользователя в приложения. я бы понял, если бы вы сразу показывали карту с таксистами, а потом просили регистрацию. тогда это было-бы оправданно.
1. если мы получаем рейт для акаунта можно поставить капчу…
2. можно отслеживать акаунты который подозрительно себя ведут, и пытаются навредить системе.
я откровенно не понимаю, зачем делать костыль, если это никак не упрощает посадку нового пользователя в приложения. я бы понял, если бы вы сразу показывали карту с таксистами, а потом просили регистрацию. тогда это было-бы оправданно.
Данное поведение не представляет угрозы для пользовательских данных. Через этот API endpoint видны только свободные машины.
Машина пропадает из выдачи в тот момент, когда водитель назначается на заказ. То есть невозможно установить точку подачи такси.
Иван, здравствуйте. Я почти поверил написанному вам
но меня смущает вот эта гифка из поста
Я правильно понимаю, что водитель 2 раза объехал Мск, только по собственной инициативе лучше узнать город между заказами?
Скорее всего водитель делал заказы у другого агрегатора
Добрый день!
Этот факт вполне объясним. Что могло быть:
1) Бывает, что пассажиры по договоренности с водителем отменяют заказы. В таком случае, с точки зрения системы водитель остается свободным.
2) Некоторые таксисты работают сразу с несколькими приложениями и во время заказа не всегда выключают поиск заказов, оставаясь для системы свободными.
Тем не менее, находясь на нашем заказе (или на чужом, если водитель не находится в режиме поиска заказа), машина не видна на карте.
Этот факт вполне объясним. Что могло быть:
1) Бывает, что пассажиры по договоренности с водителем отменяют заказы. В таком случае, с точки зрения системы водитель остается свободным.
2) Некоторые таксисты работают сразу с несколькими приложениями и во время заказа не всегда выключают поиск заказов, оставаясь для системы свободными.
Тем не менее, находясь на нашем заказе (или на чужом, если водитель не находится в режиме поиска заказа), машина не видна на карте.
Если клиент сел, и машина пропала, а потом машина появилась в новом месте, то это не говорит о том, что клиента высадили в новом месте?
Но ведь водитель просто может пойти отдохнуть, поесть. Уйти домой и еще куча причин не связанных с поездкой. Как в таком формате можно различить реальные поездки от шума?
Когда вы сядете в такси, а я увижу какой id пропал из выдачи, разве я буду думать, что таксист решил вами закусить на обед?
А как можно узнать, что водитель пропал именно потому что он назначил я ко мне на заказ (именно в момент назначения он исчезает, а не подачи авто)?
Выглядит не реалистично. Но давай так, если сможешь придумать способ как отличить пропажу водителя по причине назначение на заказ от ушёл отдохнуть, с меня односолодовый смузи. Идёт?
Я вообще не понимаю такую постановку вопроса, что тут отличать-то. Рассмотрим ситуацию, если id действительно исчезают: сейчас пол второго ночи, ставлю карту с id'шками на запись. Моя жена (или муж) собирается в командировку. Вызываем такси в аэропорт и смотрим id того, кто пропал из карты — того, кто приехал к нам на вызов. Если id не исчез сразу при вызове, то провожаю и вижу как id все-таки исчез. Вопрос: что тут вообще надо отличать? Ну если еще и окажется, что такси появилось не в аэропорте, а у дома моего лучшего друга (подруги), то точно, значит, таксист пообедать к нему заехал.
Ну то есть де-факто есть вероятностная модель которая может что-то показать, а может и не показать.
Есть модель, которая может показывать раз за разом одно и тоже (в случае длительной измены). Так что сомнения в достоверности снимаются за какое-то время. Плюс к тому, есть возможность сделать сервис наподобие флайтрадара, где любой человек мог бы особо не напрягаясь пробить всякую такую информацию задним числом.
Сценарий 1 – мы знаем конечную точку:
Допустим мы магазин, концертный зал, кружок по хоровому плетению лаптей. В таком случае постоянно собирая статистику по местам «исчезновения» и появления машин мы можем выделить машины, которые появлялись у нашей геопозиции перед началом встречи/сеанса/семинара и вычислить примерные районы, в которых эти машины находились в момент бронирования. Собрав статистику за несколько месяцев, если посещаемость заведения не крошечная, получим тепловую карту местности, откуда к нам выезжают наши посетители (это может быть как место их проживания, так и место работы). Посетитель не давал нам никаких согласий, при этом мы узнали, что есть выборка из «того стрёмного коттеджного посёлка» или постоянные клиенты из компании N. Дальше с этими данными можно делать много всего.
Сценарий 2 – мы знаем примерное место и время отъезда клиента:
Конец мероприятия, камера на выходе из учреждения, недоверчивый супруг и т.п. Эти сценарии предполагают достаточно точное информирование о времени и месте вызова машины. Соответственно мы можем, основываясь на вычисленной нами плотности машин по местности, выставлять динамическое сканирование статуса машин в определённом радиусе от точки (отсекая необходимость сканировать весь город, экономя запросы и повышая дискретизацию). Записываем все «пропавшие» машины за предполагаемый период от вызова до посадки, ищем точки, в которых машины всплыли. Теперь у нас есть всего несколько вариантов того, куда человек приехал. Собираем статистику или делаем предсказания, которые сравниваем с фактическими данными.
Сценарий 3 – мы можем работать и с двух концов:
Сначала мы сработали по сценарию 1, затем мы фиксируем момент выхода и, зная собственную геопозицию, вычисляем, куда наши посетители разъехались (сценарий 2). Если мы можем идентифицировать наших посетителей, то за несколько посещений, когда кто-то был, а кого-то не было, и, сделав поправку на построение человеком шаблонов в расписании дел на неделю, мы сможем не просто составить тепловые карты, но вычислить конкретные районы откуда к нам приезжает конкретный посетитель и куда уезжает. Даже если посетителей мы не идентифицируем, это даёт вместо набора районов с вероятностью того, откуда и куда едет посетитель получить конкретные цифры и типичные маршруты. А имея типичные маршруты можно продолжать выстраивать их в обе стороны. А имея достаточно длинный маршрут можно вычислить личность человека.
Не секрет, что множество вай-фай точек используется для трекинга прохожих, посетителей и т.д. Если у нас есть к ним доступ, то это значительно уменьшит объём данных, которые необходимо собрать до однозначного вычисления конкретного человека в сценариях 2 и 3.
Допустим мы магазин, концертный зал, кружок по хоровому плетению лаптей. В таком случае постоянно собирая статистику по местам «исчезновения» и появления машин мы можем выделить машины, которые появлялись у нашей геопозиции перед началом встречи/сеанса/семинара и вычислить примерные районы, в которых эти машины находились в момент бронирования. Собрав статистику за несколько месяцев, если посещаемость заведения не крошечная, получим тепловую карту местности, откуда к нам выезжают наши посетители (это может быть как место их проживания, так и место работы). Посетитель не давал нам никаких согласий, при этом мы узнали, что есть выборка из «того стрёмного коттеджного посёлка» или постоянные клиенты из компании N. Дальше с этими данными можно делать много всего.
Сценарий 2 – мы знаем примерное место и время отъезда клиента:
Конец мероприятия, камера на выходе из учреждения, недоверчивый супруг и т.п. Эти сценарии предполагают достаточно точное информирование о времени и месте вызова машины. Соответственно мы можем, основываясь на вычисленной нами плотности машин по местности, выставлять динамическое сканирование статуса машин в определённом радиусе от точки (отсекая необходимость сканировать весь город, экономя запросы и повышая дискретизацию). Записываем все «пропавшие» машины за предполагаемый период от вызова до посадки, ищем точки, в которых машины всплыли. Теперь у нас есть всего несколько вариантов того, куда человек приехал. Собираем статистику или делаем предсказания, которые сравниваем с фактическими данными.
Сценарий 3 – мы можем работать и с двух концов:
Сначала мы сработали по сценарию 1, затем мы фиксируем момент выхода и, зная собственную геопозицию, вычисляем, куда наши посетители разъехались (сценарий 2). Если мы можем идентифицировать наших посетителей, то за несколько посещений, когда кто-то был, а кого-то не было, и, сделав поправку на построение человеком шаблонов в расписании дел на неделю, мы сможем не просто составить тепловые карты, но вычислить конкретные районы откуда к нам приезжает конкретный посетитель и куда уезжает. Даже если посетителей мы не идентифицируем, это даёт вместо набора районов с вероятностью того, откуда и куда едет посетитель получить конкретные цифры и типичные маршруты. А имея типичные маршруты можно продолжать выстраивать их в обе стороны. А имея достаточно длинный маршрут можно вычислить личность человека.
Не секрет, что множество вай-фай точек используется для трекинга прохожих, посетителей и т.д. Если у нас есть к ним доступ, то это значительно уменьшит объём данных, которые необходимо собрать до однозначного вычисления конкретного человека в сценариях 2 и 3.
Знаете, все правильно пишете. И это является как бы не совсем санкционированный способом применять API. Насколько я понимаю, его натянуть на взлом и нарушение работы информационных систем не получится, но вот по собранным данным сделать какие-то интересные выводы (Вы сами написали как) — можно. Решение для ситимобила — очевидно — закрывать, ограничивать доступ к апихе.
Но вообще я про другое хотел написать. Люди сами добровольно сдают свои данные, включая данные о координатах, о своем образе жизни куче других сервисов. Например, забежал ты на обеде в рабочий день в кафешку, и сфотался в 4square или Инстаграме. Все. Готово. Можно немного посоцинженерить и найти все (
Но вообще я про другое хотел написать. Люди сами добровольно сдают свои данные, включая данные о координатах, о своем образе жизни куче других сервисов. Например, забежал ты на обеде в рабочий день в кафешку, и сфотался в 4square или Инстаграме. Все. Готово. Можно немного посоцинженерить и найти все (
В данном случае пользователи осознанно или небрежно не предоставляли свои данные третьим лицам. Но из-за особенностей работы сервиса, которые создали сами разработчики, третьи лица могут собрать набор данных, который в определённый момент количественного роста приведёт к качественному скачку и позволит получить персональные данные. И даже в случае, если до персонализации не дойдёт — возможны иные нежелательные последствия (пример с ассоциацией с компаниями, учреждениями, особыми местами проживания).
При этом ситимобил по какой-то причине упорно делают хорошую мину.
При этом ситимобил по какой-то причине упорно делают хорошую мину.
Машина становится исчезает не когда посадила клиента, а когда приняла заказ. ТО есть в радиусе пары километров от точки посадки. Выборка усложняется.
С место высадки также, я так пониманию можно увидеть точное место высадки, при условии, что водитель не успел схватить новый заказ в пути, от этого же или другого агрегатора. Там можно только гадать как это работает. Т.е. точек то много, можно какую-то статистику пособирать наверно, но конкретного Васю вычислить сложно.
С место высадки также, я так пониманию можно увидеть точное место высадки, при условии, что водитель не успел схватить новый заказ в пути, от этого же или другого агрегатора. Там можно только гадать как это работает. Т.е. точек то много, можно какую-то статистику пособирать наверно, но конкретного Васю вычислить сложно.
Может быть сложно сделать систему, которая даст результат в 100 случаях из ста, но то, что система дает возможность в каком-то случае успешно провести слежку — с этим не поспоришь. Может быть не днем на Красной площади, но ночью в частном секторе — запросто.
Вы бы лучше подумали вот о чем. Очевидно, что все сервисы такси внутри себя содержат информацию о:
— перемещении клиента
— информацию о формах оплаты
Это все можно посмотреть в приложении. Значит, есть апишка, которая позволяет это вытащить. Очень интересно было бы на нее посмотреть и понять насколько она надёжно и/или безопасно написана. А вдруг в ней дыры и можно подсмотреть данные другого клиента )
Хотя о чем это я. Наверняка, если там дыры, то они уже кем-то активно эксплуатируются втихую и статьи на хабр не будет.
А ещё интересный вопрос — можно ли провести атаку вида — вводим чужой аккаунт, а потом угадываем код подтверждения — у нас же по сути только один фактор для входа в приложение — это или смс при первоначальной регистрации (от 4 до 6 псевдорандомных цифр) до токена, который сохраняется в самом приложении на телефоне «насовсем». И, да, все эти программы позволяют работу с нескольких телефонов. По крайней мере как я помню. И как снести программу удаленно, если телефон, например, украли?
— перемещении клиента
— информацию о формах оплаты
Это все можно посмотреть в приложении. Значит, есть апишка, которая позволяет это вытащить. Очень интересно было бы на нее посмотреть и понять насколько она надёжно и/или безопасно написана. А вдруг в ней дыры и можно подсмотреть данные другого клиента )
Хотя о чем это я. Наверняка, если там дыры, то они уже кем-то активно эксплуатируются втихую и статьи на хабр не будет.
А ещё интересный вопрос — можно ли провести атаку вида — вводим чужой аккаунт, а потом угадываем код подтверждения — у нас же по сути только один фактор для входа в приложение — это или смс при первоначальной регистрации (от 4 до 6 псевдорандомных цифр) до токена, который сохраняется в самом приложении на телефоне «насовсем». И, да, все эти программы позволяют работу с нескольких телефонов. По крайней мере как я помню. И как снести программу удаленно, если телефон, например, украли?
Сейчас был на почте, оказалось, что у них и программы нет, которую надо сносить. Придя с ворованной сим-картой, можно получать посылки без паспорта.
Только при условии, что Вы сами подписались на «упрощенный способ» получения почтовых отправлений. Вроде бы если нет этого — только по паспорту, по старинке.
Я уж не говорю о том — откуда возьмется ворованная сим-карта.
Я уж не говорю о том — откуда возьмется ворованная сим-карта.
Программу такси удалять надо тоже только, если сам ее установил и сам в нее банковскую карточку прописал. А ворованная симка из ворованного телефона, «если телефон, например, украли».
Почта почти насильно переводит всех на получение по смс. А иногда даже и просто молча и не спрашивая — был свидетелем. Если вы хотите получать по паспорту, вам придется регулярно и очень настойчиво отказываться.
а не надо даже ничего воровать. У меня жена получала мою посылку сказав СВОЙ номер телефона для получения кодика. То есть их ПО в принципе не матчит номер телефона для кодика и номер телефона, на который привязана посылка. Сначала меня удивляло зачем они спрашивают номер телефона, если он скорее всего есть в базе, потом подумал, что может защита от сотрудников почты, чтобы не спамили отправляя смс, то есть если введенный номер не совпал с хранящимся в БД, смс не уйдет. Но нет! Можно ввести любой номер телефона и на него придет кодик. То есть по факту сотрудники почты могут получать посылки на себя или на левые симки.
На почте можно с любой сим картой получать посылку без паспорта если у нее «Упрощенный способ»
У неё, у посылки или у неё, у сим карты?
Или теперь уже с любыми номерами на любое имя можно получать и заявления не нужны?
Или теперь уже с любыми номерами на любое имя можно получать и заявления не нужны?
Провёл эксперимент, на посылке номер не тот, который привязывал к своему паспорту. При получении назвал его, в базе он не нашёлся, предложили назвать ещё раз, с обычным номером выдали (правда был и казус, вначале меня спросили, оканчивается ли мой номер на хх-хх, и это не был ни один из двух моих номеров...)
НЛО прилетело и опубликовало эту надпись здесь
Оставлю тут.
Читал про возможности защититься шифрованием того что клиент все равно должен прочитать.
Ади Шамир (Adi Shamir), один из создателей RSA.
Первый закон Шамира гласит: систем с абсолютной безопасностью не существует и никогда не будет существовать.
Второй закон Шамира гласит: криптографию не сломают, ее обойдут.
Шамир — устранить все возможные уязвимости в конкретной программе ныне так же бессмысленны, как и 30 лет назад.
Возможно лучшее из того что уже писали, это подкрутить само общение клиента и сервера. Без усложнения логики, и без наворотов вроде отслеживания брутов и ложных блокировок.
Читал про возможности защититься шифрованием того что клиент все равно должен прочитать.
Ади Шамир (Adi Shamir), один из создателей RSA.
Первый закон Шамира гласит: систем с абсолютной безопасностью не существует и никогда не будет существовать.
Второй закон Шамира гласит: криптографию не сломают, ее обойдут.
Шамир — устранить все возможные уязвимости в конкретной программе ныне так же бессмысленны, как и 30 лет назад.
Возможно лучшее из того что уже писали, это подкрутить само общение клиента и сервера. Без усложнения логики, и без наворотов вроде отслеживания брутов и ложных блокировок.
А еще у Ситимобила худшее в Москве управление качеством сервиса — их машины неоднократно игнорируют пешеходные переходы/красный свет, а в ответ поддержка по телефону говорит «ну, пишите жалобу в полицию». Ты же Я.Такси обрабатывают и реагируют по таким заявкам с сайта.
Так, хорошо, разобрались, все машины можно посмотреть. А как с тем, чтобы попробовать создать заказы для всех машин одновременно?
вот эти ситуации, когда какие-то данные можно получить подсмотрев запросы — они ну очень распространенные на самом деле
а вот что за такое можно получать вознаграждение по bugbounty — надо запомнить
ну и визуализация, да, красиво :)
а вот что за такое можно получать вознаграждение по bugbounty — надо запомнить
ну и визуализация, да, красиво :)
Авторизация, сессии — нет не слышали. По моему только приложение должно иметь туда доступ.
И? Берём сессию приложения и получаем точно такой-же результат. Вопрос не в сессии, а об ограничении потоковых запросов
А что мешает с приложения ключи стянуть?
Варианты "пусть только приложение может делать запросы" просто заканчиваются эмуляцией либо извлечением ключей из бинаря.
Я не специалист по ИБ, но без деградации функционала в голову только рейт лимиты и анализ активности приходят, но от кучки проксей это тоже мало поможет.
НЛО прилетело и опубликовало эту надпись здесь
Как я нашел способ отследить всех водителей «Ситимобил»
А я нашёл способ отследить где живёт автор статьи по КДПВ. )
НЛО прилетело и опубликовало эту надпись здесь
Uber показывает позиции машин, так оно выглядит как по мне более наглядно, чем просто информация о радиусе. Показывается даже как машина едет от своего исходного положения к заказчику. Но что-то я сомневаюсь, что там можно собрать инфу со всех машин в сети, как это удалось автору.
Показывать только количество на этапе предзаказа — вполне разумный вариант, т.к. пользователю важно знать только факт возможности заказа и как далеко от него ближайшая машина. А вот когда пользователь заказал подачу, то конкретную машину можно и на карте вывести.
НЛО прилетело и опубликовало эту надпись здесь
Вначале, до того, как заказчик выбрал машину, показываются несколько ближайших машин на карте. Заказчик может кликнуть или на любую машину на карте, или на списке машин внизу. Когда заказчик сделал заказ, остальные машины исчезают и показывается только заказанная машина, а также путь, по которому она едет к заказчику.
НЛО прилетело и опубликовало эту надпись здесь
Я думаю, всё упирается в маркетинг и в экономическую целесообразность. Uber уже много лет этим занимается, скорее всего проведены все А/В тесты на то, где и как показывать и дублировать информацию, чтобы получить максимальную прибыль.
Непонятно, зачем передавать ID машины
Например, подойти поближе, что бы таксист пять минут не заезжал на улочку или перейти на другую сторону дороги. Опять-таки расчет времени прибытия машины весьма приблизительный, информация о пробках тоже, а тут я вижу состояние пробки и иногда понимаю, что с той улочки ему выезжать минут 15, а не 3 как показывает приложение и еду на метро.
Очень круто и информативно) Респект)
я считаю если б не
то такой картины не было=)
mail.ru позволяет мне делать все несколько тысяч запросов за минуту с одного и того же ip.
то такой картины не было=)
Попробовал протестировал. Отправил координаты центра Новосибирска:
В ответ получил данные из нижегородской области:
В чем причина?
{
"latitude": 55.028637,
"longitude": 82.922220,
"limit": 2,
"method": "getdrivers",
"radius": 5,
"tariff_group": [ 4, 5, 6 ],
"ver": "4.33.0"
}
В ответ получил данные из нижегородской области:
{
"drivers": [
{
"id": "2c03db966034e740b6517a098a1b5aca",
"lt": 55.2269635,
"ln": 45.0146678,
"direction": 7,
"CarColorCode": "000000",
"car_type": "comfort"
},
{
"id": "07d7bf42c10b84a3b5931bf0f9cf0024",
"lt": 55.3375673,
"ln": 37.5548681,
"direction": 7,
"CarColorCode": "000000",
"car_type": "sedan"
}
],
"service_status": 1,
"nearest": {
"duration": 359
}
}В чем причина?
НЛО прилетело и опубликовало эту надпись здесь
Да, я тоже проверил и нашел тоже самое для сервиса в своем населенном пункте.
Самое забавное, что сам сервис — это аутсорс, который предоставляет приложение для диспетчера/таксиста/клиента за фиксированную цену в месяц. И работает он в России, Украине, Белоруссии и т.д.
Самое забавное, что сам сервис — это аутсорс, который предоставляет приложение для диспетчера/таксиста/клиента за фиксированную цену в месяц. И работает он в России, Украине, Белоруссии и т.д.
Смотрите: с точки зрения маркетинга пользователю показывать кнопку «регистрация» лучше всего не на первом экране приложения, а где-то там где он уже собрался купить услугу.
С точки зрения пользователя следующая за таких подходом кнопка будет «удалить приложение».
Или я могу заказать «без регистрации и смс» (хотя бы раз), либо мне нужно регистрироваться, всё остальное начинает вызывать подозрение что операторам не на чем больше зарабатывать, со всеми вытекающими.
Но даже в этом случае, можно ограничить информацию — не показывать точное положение машин на карте, таким образом ничего не раскрывая, или не показывать их вообще, ограничившись более общей информацией (в духе «в радиусе 3 кварталов от вас более 20 свободных машин»).
В конце концов, когда человек заказывает такси просто по телефону, у него не требуют регистрации, и даже карту не показывают, не говоря уже о машинах в его районе — и ничего, работает прекрасно.
Если установить ограничения на скачку на IP то пострадают пользователи мобильных сетей (их операторы пускают через небольшие пулы IP).
Какова вероятность что одновременно хотя бы несколько десятков пользователей в одной мобильной сети в одном пуле (т.е. примерно рядом друг с другом) воспользуются приложением в первый раз?
Впрочем, даже это решается элементарно — информация о положении банально кэшируются, и все запросы в течение 30 секунд получат одинаковый ответ. В конце концов, точное положение машин совершенно неважно, и готов поспорить что если специально не копать то никто ничего не заметит при таком подходе, и на качестве услуг это тоже не скажется.
Вот пример с наркотиками, находим тех кто работают физически дольше чем нормальный человек продолжительное время, смотрим за такими водителями и вуаля ниточка к наркотрафика приоткрыта
Что то зачастили со снифингом траффика такси, хорошо хоть у Сити мобил нельзя по апи оплачивать без авторизации, а то автор прецедент бы создал на много серьезнее.
Сертификаты в приложениях лучше запинивать — это поднимает планку для перехвата трафика.
Напоминает поиск покимонов в Pokimon Go.
3apa3a знакомый ник, похоже с cracklab :)
О еще были статьи от Ms-Rem и wasm ru — лучшее время.
У mail.ru бывают серьезные баги. Я находил баг в vk, можно было узнать какую рекламу показывают любому пользователю вк.
3apa3a знакомый ник, похоже с cracklab :)
О еще были статьи от Ms-Rem и wasm ru — лучшее время.
У mail.ru бывают серьезные баги. Я находил баг в vk, можно было узнать какую рекламу показывают любому пользователю вк.
А реально(насколько сложно) получить стоимость заказа из точки А в точку В? А то надоело руками проверять :)
СравниТакси? Приложение для телефонов. Или надо программно?
Было бы круто программно, чтобы самому поиграться.
Я обычно использую sslsplit. Вот что сходу нашлось. Для других сервисов думаю можно найти аналогично.
Заголовок спойлера
curl -d '{"skip_estimated_waiting":false,"estimate_waiting_selected_only":false,"summary_version":2,"supports_paid_options":true,"supports_hideable_tariffs":true,"with_title":true,"format_currency":true,"parks":[],"supports_explicit_antisurge":true,"id":"0000000000000000000000000","size_hint":240,"payment":{"type":"card","payment_method_id":"cash"},"selected_class":"econom","route":[[30.33606681550002,59.936871546400001],[30.4992504,59.8971657]],"selected_class_only":false,"position_accuracy":0,"suggest_alternatives":true,"supports_multiclass":true,"zone_name":"spb","supported_markup":"tml-0.1","supports_no_cars_available":true,"tariff_requirements":[{"class":"econom","requirements":{}},{"class":"business","requirements":{}},{"class":"comfortplus","requirements":{}},{"class":"vip","requirements":{}},{"class":"ultimate","requirements":{}},{"class":"maybach","requirements":{}},{"class":"minivan","requirements":{}},{"class":"child_tariff","requirements":{}},{"class":"mkk_antifraud","requirements":{}},{"class":"cargo","requirements":{}},{"class":"express","requirements":{}}],"extended_description":true,"requirements":{}}' -XPOST 'https://tc.mobile.yandex.net/3.0/routestats?block_id=default' -H 'Content-Type: application/json; charset=utf-8'есть апи у яндекс такси для получения стоимости
Помню в компании, где я работал делали защиту от такого скрейпинга для какой-то геолокационной игры:
— аккаунт привязан к телефону
— запросы API с токеном пользователя
— можно рассчитать расстояние между координатами запросов, и если пользователь «двигается слишком быстро» — банить его на 10 минут
— аккаунт привязан к телефону
— запросы API с токеном пользователя
— можно рассчитать расстояние между координатами запросов, и если пользователь «двигается слишком быстро» — банить его на 10 минут
Как-то год назад заказывал такси в области, нашел для этого приложение от компании, которая клепает приложения для различных таксопарков и компаний десятками. Один API на всех, одна общая проблема — четырехзначный код из СМС, отсутствие защиты от брутфорса. Отдельно забавно то, что сначала можно определить существующих клиентов, потом подобрать код к каждому аккаунту. А там привязанные карты, история поездок, бонусы и корпоративное такси. Потом мне рассказали о схожей проблеме с доступом в интерфейс админа и диспетчера, довольно весело. И на письма они решили не отвечать.
А зачем вообще пользователю показывать машины рядом? Он всё равно не может назначить себе конкретную машину.
Давайте показывать только ту, которую система назначила пассажиру, и проблема решена.
Давайте показывать только ту, которую система назначила пассажиру, и проблема решена.
Впервые проявил активность и сразу насрали в карму. Следующую статью предлагаю написать про яндекс такси с предложением парсить их представителям Ситимобил. Точно такой же запрос без авторизации. Точно так же возвращаются ид машин. Рейтлимит не проверял, скорее всего его нет.
curl -d '{"simplify":true,"classes":["econom"],"id":"000000000000000000000000000000","point":[30.33606681550002,59.936871546400001],"supported":["code_dispatch"],"full_adjust_task":true,"current_drivers":[]}' -XPOST 'https://tc.mobile.yandex.net/3.0/nearestdrivers?block_id=default' -H 'Content-Type: application/json; charset=utf-8'ответ
{
"drivers": [
{
"display_tariff": "econom",
"free": true,
"id": "2669ba69328b74a733f34aca3e87098f",
"positions": [
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:42.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:41.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:37.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:36.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:33.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:31.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:30.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:29.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:27.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:26.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:23.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:21.000000+0000"
},
{
"direction": 7.0,
"lat": 59.938283,
"lon": 30.336619,
"timestamp": "2019-12-19T15:06:19.000000+0000"
}
]
},
{
"display_tariff": "econom",
"free": true,
"id": "96a7724ac3666322272512aa2d914f89",
"positions": [
{
"direction": 282.0,
"lat": 59.937850999999995,
"lon": 30.331927,
"timestamp": "2019-12-19T15:06:44.000000+0000"
},
{
"direction": 282.0,
"lat": 59.937850999999995,
"lon": 30.331927,
"timestamp": "2019-12-19T15:06:35.000000+0000"
},
{
"direction": 282.0,
"lat": 59.937850999999995,
"lon": 30.331927,
"timestamp": "2019-12-19T15:06:27.000000+0000"
},
{
"direction": 282.0,
"lat": 59.937850999999995,
"lon": 30.331927,
"timestamp": "2019-12-19T15:06:19.000000+0000"
}
]
},
{
"display_tariff": "business",
"free": true,
"id": "6c5a49546c1c369269e3e441992a063a",
"positions": [
{
"direction": 184.0,
"lat": 59.936082,
"lon": 30.341468,
"timestamp": "2019-12-19T15:06:48.000000+0000"
},
{
"direction": 184.0,
"lat": 59.936249999999994,
"lon": 30.341492,
"timestamp": "2019-12-19T15:06:38.000000+0000"
}
]
},
{
"display_tariff": "econom",
"free": true,
"id": "462341153693937e3089e3f9986eccdf",
"positions": [
{
"direction": 198.0,
"lat": 59.935739999999996,
"lon": 30.341271,
"timestamp": "2019-12-19T15:06:41.000000+0000"
},
{
"direction": 260.0,
"lat": 59.935984999999995,
"lon": 30.341431,
"timestamp": "2019-12-19T15:06:31.000000+0000"
},
{
"direction": 174.0,
"lat": 59.936065,
"lon": 30.341400999999998,
"timestamp": "2019-12-19T15:06:17.000000+0000"
}
]
},
{
"display_tariff": "econom",
"free": true,
"id": "6d6004d783a6b1ceb4eb1ee79986127f",
"positions": [
{
"direction": 0.0,
"lat": 59.936989,
"lon": 30.330199999999998,
"timestamp": "2019-12-19T15:06:44.000000+0000"
},
{
"direction": 0.0,
"lat": 59.937002,
"lon": 30.330174,
"timestamp": "2019-12-19T15:06:36.000000+0000"
}
]
},
{
"display_tariff": "business",
"free": true,
"id": "4f3240e25b5b3755020ff4acf795a52c",
"positions": [
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:43.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:36.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:33.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:32.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:29.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:26.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:25.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:23.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:22.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:19.000000+0000"
},
{
"direction": 174.0,
"lat": 59.937272,
"lon": 30.330042,
"timestamp": "2019-12-19T15:06:17.000000+0000"
}
]
},
{
"display_tariff": "comfortplus",
"free": true,
"id": "9c130b08a5a03f252e7d38639fbf1b80",
"positions": [
{
"direction": 224.0,
"lat": 59.937495999999996,
"lon": 30.32998,
"timestamp": "2019-12-19T15:06:48.000000+0000"
},
{
"direction": 224.0,
"lat": 59.937495999999996,
"lon": 30.32998,
"timestamp": "2019-12-19T15:06:31.000000+0000"
}
]
},
{
"display_tariff": "econom",
"free": true,
"id": "1cfbd787a81806c0cbe76b6d6ff53965",
"positions": [
{
"direction": 189.0,
"lat": 59.937428999999995,
"lon": 30.330049,
"timestamp": "2019-12-19T15:06:42.000000+0000"
},
{
"direction": 189.0,
"lat": 59.937428999999995,
"lon": 30.330049,
"timestamp": "2019-12-19T15:06:33.000000+0000"
},
{
"direction": 189.0,
"lat": 59.937428999999995,
"lon": 30.330049,
"timestamp": "2019-12-19T15:06:25.000000+0000"
},
{
"direction": 189.0,
"lat": 59.937428999999995,
"lon": 30.330049,
"timestamp": "2019-12-19T15:06:17.000000+0000"
}
]
},
{
"display_tariff": "econom",
"free": true,
"id": "552f58f744ad5655b13e1039da0934b5",
"positions": [
{
"direction": 103.0,
"lat": 59.934892999999995,
"lon": 30.329645,
"timestamp": "2019-12-19T15:06:33.000000+0000"
},
{
"direction": 103.0,
"lat": 59.934942,
"lon": 30.32924,
"timestamp": "2019-12-19T15:06:16.000000+0000"
}
]
},
{
"display_tariff": "econom",
"free": true,
"id": "8e06bb9ae835176c2f38aa8e380cc1df",
"positions": [
{
"direction": 104.0,
"lat": 59.93367,
"lon": 30.339648999999998,
"timestamp": "2019-12-19T15:06:47.000000+0000"
},
{
"direction": 104.0,
"lat": 59.93367,
"lon": 30.339648999999998,
"timestamp": "2019-12-19T15:06:42.000000+0000"
},
{
"direction": 104.0,
"lat": 59.933792,
"lon": 30.338673999999997,
"timestamp": "2019-12-19T15:06:33.000000+0000"
}
]
}
]
}После чего пишем статью про gmail, они неправильно настроили spf+dmarc
~all — разрешает подделывать адреса отправителей, т.е. любой может написать от вашего адреса почты. DMARC политика установлена в none что также разрешает всякие непотребства. Ждем)
Заголовок спойлера
dig -t txt _spf.google.com +short
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
dig -t txt _dmarc.gmail.com +short
"v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
Хочу добавить: это не критика автора статьи, статья очень крутая, я восхищен анимацией, собранной статистикой и слогом. Больше тут недоумение реакцией и критикой сервиса такси. Каммон, это действительно не та информация, которую стоит как-то сильно защищать.
Почитал бы статью про gmail. Т.к. используется как корпоративная…
особенно по поводу момента
особенно по поводу момента
т.е. любой может написать от вашего адреса почты.
Статью не обещаю. Напишу только что
1) если почта корпоративная — все записи dkim+spf+dmarc настраивает ваш админ на вашем домене. И он волен крутить ручки как угодно. Другое дело что строгие правила редко где нужны. (Лучше пусть кто-то напишет от вашего имени чем письмо не дойдет).
2) у гугла так сделано потому что если сделать более строгие требования есть большие шансы что поломается почта у тех кто пользуется пересылкой (а вы не хотите чтобы ваша почта терялась)
Видимо гугл на домене gmail уповает на другие механизмы защиты от спама.
О и правда! Спасибо. Можно и на водил я.такси посмотреть. Странно, что автор это проигнорировал, с двумя агрегаторами вышло бы интереснее)
Вроде грамотный человек, а пишет (как и многие написали бы): «Информацию о 10 ближайших водителях к геопозиции можно получить...», когда по правилам русского языка надо писать «Информацию о 10 ближайших к геопозиции водителях можно получить...» Спросите, какая разница? Для вас – никакой.
Давно с таким удовольствием не читал комментарии.
Достаточно убрать ID авто из ответа, или заменить его на 1..n., и проблема перестанет существовать.
Displaying information about cars close to user
Чем больше живу в IT и особенно безопасности, тем больше понимаю, что IT — гуманитарная наука, где-то в районе философии. И плавно переходящая в магию.
Для простого человека полностью понятно, что такое «информация о машинах близких к пользователю». Для IT-безопасника сразу вопросы:
1. Что такое пользователь, как мы их определяем-проверяем
2. Что такое информация о машинах? Например, если первым вызовом мы узнаем о 10 машинах, а следующими — по каждой из найденных машин, узнаем ФИО водителя, его заработок за последнюю неделю, его переписку с поддержкой… А просто график его работы (его автомобиля) узнать? Если график узнавать нельзя — то как быть с тем, что график можно самому нарисовать, если круглые сутки запрашивать информацию?
3. Что такое «близкий»? Каков радиус и как он может меняться?
4. Что такое точка (где пользователь). Как она определяется, насколько надежна. Что если пользователь просто подсунет данные как в статье? Допустимо ли для точки перемещаться, чтобы сейчас точка была там, а через 10 секунд — уже в 20км оттуда? Допустимо ли пользователя за минуту «пропутешествовать» весь большой город и снять данные отовсюду?
Чем больше живу в IT и особенно безопасности, тем больше понимаю, что IT — гуманитарная наука, где-то в районе философии. И плавно переходящая в магию.
Для простого человека полностью понятно, что такое «информация о машинах близких к пользователю». Для IT-безопасника сразу вопросы:
1. Что такое пользователь, как мы их определяем-проверяем
2. Что такое информация о машинах? Например, если первым вызовом мы узнаем о 10 машинах, а следующими — по каждой из найденных машин, узнаем ФИО водителя, его заработок за последнюю неделю, его переписку с поддержкой… А просто график его работы (его автомобиля) узнать? Если график узнавать нельзя — то как быть с тем, что график можно самому нарисовать, если круглые сутки запрашивать информацию?
3. Что такое «близкий»? Каков радиус и как он может меняться?
4. Что такое точка (где пользователь). Как она определяется, насколько надежна. Что если пользователь просто подсунет данные как в статье? Допустимо ли для точки перемещаться, чтобы сейчас точка была там, а через 10 секунд — уже в 20км оттуда? Допустимо ли пользователя за минуту «пропутешествовать» весь большой город и снять данные отовсюду?
Интересно, это кто-то еще нашел альтернативное применение API, или так, просто совпадение?
Вы, наверняка, в курсе, что у Ситика были серьезные проблемы в пятницу. Пошла странная волна фейковых заказов за наличку, подъезжаешь, никто не выходит, отменяешь, получаешь блок. Вечер пятницы, машин нет, коэффициенты улетели в стратосферу. Сам «Сити» ничего не комментирует, операторы колл-центров, до которых почти невозможно было дозвониться из-за больших очередей, отделываются стандартными отговорками. Судя по всему, Яшка решил поддавить конкурента в жирные предновогодние дни. Интересно, Сити на этой неделе придумают что-то или опять лягут?
Как я нашел способ отследить всех водителей «Ситимобил»