PHP, HTML, CSS, Javascript Form Security

Question

У меня есть вопрос о безопасности.У меня есть веб-сайт, запрограммированный на HTML, CSS, PHP, Javascript (jQuery) ...

На всем сайте есть несколько форм (особенно с переключателями).

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

Меня беспокоит следующее:

Как я могу запретить кому-либо использовать инструмент разработчика / редактор исходного кода (например, отладку Google Chrome /Модуль Developer Tool) и вручную изменить значение переключателя, прежде чем нажать кнопку «Отправить»?Я боюсь, что люди смогут вручную изменить значение ввода переключателя перед отправкой формы.Если они действительно могут это сделать, это полностью разрушит цель сценария, который я строю.

Надеюсь, это имеет смысл.

Спасибо!

Джон

Answer 1

Как можно запретить кому-либо использовать инструмент разработчика / редактор исходного кода (например, модуль отладки / инструмента разработчика Google Chrome) и изменять значение переключателя вручную до нажатия кнопки отправки?

Ты не можешь. У вас нет контроля над тем, что отправляется на сервер.

Проверьте, что данные соответствуют тем требованиям, которые вы для них устанавливаете, прежде чем вставлять их в базу данных. Если это не в порядке, отклоните его и объясните проблему в ответе HTTP.

Answer 2

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

Проверка на стороне сервера для безопасности.

Answer 3

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

Поэтому мантра должна быть: Всегда иметь проверку на стороне сервера

Answer 4

Любые данные , отправленные из браузера на сервер, могут обрабатываться вне вашего контроля, включая данные формы, параметры URL-адреса и файлы cookie.Ваш PHP-код должен знать, какие наборы значений действительны, и отклонять запрос, если он не выглядит разумным.

При отправке пользовательских данных в базу данных вы захотите убедиться, что злонамеренная строка, введенная пользователем, может 'изменить значение запроса SQL.См. SQL-инъекция .И когда вы отображаете введенные пользователем данные (либо непосредственно в следующем ответе, либо позже, когда вы читаете их обратно из базы данных), убедитесь, что вы правильно их кодируете, чтобы избежать ввода пользователем вредоносной строки, выполняющейся как нежелательный JavaScript в пользовательскомбраузер.См. Межсайтовый скриптинг и шпаргалку по профилактике

Answer 5

В этом сценарии я бы рекомендовал использовать значения в качестве ключей и искать их на стороне сервера.

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

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

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

Answer 6

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

Итак, на сервересторона, вы должны обработать свой ввод, как будто не было никакой проверки клиента вообще.

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

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

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

OWASP - отличный ресурс для веб-безопасности.Взгляните на их раздел о проверке данных .

Некоторые советы, которые стоит цитировать:

Где включить проверку

Проверка должна быть выполненана каждом уровне.Однако проверка должна выполняться согласно функции сервера, выполняющего код.Например, уровень веб / представления должен проверяться на наличие проблем, связанных с вебом, уровни постоянства должны проверяться на наличие проблем постоянства, таких как внедрение SQL / HQL, поиск в каталогах должен проверять внедрение LDAP и так далее.

Соблюдайте это правило без исключения.