Блокируйте пользовательский доступ к внутренностям сайта с помощью HTTP_REFERER
Ошибка означает, что второй аргумент, как ожидается, будет ссылкой на переменную.
Поскольку вы не передаете переменную, а целое число 0, оно генерирует указанную ошибку.
Чтобы обойти это, выполните следующие действия:
$update->bind_param("is", $a = 0, $selectedDate); //LINE 13
Если вы хотите понять, что происходит, а не просто фиксировать ваш Fatal error, прочтите следующее: http: // php. нетто / ручной / EN / language.references.pass.php
9 ответов
Я не уверен, могу ли я решить это сразу, но мы можем пойти назад и вперед по мере необходимости.
Во-первых, я хочу повторить то, что я думаю, что Вы говорите и удостоверяетесь, что я ясен. Вы хотите запретить запросы к servlet1, и servlet2 является запросом, не имеет надлежащего ссылающегося домена, и он действительно имеет строку запроса? Я не уверен, что понимаю (servlet1|servlet2)/. + \?. +, потому что это похоже, Вы требуете файла под servlet1 и 2. Я думаю, возможно, что Вы комбинируете PATH_INFO (прежде чем"?") с ПОЛУЧИТЬ строкой запроса (после того, как"?"). Кажется, что часть PATH_INFO будет работать, но ПОЛУЧИТЬ тест запроса не будет. Я сделал быстрый тест на своем сервере с помощью script1.cgi и script2.cgi, и следующие правила работали для выполнения то, что Вы просите. Они, очевидно, редактируются немного для соответствия моей среде:
RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]
Вышеупомянутые пойманные неправильные-referer запросы к 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]
Надо надеяться, это, по крайней мере, получает Вас ближе к Вашей цели. Сообщите нам, как это работает, я интересуюсь Вашей проблемой.
(BTW, я соглашаюсь, что блокирование ссылающегося домена является плохой безопасностью, но я также понимаю, что действительность иногда вызывает несовершенные и частичные решения, которые Вы, кажется, уже подтверждаете.)
У меня нет решения, но я держу пари, что доверие ссылающемуся домену никогда не будет работать, потому что агенты пользователя свободны не отправить его вообще или имитировать его к чему-то, что впустит их.
Вы не можете сказать независимо пользователям и злонамеренным сценариям их запросом HTTP. Но можно проанализировать, какие пользователи запрашивают слишком много страниц в слишком короткое время и блокируют их IP-адреса.
Я предполагаю, что Вы пытаетесь предотвратить анализ экранных данных?
По моему честному мнению это - жесткое для решения и пытающийся зафиксировать путем проверки, что значение HTTP_REFERER является просто лейкопластырем. Любой идущий в беспокойство автоматизации представлений собирается быть достаточно здравым смыслом для отправки корректного ссылающегося домена от их 'автомата'.
Вы могли попробовать ограничение уровня, но на самом деле не изменяя приложение для принуждения некоторой is-this-a-human проверки (КАПЧА) в какой-то момент затем Вы собираетесь найти, что это трудно предотвращает.
При попытке препятствовать тому, чтобы боты поисковой системы получили доступ к определенным страницам, удостоверьтесь, что Вы используете правильно отформатированный файл robots.txt.
Используя HTTP_REFERER ненадежно, потому что он легко фальсифицируется.
Другая опция состоит в том, чтобы проверить строку агента пользователя на известных ботов (это может потребовать модификации кода).
JavaScript является другим полезным инструментом, чтобы предотвратить (или по крайней мере задержаться) анализ экранных данных. Большинство автоматизированных инструментов очистки не имеет интерпретатора JavaScript, таким образом, можно сделать вещи как установка скрытых полей и т.д.
Править: Что-то вроде этой статьи Phil Haack.
Используя ссылающийся домен очень ненадежно как метод проверки. Как другие люди упомянули, это легко имитируется. Ваше лучшее решение состоит в том, чтобы изменить приложение (если Вы можете),
Вы могли использовать КАПЧУ или установить своего рода cookie или сеансовые куки, которые отслеживают какой страница пользователь, которого в последний раз посещают (сессию было бы более трудно имитировать) и, отслеживают историю просмотра страницы и только позволяют пользователям, которые просмотрели страницы, требуемые добираться до страницы, которую Вы хотите заблокировать.
Это, очевидно, требует, чтобы у Вас был доступ к рассматриваемому приложению, однако это - самый надежный путь (не полностью, но "достаточно хороший", по-моему.)
Сделать вещи немного более ясными:
Да, я знаю, что использование HTTP_REFERER является абсолютно ненадежным и несколько ребяческим, но я вполне уверен, что люди, которые учились (от меня, возможно?) сделать автоматизацию с Excel VBA не будет знать, как ниспровергать HTTP_REFERER в отрезке времени, чтобы иметь конечное решение.
У меня нет доступа/полномочия для изменения кода приложения. Политика. Вы верите этому? Так, я должен для ожидания, пока правообладатель не вносит изменения, которые я запросил.
От предыдущего опыта я знаю, что требуемые изменения возьмут двухмесячный для входа Производство. Нет, бросая их Гибкие Книги по Методологиям в их головах ничего не улучшили.
Это - приложение интранет. Таким образом, у меня нет большого количества молодежи, пытающейся подорвать мой престиж. Но я достаточно молод, чтобы попытаться подорвать престиж "очень необычные глобальные консультационные услуги, который прибывает из Индии", но где, любопытно, нет ни одного индийца, работающего там.
До сих пор лучший ответ появляется от "Michel de Mare": заблокируйте пользователей на основе их дюйм/с. Ну, то, что я вчера сделал. Сегодня я хотел сделать что-то более универсальным, потому что у меня есть много пользователей кенгуру (спрыгивающий с IP-адреса другому), потому что они используют VPN или DHCP.
Вы смогли использовать anti-CSRF маркер для достижения того, что Вы после.
Эта статья объясняет это более подробно: Подделки Запроса перекрестного сайта