Ajax Security - PullRequest
       6

Ajax Security

2 голосов
/ 07 апреля 2009

У нас есть тяжелое Ajax-зависимое приложение. Каковы хорошие способы убедиться, что запрос к серверным сценариям не поступает через автономные программы, а через реального пользователя, сидящего в браузере

Ответы [ 7 ]

6 голосов
/ 07 апреля 2009

На самом деле их нет.

Любой запрос, отправленный через браузер, может быть подделан автономными программами.

В конце концов, действительно ли это имеет значение? Если вы беспокоитесь, убедитесь, что запросы аутентифицированы и авторизованы, и ваш процесс аутентификации хорош (помните, что Ajax отправляет файлы cookie браузера - так что ваша «обычная» аутентификация будет работать нормально). Просто помните, что, конечно, автономные программы тоже могут аутентифицироваться.

3 голосов
/ 08 апреля 2009

Не существует способа автоматически блокировать запросы «не пользователя браузера», затрагивающие ваши серверные сценарии, но есть способы определить, какие сценарии были запущены вашим приложением, а какие нет.

Обычно это делается с помощью чего-то, называемого "крошки". Основная идея заключается в том, что страница, выполняющая запрос AJAX, должна генерировать (на стороне сервера) уникальный токен (который обычно представляет собой хэш unix timestamp + salt + secret). Этот токен и метка времени должны передаваться в качестве параметров в запрос AJAX. Сценарий обработчика AJAX сначала проверит этот токен (и действительность метки времени Unix, например, если она находится в пределах 5 минут от метки времени токена). Если токен получен, вы можете приступить к выполнению этого запроса. Обычно эта генерация токенов + проверка может быть закодирована как модуль Apache, так что он запускается автоматически и отделен от логики приложения.

Мошеннические сценарии не смогут генерировать действительные токены (если они не выясняют ваш алгоритм), и поэтому вы можете спокойно их игнорировать.

Имейте в виду, что хранение токена в сеансе также является другим способом, но это не принесет вам больше безопасности, чем система аутентификации вашего сайта.

3 голосов
/ 07 апреля 2009

Каковы хорошие способы убедиться, что запрос к серверным сценариям не поступает через автономные программы, а через реального пользователя, сидящего в браузере

Нет способов. Браузер неотличим от отдельной программы; браузер может быть автоматизирован.

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

2 голосов
/ 07 апреля 2009

Я не уверен, о чем ты беспокоишься. С того места, где я сижу, я вижу три вещи, с которыми может быть связан ваш вопрос:

Во-первых, вы можете помешать неавторизованным пользователям сделать правильный запрос. Это решается с помощью куки-файла браузера для хранения идентификатора сеанса. Идентификатор сеанса должен быть привязан к пользователю, обновляться каждый раз, когда пользователь проходит процесс входа в систему, и должен иметь таймаут неактивности. Любой запрос приходит без действительного идентификатора сеанса, который вы просто отклоняете.

Во-вторых, вы можете запретить третьей стороне повторные атаки на ваш сайт (то есть прослушивание трафика невинного пользователя с последующей пересылкой тех же вызовов). Простое решение - перейти через https для этого. Уровень SSL не позволит кому-либо воспроизвести любую часть трафика. Это требует больших затрат со стороны сервера, поэтому вы должны быть уверены, что действительно не можете пойти на такой риск.

В-третьих, вы можете запретить кому-либо использовать ваш API (в конце концов, так называются AJAX) для внедрения своего собственного клиента на ваш сайт. Для этого очень мало что можно сделать. Вы всегда можете найти подходящего User-Agent, но его легко подделать, и, вероятно, это будет первое, что кто-то попытается использовать в вашем API. Вы всегда можете реализовать некоторую статистику, например, посмотреть на среднее количество запросов AJAX в минуту для каждого пользователя и посмотреть, не превышает ли какой-либо пользователь ваш средний показатель. Это сложно реализовать, и это полезно только в том случае, если вы пытаетесь предотвратить автоматическое реагирование клиентов, чем это может сделать человек.

1 голос
/ 07 апреля 2009

Является ли Safari браузером для вас?
Если это так, то же самое ядро, которое вы получили во многих приложениях, скажем, в тех, которые используют библиотеки QT QWebKit. Так что я бы сказал, нет способа узнать это.

Пользователь может подделать любой запрос по своему усмотрению - подделывать заголовки как UserAgent так, как ему нравится ...

Один вопрос: зачем вам делать то, что вы просите? Какая разница для вас, если они запрашивают у браузера или у кого-то еще?
Не могу придумать одну причину, по которой вы бы назвали здесь «безопасность».

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

0 голосов
/ 07 апреля 2009

Как уже упоминалось ранее, нет способа сделать это ... Но есть кое-что, что нужно отметить, полезно для предотвращения атак CSRF, направленных на определенные функции AJAX; например, установка настраиваемого заголовка с помощью объекта AJAX и проверка этого заголовка на стороне сервера.

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

0 голосов
/ 07 апреля 2009

Интересный вопрос.

А как насчет браузеров, встроенных в приложения? Вы не против?

Возможно, вы можете придумать способ «доказать», что запрос поступает из браузера, но в конечном итоге он будет эвристическим. Граница между браузером и приложением размыта (например, встроенный браузер), и вы всегда рискуете отклонить пользователей от неожиданных браузеров (или их неожиданных версий).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...