Клуб API Карт

Клуб API Карт

Защита данных XML-файла от третьих лиц

Пост в архиве.

По умолчанию, любой желающий может залезть в исходники и получить адрес XML-файла, чего не очень хотелось бы.


Не разбираюсь в механизме работы, поэтому возник конкретный вопрос:

Откуда происходит обращение к XML файлу описания объектов: сервера Яндекса или клиентского компьютера?


Если с сервера Яндекса, можно было бы организовать простейшую фильтрацию серверов Яндекс.карт, чтобы блокировать доступ к данным третьих лиц: например, организовать вывод XML-файла только при запросах с определенной группы IP.

25 комментариев
Авторизуйтесь, чтобы оставить комментарий
belegnar
28 января 2016, 08:58
А в чем прикол ограничивать доступ к данным, которые и так визуализируются?
Raunlach
28 января 2016, 08:58
Это не прикол, а правила хорошего тона, особенно, когда дело касается каких-либо личных данных пользователей. ------------------------------------------------------- Пример 1: вы создаете сервис социальной сети, отображающий гео-информацию о пользователях. Де-юро вы должны в правилах пользования сайтом прописать, что пользователь соглашается на использование его личных данных в рамках работы интернет ресурса. А со своей стороны, пообещать, что сделаете все, чтобы информация не утекла. Но как только вы сделаете выгрузку XML - вы выдаете выводимые личные данные буквально на блюдечке, в разжёванном виде, да еще и группой. Пример 2: у вас супер-ресурс о скидках и акциях с сервисом гео-визуализации. Все бы ничего, но весь ваш сервис строится на том, что вы кропотливо собираете информацию по всему городу. Эксклюзивность базы - ваше основное конкурентное преимущество. Гео-сервисы - отличное подспорье в борьбе за качество услуг. Однако выставить базу в XML - все равно, что слить всю базу конкурентам. ----------------------------------------------------------- Интернет - это территория свободы. Но твоя свобода заканчивается там, где начинается ущемление свободы других или появляются деньги. В этом случае должна появится ответственность и элементарные нормы "поведения". Открытый XML - это как привычка ходить по улицам голой у девушек: она может быть и красивая, и посмотреть приятно, но вот когда она каждый вечер будет проходить мимо темного сквера, вероятность успешного возвращения домой будет резко падать. Так что, прежде чем открывать на всеобщее обозрение баззы данных своего интернет ресурса. стоит подумать, к чему это может привести.
belegnar
28 января 2016, 08:58
Как все сложно... Только дело в том, что единственный способ защитить визуализированные данные от роботов - выдавать графический файл. И то, в случае с картой его будет достаточно просто разобрать. Излишество это, но если Ваше время ничего не стоит - вольному воля. =)
Raunlach
28 января 2016, 08:58
Мое время стоит дорого, но еще дороже стоит защита данных :)
belegnar
28 января 2016, 08:58
Зачем защищать то, что защите не подлежит? =)) Даешь открытую информацию!
Raunlach
28 января 2016, 08:58
...и мир во всем мире ;)
wasteatime
28 января 2016, 08:58
Я могу дико ошибаться, но карта работает на клиентской машине, обращения за xml'ем идут от карты, xml запрашивается с клиентской машины, да? Посмотри с какими заголовками ходит карта, и поставь фильтрацию на совпадение всех (части) заголовков.
Raunlach
28 января 2016, 08:58
1) любой злоумышленник/конкурент получает доступ к сервису на уровне пользователя (ибо по лецензии вы не имеете прав ограничивать свободный доступ) 2) доступ на уровне пользователя дает возможность свободного доступа к XML с клиентской машины. Отсюда: злоумышленнику/конкуренту даже заморачиваться не надо, чтобы получить доступ к XML. Посему, основная проблема: есть ли возможность ограничить доступность данных в паре "интернет-ресурс" - "сервер Яндекс.Карты" и исключить доступ к XML, в том числе, клиентской машины конечного пользователя сервисом.
wasteatime
28 января 2016, 08:58
А в первом сообщения я о чем написал?
Raunlach
28 января 2016, 08:58
Иван, большая половина всего сообщения - была под знаком вопроса, что было воспринято мной, как повод к развернутому пояснению :) Спасибо за мысль про отслеживание заголовков, но мне надо еще разбираться, как это сделать :D Поэтому все еще надеюсь получить ответ от тех, кто знает регламент работы сервиса или уже проанализировал обращение к файлу.
Михаил Королев
28 января 2016, 08:58
а у вас неавторизованный человек может запросить XML с сервера зная урл? имхо запрашивает клиент, а раз Ваш посетитель авторизован - какие проблемы?
Raunlach
28 января 2016, 08:58
Ребят, давайте не будем разводит пальцовки для частных случаев. Авторизация - это ЧАСТНЫЙ СЛУЧАЙ, заплатка, которая в принципе не решает проблему. Да к тому же абсолютно бесполезна для сайтов с открытой регистрацией. Давайте еще скажем, что лучший способ избежать проблем - вообще отказаться от использования гео-сервисов на сайте или вовсе прикрыть сайт. Постановка проблемы была четкая: возможно ли замыкание цепочки обмена XML файлов между двумя точками: интернет сайт - сервер Яндекс.Карт - ответ пока не дан.
Михаил Королев
28 января 2016, 08:58
причём тут распальцовка? :-| попытка помочь в Вашей проблеме - не распальцовка.. по сути предложенния мысли такие: Ведь информация если открыта - то и нет вопроса о её доступности. а если юзер видит только то что ему положено - то этим рулить так-же как и доступом к странице на которой сия карта. разве не так? ну и кк вариант, можно отказаться от XML в пользу javascript api - тут возможностей контроля гораздо больше
Raunlach
28 января 2016, 08:58
:) ВСЕ составляющие Колы вы можете отыскать на любой бутылке, не говоря уже о пробе на вкус сего напитка. Но вот попробуйте найти точный список исходных ингредиентов и рецепт приготовления - это врядли. Давайте разделим доступ к исходной базе(коду) и открытость результат работы сайта (программы). Мы можем вывести базу всех Объектов на карте. Пользователь с легкостью может ознакомится и работать с ними - это открытость. Но при этом, запарится вытаскивать и сохранять информацию обо всех объектах для дальнейшего использования в своих целях. Если у нас будет открытый XML - помимо открытости информации, любой пользователь получает бесплатный доступ к точной "рецептуре" и всем составляющим вашего гео-сервиса.
Михаил Королев
28 января 2016, 08:58
тут имхо переход на javascript решит все проблемы.. по кр. мере я в магазине это сделал именно так. - покупатель уточняет место на карте куда прийти курьеру, а в админке менеджеры видят заказы на карте, могут назначать курьеров, печатать накладные с картой и тп. никаких XML-ей - всё что открыто - то видно, остальное - моё.
Raunlach
28 января 2016, 08:58
Для этой конкретной задачи - и мудрить особо не надо, потому что есть строго определенная группа пользователей(менеджеры), имеющих исключительный доступ к сводным данным по клиентам. Кроме менеджеров только сам клиент может посмотреть адрес, и то, только свой. См. два примера, которые я привел выше. Для таких типовых задач конечным пользователем сводных данных является обычный посетитель. Что делать, если задача состоит в ограничении доступа только к уже скомпилированным данным?
Михаил Королев
28 января 2016, 08:58
как яуже сказал выше - откажитесь от xml для обоих примеров и делайте на javascript всё. - подключаете нужные скрипты, а в коде страницы выдаёте нужные массивы данных для вашего javascript-a, с инфой нужной для отображения на карте только этой страницы. ну и по onload - всё что надо отобразится на карте. если хочется запутать конкуретнов - выдавайте в массив искаженные данные чтобы их js компилил в нужные - но это имхо излишне. не вижу проблемы с реализацией такого подхода. убить время на написание функций отображения из массивов, после этого - "всё как по маслу" если совсем страшно - подкачивайте данные аяксом по мере необходимости, вообще без прямой выкладки массивов в код.
Raunlach
28 января 2016, 08:58
да, про мысль про чистый javascript - спасибо, уже взял на заметку :)
webliveby
28 января 2016, 08:58
А как насчёт Шифрование XML-документов Спецификации W3C о шифровании XML Перейдем к шифрованию, которое позволяет нам закрыть (то есть преобразовать в такой вид, при котором будет непонятен смысл) передаваемые данные и восстановить их на принимающей стороне. В консорциуме W3C создана рабочая группа (http://www.w3.org/Encryption/2001/), которая специально занимается вопросами шифрования XML-данных. Спецификация «XML — Encryption Syntax and Processing» («Синтаксис и обработка шифрования XML») сегодня получила статус рекомендации и доступна по адресу: http://www.w3.org/TR/xmlenc-core/. Шифрование данных XML производится традиционными методами криптографии с открытыми ключами. Сначала шифруются сами данные, как правило, с помощью случайно формируемого секретного ключа, который затем тоже кодируется — при помощи открытого ключа предполагаемого получателя. Эта информация упаковывается так, чтобы извлечь секретный ключ и расшифровать данные мог только указанный получатель. Для дешифрования секретного ключа применяется скрытый ключ, а затем происходит дешифрование данных с помощью найденного секретного ключа.
Марат Дулин
28 января 2016, 08:58
Данную проблему не решить разграничивая доступ к XML, ведь Яндекс.Карты обработают XML и вернут его в JavaScript представлении. А ограничить доступ к JavaScript-представлению вам не удастся. Мне кажется, что в данном случае вам не подойдет YMapsML. Следует разработать собственные средства защиты.
Raunlach
28 января 2016, 08:58
Видимо, придется... )
karmatsky
28 января 2016, 08:58
Присоединяюсь к предыдущему оратору ;) Для того чтобы не давать пользователям получить сразу много данных, самый лучший способ -- это не публиковать их сразу одной большой пачкой в виде YMapsML. Да, XML-файлы запрашиваются серверами Яндекса и преобразуются в js-код.
Raunlach
28 января 2016, 08:58
Резюмирую: 1) Фильтрация доступа к XML позволит избежать только прямого доступа к данным. 2) Однако после обработки сервер Яндекс.карт отдаст эти же самые данные в виде js-кода Вывод: фильтрация доступа к XML - "защита от дурака". При должном уровне знаний JS и желания - данные все равно снимут.
Марат Дулин
28 января 2016, 08:58
При должном уровне знаний можно и прямо с карты данные снять :-)
Raunlach
28 января 2016, 08:58
))))