Задать вопрос

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

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


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


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

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


Есть ли какой-то механизм определить что данные отдаются только что загруженной странице с моего сайта, а не стороннему грабберу данных?
  • Вопрос задан
  • 6907 просмотров
Подписаться 4 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 9
alekciy
@alekciy
Вёбных дел мастер
Нужно понимать, что если идет предоставление данных публично, то все эти ухищрения — попытка удержать воду в решете. Конкурентов нужно давить более высоким уровнем сервиса на своем ресурсе, а не втыкать палки в колеса посетителям с опасностью попасть в легитимного пользователя который плюнет и уйдет в конкуренту.
Ответ написан
veikus
@veikus
Как уже сказали выше — на каждую защиту найдется возможность ее обойти. Но вот несколько вариантов:
1) Самое простое — ограничение на количество запросов с одного IP
2) При загрузке HTML странице в сессию записывайте какое-нибудь значение таймера, а при запросе json проверяйте как давно пользователь открывал страницу.

И пожалуй наиболее важный пункт
При обнаружении запросов от бота — блокируйте не все запросы, а только случайные (а лучше отдавайте левые данные) — тогда сложнее будет отследить какие изменения в алгоритме бота приводят к ошибке.
Ответ написан
Комментировать
@kirsan_vlz
1) А каким образом вы сможете защитить данные на сайте без авторизации от вытягивания их html-парсером, то есть как бы вы защищали ваш пример, если бы он не использовал ajax?
2) Можно для каждой страницы генерировать некий токен, который будет передаваться вместе с запросом к api. Но что будет мешать боту сначала загрузить страницу, спарсить с неё этот токен и использоавть его для запроса к api? Таким образом возвращаемся к пункту (1) — как бы вы защищали сайт без авторизации пользователей, если бы он не использовал ajax?
Ответ написан
taliban
@taliban
php программист
Поверьте, никак, я занимался именно утаскиванием данных, и скажу Вам наверняка: на каждую защиту таких данных есть новая лазейка чтоб вытащить их, забейте, это невозможно, «злодей» может подделать любые залоговки, учитывая протокол, вы не сможете проверить их достоверность
Ответ написан
Комментировать
Kakysha
@Kakysha
Вы похожи на фанатика, который не очень смыслит в делах программистских, но считает его идею сверхгениальной и тут же заботится о защите своих данных. Нет смысла заморачиваться на этом, вам дали отличный совет — придумайте что-нибудь такое, чтобы конкурентов не бояться.
Ответ написан
Комментировать
hayk
@hayk
Если вы хотите защититься от грабберов, то вам стоит в своем приложении придумать правила, согласно которым оно сможет отличать людей от роботов, и банить последних. Правила могут быть основаны на анализе порядка действий, частоте запросов (человек например информацию обычно читает), юзерагенте, реферере (вернее его наличие или отсутствие) и т.д.
Ответ написан
Комментировать
AleksDesker
@AleksDesker
Разницы между HTML и json нет, чтоб прикрутить что-нить вроде simplehtmldom.sourceforge.net/manual.htm уйдет 2 минуты лишних. Если очень хотите заняться security through obscurity, переделайте синтаксис ясона, во что-нить вроде <!!Key!!>Value<*><!!Key2!!>Value2<*> и меняйте его каждый день, но лучше найти более полезное занятие для себя.
Ответ написан
Комментировать
@nutz
Соглашусь с тем, кто говорит, что надо не данные защищать, а делать их граббинг ненужным.
Но все же летает одна мысль в голове. Смысл в следующем.
Сделать некий модуль, например, на флеше (либо что-то другое, что нельзя потом открыть просто и посмотреть что внутри), который будет делать запросы на сервер и при получении ответа вызывать указанную функцию js. Сервер по запросу будет формировать каким-то образом зашифрованный контент, а модуль его расшифровывать и передавать в колбэк результат.
То есть, если раньше использовался jquery для ajax-запросов, примерно так
$.get('/get.php', {module: 'module'}, function(data){
console.log(data)
}, 'json');
То теперь это можно будет заменить на вызов метода обертки для этого флеш-модуля не меняя логику всего приложения.
К сожалению с флешом не знаком вообще, поэтому не уверен, что подобную схему можно реализовать. Кроме того решение с флешом не будет работать там, где флеш не установлен.
Ответ написан
@egorinsk
Лучшая защита от граббинга — выявлять ботов, например, через логи, и банить/перенаправлять на страницу с капчей/писать абузы если сервер в Германии/посылать проклятия/подсовывать кривые данные.

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

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

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

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

Войдите, чтобы написать ответ

Похожие вопросы