У нас есть тяжелое приложение, зависящее от Ajax. Каковы хорошие способы убедиться, что запрос на серверные скрипты не проходит через автономные программы и через фактического пользователя, сидящего в браузере.Ajax Security
Интересный вопрос.
Что касается браузеров, встроенных в приложения? Не возражаете?
Возможно, вы думаете о способе «доказать», что запрос поступает из браузера, но в конечном итоге он будет эвристическим. Линия между браузером и приложением размыта (например, встроенный браузер), и вы всегда будете подвергать риску отклонения пользователей от неожиданных браузеров (или их неожиданных версий).
На самом деле нет.
Любой запрос, отправленный через браузер, может быть сфальсифицирован автономными программами.
В конце дня это действительно имеет значение? Если вы беспокоитесь, убедитесь, что запросы аутентифицированы и авторизованы, и ваш процесс аутентификации является хорошим (помните, что Ajax отправляет куки-файлы браузера, поэтому ваша «нормальная» аутентификация будет работать нормально). Просто помните, что, конечно, автономные программы также могут аутентифицироваться.
Является ли Safari веб-браузером для вас?
Если это так, вы можете использовать тот же движок, что и во многих приложениях, только для тех, кто использует библиотеки QT QWebKit. Поэтому я бы сказал, что нет способа узнать это.
Пользователь может подделать любой запрос один хочет - фальсифицируя заголовки, как UserAgent любых им нравится ...
Один вопрос: почему вы хотите, чтобы делать то, что вы просите? Какая разница для вас, если они запрашивают у браузера или из любого другого?
Не могу придумать одну причину, которую вы бы назвали «безопасностью» здесь.
Если вы по-прежнему хотите сделать это по какой-либо причине, подумайте о создании собственного приложения с встроенным браузером. Он мог бы как-то аутентифицироваться для приложения в каждом запросе - тогда вы отправляете только действительные ответы на браузер вашего приложения.
Пользователь все равно сможет реконструировать приложение.
Каких хорошие способы сделать это убедиться, что запрос на скрипты сервера не идет через отдельные программы и через фактический пользователь сидит в браузере
Там нет способов. Браузер неотличим от автономной программы; браузер может быть автоматизирован.
Вы не можете доверять никаким данным с вашей стороны. Если вы полагаетесь на сотрудничество на стороне клиента для какой-либо цели безопасности, вы обречены.
Как уже упоминалось ранее, нет возможности выполнить это ... Но стоит отметить, что полезно для предотвращения атак CSRF, предназначенных для конкретных функций AJAX; например, настраивать пользовательский заголовок с помощью объекта AJAX и проверять этот заголовок на стороне сервера.
И если в значении этого заголовка вы устанавливаете случайный (одноразовый использование) токен, вы можете предотвратить автоматические атаки.
Я не уверен, о чем вы беспокоитесь.С того места, где я сижу, я вижу три вопроса, которые могут возникнуть у вашего вопроса:
Во-первых, вы можете запретить неавторизованным пользователям делать действительный запрос. Это разрешает использование cookie браузера для хранения идентификатора сеанса. Идентификатор сеанса должен привязываться к пользователю, быть регенерированным каждый раз, когда пользователь проходит процесс входа в систему и должен иметь таймаут бездействия. Любой запрос приходит без действительного идентификатора сеанса, который вы просто отклоняете.
Во-вторых, вы можете запретить третьему лицу совершать повторные атаки против вашего сайта (т. Е. Обнюхивать невидимый пользовательский трафик и затем отправлять одни и те же вызовы). Легкое решение - перебрать https для этого. Уровень SSL не позволит кому-либо воспроизвести какую-либо часть трафика. Это связано с себестоимостью на стороне сервера, поэтому вы хотите убедиться, что вы действительно не можете принять такой риск.
В-третьих, вы можете запретить кому-либо использовать ваш API (это то, что вызовы AJAX в конце) реализовать своего клиента на вашем сайте. Для этого вы можете сделать очень мало. Вы всегда можете найти подходящего User-Agent, но это легко подделать, и, вероятно, это будет первое, о чем подумает кто-то, кто пытается использовать ваш API. Вы всегда можете реализовать некоторую статистику, например, глядя на средние запросы AJAX в минуту на основе каждого пользователя и посмотреть, превышает ли какой-либо пользователь выше среднего. Его трудно реализовать, и это полезно только в том случае, если вы пытаетесь не разрешать автоматическим клиентам реагировать быстрее, чем люди.
Невозможно автоматически заблокировать запросы пользователей, не являющихся пользователями браузера, на ваши скрипты на стороне сервера, но есть способы определить, какие сценарии были инициированы вашим приложением, а какие нет.
Обычно это делается с использованием так называемых «крошек». Основная идея заключается в том, что страница, создающая запрос AJAX, должна генерировать (на стороне сервера) уникальный токен (обычно это хэш времени unix timestamp + salt + secret). Этот токен и временная метка должны быть переданы в качестве параметров для запроса AJAX. Сценарий обработчика AJAX сначала проверяет этот токен (и действительность отметки времени unix, например, если она попадает в течение 5 минут от метки времени маркера). Если токен проверяется, вы можете продолжить выполнение этого запроса. Обычно эта маркерная генерация + проверка может быть закодирована как модуль Apache, так что она запускается автоматически и отделена от логики приложения.
Мошеннические сценарии не смогут генерировать действительные маркеры (если только они не выясняют ваш алгоритм), и поэтому вы можете смело игнорировать их.
Имейте в виду, что сохранение токена в сеансе также является другим способом, но это не будет покупать больше безопасности, чем система проверки подлинности вашего сайта.
Вы говорите, что хотите только, чтобы люди использовали эти аякс-запросы через ваш веб-сайт через веб-браузер, а не через кого-то, делающего приложение для взаимодействия с ajax? – Shard
есть. Может ли это быть достигнуто, по крайней мере, до определенного уровня безопасности. – Rakesh
Я не могу придумать ни одного преимущества в плане безопасности, которое исходит из этого. Кроме того, нет способа гарантировать, что запрос поступает из браузера. @blowdart прав. –