Заблокируйте доступ пользователя к внутренним частям сайта, используя HTTP_REFERER

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

Итак, я решил заблокировать пользователей на основе значения 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)/.+и оно сработало настолько хорошо, что мои пользователи были заблокированы независимо от того, перемещались они по сайту или нет.

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

6.08.2008 14:44:09
9 ОТВЕТОВ
РЕШЕНИЕ

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

Во-первых, я хочу повторить то, что я думаю, что вы говорите, и убедиться, что я ясно. Вы хотите , чтобы запретить запросы servlet1 и servlet2 это требование не имеет надлежащего реферер и делает есть строка запроса? Я не уверен, что понимаю (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]

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

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

2
6.08.2008 18:41:13

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

1
6.08.2008 14:49:13

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

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

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

0
6.08.2008 15:00:15

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

1
6.08.2008 15:02:26

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

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

1
6.08.2008 15:10:37

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

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

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

1
6.08.2008 15:08:30

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

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

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

0
6.08.2008 15:32:11

Чтобы сделать вещи немного более понятными:

  1. Да, я знаю, что использование HTTP_REFERER совершенно ненадежно и несколько по-детски, но я уверен, что люди, которые научились (от меня, может быть,?) Автоматизировать работу с Excel VBA, не будут знать, как нарушить HTTP_REFERER в течение определенного периода времени, чтобы иметь окончательное решение.

  2. У меня нет доступа / привилегий для изменения кода приложения. Политика. Ты веришь, что? Поэтому я должен подождать, пока правообладатель внесет изменения, которые я запросил.

  3. Из предыдущего опыта я знаю, что запрошенные изменения потребуются в течение двух месяцев, чтобы войти в производство. Нет, бросая их Agile методологии Книги в их головах ничего не улучшили.

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

Пока что лучший ответ приходит от «Мишеля де Маре»: блокировать пользователей на основе их IP-адресов. Хорошо, что я сделал вчера. Сегодня я хотел сделать что-то более общее, потому что у меня много пользователей кенгуру (переход с IP-адреса на другой), потому что они используют VPN или DHCP.

0
6.08.2008 15:58:14

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

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

0
27.01.2013 12:44:43