PHP $ _POST и отказ от безопасности поддельных форм

Question

В настоящее время я пишу веб-приложение, которое использует формы и данные PHP $ _POST (пока что стандартно! :)).Однако (и это может быть нубский запрос), я только что понял, что теоретически, если кто-то соберет файл HTML на своем компьютере с поддельной формой, включите это действие в качестве одного из сценариев, используемых на моем сайте.и заполнить эту форму своими собственными случайными данными, не могли ли они затем отправить эти данные в форму и вызвать проблемы?

Я выполняю очистку данных и т. д., поэтому я не слишком беспокоюсь о XSS или атаках в стиле внедренияЯ просто не хочу, чтобы кто-то мог, например, добавлять бессмысленные вещи в корзину и т. Д. И т. Д.

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

Итак, мой вопрос - есть ли надежный способ убедиться, что мои php-скрипты могут вызываться только с форм, размещенных на моем сайте?Возможно, некоторые Http Referrer проверяют сами скрипты, но я слышал, что это может быть ненадежно, или может быть htaccess voodoo?Кажется, что слишком большая дыра в безопасности (особенно для таких вещей, как отзывы клиентов или любые отзывы клиентов) просто оставить открытой.Любые идеи будут очень цениться.:) Еще раз спасибо!

Answer 1

http://en.wikipedia.org/wiki/Cross-site_request_forgery

http://www.codewalkers.com/c/a/Miscellaneous/Stopping-CSRF-Attacks-in-Your-PHP-Applications/

http://www.owasp.org/index.php/PHP_CSRF_Guard

Answer 2

Существует простое правило: Никогда не доверяйте пользовательскому вводу .

Все вводимые пользователем данные, независимо от того, что происходит, должны быть проверены сервером. Поддельные POST-запросы являются стандартным способом выполнения SQL-атак или других подобных атак. Вы не можете доверять заголовку реферера, потому что это тоже может быть подделано. Любые данные в запросе могут быть подделаны. Невозможно удостовериться, что данные были отправлены из безопасного источника, такого как ваша собственная форма, потому что для всех возможных проверок требуются данные, представленные пользователем, которые могут быть подделаны.

Единственный способ защитить себя - дезинфицировать весь пользовательский ввод. Принимайте только те значения, которые приемлемы. Если значение, например идентификатор, относится к объекту базы данных, убедитесь, что оно существует. Никогда не вставляйте неподтвержденный пользовательский ввод в запросы и т. Д. Список просто продолжается.

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

1. Никогда не вставляйте необработанный пользовательский ввод в запросы. Либо избегайте их, используя такие функции, как mysql_real_escape_string(), либо, что еще лучше, используйте подготовленные запросы через API, такие как PDO. Использование необработанного пользовательского ввода в запросах может привести к SQL-инъекциям.
2. Никогда не выводить введенные пользователем данные непосредственно в браузер. Всегда передавайте его через такие функции, как htmlentities(). Даже если данные поступают из базы данных, вам не следует им доверять, поскольку исходный источник всех данных обычно принадлежит пользователю. Небрежный вывод данных пользователю может привести к атакам XSS.
3. Если данные, представленные пользователем, должны принадлежать к ограниченному набору значений, убедитесь, что это так. Например, убедитесь, что любой идентификатор, представленный пользователем, существует в базе данных. Если пользователь должен выбрать значение из раскрывающегося списка, убедитесь, что выбранное значение является одним из возможных вариантов.
4. Любая и вся проверка ввода, такая как разрешенные буквы в именах пользователей, должна выполняться на стороне сервера. Любая проверка формы на клиенте, такая как проверка JavaScript, предназначена только для удобства пользователя. Они не обеспечивают никакой безопасности данных.

Answer 3

Ответ на ваш вопрос короток и однозначен:

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

Конечно, нет.

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

было бы невозможно предсказать все случаи.

Наоборот, было бы.
Все хорошие сайты делают это.
В этом нет ничего сложного.

Количество параметров в каждой форме ограничено. И вам просто нужно проверить каждый параметр - и все.

Answer 4

Посмотрите @ учебник по nettuts в теме.

Просто обновляю мой ответ ранее принятым ответом также в теме .

Answer 5

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

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

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

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

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

Answer 6

Я не вижу проблемы, пока вы доверяете своему способу очистки данных ... и говорите, что очищаете его.

Вы знаете о http://php.net/manual/en/function.strip-tags.php, http://www.php.net/manual/en/function.htmlentities.php и http://www.php.net/manual/en/filter.examples.validation.php верно?