Защита json данных передаваемых с сервера?

Question

[Shums]

В современных сайтах, когда все большая часть рендеринга переходит на сторону браузера, server-side выступает только в роли передачи данных (в json формате например). Это превращает server-side в некий API (запрос -> выдача структурированных данных)


Столкнулся с проблемой, что таким образом множество данных может быть просто утянуто с сайта без всякого парсинга html страниц.


Если на сайтах с авторизацией проще обойти такие вещи, то как быть с сайтами где авторизации нет?

Например: сайт-доска обявлений: конкурентам будет легко и удобно вытащить всю информацию и занести на свой сайт.


Есть ли какой-то механизм определить что данные отдаются только что загруженной странице с моего сайта, а не стороннему грабберу данных?

Answer 1

[Алексей Сундуков]

Нужно понимать, что если идет предоставление данных публично, то все эти ухищрения — попытка удержать воду в решете. Конкурентов нужно давить более высоким уровнем сервиса на своем ресурсе, а не втыкать палки в колеса посетителям с опасностью попасть в легитимного пользователя который плюнет и уйдет в конкуренту.

Comments

[Shums]

Естественно фанатизмом заниматься никто не будет. Ищется простой способ вставить палки в колеса тем, кто захочет разом стянуть всю информацию

[Алексей Сундуков]

Кто занимается грабингами сайтов те давно уже имеют на каждую возможную палку контрпалку. Так что все эти защиты от грабинга не защищают, ведь конкуренты не сами грабят, а наверняка нанимают людей занимающихся этим профессионально (на фрилансру таких заказов много, как и желающих их выполнить). Поэтому все палки отразятся не на них, а на посетителях сайта.

Answer 2

[veikus]

Как уже сказали выше — на каждую защиту найдется возможность ее обойти. Но вот несколько вариантов:
1) Самое простое — ограничение на количество запросов с одного IP
2) При загрузке HTML странице в сессию записывайте какое-нибудь значение таймера, а при запросе json проверяйте как давно пользователь открывал страницу.

И пожалуй наиболее важный пункт
При обнаружении запросов от бота — блокируйте не все запросы, а только случайные (а лучше отдавайте левые данные) — тогда сложнее будет отследить какие изменения в алгоритме бота приводят к ошибке.

Answer 3

[kirsan_vlz]

1) А каким образом вы сможете защитить данные на сайте без авторизации от вытягивания их html-парсером, то есть как бы вы защищали ваш пример, если бы он не использовал ajax?
2) Можно для каждой страницы генерировать некий токен, который будет передаваться вместе с запросом к api. Но что будет мешать боту сначала загрузить страницу, спарсить с неё этот токен и использоавть его для запроса к api? Таким образом возвращаемся к пункту (1) — как бы вы защищали сайт без авторизации пользователей, если бы он не использовал ajax?

Comments

[Shums]

1) парсить html страницы накладнее. Не у всех есть будет время и желание этим заниматься. А при развитии сайта и изменении разметки страниц — на парсинг и его настроку придется постоянно тратить время. Не все будут готовы действовать этим варинатом, но вот ajax данные не только в голом, еще и в удобном виде.

2) вопрос с токеном к странице рассматривался, но естественно всплыл тот же вопрос о парсинге токена из страницы.

хочу добавить, что целью ставится лишь усложнить жизнь таким умельцам — возможно у части это просто отобъет охоту, сливать данные с сайта

[kirsan_vlz]

Если просто усложнить, то можно данные передавать в зашифрованном виде, а функцию расшифровки встраивать в страницу. Алгоритм шифрования не обязательно делать сложным, достаточно будет того, что боту придётся найти на странице этот алгоритм (который может быть обфусцирован и по имени его не вызовешь), потом раскодировать им сообщение и только тогда пользоваться. А если предусмотреть штук десять алгоритмов, выдавать их рандомом и периодически пополнять, то страницы парсить будет гораздо проще )

Answer 4

[Анатолий]

Поверьте, никак, я занимался именно утаскиванием данных, и скажу Вам наверняка: на каждую защиту таких данных есть новая лазейка чтоб вытащить их, забейте, это невозможно, «злодей» может подделать любые залоговки, учитывая протокол, вы не сможете проверить их достоверность

Answer 5

[Kakysha]

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

Answer 6

[hayk]

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

Answer 7

[AleksDesker]

Разницы между HTML и json нет, чтоб прикрутить что-нить вроде simplehtmldom.sourceforge.net/manual.htm уйдет 2 минуты лишних. Если очень хотите заняться security through obscurity, переделайте синтаксис ясона, во что-нить вроде <!!Key!!>Value<*><!!Key2!!>Value2<*> и меняйте его каждый день, но лучше найти более полезное занятие для себя.

Answer 8

[nutz]

Соглашусь с тем, кто говорит, что надо не данные защищать, а делать их граббинг ненужным.
Но все же летает одна мысль в голове. Смысл в следующем.
Сделать некий модуль, например, на флеше (либо что-то другое, что нельзя потом открыть просто и посмотреть что внутри), который будет делать запросы на сервер и при получении ответа вызывать указанную функцию js. Сервер по запросу будет формировать каким-то образом зашифрованный контент, а модуль его расшифровывать и передавать в колбэк результат.
То есть, если раньше использовался jquery для ajax-запросов, примерно так
$.get('/get.php', {module: 'module'}, function(data){
console.log(data)
}, 'json');
То теперь это можно будет заменить на вызов метода обертки для этого флеш-модуля не меняя логику всего приложения.
К сожалению с флешом не знаком вообще, поэтому не уверен, что подобную схему можно реализовать. Кроме того решение с флешом не будет работать там, где флеш не установлен.

Comments

[Kir Shatrov]

Флеш успешно декомпилируется

Answer 9

[egorinsk]

Лучшая защита от граббинга — выявлять ботов, например, через логи, и банить/перенаправлять на страницу с капчей/писать абузы если сервер в Германии/посылать проклятия/подсовывать кривые данные.

Можно использовать яваскрипт для расшифровки данных (фи).

Можно выводить данные в текстовом виде, типа время в виде вчера, 4 часа назад, это чуть-чуть может осложнить жизнь.

Еще работающий вариант — сделать платным просмотр данных/части данных.

А вообще, вряд ли вы защититесь. Уверен, я бы ваш сайт на раз разграбил, если бы вдруг начал заниматься гарббингом.

Comments

[egorinsk]

Еще можно капчу спрашивать для просмотра данных)) Но и это обходится.