Вы проверяете свои переменные URL?

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

Чтобы улучшить взаимодействие с пользователем, поля ввода могут (и ИМХО должны) проверяться на клиенте. Это может предотвратить обратный путь к серверу, который приведет только к той же форме и сообщению об ошибке.

Однако входные данные должны быть проверены на стороне сервера всегда, поскольку пользователь может просто вручную изменить входные данные в URL-адресе GET или отправить созданные данные POST.

В худшем случае вы можете получить уязвимость SQL-инъекция или, что еще хуже, XSS.

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

• Допустим, вы знаете, что это целое число, используйте int.Parse или сравните его с регулярным выражением «^ \ d + $».
• Если это строка и выбор ограничен, создайте словарь и пропустите строку через него. Если совпадения нет, измените строку на значение по умолчанию.
• Если это строка, указанная пользователем, сопоставьте ее со строгим регулярным выражением, например "^ \ w + $"

Как и в случае любого пользовательского ввода, важно проверить очень сильно, чтобы убедиться, что это именно то, что вы ожидаете. Так да!

Да, да, и трижды да.

Конечно, многие веб-фреймворки сделают это за вас, например, Struts 2.

Одна из важных причин - проверить sql-инъекция. Так что да, всегда дезинфицируйте вводимые пользователем данные.

Да, проверьте их как можно тщательнее. В PHP я всегда проверяю типы (IsInt(i), IsString(p)).

не только то, что говорят другие. Представьте себе переменную строки запроса с именем nc, которая может иметь значения 10, 50 и 100, когда пользователь выбирает 10, 50 и 100 результатов на странице соответственно. Теперь представьте, что кто-то меняет это значение на 50000. Если вы просто проверяете, что это целое число, вы будете показывать 50000 результатов на страницу, что повлияет на количество просмотров страниц, загрузку сервера, время выполнения скриптов и так далее. К тому же это может быть вся ваша база данных. Если у вас есть такие правила (10, 50 или 100 результатов на страницу), вам следует дополнительно проверить, равно ли значение nr только 10, 50 или 100, а если нет, установите его по умолчанию. Это может быть просто min (nc, 100), поэтому он будет работать, если nc изменить на 25, 75 и так далее, но по умолчанию будет 100, если он увидит что-то выше 100.

Хочу подчеркнуть, насколько это важно. Я знаю, что в первом ответе говорилось о внедрении SQL-кода и уязвимостях XSS. Последний рейв в SQL Injection передает двоично закодированный оператор SQL в строках запроса, который, если он обнаружит дыру для SQL-инъекции, добавит http: //reallybadsite.com'/> в каждое текстовое поле в вашей базе данных.

Как веб-разработчики, мы должны проверять весь ввод и очищать весь вывод.

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