Заблокируйте доступ пользователя к внутренним частям сайта, используя HTTP_REFERER - PullRequest
4 голосов
/ 06 августа 2008

У меня есть контроль над HttpServer, но не над ApplicationServer или Java-приложениями, которые там находятся, но мне нужно заблокировать прямой доступ к определенным страницам в этих приложениях. Точно, я не хочу, чтобы пользователи автоматизировали доступ к формам, отправляющим прямые запросы GET / POST HTTP к соответствующему сервлету.

Итак, я решил заблокировать пользователей на основе значения HTTP_REFERER. В конце концов, если пользователь перемещается внутри сайта, он будет иметь соответствующий HTTP_REFERER. Ну, это то, что я думал.

Я реализовал правило перезаписи в файле .htaccess, которое гласит:

RewriteEngine on 

# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteRule (servlet1|servlet2)/.+\?.+ - [F]

Я ожидал запретить доступ пользователям, которые не перемещались по сайту, но отправляли прямые GET-запросы к сервлетам "servlet1" или "servlet2", используя строки запросов. Но мои ожидания неожиданно закончились, потому что регулярное выражение (servlet1|servlet2)/.+\?.+ не сработало вообще.

Я был очень разочарован, когда изменил это выражение на (servlet1|servlet2)/.+, и оно работало настолько хорошо, что мои пользователи были заблокированы независимо от того, перемещались они по сайту или нет.

Итак, мой вопрос: как мне сделать так, чтобы «роботы» не имели прямого доступа к определенным страницам, если у меня нет доступа / привилегий / времени для изменения приложения?

Ответы [ 8 ]

2 голосов
/ 06 августа 2008

Я не уверен, что смогу решить это за один раз, но мы можем идти туда-сюда при необходимости.

Во-первых, я хочу повторить то, что я думаю, что вы говорите, и убедиться, что я ясен. Вы хотите запретить запросы к сервлету1 и сервлету2, если запрос не имеет правильного реферера и у него есть строка запроса? Я не уверен, что понимаю (servlet1 | servlet2) /.+\?.+, потому что похоже, что вам нужен файл под servlet1 и 2. Я думаю, возможно, вы комбинируете PATH_INFO (перед "?") С GET строка запроса (после "?"). Похоже, что часть PATH_INFO будет работать, но тест запроса GET не будет. Я сделал быстрый тест на своем сервере, используя script1.cgi и script2.cgi, и следующие правила сработали, чтобы выполнить то, что вы просите. Очевидно, они немного отредактированы, чтобы соответствовать моей среде:

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]

Выше были перехвачены все неправильные запросы к файлам script1.cgi и script2.cgi, которые пытались отправить данные, используя строку запроса. Однако вы также можете отправлять данные, используя path_info и публикуя данные. Я использовал эту форму для защиты от любого из трех методов, используемых с неправильным реферером:

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]

Основываясь на примере, который вы пытались заставить работать, я думаю, это то, что вы хотите:

RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule (servlet1|servlet2)\b - [F]

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

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

1 голос
/ 06 августа 2008

Использование реферера очень ненадежно в качестве метода проверки. Как уже упоминали другие люди, это легко подделать. Ваше лучшее решение - изменить приложение (если вы можете)

Вы можете использовать CAPTCHA или установить какой-либо файл cookie или файл cookie сеанса, который отслеживает, какую страницу посетил пользователь в последний раз (сеанс будет сложнее подделать), отслеживает историю просмотров страниц и разрешает только пользователям просмотрели страницы, необходимые для перехода на страницу, которую вы хотите заблокировать.

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

1 голос
/ 06 августа 2008

Javascript - еще один полезный инструмент для предотвращения (или, по крайней мере, задержки) очистки экрана. Большинство автоматизированных инструментов очистки не имеют интерпретатора Javascript, поэтому вы можете выполнять такие действия, как установка скрытых полей и т. Д.

Редактировать: что-то вроде этой статьи Фила Хаака .

1 голос
/ 06 августа 2008

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

1 голос
/ 06 августа 2008

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

0 голосов
/ 20 августа 2008

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

Эта статья объясняет это более подробно: Подделка межсайтовых запросов

0 голосов
/ 06 августа 2008

Если вы пытаетесь запретить поисковым роботам доступ к определенным страницам, убедитесь, что вы используете правильно отформатированный файл robots.txt .

Использование HTTP_REFERER ненадежно, потому что легко подделывается .

Другой вариант - проверить строку агента пользователя на наличие известных ботов (это может потребовать изменения кода).

0 голосов
/ 06 августа 2008

Полагаю, вы пытаетесь предотвратить скребок экрана?

По моему честному мнению, это трудно решить и попытаться исправить, проверив значение HTTP_REFERER - это просто липкая штукатурка. Любой, кто захочет автоматизировать подачу заявок, будет достаточно сообразителен, чтобы отправить правильного реферера из своего «автомата».

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

...