Это был запрос на получение информации о ближайших машинах. Выполнив этот запрос несколько раз с разными параметрами я понял, что можно выгружать данные о таксистах практически в реалтайме. Вы только представьте, сколько интересного можно теперь узнать!
С чего все началось?
Да, я действительно сидел и смотрел трафик с телефона. Дело в том, что я инженер, и постоянно изучаю, как работают технологии и разные вещи вокруг меня. Так было и в этот раз.
Я использовал mitmproxy (Man In The Middle Proxy) — программа для атаки «человек посередине». Есть много инструкций по её установке и настройке, а общий принцип такой:
- Подключаешься к домашнему WiFi с телефона и компьютера
- Запускаешь mitmproxy на компьютере
- В телефоне прописываешь локальный адрес компьютера как основной прокси (уже можно смотреть внутрь http)
- Скачиваешь и подтверждаешь сертификат на телефоне (позволяет заглядывать внутрь https)
Теперь, грубо говоря, весь трафик с телефона идет сначала на компьютер, расшифровывается, показывается на экране, зашифровывается и идет дальше. И наоборот.
Таким способом я изучаю, как сделаны разные приложения, а иногда нахожу очень интересные вещи. Например, в этот раз я увидел запрос от приложения «Ситимобил» на получение информации о ближайших водителях, который не требовал аутентификации.
Bug bounty Mail.ru
Я оформил всю информацию на hackerone и отправил на рассмотрение. После опыта взаимодействия с баг баунти Яндекса, я не рассчитывал на быстрый ответ, однако уже через 3 минуты некто «3apa3a» закрыл мой репорт. Отличная скорость, Mail.ru!
В ответе написали, что данные показываются пользователю в приложении, а значит не являются чувствительными и защищать их не надо.
Ну что ж. Раз это публичные данные, давайте развлекаться!
Как получить данные?
Информацию о 10 ближайших водителях к геопозиции можно получить, отправив POST запрос на следующий адрес:
https://c-api.city-mobil.ru/getdriversПри этом в теле запроса нужно указать интуитивно-понятные параметры:
{
"latitude": LAT,
"longitude": LON,
"limit": 10,
"method": "getdrivers",
"radius": 5,
"tariff_group": [ 4, 5, 6 ],
"ver": "4.33.0"
}Здесь tariff_group — массив классов авто. Например, эконом, комфорт, бизнес и т.п.
При этом поля radius и limit не работают, как надо, но и убрать их нельзя.
В итоге, запрос на получение информации можно отправить просто из командной строки:
curl -X POST --data '{ "latitude": 55.7, "limit": 10, "longitude": 37.6, "method": "getdrivers", "radius": 5, "tariff_group": [4], "ver": "4.33.0" }' https://c-api.city-mobil.ru/getdriversВ ответ приходит JSON с данными о 10 ближайших к (LAT, LON) автомобилях:
{
"drivers":[
{
"id":"1c1f6779f893af6fe5bf4509af7366cd",
"lt":"55.7025061",
"ln":"37.5954334",
"direction":"3",
"CarColorCode":"000000",
"car_type":"comfort_plus"
},
{
"id":"1a13d0daad9b6a3fa2b3d04a5b6f8c2a",
"lt":"55.7019682",
"ln":"37.6054896",
"direction":"3",
"CarColorCode":"000000",
"car_type":"comfort"
},
{
"id":"c7c1634fae41a68924083af1d496d0a7",
"lt":"55.7014223",
"ln":"37.6067352",
"direction":"3",
"CarColorCode":"000000",
"car_type":"comfort_plus"
},
{
"id":"f15ce054ccdaa268b16a0904b9eecdae",
"lt":"55.6956527",
"ln":"37.5972063",
"direction":"4",
"CarColorCode":"000000",
"car_type":"sedan"
},
{
"id":"94ebc0fcc644bb1da4b57e7d23942e6d",
"lt":"55.694786",
"ln":"37.5982642",
"direction":"4",
"CarColorCode":"000000",
"car_type":"sedan"
},
{
"id":"7251c45ee945c9cb839d69d5902b9f17",
"lt":"55.7009351",
"ln":"37.6094206",
"direction":"3",
"CarColorCode":"000000",
"car_type":"comfort"
},
{
"id":"cb9dab2ba7379c3db817dd76ec68e6c5",
"lt":"55.6950137",
"ln":"37.6041883",
"direction":"8",
"CarColorCode":"000000",
"car_type":"sedan"
},
{
"id":"761891d9c1129b1678c3eba616249e2b",
"lt":"55.6944542",
"ln":"37.5951122",
"direction":"2",
"CarColorCode":"000000",
"car_type":"sedan"
},
{
"id":"4f0e835751cadaa5d5386f0e1374f315",
"lt":"55.7066516",
"ln":"37.6011767",
"direction":"7",
"CarColorCode":"000000",
"car_type":"sedan"
},
{
"id":"2eb330cad5e5d9c87e6d0600a9ff10e8",
"lt":"55.7066801",
"ln":"37.6009127",
"direction":"8",
"CarColorCode":"000000",
"car_type":"comfort"
}
],
"nearest":{
"duration":420
},
"service_status":1
}
Посмотрим, что тут у нас
{
"id":"2eb330cad5e5d9c87e6d0600a9ff10e8",
"lt":"55.7066801",
"ln":"37.6009127",
"direction":"8",
"CarColorCode":"000000",
"car_type":"comfort"
}
Идентификатор, широта, долгота, код направления (Северо-запад), код цвета и тип авто. Отлично!
Нужно больше данных!
Так как поля лимит и радиус в запросе игнорируются, а в ответ возвращается не больше 10 ближайших авто, нельзя так просто взять и выбрать N точек на Москву, чтобы за N запросов получить всю информацию об автопарке.
Но решение есть. Я написал алгоритм, похожий на заливку, который запускает запросы на поиск с координатами водителей, найденных на прошлом этапе. Ещё я все это дело распараллелил, а прокси подключать не пришлось — mail.ru позволяет мне делать все несколько тысяч запросов за минуту с одного и того же ip.
В результате за пару десятков секунд собирается информация о всех таксистах «Ситимобил», которые сейчас на линии в Москве и Московской области. Именно так получается гифка из начала статьи.
Думаете, сколько водителей на линии в воскресенье утром?
В 11 утра их было 4374
Но разве нас интересует срез? Давайте посмотрим в динамике.
Найс. А как эти водители распределены в пространстве?
Ну и напоследок давайте проследим за каким-нибудь водителем.
Вот, видно маршрут. А ведь можно еще поднять частоту опроса и получить более точные данные.
И что такого?
А то, что данные вроде как важные.
Во-первых, можно оценить долю рынка и доходность компании «Ситимобил».
Во-вторых, на месте другого агрегатора (например, Яндекс.Такси) я бы использовал данные о положении таксистов конкурентов. Для ценообразования, например. Или вычислил водителей, работающих и там, и там на основе корреляций в геопозициях.
В-третьих, раз можно отследить конкретного таксиста, можно отследить и его клиента. Это уже серьёзно. По факту, можно узнать, куда уехал человек на «Ситимобиле», если вы знаете, где он сел в такси.
Заключение
Не нужно недооценивать важность данных, которые показываются клиенту.
Если Mail.ru все еще считают, что эту информацию не нужно защищать, то Яндекс.Такси, вот вам гора данных. С её помощью вы сможете забрать часть прибыли Ситимобила.
Если же Mail.ru признаёт, что данные чувствительные и закрывает к ним доступ, то будет честно выплатить вознаграждение по bug bounty.
Как ещё можно использовать данные о таксистах по вашему мнению?
Спасибо, что дочитали! Надеюсь, вам было интересно.
Успехов!
Комментарии (280)
Victor_koly
18.12.2019 17:32Но, в теории, при параметре «radius»: 5 может получиться существенно меньше 10 водителей? И вообще, может оказаться такое хитрое распределение машин, что в какой-то момент поиск оборвется — в радиусе 5 (км?) от каждого предыдущего водителя не будет найдено ни одного нового, но какие-то машины не попадут в массив?
Krupnikas Автор
18.12.2019 17:37+6Да, действительно такое может быть. Если в Яндекс.Такси будут делать промышленное решение, то пусть учтут)
mixeden
18.12.2019 18:17Крутая дыра, интересно, через сколько исправят.
tbl
18.12.2019 18:22Думаю, что Zaraza уже получил волшебный пендаль за то, что закрыл репорт без разбора.
pin2t
18.12.2019 20:35+9Наоборот, премию за быстрый разбор тикета. Он же написал вполне аргументированно, почему они не считают это дырой.
tbl
19.12.2019 02:52Тогда это зависит от желания левой пятки руководителя саппорта. И если этому руководителю прилетит посильнее от того, кто повыше, то настроение левой пятки будет испорчено настолько, что он не будет прикрывать своего подчиненного.
DMGarikk
18.12.2019 18:24забавно то что это судя по всему может быть очень непросто
mixeden
18.12.2019 18:48+3Вообще я даже не знаю, можно ли это закрыть, и, если закрыть, изменит ли это хоть что-то. По примеру вк у них токены, скорее всего, живущие вечно. То есть если они сделают этот метод доступным только авторизованным пользователям, никто не мешает этим авторизованным пользователям взять токен и шуровать запросы.
Разве что можно сделать какой-то фильтр запросов (типа если с одного пользователя спрашиваются координаты водителей в 100 разных местах — это несколько странно).sshikov
18.12.2019 19:13+2Ну, остальные же забанили подобные запросы (например, попробуйте закинуть в гугль больше чем положено запросов геокодирования — вас забанят по IP, или по вашему ID, потому что у авторизованных пользователей тоже есть лимиты, или они платят деньги за запрос)? Почему это у данной компании может не получиться? Не факт что просто — но должно быть вполне решаемо.
А еще проще — вообще не банить, а просто вводить задержку. И на этом тысяча запросов в цикле становится невыгодной.mixeden
18.12.2019 19:19Ну я и говорю: «если с одного пользователя спрашиваются координаты водителей в 100 разных местах — это несколько странно».
Другое дело, что я, например, не знаю, как с этим разобрались, например, в Яндексе, а разбираться сейчас у меня времени нет (предложение автору статьи).
Пример с гуглом чутка неправильный — там геокодирование является частью сервисов, которые можно купить и использовать. А тут с ситимобилом несколько другая ситуация: они же не продают данные о передвижении своих водителей. Поэтому «платят деньги за запрос» — стратегия, которая к ситимобилу не применима.
Мне лично кажется, что флудконтроль бы всех спас. Не выписывать перманентный бан, просто после, скажем, 20 странных запросов блокать на часок.
peresada
19.12.2019 07:57Можно хешировать запрос с солью, которая вшита в приложение и в бекенд, и добавить привязку ко времени, скажем 30 секунд — и пользоваться этой дырой станет значительно сложнее
tbl
18.12.2019 20:07+1Особенно под конец года, у всех годовые и квартальные планы горят, баги фиксить некогда. Астрологи предсказывают увеличение говнокода в проде.
Feihoa
18.12.2019 18:19+5Видимо вопросы на собеседовании в «Ситимобил» на оценку асимптотической сложности алгоритма и ему подобные не помогают защищать свои http-концы.
tbl
18.12.2019 20:42+2Про оценку асимптотической сложности алгоритмов на собеседованиях спрашивают обычных разрабов, а про интеграцию компонентов между собой — техлидов и архитекторов. Только когда доходит до проектирования реальной системы, непосредственное участие принимают обычные разрабы, а техлиды (занятые переписками с менеджерами, согласованием трудозатрат и отпусков и другими важными вещами) визируют такие решения по интеграции, практически не глядя, просто потому что времени на нормальное ревью не остается.
3aiats
18.12.2019 18:22По данным вики на конец 2018 года в Москве зарегистрировано 100 000 водителей такси. То есть «ситимобил» занимает примерно 5% рынка?
Krupnikas Автор
18.12.2019 18:34~5000 это число активных таксистов в срезе времени. Я собирал данные примерно сутки. За это время было замечено порядка 10000 уникальных водителей. Думаю, если собирать данные достаточно долго, то можно будет понять, сколько водителей всего, когда они работают, какая у них средняя продолжительность смены и т.п.
boroda_el
18.12.2019 21:38+1какая у них средняя продолжительность смены
Вот об этом бы очень было интересно почитать. Насколько помогают все кнуты и пряники, и как много таксерит по 20 часов выпучив глаза.worldaround
18.12.2019 22:48По 20 часов он таксерит с трех разных аккаунтов.
salas
19.12.2019 01:02+1В аккаунте разве номер машины не записан?
Abiron
19.12.2019 01:44На одной машине могут ездить разные таксисты, легально. Часто просто работают в несколько смен.
worldaround
19.12.2019 02:02В контексте темы статьи у нас нет доступа к гос. рег. знакам автомобиля. А если бы и были, то что плохого в том, что автомобиль работает 24/7? Аренда машины в Москве сжирает половину дохода таксиста, использовать ее в две смены — благое дело. Я не знаю как в сити, но вот в яндексе аккаунт таксиста блокируется при переработке и вы по id ее не найдете.
RiseOfDeath
18.12.2019 18:38Я бы заметил что процент водителей/машин (или, например, магазинов если абстрагироваться от перевозчиков) от общего числа это не доля рынка.
Ну и к тому же таксисты часто работают одновременно на несколько агрегаторов (у какого вылезет заказ пожирнее, у того и возьмет заказ). Видел «иконостасы» из 3-4 мобильников.3aiats
18.12.2019 18:42В другой отрасли — я бы с вами согласился, но на рынке такси достаточно высокая миграция водителей вслед за доходом и удержать их неценовыми факторами довольно сложно. При этом доход достаточно равномерен. Так что считаю что в данном случае количество водителей напрямую коррелирует с долей рынка.
prika148
18.12.2019 18:41В статье упоминалось количество водителей онлайн в определённый момент времени. Вероятно, существенная часть зарегистрированных водителей такси проводит на линии очень мало времени. Так что, по всей видимости, Ситимобил занимает больше, чем 5% рынка
Mykola_Von_Raybokobylko
19.12.2019 11:16Куча водителей берут заказы из разных систем.
В довесок что озвучил автор. Подобная расхлябанность разработчиков позволяет не только отследить регулярные маршруты и время клиентов такси, но и показать отклонения во времени и маршруте лицам которые не должны это знать.
abbath0767
18.12.2019 18:28Кажется я начинаю понимать зачем Ситимобил спрашивает про все уровни osi.
tbl
18.12.2019 18:42Неважно, что спрашивают на собеседованиях, если по факту бизнес требует от разрабов "… уяк-… уяк, и в продакшен"
denisromanenko
18.12.2019 19:52+2О, опять бизнес виноват. Нет, ну бизнес конечно виноват, но в каких-то других, глобальных проблемах: но неужели отслеживать частоту запроса с одного IP — это вот прям дико сложная задача, которая оттягивает все ресурсы от разработки и мешает выходу новой версии?
Это основа, блин.
Это при самом тупом моделировании системы на салфетке из кофейни нужно учитывать, прямой путь к ддосу.
Это говорит только о некомпетенции авторов сервера, но не о нехватке времени на правильную реализацию.
tbl
18.12.2019 20:00+6"Покатим в прод в виде MVP, а по нормальному сделаем потом (никогда)". Неработающие поля limit и radius как бы на это намекают.
gecube
18.12.2019 21:22+1У ситимобил полгода назад была существенно серьезная проблема с сценариями обработки действий пользователя. Там были тупиковые ветки, которые даже звонок в техподдержку не исправлял. Не говорю о том, что постоянно проблема с машинами. Ситимобил, до свидания! Вместо того, чтобы сделать технически конкурентоспособный продукт, вы решили тупо вбухать деньги в рекламу (транспорт, Ютуб, тв) и поэтому клиента в лице меня вы потеряли насовсем.
Настоящая статья — это яркая иллюстрация, что к этому аггрегатору ни в коем случае нельзя идти ни в коем качестве.
batyrmastyr
18.12.2019 23:39Скорее всего они перестали работать когда другие исследователи ухнули радиус в 1000 км и лимит в пару лямов.
tbl
19.12.2019 02:47Презумпция бритвы Хэнлона утверждает: «Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью».
Поэтому, если бы был нормально устоявшийся и регламентированный процесс разработки, в котором участвовал QA-инженер, то он бы обнаружил такие корнер-кейсы, и тогда разрабам пришлось либо лимитировать сверху входные параметры, либо вводить постраничный отбор.
А тут: что имеем, то и имеем.batyrmastyr
19.12.2019 13:57Так я как раз приписываю глупости, точнее двум: введению этих параметров, хоть они и не нужны, а потом кривому их удалению.
Хотели бы удалить нормально — сделали бы эти параметры необязательными на сервере, потом перестали передавать из приложений, а через энное удалили с сервера.
DonkeyHot
19.12.2019 06:51Неработающие поля limit и radius как бы на это намекают.
В API инстаграма тоже полно неработающих полей и эндпойнтов.
Для активно развивающегося сервиса это обычное дело, все не предусмотришь.
Neikist
18.12.2019 20:01+5Скорее всего было так:
— Вот, я запилил для демки фичу, но нужно будет еще защиту на нее навесить и вообще отладить так как не все параметры работают.
— Зачем это? У нас задача срочная новая горит, потом когда нибудь займешься.denisromanenko
18.12.2019 20:10-4Rate limit делается за 5 минут, и на это не нужно спрашивать разрешения у злого дяди менеджера, это в крови должно быть, руки сами проверку на количество запросов должны набивать.
А еще админы серверов вообще должны fail2ban настраивать во сне. Или облака так расслабили девопсов, что пущай кто угодно к нам стучится, на всех хватит!?
Neikist
18.12.2019 20:14+1А точно ли по бизнес логике тут именно Rate limit нужен? Вполне возможно что нужна более сложная логика поскольку какие то сценарии где пользователь будет делать частые запросы окажутся валидными. Вы уверены что готовы решать за бизнес что ему нужно?
be_a_dancer
19.12.2019 08:25Не могу представить сценарий, когда пользователь будет опрашивать сервер с частотой более 60 раз за минуту.
Приведите, пожалуйста, пример, может я что-то упускаю?Neikist
19.12.2019 09:19+1Да запросто, не просто текущее положение показать, но и движение. Плавно и точно. Ну и как бы 60 раз в минуту для парсинга вполне достаточно, так что дыру не закроет.
Elmot
19.12.2019 14:33Если по IP считать — то легко. Конец рабочего дня в большой конторе, масса народу вызывает такси с мобильников через рабочую вафлю с серым IP.
gecube
19.12.2019 16:02-1Не пользуюсь рабочей вайфлей, т.к. там Корп перехват данных. Не говоря уже о том, что
1. Использование Корп вафли в личных целях — атата
2. Зачастую лте работает тупо быстрее, чем Корп вафляvlivyur
20.12.2019 09:09Т.е. с мобильного интернета с единственного IP для всех клиентов опсоса?
gecube
20.12.2019 10:04Ну, может не прям единственного, а с пула айпишников, но все равно клиентов у опсоса явно больше, чем пул. Поэтому нам от этого не будет легкче. Почему не Корп вафля — я выше написал.
Elmot
20.12.2019 11:38-11. Использование Корп вафли в личных целях — атата
Не раздавать работникам отдельную сеть для мобильников в своем здании — атата-атата.
Раздавать тормозную сеть в своем здании — атата-атата-атата.
tcapb1
18.12.2019 20:24+10Не за 5 минут всё же. Просто fail2ban — это полдела. Ещё нужно добавить такой ответ в API, задокументировать, протестировать чтобы ограничения были разумными и не сказывались на обычных пользователях, выводить в интерфейсе приложения человекопонятное сообщение «вы слишком часто делаете запросы, отдохните чуток или воспользуйтесь Яндекс.Такси» и наверное я ещё не всё учёл. Довольно часто бывает когда кажется, что работы на 5 минут, а потом одно тянет другое, другое тянет третье, разработчик в пределах своей компетенции задачу полноценно решить не может, нужно подключать других сотрудников — и даже если разработчик добросовестно отрепортит, задача может застрять на уровне выше.
Ну и можно посмотреть предлагаемые варианты решения ниже по ветке, с авторизацией пользователя для запроса, проверке геокоординат пользователя и т.д. Явно не 5 минут времени.denisromanenko
18.12.2019 20:37-3Ааа, классический зеноновский парадокс, где быстроногий Ахиллес никогда не догонит черепаху.
Уверен, как и в многих современных чудо-приложениях, 70 % ошибок на стороне пользователя обрабатываются на стороне пользователя как «Упс, что-то пошло не так, попробуйте через пару минут». Но даже это лучше сотен тысяч данных в открытом доступе.
worldaround
18.12.2019 22:56А зачем нужен лимит? С нагрузкой сервер пока справляется, а выкачать все данные можно и с лимитом.
gecube
18.12.2019 23:11+2Например, чтобы обеспечить качество предоставления услуги. Сэкономить деньги, в конце-концов
Давайте представим некий надуманный пример. Выкатили обновление. Клиент начал генерировать запросы на всю ширину канала клиента. Некоторые клиенты по лте, некоторые — по вайфай. Сами себя заддосили, получается. Был бы рейтлимит на стороне сервера — все было бы сильно лучше )
Т.е. рейтлимит это всего лишь один из инструментов и его можно применять, когда от него есть выгодаsomebody4
18.12.2019 23:13+1Сэкономить деньги, в конце-концов
Если у тебя ферма из серверов и ферма из балансеров, то правильная реализация рейтлимита, особенно с HA опцией, это не про «сэкономить деньги», дешевле пару лишних серверов поставить.
kbaa
19.12.2019 05:10отслеживать частоту запроса с одного IP
поможет как лечение подорожником
rotating proxy которые будут отправлять каждый запрос с рандомного IP стоят $50/месяц плюс-минус, в зависимости от объемов траффикаgecube
19.12.2019 09:30+1С rotating proxy как раз можно бороться.
А лучше бы сказали о другой проблеме и ее решении.
Очевидно, что такси пользуются только физики. Это означает, что они выходят с вполне понятных пулов адресов, принадлежащих провайдерам. Их динамическим пулам. Не адресам Амазона, Гугла, хостинг-провайдеров и прочего. Единственное, что остаётся — это корпоративщики со своими автономными системами и внутренним вайфаем для сотрудников. Т.е. к чему это я — можно построить алгоритм определения человек ли к нам пришел или парсер и source ip использовать в качестве одного из критериев. Это раз.
Два. Всякие моб клиенты легко скрываются за 1 ip адресом, т.к. провайдер жадный и по сути можно не тратить адреса попусту. В этом случае рейтлимит (глупый рейтлимит, конечно) тупо сломает работу приложения у клиентов, сидящих, скажем, с одного опсосаworldaround
19.12.2019 10:27Надо вычислять клиентов по ip, чтобы за ними не следили посторонние? Да только как это делать, когда государство всеми силами загоняет их в VPN?
gecube
19.12.2019 10:55Извините, пожалуйста, совершенно не понял, что Вы хотели сказать. Можете развить свою мысль?
myz0ne
19.12.2019 11:22Что есть тенденция из-за наших новых законов и из-за блокировок гнать весь трафик через зарубежный впн. И такие блокировщики по AS доставляют боль. Иногда проще отказать от сервиса чем отключать ради него впн.
gecube
19.12.2019 11:49-3Если Вы выходите через VPN, то будьте готовы, что сервисы, которые определяют Ваше местоположение, скажем, по GeoIP — работать не будут. И вообще — я допускаю, что человеку честному нечего скрывать, поэтому он не будет ходить через VPN (на самом деле это не так) и поставщики услуг могут прямо в договоре присоединения к своей услугу писать, что обфускация настоящего IP запрещена.
Neikist
19.12.2019 12:06Скрывать может и нечего (хотя есть чего всем), но доступ к заблокированным ресурсам часто нужен.
myz0ne
19.12.2019 12:12+1Думаю те, кто ходят готовы к этому. Вопрос в том, готов ли бизнес потерять клиента (а значит и деньги) из-за странной политики к пользователям впн.
mayorovp
19.12.2019 13:38Думаю, вопрос можно поставить ещё проще: готов ли бизнес потерять вообще всех клиентов из России во время очередной волны блокировок Телеграмма.
vikarti
19.12.2019 16:19Скрывать — нечего. А то что заблокировали доступ к совершенно легитимному (и возможно нужному для работы — были ведь случаи с блокировкой гитхаба) сайту.
Поставщику же услуг при наличии вопросов будет так так и сказано что Россия, цензура-которой-нет, вот и приходится так, личность подтвердить — ну давайте как то еще подтвердим. И проходит обычно (Речь НЕ про музыкально-фильмовые сервисы).
Российским же поставщикам(даже финансовых услуг) (опять же речь не про музыкально-фильмовые сервисы) обычно хватает либо просто звонка «вы тут недавно входили — это точно вы? а на контрольные вопросы ответить готовы?» либо прямо слов что используется VPN, да — оно надо, да — если дадите список адресов куда напрямую ходить — поставлю исключение.
А насчет договора — так где вы обфускацию увидели — X-Forwarded-For от прокси приходит с честным IP.
При если договора именно ЧИТАТЬ — иногда возникают вопросы какого черта провайдер сам не соблюдает (в договоре сказано что минимум Андроид 2.3 — в сторе 4., версию под iPad1 предоставить отказались хотя обязаны по договору)
Про ограничения доступа в том же договоре — сказано просто «территория Российской федерации» (про IP ни слова)gecube
19.12.2019 16:51Я понимаю Вашу грусть, но вот, к примеру, с гуглом — я регулярно ловлю капчу при выходе через домашний интернет. Обнаружена подозрительная активность и блаблабла. Понимаю, что сравнивать сервис такси и поиск в гугле глупо. Но тем не менее — факт есть.
worldaround
19.12.2019 13:02Есть вариант, считать людей людьми, если они заходят не с проксей, а с мтс, билайна или мегафона и делиться с ними урывками «публичной» информации. Но не тут-то было, они придут и с впна, нельзя же их разочаровывать.
commanderxo
19.12.2019 12:09+1Т.е. к чему это я — можно построить алгоритм определения человек ли к нам пришел или парсер и source ip использовать в качестве одного из критериев.
Алгоритм Сергея по косвенным признакам вычисляет траекторию такси, а с ним и пассажира. В ответ, алгоритм Ситимобила пытается по косвенным признакам вычислить Сергея.
Если долго смотришь в бездну, бездна начинает смотреть на тебя.
/* Если вдруг Сергей неосторожно сядет в такси Ситимобила, то произойдёт бесконечная рекурсия и настанет конец Вселенной. */
myz0ne
19.12.2019 13:04Есть такая штука — Residential Proxies. В итоге как обычно — защита обходится не так сложно. Но в то же время доставит проблемы легитимным пользователям впн.
kbaa
19.12.2019 13:20+1я потрачусь на прокси чуть подороже и поставлю в настройках выдавать моему боту IP из пула определенных операторов и соберу данные
или
я попытаюсь заказать такси, когда телефон подключен к wifi и на роутере прописан впн. и останусь без таксиgecube
19.12.2019 13:26+1Знаете, про GeoIP и определение положение абонента на сайтах я уже поел говна, т.к. меня регулярно кидает в другой регион (где куплена SIMка), а не где я фактически нахожусь. Так что да — мифическая забота о пользователе для определенного процента пользователей выходит боком. Зато 99% остальных пользователей довольны…
vikarti
19.12.2019 16:03+1Очевидно, что такси пользуются только физики.
Нет.
Несколько лет назад у меня была работа с опцией — звониш в конкретный таксопарк, говоришь волшебное слово и едешь на такси домой, утром наоборот. За счет фирмы. Спецтариф какой то. Не верю что сейчас у таксистов нет такой опции. В приложениях может пока еще и нет — пока.gecube
19.12.2019 16:54Да, спасибо за уточнение. Под физики — я имел в виду конкретных людей, пускай и работающих в корпорациях и пользующихся такси по служебной необходимости.
Действительно, я видел у Убера корп. тариф, но прошу обратить внимание, что устройство-то скорее всего с которого происходит вызов — обычный телефон (или планшет) с обычным же интернетом (обычный мобильный опсос). А волшебное слово и корп. тариф — это больше про форму оплату (хотя там тоже нюансы )…
mayorovp
19.12.2019 10:12Сложная-несложная, но отдельная. Требующая своей аналитики (раз в секунду — это уже слишком часто или ещё нет?), архитектурных решений (информацию о прошлых запросах надо же где-то хранить)… Вполне может оказаться, что защитой от ddos вообще другой подрядчик занимался.
Alexsey
19.12.2019 00:37Да у них вообще весьма интересно все. Не совсем понимаю как можно на полном серьезе делать вакансию со словами «Ищем backend с 3+ годами опыта. У нас тут все на php, с удовольствием примем всех желающих переучится на него» и спамить всем у кого в резюме написано слово «разработчик» эту вакансию. Ладно бы они джунов искали, но 3+ это уже человек у которого знания его текущего языка на достаточно глубоком уровне и тут они предлагают все выбросить и пойти изучать другой язык.
be_a_dancer
19.12.2019 08:29Практика переучивания достаточно распространена. Правда первый раз вижу, стобы требовалось переучиться на php. Но при этом, видел вакансии с переучиванием на го и даже на badoo tech был доклад про это.
Некоторым хочется чего-то нового.
Hakhagmon
18.12.2019 18:44+5Ситимобил входит в МРГ, а как мы помним по ВК, они по Bug Bounty ну платят.
«Это так и должно работать», а через неделю фиксят
ooprizrakoo
19.12.2019 00:22+3если зайти на страницу компании на hackerone, там написано что через сервис всего уже было выплачено $564,656
Из них
$122,681
Bounties paid in the last 90 days
pyrk2142
19.12.2019 06:21МРГ очень неоднородная структура. Имхо, у самого Mail.ru весьма высокие требования по безопасности, плюс достойная адекватность и готовность общаться у сотрудников (z3apa3a вообще рассказал мне довольно много интересных вещей в рамках репортов), ВК — это нечто крайне странное, безопасники готовы месяцами не исправлять довольно серьезные уязвимости, потом выкатить дырявое решение, а на все вопросы о том, почему бы не сделать безопасно и нормально, заявить, что так оптимальнее.
RecruitP
18.12.2019 18:46-11Закрывший тикет представитель citymobil указал не на то, что данные в приложении секьюрны, а на то, что они сами по себе открыты. Это не уязвимость, не баг и не недоработка, это одна из стандартных функций сервиса, на это указывают и очевидные ограничения АПИ.
Возможно, у ТС не хватает опыта и компетентности в этой области, так как вещи это банальные и представляют собой базис. Их не забывают защищать, ибо их изначально не делают открытыми без надобности.
Эту “проблему” в глобальной перспективе невозможно решить, разве что не показывать этой информации вовсе.
d3emp
18.12.2019 18:57-4Почему их нельзя зашифровать?
RecruitP
18.12.2019 19:05+8Зачем шифровать данные, если мы отдаём их юзерам? В каком бы виде данные не передавались, их в любом случае нужно интерпретировать чтобы показать конкретную точку на карте, и ничего не мешает “злоумышленнику” делать это точно так же, как делает приложение.
Возможно, я неправильно понял вопрос?d3emp
18.12.2019 19:37Я имею в виду почему нельзя передавать координаты в зашифрованном виде и расшифровывать их на стороне пользователя? Где на каждую пользовательскую сессию уникальный ключ-идентификатор
RecruitP
18.12.2019 20:30+1Чтобы что? К тому же трафик и так шифруется по https протоколу ;/
d3emp
19.12.2019 09:56Чтобы человек посередине видел не открытый json, а зашифрованные данные, которые расшифровываются в приложении. И надо будет не просто снифать, а лезть в работающее приложение, которое может иметь свои механизмы защиты.
Neikist
19.12.2019 10:07Так как это защитит от того чтобы написать свой клиент для апишки с тем же шифрованием? Можно будет ровно так же собирать данные. Собственно в статье так и было сделано.
d3emp
19.12.2019 10:44Вот этого я как раз и не понимаю. Приходит ему к примеру ответ "car_type":"GhRd35nai7", каким ключем он будет это расшифровывать?
gecube
19.12.2019 10:57+1сертификатом/ключом, которые hack0r вытащит из самого приложения. Или Вы думаете, что на каждую сессию будет генерировать сессионный ключ? ну, ок, это все равно не отменяет возможности написания полноценного эмулятора приложения, но это явно будет ТУПО дороже, чем просто сниффать трафик и строчить разгромные статьи на хабр ) И, понятно, что экономической целесообразности в этом уже не будет, т.к. взлом будет стоить дороже, чем защищаемые данные (в общем-то, в этом и есть цель ИБ).
MilesSeventh
19.12.2019 19:30Найдется другой товарищ, который зареверсит само приложение и все равно вытащит нужные уязвимости, это не решение.
Aetae
18.12.2019 22:28Более-менее «защитить» можно элементарно. Запоминать предыдущие точку и время запроса и сравнивать с новой. Если скорость перемещения больше ~250км/ч — клиент на подозрении, если повтор — бан за нарушение условий использования.
tcapb1
18.12.2019 22:51+1Человек не обязательно заказывает такси себе. Зайти в приложение, а затем переместиться на другую точку — вполне нормально. Или например телефон подглючивает и определяет собственные координаты не в том месте. Или например я при повышенном спросе ползаю по карте и смотрю, может с другой точки будет заказать дешевле.
NINeOneone
19.12.2019 09:53Справедливости ради — ограничить такую возможность все же дешевле, чем выкатывать дыру из поста.
Имею ввиду ограничить радиус скажем в полкилометра от начальной точки.JerleShannara
19.12.2019 10:42+2Я вызываю такси около стен Кремля… один шажок и я уже во Внуково и забанен. Я вчера вызывал такси в Питере, а сегодня вызываю в Самаре, но вот геодата на старте не подхватилась и я в Питере, хотя в реальности в Самаре, как хорошо, что у меня AGPS+GPS+Glonass ну и чип этого GPS быстрый, всего 30 секунд и я в Самаре… вот только опять бан.
Ещё реальных тесткейсов наплодить?
Rollant
19.12.2019 16:03Как в потоке запросов выловить предыдущий запрос от этого клиента? По IP не получится, т. к. за одним натом может быть куча телефонов. Куки злоумышленник, скорее всего, догадается выбросить, благо запрос работает без авторизации. Что ещё?
vlivyur
20.12.2019 10:58А я всего-навсего случайно включил определение положения по всем источникам для «высокой точности».
Tangeman
18.12.2019 19:13+7Эту проблему можно решить рядом способов:
— показывать данные только авторизованным пользователям (если у человека нет приложения, данные ему не нужны);
— ограничивать количество запросов в единицу времени (чаще чем раз в 10-15 секунд не имеет смысла запрашивать, для практического применения возможно и минуты будет достаточно);
— бить тревогу если запросы начинают идти на локации значительно удаленные от места где находится пользователь приложения;
— не отдавать результат если пользователь находится в поездке (ему это уже или ещё не нужно, пока он не достигнет конечной точки);
— … и ещё можно придумать мониторинг и ограничения, не создающие проблем честным пользователям, но не дающие возможности следить за водителями кому угодно.
Да даже банальный rate-limit на раз в 30 секунд с одного IP существенно сократит (если совсем не уберёт) возможности слежки, уж маршрут-то точно станет тяжко отслеживать.RecruitP
18.12.2019 19:23Я говорил о решении проблемы, а не ограничениях. Можно накатывать сколько угодно условий, скраппить данные это не помешает, но давайте по пунктам.
показывать данные только авторизованным пользователям (если у человека нет приложения, данные ему не нужны);
Вы можете передавать данные авторизации вместе с запросом, серверу глубоко всё равно с приложения или тапка они отправлены, любой user agent можно подменить хотя бы с помощью того же reverse proxy.
ограничивать количество запросов в единицу времени (чаще чем раз в 10-15 секунд не имеет смысла запрашивать, для практического применения возможно и минуты будет достаточно);
Прокси помогут as well.
бить тревогу если запросы начинают идти на локации значительно удаленные от места где находится пользователь приложения;
Невозможно точно установить местоположение пользователя, как вы собираетесь это сделать?Tangeman
18.12.2019 19:50+3Вы можете передавать данные авторизации вместе с запросом, серверу глубоко всё равно с приложения или тапка они отправлены, любой user agent можно подменить хотя бы с помощью того же reverse proxy.
Это смотря как делать авторизацию, не говоря уже о том что пользователю придётся сначала регистрироваться, а это привязка по номеру телефона (подозреваю, что с верификацией).
В токен авторизации можно забить текущие координаты пользователя и ограничить радиус запроса в (скажем) 3 км.
Далее, если мы ограничим выдачу результатов только авторизованным пользователям, то в сочетании с банальным rate-limit не помогут ни прокси, ни что-то ещё, ибо он привязан к пользователю, а не IP.
Вы конечно скажете что можно создать сотню или тысячу пользователей, но их можно быстро вычислить по частоте запросов (тот кто просто ездит не делает запросы даже раз в минуту на протяжении часа), не говоря уже о том что на каждого пользователя потребуется свой номер телефона, а три разных запроса (скажем) в течение минуты с разных IP но от одного пользователя явное свидетельство чего-то «левого».
Конечно, если разбить город сеткой 100x100, в каждый квадрат «посадить» отдельного пользователя (уже 10 тыс. нужно), и каждый из них будет делать запрос раз в минуту — то что-то из этого и получится, но стоимость такого съёма информации будет просто невероятной, причём их всё ещё легко отследить (при желании), ибо они не ездят.
Невозможно точно установить местоположение пользователя, как вы собираетесь это сделать?
Правда? Приложение для вызова такси не использует GPS смартфона для определения положения пользователя? Да, можно подменить данные — но «прыгунов» легко отследить, не думаю что если кто-то реально способный перемещаться со скоростью более км/минуту (и делающий это между запросами) нуждается в такси, в сочетании с ограничением по радиусу поиска это отфильтрует левые запросы.RecruitP
18.12.2019 19:59тот кто просто ездит не делает запросы даже раз в минуту на протяжении часа
Похоже, вы просто напросто забыли что данная возможность предназначена для отслеживания автомобилей (не автомобиля) и их положения в реальном времени. Будет сложновато для обычных пользователей без корыстных намерений сделать это с такими ограничениями.
Не говоря уже о том, что gps технологии поддерживаются не всеми устройствами.Tangeman
18.12.2019 20:40+1Будет сложновато для обычных пользователей без корыстных намерений сделать это с такими ограничениями.
Для гиков дается burst на 10 запросов и далее rate-limit на 1 запрос/минуту — этого более чем достаточно чтобы насладится видом вокруг несколько раз, вызвать машину, дождаться её и уехать. Среднему пользователю совершенно неважно что машины в районе сместятся на несколько сотен метров (или даже на километр) пока он изучает карту, ему важно (и то вопрос) видеть сколько их рядом.
Если машина заказана и уже едет и хочется знать где она — отдается только её положение, что ещё нужно пользователю для приятного опыта?
В конце концов, подавляющему большинству важно только знать когда будет подана машина, может быть уведомление об опоздании заказанной, но сколько их вокруг и каких именно (особенно после заказа) — это совершенно иррелевантно.
Просто знать положение и количество такси в округе — почти бесполезно, не зная чем они заняты и когда освободятся, их цвет тем более бесполезен (по крайней мере, пока одно из них не едет за вами — но цвет остальных в этом случае тем более неважен).
Не говоря уже о том, что gps технологии поддерживаются не всеми устройствами.
Ок, тогда пользователь сам укажет где он. Но если он будет менять положение каждые 15 секунд со смещением в несколько километров, опрашивая машины в округе — разве это реалистично для того кто просто хочет уехать? Он что, телепортироваться собирается в район где их больше? А если собирается (и может) — то зачем ему, собственно, такси?
WraithOW
18.12.2019 20:51Похоже, вы просто напросто забыли что данная возможность предназначена для отслеживания автомобилей (не автомобиля) и их положения в реальном времени.
Нет, её назначение — создать у пользователя впечатление, что он сможет быстро уехать, но при этом не сильно пользователю наврать. Более того, пользователь абсолютно не расстроится, если в момент назначения машины он получит не уже нарисованную на карте, а какую-то новую — главное, что машина есть. Точность местоположения и реальное время здесь не нужны от слова совсем.
И да, вам не нужно делать сто тысяч запросов в секунду, чтобы рисовать машинки на карте — дайте клиенту позицию и направление, пусть экстраполирует, юзеры не будут бегать по улице и сравнивать. Дороги у нас обычно прямые, максимум, что произойдет — машина на карте немного проедет перекресток, а потом прыгнет на перпендикулярную дорогу, будто кому-то на это не побоку. Одного запроса раз в 10-15 секунд вполне хватит.gecube
18.12.2019 21:25Расстроится. Неоднократно было — машине в округе есть, но не назначают ни одной, либо назначают самую бальную...
tmin10
19.12.2019 00:37В яндексе же тоже так: вокруг рисуется много машин, а заказ никто не берёт. А через некоторое время берёт машина, которой до тебя ещё минут 10 ехать. И в gett подобное есть.
vlivyur
20.12.2019 13:09Мне кажется нарисованные машинки никакого отношения к реальности не имеют. Просто как прикольная анимация.
WraithOW
19.12.2019 13:15+1но при этом не сильно пользователю наврать
Если вы не можете уехать, то очевидно, что ваше впечатление и реальность существенно различаются. Суть моего коммента в том, что реальному юзеру не важно, как эти машинки технически рисуются — ему нужно сесть и уехать. Если получилось — он доволен, не получилось — он недоволен. Реалтайм там или экстраполяция — дело сто первой важности.gecube
19.12.2019 13:27+1Так я про это и говорю. Мне не важно сколько машин в округе, если я не могу уехать. Или мне рисуют время ожидания 5 минут, а по факту машина будет ехать 10… И нарисованные машинки «на районе» только усиливают фрустрацию — т.к. вот они… а уехать нельзя.
myz0ne
18.12.2019 20:04В некоторых сервисах такси есть такая штука — вызов такси кому-то в другой части города. Есть например в том же яндексе. И точно так же показываются машины рядом. Удобная штука. А вот вы предложили сделать ее менее удобной.
Tangeman
18.12.2019 20:47Нисколько. Это решается уже упомянутым мной выше бурстом. К тому же, я (будучи сервисом) с трудом поверю что пользователь вдруг решил заказать такси десятку разных «других» в разные районы города за короткое время, а если и решил, то вряд-ли будет это делать регулярно и продолжительное время — он что, свой сервис заказов открыл, а у всех без исключения «других» нет смартфонов с приложением? И он готов отвечать каждому водителю «Я тут стою у зелёного киоска, вы где?» вместо этих самых «других», или наоборот, каждому «другому» — «Да едет он к вам, едет, в пробке стоит, опоздает на 10 минут»?
gecube
18.12.2019 21:27Не в некоторых, а во всех известных мне. И это жизненно необходимая возможность. Например, заказать такси жене/ребенку/теще/другу и т п
Или едешь ты в метро, gps прыгает, а ты хоп — и вызвал такси на конечную метро по адресу )
fougasse
18.12.2019 19:52Шаринговые сервисы типа Share Now показывают машины и без логина, все.
Кстати, интересно было бы поковыряться в их трафике, хотя это мало что даст.gecube
18.12.2019 21:28+2Почти наверняка эти сервисы обфусцируют уникальный айди машины. Т.е. в моменте посмотреть картину распределения можно, а вот построить карту передвижений — нет
saver
18.12.2019 19:15Эту “проблему” в глобальной перспективе невозможно решить, разве что не показывать этой информации вовсе.
А почему нельзя показывать пользователю варианты автомобилей вокруг только после создания заказа? Как это делает тот же Я.Такси. Тогда можно было бы отдавать их не по локации пользователя, а по локации самого заказа, который этот пользователь создал. Локацию заказа поменять у пользователя не получится, не пересоздавая заказ. Как и создавать 100500 заказов в минуту. Вот и решение.fougasse
18.12.2019 19:53-2Потому, что я не хочу делать заказ, если рядом нет машин?
Tangeman
18.12.2019 20:56+2Достаточно сделать чуть другую систему — делаете заказ, водитель делает преложение — «буду через 20 минут» — вы можете бесплатно отказаться если не устраивает, а если «буду через 3 минуты» — то всё равно сколько машин в округе, вам ведь важно быстро уехать, или нет?
И даже если округа вся занята машинами, у вас всё равно никакой гарантии не будет что кто-то из них уложится в нужное вам время, хотя… если никто не уложится — разве вы будете вызывать вертолёт? В лучшем случае будете заказывать у другой службы, но не факт что ситуация там будет лучше (особенно в час пик), и обозревание количества машин вокруг совершенно на это не может повлиять.gecube
18.12.2019 21:30Да 200%. Меня не волнует плотность машин в конкретном районе. Я уже выше писал почему — легко может оказаться, что свободных водителей нет. А машины на карте есть
А интересует меня — среднее время ожидания по конкретному адресу. Если оно больше некой величины, то пора садиться на ОТ или искать каршэринговую тачкуfougasse
18.12.2019 22:21+1Меня интересует количество свободных машин.
Если ребята показывают все машины — в этом, действительно, нет смысла.Elmot
19.12.2019 14:38Есть еще машины, которые вотпрямщас заняты, но уже почти исполнили заказ и через 3-4 минуты (должны быть) свободны. При распределении заказов агрегаторы такие машины тоже считают.
fougasse
18.12.2019 22:20+1Лишние действия от пользователя вместо нормальной реализации от поставщика услуг.
Мне важно уехать, когда быстро, когда комфортно — зависит.
А идиотские ограничения "не заказал — не покажем машины рядом" автоматически отправляют таких вот оптимизаторов, в лучшем случае, в конец списка сервисов.Tangeman
18.12.2019 22:38Что значит «лишние»? Он заказывать не собирается, что-ли? Тогда зачем полез в приложение? А если собирается, всё равно жмёт кнопку «заказать», и независимо от плотности и количества машин показанных на карте время ожидания его может не устроить (они все могут быть заняты, ехать в другом направлении, etc).
«Правильные» сервисы сами оценивают время ожидания в данной точке с учётом наличия машин, их занятости и среднего времени на подачу для каждого конкретного водителя из каждой конкретной точки, при этом можно ещё учесть и траффик, пробки, вероятность принятия заказа и ещё много всего такого что известно сервису (но не может быть показано на карте).
Пользователю может быть «неудобно» только в одном случае — если карта даёт ему возможность сделать drag & drop конкретной машины, с последующей материализацией этой самой машины там где он стоит через несколько секунд.
За всё время пользования подобными сервисами не могу вспомнить ни одного случая когда информация о машинах хоть как-то была полезна, хотя красиво, да — создает атмосферу «мы заботимся о вас» и «смотрите как у нас круто, сколько машин вокруг».
0xd34df00d
19.12.2019 03:16если никто не уложится — разве вы будете вызывать вертолёт?
Поеду на метро, например.
progman_rus
19.12.2019 13:01тогда так:
1. запрос на сервер: «сколько машин в радиусе 500м от указанной позиции»
2. ответ сервера: 42. Из них премиум 2, эконом 30, бизнес 10. Заказывать будете?
координаты и идентификаторы машин клиенту не выдаются. ибо зачем?fougasse
19.12.2019 15:22Ну так тут же нужно DTO преобразовать, согласовать поля, пару митингов с PO.
Проще отдать все данные и пойти кущать печенье.
unwrecker
19.12.2019 01:44Достаточно убрать id из выдачи. И всё — данные уже не соберёшь, ибо машины двигаются, координаты меняются, сопоставить невозможно. Даже количество машин не оценишь.
Roman_Solodukhin
19.12.2019 12:16Сначала подумал об этом. Но как тогда приложение будет рисовать линейное движение автомобилей на карте? Они же как мошки начнут мерцать.
progman_rus
19.12.2019 13:03а зачем приложению рисовать движение автомобилей на карте?
лично меня при заказе волнует лишь где сейчас находится заказанная мной машина.gecube
19.12.2019 13:29+2ну, вообще это крутой ui/ux. А еще очень круто наблюдать, когда твоего ребенка/жену/пр. везет такси — ты точно чувствуешь, что контролируешь ситуацию. И можешь выйти к моменту подачи и встретить. А не реагировать пост-фактум на смс со списанием (которой может и не быть).
Или текущее положение машины очень удобно, если экономишь время и можешь пойти (тупо) навстречу водителю, чтобы не стоять в пробке или типа тогоprogman_rus
19.12.2019 17:11ну так после заказа и нужно рисовать именно эту машину. А до заказа зачем рисовать все свободные?
достаточно информирования что недалеко от вас Х машин, время подачи прмиерно Y
заказывать будете?gecube
20.12.2019 10:00Эм, ну, согласен. Прошу прощения, видимо, не совсем понял о каком именно движении Вы говорили. Если речь о движении машин вокруг меня до момента заказа, то, да, соглашусь — для меня как клиента особого толку в нем нет, только аккумулятор сажать, потому что процессор отсчитывает, а экран отображает эти данные )) тем более, что ни разу не было, что я сел в ближайшую машину ) Т.е., повторюсь, мне важно как клиенту:
1. Знать время подачи (реальное)
2. Стоимость поездки
3. После оформления заказа — наблюдать как едет автомобиль (я написал почему).
И ещё — у Яндекса есть, например, очень крутая Ui/Ux штука — когда он предлагает, например, мне перейти через дорогу и сэкономить на поездке сколько-то рублей.
fougasse
19.12.2019 15:23Зачем-то всякие Уберы и простые службы рисуют, пользователю дают ощущение участия в процессе.
unwrecker
19.12.2019 14:23Во время поиска машины приложение не рисует движение. А в процессе ожидания и поездки логично передавать положение только одной машины.
fougasse
19.12.2019 15:25В процессе движения не вижу логичности в ограничении только одной машиной. Если мне нужно посмотреть что там в точке прибытия с другими машинами.
Например, мне обратно ехать через 10 минут — вариант заплатить текущему водителю за простой или отпустить и не спешить особо вызвав другого.
Кейсов очень много можно найти, если начинать продумывать удобство пользователя.gecube
19.12.2019 16:03Задача сервиса — не дать вам возможность сэкономить путем оплаты 10 минут простоя водителя, а слупить с клиента максимально денег. Или окучить Макс количество клиентов
В определенной парадигме — это может быть провокация создания новых заказов.
vladkorotnev
20.12.2019 11:26Приехал куда-то в жопу мира на 20 минут, варианты:
- Посмотрел, что машин рядом нет и не предвидится, заранее оплатил простой, получено с меня 2X+T денег.
- Вышел, сделал дела, открыл заново, офигел от ситуации, кое-как заказал — получено с меня 2Х денег, я недоволен покрытием, водитель первого захода недоволен, что обратно ехал пустым.
- (как 2, но утрированно)… открыл заново, попытался заказать, десяток раз словил дулю — позвонил в таксопарк и уехал обычным такси, в итоге — получено всего лишь Х денег.
Так что сколько людей, столько и кейсов.
gecube
20.12.2019 11:36Да, выглядит логично, НО — как Вы посмотрите сколько машин вокруг, если во время заказа отображается (но это не точно) — только текущая машина и ее передвижение по карте? Т.е. получается — смотреть со второго телефона (пока мультиаккаунт на телефонах плохо работает)?
losse_narmo
20.12.2019 12:03Каждый раз когда я пользовался яндекс-такси и знал, что мне скоро обратно, то просто говорил это водителю и всегда он просто не уезжал.
Иногда кстати они и сами спрашивают «вы обратно скоро?»
vlivyur
20.12.2019 13:15Если машина свободна, то зачем видеть её движение (она, конечно, может двигаться к ближайшей точке притяжения, но часто они просто стоят и ждут следующий заказ)?
Qwerty710
18.12.2019 18:51То есть это просто запрос на конкретный домен? Можно через браузер всё это провернуть?
Krupnikas Автор
18.12.2019 19:09+1Да, только это POST запрос. Не сработает, если просто вставить ссылку в адресную строку, так как там исполняется GET запрос. Но можно сделать из кода странтцы на js.
kbaa
19.12.2019 05:15ff позволяет через инструменты разработчика редактировать запросы, самый простой способ
Ghool
18.12.2019 18:52+9Имхо дырка в одном: можно отслеживать, куда едет клиент, если знаешь, где и когда он сел в такси.
А показывается ли положение ЗАНЯТЫХ такси?
RaFaeL-NN
18.12.2019 23:26+2Даже если не показывается, то возможно отследить место, в котором машина станет свободной
Ghool
19.12.2019 00:14Тоже думал об этом.
Теоретически — да. А практически, машина может и не освободиться, если водитель решит закончить рабочий день.
Или если он сразу схватит нового пассажира между сканированиями.
Ну и отслеживание онлайн это совсем не то, что ты после поездки выясняешь, куда же человек ездил.
При чём история не ведётся: пропустил момент освобождения такси, и всё, данных нет
FluffyMan
18.12.2019 18:58POST запрос на /getdrivers
А так пишут?) В смысле, глагол в endpoint'е, POST вместо GET на получение списка и дублирующий `method: getdrivers` в теле запроса.fastmeow
18.12.2019 21:31-1Если я правильно понимаю, в GET запросе параметры можно передавать лишь в query либо в header-ах, при этом в POST (PUT, etc.) доступен «payload» — body. И вот насколько мне известно передача данных в payload-е секьюрнее с точки зрения возможности отследить что ты и куда отправляешь на уровне просмотра твоего трафика. Но это не точно.
gecube
18.12.2019 21:36-1Чуточку секурнее. А ещё можно струячить не http, а grpc запросами, которые то же самое, но лучше. А к чему это я. Gprc уже без спец знаний и средств просто так не распарить. А эффективность может быть выше (компактнее хранение)
Tangeman
18.12.2019 22:21+1в GET запросе параметры можно передавать лишь в query либо в header-ах
Вы удивитесь (как удивился в своё время я сам) — в GET можно использовать body, спецификация это не запрещает. Неплохое обсуждение тут.
Проблема может быть только с (кэширующими) прокси, которые используют старую спецификацию (где «смысл» GET запроса определялся исключительно URI, а тело игнорируется).fastmeow
18.12.2019 22:28Это то понятно, но можно много вещей делать игнорируя спецификации. Тем более Вы сами явно выделили причину не использовать этот костыль.
Ещё одна причина почему могут юзать POST вместо GET — возможно большинство ручек подразумевают у них POST запросы, и им просто было проще вообще все запросы делать POST копипастой из других мест в коде. Т.е. внутренние парсеры, кодогенерация, и так далее мб уже были настроены под POST так что их и юзали.Tangeman
18.12.2019 23:05Это не костыль — спецификация как раз это допускает, и старая и новая, просто смысла в те времена в теле не было, всё легко влезало в URI, JSON ещё не было, XML только начинал свой путь. Новая же спецификация явно это поддерживает, поскольку «смысл» запроса уже не определяется только URI.
Посмотрите на банальные гугло-запросы хотя бы, или всякие баннерные URI и прочая (типо OAuth) — там уже доходит до килобайтов, в логи прокси и серверов иногда просто страшно смотреть (причём в большинстве случаев, кроме пожалуй отладки прокси или сервера, это бесполезные записи).
И наконец, иногда всё же хочется скрыть тело запроса (параметры) от случайного (или избыточного) логирования (ясный пень что при желании и тело можно логировать, но это и в случае POST/PUT можно).
PsyHaSTe
21.12.2019 00:29+1Вы удивитесь (как удивился в своё время я сам) — в GET можно использовать body, спецификация это не запрещает. Неплохое обсуждение тут.
Можно, но сервер не должен читать это тело. Иначе, если он отдает разный ответ в зависимости от тела он нарушает спецификацию:
Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request.
Dywar
18.12.2019 22:43Можно.
В том случае когда query string большой/сложный, это прям в REST написано.
Но в целом да, что то не так с названием.
vladkorotnev
19.12.2019 04:21У меня сейчас на столе в разборке приложение, у которого всегда
POST /, а глагол и все аргументы в QueryString, запакованном ZIP и загнанном в base64; так что пишут все вообще как хотят
arthuriantech
19.12.2019 10:22+1Так делают. 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
chyvack
18.12.2019 19:01+1«некто «3apa3a»» случаем не автор 3proxy github.com/z3APA3A?
RecruitP
18.12.2019 19:13+5Владимир Дубровин имеет профиль на хабре с несколькими публикациями.
habr.com/ru/users/z3apa3a
zenkov
18.12.2019 19:06-2> А то, что данные вроде как важные.
Вроде как да, а вроде и нет.
> можно отследить конкретного таксиста, можно отследить и его клиента
Ну и что? Сомневаюсь что Ситимобил хоть раз гарантировал приватность в этом вопросе.
> Яндекс.Такси, вот вам гора данных
ЯДу бы самому не мешало эти данные раскрыть.
recompileme
18.12.2019 19:07Практически любое моб приложение страдает подобными дырами. Многие прям в лог плюют дебаг информацией. Включая, банковские. Спасает только то, что для реверсинжиниринга моб приложений нужен уровень чуть выше консольки в хроме… Хотя, может быть и не спасает. Просто кому это действительно надо — молча пользуются.
Mugik
18.12.2019 19:38+4Защитить эти данные и вправду сложно.
Формально любая ручка, отданная юзеру — публичная. Есть телефон с приложением — значит есть и полный доступ, ограничения по лимиту обходятся через прокси.
Единственный способ защитить — это хорошее шифрование и дешифратор в приложении. Есть умельцы которые смогут реверснуть код, против такого — смена соли при каждом обновлении приложения.
Ну это ладно, можно простить, менеджеры напрягают, спринты горят, задачи еще вчера должны были быть в проде.
Но вот POST запрос на getdrivers это реально треш. К тому же вперемешку и snake и camel, неработающие радиус и лимит, еще не пойми зачем они версии каждый раз таскают прямо в теле запроса…
Если я был бы разработчиком там, мне было бы стыдно за такое. Взять 2-3 недели как техдолг и привести в нормальный вид. Самим то не стремно такой шлак изрыгать?Gutt
18.12.2019 19:44+2Единственный способ защитить — это хорошее шифрование и дешифратор в приложении.
Это не защитит данные, а сделает их получение чуть более сложным. Придётся гонять приложение в эмуляторе, подсовывая ему разные данные о местоположении и делая скриншоты, которые потом нужно будет правильно распарсить. Просто будет меньше людей, которым будет не лень это сделать.He11ion
18.12.2019 20:50+4Все можно, т.к. вообще неясно зачем эти данные приложению — достаточно отрисовать 2-3-… н «вирутальных» такси, не привязанных к реальным координатам/идентификаторам. Тут просто кривое проектирование апи/продукта.
Tangeman
18.12.2019 21:01+3Есть телефон с приложением — значит есть и полный доступ, ограничения по лимиту обходятся через прокси.
Только если нет идентификации и аутентификации. Если есть, то привязка ограничений идёт к пользователю, никакие прокси мира не помогут, а создание сотен пользователей может быть сильно затруднено или чрезмерно накладно. Опять-таки, как я уже говорил выше, легко отследить тех кто только спрашивает но никогда (или почти никогда) не заказывает.
WraithOW
18.12.2019 21:07Единственный способ защитить — это хорошее шифрование и дешифратор в приложении. Есть умельцы которые смогут реверснуть код, против такого — смена соли при каждом обновлении приложения.
Абсолютной защиты естественно не бывает, но банальные ssl pinning + firebase anonymous auth мигом повысили бы сложность с «я тут за вечерок снял траффик и наклепал скрипт» до «геморройно, ну его нафиг» для большинства любителей пошуршать там, где их не ждут.
JTG
20.12.2019 19:25+2Повысили бы сложность незначительно. Собирать собственный андроид с пасьянсом и блудницами для отключения certificate pinning сегодня не обязательно, расковырять javax.net.ssl.SSLContext полгода назад можно было с помощью xposed-модуля github.com/Fuzion24/JustTrustMe, сейчас вроде работает Frida — например, gist.github.com/cubehouse/56797147b5cb22768b500f25d3888a22, для Magisk что-то ещё было.
Hait
18.12.2019 23:54Можно поставить ограничение на количество запросов на аккаунт. В таком случае прокси не поможет
200sx_Pilot
19.12.2019 00:00Не нужно защищать данные.
Нужно отдавать пользователю ровно то, что он попросил — сколько машин рядом, и где эти машины.
Не привязывая к меткам машин какие-то ID.
И обновляя метки при каждом обращении.
А уже после заказа — конкретизировать авто до цвета, марки, модели, номерного знака, ВИН, ИНН водителя… :)
myz0ne
18.12.2019 19:53+7Опять хакер в солонку нассал. Мне кажется что точно стоит убрать id машины — уже этого будет достаточно. Но если есть фича с выбором конкретного такси для поездки — она поломается. Как вариант можно наверное после каждой поездки назначать новый ид машины (ид — который отдается в приложение); не показывать машины в поездке.
Gorodnya
18.12.2019 21:48Krupnikas, круто, что у вас не только текстовое описание, а и визуальное.
Когда я нашёл уязвимости в другом сервисе такси (Как ездить на такси за чужой счёт — уязвимости на примере одного сервиса), я видел такую же ситуацию, но не мог так хорошо расписать её. Что ж, попробую сообщить сейчас, с ссылкой на ваш пост, о результатах сообщу ;)
Lobushkin
18.12.2019 22:34-1Всем привет. Сергей, ещё раз здравствуйте. Ситимобил на связи.
Мы внимательно изучили всю ситуацию, описанную Сергеем Крупником. Мы ожидаем, что все детали найденных дефектов, а также любые вопросы касающиеся уязвимостей, будут сначала заданы нам в тикете на HackerOne (https://hackerone.com/reports/756833). В данной ситуации мы не получили всех тех деталей, которые описаны в статье, и очень ждем от автора, что в будущем вместе с ним лично будем обсуждать любые возникающие вопросы.
Теперь по существу. Отображение доступных машин поблизости без пассажиров — штатная функциональность любого приложения по заказу такси, которую на данный момент нет планов менять. Описанный баг не позволял получить данные водителей Ситимобил с пассажирами и не позволял трэкать их перемешения. В любом случае, у нас есть план технически ограничить получение подобных данных.
По условиям программы Bug Bounty мы не можем можем выплатить вознаграждение после открытой публикации уязвимости. Но от команды Ситимобил считаем важным выдать вознаграждение за сообщение об этой возможности и проделанные усилия для её описании. Мы также готовы предложить Крупнику присоединиться к инженерной команде Ситимобил. Ещё мы призываем всех специалистов, кто занимается безопасностью пользовательских данных, сообщать нам о найденных уязвимостях через сайт HackerOne. Ситимобил очень серьёзно относиться к любым найденным уязвимостям и готов сотрдуничать со всеми, кому не безразлична эта тема. Мы также готовы выплачивать достойные вознаграждения за найденные баги в наших продуктах, но в рамках правил площадки HackerOne.Mugik
18.12.2019 22:56+20Всем привет. Георгий, еще раз здравствуйте. Станислав на связи.
Я внимательно изучил информацию по предоставленной вами ссылке и не нашел там запроса деталей. Просто тикет закрыт и есть отписка. Вам сначала в тикете и написали. И почему вы лично будете обсуждать? Я как пользователь хочу знать о существующих уязвимостях, по которым какой-нибудь псих может за мной следить.BHYCHIK
19.12.2019 00:40+4Добрый вечер! Меня зовут Иван, я руководитель серверной разработки в Ситимобил.
Данное поведение не представляет угрозы для пользовательских данных. Через этот API endpoint видны только свободные машины.
Машина пропадает из выдачи в тот момент, когда водитель назначается на заказ. То есть невозможно установить точку подачи такси.
В этом можно убедиться, если обратить внимание на то, что на экране приложения машины исчезают в основном на дорогах, а не во дворах.
Допустим, если машина находится у Кремля, точка начала поездки около метро Маяковская, а точка назначения около метро Войковская,
то машина никогда не будет отображаться около метро Маяковская. Она пропадет около Кремля и появится только около метро Войковская. То есть, невозможно установить точку подачи такси.
Фактически, единственное, что можно получить через это API — местоположение свободных машин, да и то не всех.
Мы все же решили сделать защиту в виде рейтлимитов и закрытия API за авторизацию. Через это API можно собрать аналитику о месторасположении
наших машин. Как это использовать не понятно, но, теоретически, это может представлять угрозу для нашего бизнеса.
Спасибо, что обратили внимание на такое нестандартное использование нашего API.
lesha_firs
19.12.2019 01:57+1А зачем делать костыль, в виде ограничения рейтлимитов, если при установки приложения сразу запрашивается телефон. значит уже есть авторизация. спрятать API под OAuth2 и поставить райт, это лучшее решение.
1. если мы получаем рейт для акаунта можно поставить капчу…
2. можно отслеживать акаунты который подозрительно себя ведут, и пытаются навредить системе.
я откровенно не понимаю, зачем делать костыль, если это никак не упрощает посадку нового пользователя в приложения. я бы понял, если бы вы сразу показывали карту с таксистами, а потом просили регистрацию. тогда это было-бы оправданно.
CherryPah
19.12.2019 11:37Данное поведение не представляет угрозы для пользовательских данных. Через этот API endpoint видны только свободные машины.
Машина пропадает из выдачи в тот момент, когда водитель назначается на заказ. То есть невозможно установить точку подачи такси.
Иван, здравствуйте. Я почти поверил написанному вам
но меня смущает вот эта гифка из постаBHYCHIK
19.12.2019 13:32Добрый день!
Этот факт вполне объясним. Что могло быть:
1) Бывает, что пассажиры по договоренности с водителем отменяют заказы. В таком случае, с точки зрения системы водитель остается свободным.
2) Некоторые таксисты работают сразу с несколькими приложениями и во время заказа не всегда выключают поиск заказов, оставаясь для системы свободными.
Тем не менее, находясь на нашем заказе (или на чужом, если водитель не находится в режиме поиска заказа), машина не видна на карте.
worldaround
18.12.2019 23:32+2Если клиент сел, и машина пропала, а потом машина появилась в новом месте, то это не говорит о том, что клиента высадили в новом месте?
slvABTOP
18.12.2019 23:41-1Но ведь водитель просто может пойти отдохнуть, поесть. Уйти домой и еще куча причин не связанных с поездкой. Как в таком формате можно различить реальные поездки от шума?
worldaround
19.12.2019 00:43Когда вы сядете в такси, а я увижу какой id пропал из выдачи, разве я буду думать, что таксист решил вами закусить на обед?
slvABTOP
19.12.2019 00:51А как можно узнать, что водитель пропал именно потому что он назначил я ко мне на заказ (именно в момент назначения он исчезает, а не подачи авто)?
Выглядит не реалистично. Но давай так, если сможешь придумать способ как отличить пропажу водителя по причине назначение на заказ от ушёл отдохнуть, с меня односолодовый смузи. Идёт?
worldaround
19.12.2019 01:44+1Я вообще не понимаю такую постановку вопроса, что тут отличать-то. Рассмотрим ситуацию, если id действительно исчезают: сейчас пол второго ночи, ставлю карту с id'шками на запись. Моя жена (или муж) собирается в командировку. Вызываем такси в аэропорт и смотрим id того, кто пропал из карты — того, кто приехал к нам на вызов. Если id не исчез сразу при вызове, то провожаю и вижу как id все-таки исчез. Вопрос: что тут вообще надо отличать? Ну если еще и окажется, что такси появилось не в аэропорте, а у дома моего лучшего друга (подруги), то точно, значит, таксист пообедать к нему заехал.
slvABTOP
19.12.2019 09:26+1Ну то есть де-факто есть вероятностная модель которая может что-то показать, а может и не показать.
worldaround
19.12.2019 10:47Есть модель, которая может показывать раз за разом одно и тоже (в случае длительной измены). Так что сомнения в достоверности снимаются за какое-то время. Плюс к тому, есть возможность сделать сервис наподобие флайтрадара, где любой человек мог бы особо не напрягаясь пробить всякую такую информацию задним числом.
IMnEpaTOP
19.12.2019 09:48+1Сценарий 1 – мы знаем конечную точку:
Допустим мы магазин, концертный зал, кружок по хоровому плетению лаптей. В таком случае постоянно собирая статистику по местам «исчезновения» и появления машин мы можем выделить машины, которые появлялись у нашей геопозиции перед началом встречи/сеанса/семинара и вычислить примерные районы, в которых эти машины находились в момент бронирования. Собрав статистику за несколько месяцев, если посещаемость заведения не крошечная, получим тепловую карту местности, откуда к нам выезжают наши посетители (это может быть как место их проживания, так и место работы). Посетитель не давал нам никаких согласий, при этом мы узнали, что есть выборка из «того стрёмного коттеджного посёлка» или постоянные клиенты из компании N. Дальше с этими данными можно делать много всего.
Сценарий 2 – мы знаем примерное место и время отъезда клиента:
Конец мероприятия, камера на выходе из учреждения, недоверчивый супруг и т.п. Эти сценарии предполагают достаточно точное информирование о времени и месте вызова машины. Соответственно мы можем, основываясь на вычисленной нами плотности машин по местности, выставлять динамическое сканирование статуса машин в определённом радиусе от точки (отсекая необходимость сканировать весь город, экономя запросы и повышая дискретизацию). Записываем все «пропавшие» машины за предполагаемый период от вызова до посадки, ищем точки, в которых машины всплыли. Теперь у нас есть всего несколько вариантов того, куда человек приехал. Собираем статистику или делаем предсказания, которые сравниваем с фактическими данными.
Сценарий 3 – мы можем работать и с двух концов:
Сначала мы сработали по сценарию 1, затем мы фиксируем момент выхода и, зная собственную геопозицию, вычисляем, куда наши посетители разъехались (сценарий 2). Если мы можем идентифицировать наших посетителей, то за несколько посещений, когда кто-то был, а кого-то не было, и, сделав поправку на построение человеком шаблонов в расписании дел на неделю, мы сможем не просто составить тепловые карты, но вычислить конкретные районы откуда к нам приезжает конкретный посетитель и куда уезжает. Даже если посетителей мы не идентифицируем, это даёт вместо набора районов с вероятностью того, откуда и куда едет посетитель получить конкретные цифры и типичные маршруты. А имея типичные маршруты можно продолжать выстраивать их в обе стороны. А имея достаточно длинный маршрут можно вычислить личность человека.
Не секрет, что множество вай-фай точек используется для трекинга прохожих, посетителей и т.д. Если у нас есть к ним доступ, то это значительно уменьшит объём данных, которые необходимо собрать до однозначного вычисления конкретного человека в сценариях 2 и 3.gecube
19.12.2019 09:56Знаете, все правильно пишете. И это является как бы не совсем санкционированный способом применять API. Насколько я понимаю, его натянуть на взлом и нарушение работы информационных систем не получится, но вот по собранным данным сделать какие-то интересные выводы (Вы сами написали как) — можно. Решение для ситимобила — очевидно — закрывать, ограничивать доступ к апихе.
Но вообще я про другое хотел написать. Люди сами добровольно сдают свои данные, включая данные о координатах, о своем образе жизни куче других сервисов. Например, забежал ты на обеде в рабочий день в кафешку, и сфотался в 4square или Инстаграме. Все. Готово. Можно немного посоцинженерить и найти все (IMnEpaTOP
19.12.2019 10:36В данном случае пользователи осознанно или небрежно не предоставляли свои данные третьим лицам. Но из-за особенностей работы сервиса, которые создали сами разработчики, третьи лица могут собрать набор данных, который в определённый момент количественного роста приведёт к качественному скачку и позволит получить персональные данные. И даже в случае, если до персонализации не дойдёт — возможны иные нежелательные последствия (пример с ассоциацией с компаниями, учреждениями, особыми местами проживания).
При этом ситимобил по какой-то причине упорно делают хорошую мину.
dididididi
19.12.2019 01:58Машина становится исчезает не когда посадила клиента, а когда приняла заказ. ТО есть в радиусе пары километров от точки посадки. Выборка усложняется.
С место высадки также, я так пониманию можно увидеть точное место высадки, при условии, что водитель не успел схватить новый заказ в пути, от этого же или другого агрегатора. Там можно только гадать как это работает. Т.е. точек то много, можно какую-то статистику пособирать наверно, но конкретного Васю вычислить сложно.worldaround
19.12.2019 02:06+1Может быть сложно сделать систему, которая даст результат в 100 случаях из ста, но то, что система дает возможность в каком-то случае успешно провести слежку — с этим не поспоришь. Может быть не днем на Красной площади, но ночью в частном секторе — запросто.
gecube
19.12.2019 09:40Вы бы лучше подумали вот о чем. Очевидно, что все сервисы такси внутри себя содержат информацию о:
— перемещении клиента
— информацию о формах оплаты
Это все можно посмотреть в приложении. Значит, есть апишка, которая позволяет это вытащить. Очень интересно было бы на нее посмотреть и понять насколько она надёжно и/или безопасно написана. А вдруг в ней дыры и можно подсмотреть данные другого клиента )
Хотя о чем это я. Наверняка, если там дыры, то они уже кем-то активно эксплуатируются втихую и статьи на хабр не будет.
А ещё интересный вопрос — можно ли провести атаку вида — вводим чужой аккаунт, а потом угадываем код подтверждения — у нас же по сути только один фактор для входа в приложение — это или смс при первоначальной регистрации (от 4 до 6 псевдорандомных цифр) до токена, который сохраняется в самом приложении на телефоне «насовсем». И, да, все эти программы позволяют работу с нескольких телефонов. По крайней мере как я помню. И как снести программу удаленно, если телефон, например, украли?worldaround
19.12.2019 10:59Сейчас был на почте, оказалось, что у них и программы нет, которую надо сносить. Придя с ворованной сим-картой, можно получать посылки без паспорта.
gecube
19.12.2019 11:01Только при условии, что Вы сами подписались на «упрощенный способ» получения почтовых отправлений. Вроде бы если нет этого — только по паспорту, по старинке.
Я уж не говорю о том — откуда возьмется ворованная сим-карта.worldaround
19.12.2019 11:21Программу такси удалять надо тоже только, если сам ее установил и сам в нее банковскую карточку прописал. А ворованная симка из ворованного телефона, «если телефон, например, украли».
dom1n1k
19.12.2019 15:25Почта почти насильно переводит всех на получение по смс. А иногда даже и просто молча и не спрашивая — был свидетелем. Если вы хотите получать по паспорту, вам придется регулярно и очень настойчиво отказываться.
Novikofff
19.12.2019 11:34На почте можно с любой сим картой получать посылку без паспорта если у нее «Упрощенный способ»
progman_rus
19.12.2019 13:09Зачем приложению показывать местоположение машин?
Достаточно информации, что в радиусе R от вас Х машин. Из них х1 премиум, х2 — бизнес, х3 — эконом. Ожидаемое время подачи машины t минут.
Заказывать будете?
profit.
Dywar
18.12.2019 22:53Оставлю тут.
Читал про возможности защититься шифрованием того что клиент все равно должен прочитать.
Ади Шамир (Adi Shamir), один из создателей RSA.
Первый закон Шамира гласит: систем с абсолютной безопасностью не существует и никогда не будет существовать.
Второй закон Шамира гласит: криптографию не сломают, ее обойдут.
Шамир — устранить все возможные уязвимости в конкретной программе ныне так же бессмысленны, как и 30 лет назад.
Возможно лучшее из того что уже писали, это подкрутить само общение клиента и сервера. Без усложнения логики, и без наворотов вроде отслеживания брутов и ложных блокировок.
DurRandir
18.12.2019 23:30+2А еще у Ситимобила худшее в Москве управление качеством сервиса — их машины неоднократно игнорируют пешеходные переходы/красный свет, а в ответ поддержка по телефону говорит «ну, пишите жалобу в полицию». Ты же Я.Такси обрабатывают и реагируют по таким заявкам с сайта.
nlykl
19.12.2019 19:49А вот я Драйв не реагирует. По телефону просят писать в Телеграм, а там игнорируют.
worldaround
18.12.2019 23:40+2Так, хорошо, разобрались, все машины можно посмотреть. А как с тем, чтобы попробовать создать заказы для всех машин одновременно?
kbaa
19.12.2019 05:28вот эти ситуации, когда какие-то данные можно получить подсмотрев запросы — они ну очень распространенные на самом деле
а вот что за такое можно получать вознаграждение по bugbounty — надо запомнить
ну и визуализация, да, красиво :)
AllexIn
19.12.2019 09:19+1Нельзя получить.
«Это не баг, это публичные данные!»
…
«Ой, а что, публичные данные могут быть опасными?! А что же вы нам не сказали!!!»
NeiroNx
19.12.2019 08:03Авторизация, сессии — нет не слышали. По моему только приложение должно иметь туда доступ.
AjnaGame
19.12.2019 14:43И? Берём сессию приложения и получаем точно такой-же результат. Вопрос не в сессии, а об ограничении потоковых запросов
Eswcvlad
19.12.2019 14:59А что мешает с приложения ключи стянуть?
Варианты "пусть только приложение может делать запросы" просто заканчиваются эмуляцией либо извлечением ключей из бинаря.
Я не специалист по ИБ, но без деградации функционала в голову только рейт лимиты и анализ активности приходят, но от кучки проксей это тоже мало поможет.
Nickrus
19.12.2019 16:06Многие пользователи ищут такси, будучи в цейтноте. Каждая секунда ожидания дико раздражает.
Возможно разработчики всё про всё слышали, но сознательно решили отказаться от этого в пользу быстродействия.
kryvichh
19.12.2019 11:29Как я нашел способ отследить всех водителей «Ситимобил»
А я нашёл способ отследить где живёт автор статьи по КДПВ. )
peacefulatom
19.12.2019 16:05Вообще-то он эти координаты задал в запросе:
«latitude»: 55.7, «limit»: 10, «longitude»: 37.6
progman_rus
19.12.2019 13:05Я вот не понимаю зачем приложению/юзеру показывать местоположение машин?
Достаточно информации, что в радиусе R от вас Х машин. Из них х1 премиум, х2 — бизнес, х3 — эконом. Ожидаемое время подачи машины t минут.
Заказывать будете?
А вот уже в случае если заказ сделан — показывать юзеру позицию его машины.akuzmin
19.12.2019 14:11+2Uber показывает позиции машин, так оно выглядит как по мне более наглядно, чем просто информация о радиусе. Показывается даже как машина едет от своего исходного положения к заказчику. Но что-то я сомневаюсь, что там можно собрать инфу со всех машин в сети, как это удалось автору.
Qdev
19.12.2019 16:05Показывать только количество на этапе предзаказа — вполне разумный вариант, т.к. пользователю важно знать только факт возможности заказа и как далеко от него ближайшая машина. А вот когда пользователь заказал подачу, то конкретную машину можно и на карте вывести.
akuzmin
19.12.2019 17:21Вариант-то разумный, но в наше время, кроме разумности, нужно, чтобы это красиво и впечатляюще выглядело. В общем, маркетинг, который упирается в экономическую целесообразность. Наверное поэтому на этапе предзаказа дублируют найденные рядом машины и на карте, и на списке внизу.
progman_rus
19.12.2019 17:13Показывается даже как машина едет от своего исходного положения к заказчику.
ну так и показывать заказчику позицию только его, заказанной, машины.
Все остальные то зачем? Как по мне так это неинформативная каша.akuzmin
19.12.2019 17:18Вначале, до того, как заказчик выбрал машину, показываются несколько ближайших машин на карте. Заказчик может кликнуть или на любую машину на карте, или на списке машин внизу. Когда заказчик сделал заказ, остальные машины исчезают и показывается только заказанная машина, а также путь, по которому она едет к заказчику.
progman_rus
19.12.2019 17:20Заказчик может кликнуть или на любую машину на карте, или на списке машин внизу.
И вот нафига это?
Чем одна единственная кнопочка «заказать» хуже? Автоматически система находит ближайшую свободную машину выбранного класса и осуществляет подачу.akuzmin
19.12.2019 17:23Я думаю, всё упирается в маркетинг и в экономическую целесообразность. Uber уже много лет этим занимается, скорее всего проведены все А/В тесты на то, где и как показывать и дублировать информацию, чтобы получить максимальную прибыль.
progman_rus
19.12.2019 17:25из личного опыта: меня вполне устраивает минимализм в яндекстакси
— выбрал куда
— выбрал класс машины
— нажал «заказать»
— смотришь по карте как едет к тебе твоя машина
на мой дилетантский взгляд любое усложнение данной схемы излишнеNeikist
19.12.2019 17:33Яндекс такси тоже показывает другие машины до заказа и мне как пользователю это нравится. Не так скучно смотреть на экран заказа в ожидании.
progman_rus
19.12.2019 17:37хм… честно говоря ни разу не обращал на это внимание.
мне казалось что он показывает точку машины только после того как водитель принял мой заказ.
правда я им пользовался крайний раз полгода назад )
TheRaven
20.12.2019 17:34Есть оформившееся ощущение, что рисуются машинки чисто для красоты, просто как своеобразный лоадер «ожидайте, ищем машину» и никакого отношения к реальному расположению машин оно не имеет.
anko__2000
19.12.2019 16:02Непонятно, зачем передавать ID машины
vladkorotnev
20.12.2019 11:33Вот, да, самое банальное решение, казалось бы. Ведь машина ещё не заказана и поэтому нам нужно просто облако точек, в которых рисовать маркеры.
Однако можно приблизительно всё равно отслеживать по перемещению, при достаточной доступной частоте пересканирования — даже без айдишника.
nikolayp
19.12.2019 17:43Например, подойти поближе, что бы таксист пять минут не заезжал на улочку или перейти на другую сторону дороги. Опять-таки расчет времени прибытия машины весьма приблизительный, информация о пробках тоже, а тут я вижу состояние пробки и иногда понимаю, что с той улочки ему выезжать минут 15, а не 3 как показывает приложение и еду на метро.
krasnikov_max
19.12.2019 16:04я считаю если б не
mail.ru позволяет мне делать все несколько тысяч запросов за минуту с одного и того же ip.
то такой картины не было=)
projectsolution
19.12.2019 16:04Попробовал протестировал. Отправил координаты центра Новосибирска:
{ "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 } }
В чем причина?
rsync
19.12.2019 16:04Есть данные которые приходится сознательно делать без авторизации. То что нашел автор — именно пример таких данных.
Смотрите: с точки зрения маркетинга пользователю показывать кнопку «регистрация» лучше всего не на первом экране приложения, а где-то там где он уже собрался купить услугу. То есть вместо кнопки «вызвать такси» в данном случае.
То есть взять под авторизацию эти данные нельзя.
Теперь можно ли их защитить от вот такого скачивания скриптом. Тоже нельзя. Если установить ограничения на скачку на IP то пострадают пользователи мобильных сетей (их операторы пускают через небольшие пулы IP). Если выдавать сессионные куки, то в скрипте никто не мешает их переполучать.
В общем вот такая информация сознательно остаётся без авторизации. И если автор поищет — найдёт такую же у других операторов такси.4lex
19.12.2019 17:43Да, я тоже проверил и нашел тоже самое для сервиса в своем населенном пункте.
Самое забавное, что сам сервис — это аутсорс, который предоставляет приложение для диспетчера/таксиста/клиента за фиксированную цену в месяц. И работает он в России, Украине, Белоруссии и т.д.
Tangeman
20.12.2019 15:49+2Смотрите: с точки зрения маркетинга пользователю показывать кнопку «регистрация» лучше всего не на первом экране приложения, а где-то там где он уже собрался купить услугу.
С точки зрения пользователя следующая за таких подходом кнопка будет «удалить приложение».
Или я могу заказать «без регистрации и смс» (хотя бы раз), либо мне нужно регистрироваться, всё остальное начинает вызывать подозрение что операторам не на чем больше зарабатывать, со всеми вытекающими.
Но даже в этом случае, можно ограничить информацию — не показывать точное положение машин на карте, таким образом ничего не раскрывая, или не показывать их вообще, ограничившись более общей информацией (в духе «в радиусе 3 кварталов от вас более 20 свободных машин»).
В конце концов, когда человек заказывает такси просто по телефону, у него не требуют регистрации, и даже карту не показывают, не говоря уже о машинах в его районе — и ничего, работает прекрасно.
Если установить ограничения на скачку на IP то пострадают пользователи мобильных сетей (их операторы пускают через небольшие пулы IP).
Какова вероятность что одновременно хотя бы несколько десятков пользователей в одной мобильной сети в одном пуле (т.е. примерно рядом друг с другом) воспользуются приложением в первый раз?
Впрочем, даже это решается элементарно — информация о положении банально кэшируются, и все запросы в течение 30 секунд получат одинаковый ответ. В конце концов, точное положение машин совершенно неважно, и готов поспорить что если специально не копать то никто ничего не заметит при таком подходе, и на качестве услуг это тоже не скажется.
Killarium
19.12.2019 16:04Вот пример с наркотиками, находим тех кто работают физически дольше чем нормальный человек продолжительное время, смотрим за такими водителями и вуаля ниточка к наркотрафика приоткрыта
preslilvs
19.12.2019 16:04Что то зачастили со снифингом траффика такси, хорошо хоть у Сити мобил нельзя по апи оплачивать без авторизации, а то автор прецедент бы создал на много серьезнее.
YegorP
19.12.2019 16:05Сертификаты в приложениях лучше запинивать — это поднимает планку для перехвата трафика.
iEfimoff
19.12.2019 16:05Напоминает поиск покимонов в Pokimon Go.
3apa3a знакомый ник, похоже с cracklab :)
О еще были статьи от Ms-Rem и wasm ru — лучшее время.
У mail.ru бывают серьезные баги. Я находил баг в vk, можно было узнать какую рекламу показывают любому пользователю вк.
JacobL
19.12.2019 16:45А реально(насколько сложно) получить стоимость заказа из точки А в точку В? А то надоело руками проверять :)
myz0ne
19.12.2019 17:20СравниТакси? Приложение для телефонов. Или надо программно?
JacobL
19.12.2019 17:23Было бы круто программно, чтобы самому поиграться.
myz0ne
19.12.2019 18:28+1Я обычно использую 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'
kirill89
19.12.2019 17:03Помню в компании, где я работал делали защиту от такого скрейпинга для какой-то геолокационной игры:
— аккаунт привязан к телефону
— запросы API с токеном пользователя
— можно рассчитать расстояние между координатами запросов, и если пользователь «двигается слишком быстро» — банить его на 10 минут
pyrk2142
19.12.2019 17:06Как-то год назад заказывал такси в области, нашел для этого приложение от компании, которая клепает приложения для различных таксопарков и компаний десятками. Один API на всех, одна общая проблема — четырехзначный код из СМС, отсутствие защиты от брутфорса. Отдельно забавно то, что сначала можно определить существующих клиентов, потом подобрать код к каждому аккаунту. А там привязанные карты, история поездок, бонусы и корпоративное такси. Потом мне рассказали о схожей проблеме с доступом в интерфейс админа и диспетчера, довольно весело. И на письма они решили не отвечать.
skygad
19.12.2019 17:31А зачем вообще пользователю показывать машины рядом? Он всё равно не может назначить себе конкретную машину.
Давайте показывать только ту, которую система назначила пассажиру, и проблема решена.
myz0ne
19.12.2019 18:13+2Впервые проявил активность и сразу насрали в карму. Следующую статью предлагаю написать про яндекс такси с предложением парсить их представителям Ситимобил. Точно такой же запрос без авторизации. Точно так же возвращаются ид машин. Рейтлимит не проверял, скорее всего его нет.
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" } ] } ] }myz0ne
19.12.2019 19:11Хочу добавить: это не критика автора статьи, статья очень крутая, я восхищен анимацией, собранной статистикой и слогом. Больше тут недоумение реакцией и критикой сервиса такси. Каммон, это действительно не та информация, которую стоит как-то сильно защищать.
C_21
20.12.2019 03:301. Получить почти точное количество машин конкурента на линии.
2. Вычислить водителей работающих на два лагеря.
Имея полученные данные можно корректировать бюджет для борьбы с конкурентом и в случае чего не потратить лишние деньги например.
krasnikov_max
20.12.2019 06:05Почитал бы статью про gmail. Т.к. используется как корпоративная…
особенно по поводу моментат.е. любой может написать от вашего адреса почты.
myz0ne
20.12.2019 12:19Статью не обещаю. Напишу только что
1) если почта корпоративная — все записи dkim+spf+dmarc настраивает ваш админ на вашем домене. И он волен крутить ручки как угодно. Другое дело что строгие правила редко где нужны. (Лучше пусть кто-то напишет от вашего имени чем письмо не дойдет).
2) у гугла так сделано потому что если сделать более строгие требования есть большие шансы что поломается почта у тех кто пользуется пересылкой (а вы не хотите чтобы ваша почта терялась)
Видимо гугл на домене gmail уповает на другие механизмы защиты от спама.
Buuuu730
20.12.2019 12:51О и правда! Спасибо. Можно и на водил я.такси посмотреть. Странно, что автор это проигнорировал, с двумя агрегаторами вышло бы интереснее)
Kobzar_habr
20.12.2019 12:51-1Вроде грамотный человек, а пишет (как и многие написали бы): «Информацию о 10 ближайших водителях к геопозиции можно получить...», когда по правилам русского языка надо писать «Информацию о 10 ближайших к геопозиции водителях можно получить...» Спросите, какая разница? Для вас – никакой.
rsashka
Оставайтесь на месте. За вами уже выехали ;-)
DarthVictor
Он скорее всего в курсе, маршрут-то показывается.
itisapachee
У автора данного поста возможно развитие таксистофобии, каждый таксист подъезжающий к его дому теперь вызывает опасения
hellmagic
Судя по ответу ситимобил, что не показывается маршрут такси с пассажирами, можно отследить момент ухода конкретной машины в «тень» и появление снова в новой точке. Это как минимум будет означать точку старта и финиша.
Вывод — если машина\машины регулярно забирает увозит по определенным точкам, значит можно вычислить и время отсутствия человека. Что так же является относительно важной информацией из серии персональных данных.
fougasse
Что не мешает каршерингам в Европе делать так же и не страдать от раскрытия персональных данных.
Krupnikas Автор
Если машина в одном месте пропадает, а в другом появляется, то это ли не "Таксипортация"?