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

Question

Когда вы передаете переменные через ваш сайт с помощью запросов GET, проверяете ли вы их (регулярные выражения, фильтры и т. Д.) Перед их использованием?

Скажем, у вас есть URL http://www.example.com/i=45&p=custform. Вы знаете, что «i» всегда будет целым числом, а «p» всегда будет содержать только буквы и / или цифры. Стоит ли тратить время на то, чтобы убедиться, что никто не пытался манипулировать значениями, а затем повторно отправить страницу?

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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