У меня есть динамическое веб-приложение PHP, которое получает входные параметры в URL (здесь нет ничего удивительного). Тем не менее, bingbot иногда запрашивает очень длинные URL-адреса с сайта. Например. > 10000 символов длинные URL-адреса. Одним из входных данных является UTF-имя, и bingbot каким-то образом представляет схематичные входные имена, длиной в тысячи символов, например: \ xc2 \ x83 \ xc3 \ x86 … (продолжается для тысяч символов).
Очевидно, он получает 404, потому что в базе данных нет такого имени (и, следовательно, нет такой страницы), но мне пришло в голову, стоит ли проверять длину ввода перед запросом в БД (например, имя не может быть больше, чем 100 символов) и сразу возвращает 404, если он слишком длинный. Это стандартная практика? Или это не стоит того, потому что БД справится с этим?
Я думаю о том, чтобы не делать лишнюю нагрузку на БД без необходимости. Передается ли этот длинный ввод как есть клиентским интерфейсом db (два вызова: сначала подготовка к дезинфекции ввода, а затем фактический запрос), или клиент php db знает размер столбца и усекает строку ввода перед отправкой по проводам?
Мало того, что вы спрашиваете, более чем законно, но я бы сказал, что это то, что вы должен делать как часть фильтрации / проверки ввода. Если вы ожидаете, что ваш ввод всегда будет короче 100 символов, все, что длиннее, должно быть отфильтровано.
Кроме того, похоже, что вы получаете строки UTF-8: если вы не ожидаете их, вы можете просто отфильтровать все символы, которые не являются частью стандартного набора ASCII (даже уменьшены, отфильтровывая все управляющие символы. Например, $string = filter_var($input, FILTER_SANITIZE_FULL_SPECIAL_CHARS, FILTER_FLAG_STRIP_LOW)
,
Это не только вопрос производительности БД, но и безопасности!
PS: Я не сомневаюсь, что бот на самом деле Bing. Похоже, бот пытается взломать ваш сайт.
Как я писал выше в некоторых комментариях (и, как и другие написали тоже), вы должны всегда утверждать каждый вход. Неважно, что это такое или откуда оно приходит: если оно приходит извне, оно должно быть проверено.
Общая идея состоит в том, чтобы проверить ваш вклад в соответствии с тем, что вы ожидаете. С $ input любая входная переменная (что угодно $_GET
, $_POST
, $_COOKIE
из внешних API и из много $_SERVER
переменные — плюс что-либо еще, что может быть изменено пользователем, используйте свое суждение и сомневайтесь слишком осторожно).
Если вы запрашиваете целое число или число с плавающей точкой, то это легко: просто приведите данные к (int) или (float)
$filtered = (int)$input;
$filtered = (float)$input;
Если вы запрашиваете строку, то это сложнее. Вы должны подумать о том, какую строку вы запрашиваете, и отфильтровать ее соответствующим образом. Например:
$filtered = preg_replace('/[^0-9A-Fa-f]/', '', $input);
$string = filter_var($input, FILTER_SANITIZE_FULL_SPECIAL_CHARS, FILTER_FLAG_STRIP_LOW);
, Этот также удаляет все управляющие символы.В дополнение к этому:
FILTER_SANITIZE_FULL_SPECIAL_CHARS
будет делать это также на filter_var
, Если вы этого не сделаете, вы рискуете XSS (межсайтовый скриптинг) атак.$filtered = preg_replace('/[\x00-\x09\x0B\x0C\x0E-\x1F\x7F]/u', '', htmlspecialchars($input, ENT_COMPAT, 'UTF-8'));
И многое другое. Всегда используйте свое суждение.
PS: Мой подход к фильтрации входных данных заключается в том, чтобы предпочесть санитарную обработку. То есть удалите все «опасные» и примите дезинфицированный ввод, как если бы это было написано пользователем. Вместо этого другие люди будут утверждать, что вклад должен быть только принят или отклонен.
Лично я предпочитаю подход «очистить и использовать» для веб-приложений, поскольку ваши пользователи все еще могут захотеть увидеть нечто большее, чем веб-страницу с ошибками; в настольных / мобильных приложениях я использую метод «принять или отказаться».
Тем не менее, это просто вопрос личных предпочтений, подкрепленный только тем, что мои смелости говорят мне о UX. Вы свободны следовать подходу, который вы предпочитаете.
Должна быть какая-то проверка для любых данных, прежде чем они будут использованы в запросе. Если у вас есть ограничение на длину имени, вы можете использовать его как часть проверки при проверке ввода. Если он превышает предел, он не может быть там, а затем обрабатывать его соответствующим образом. Будь то 404 или страница с сообщением об ошибке.
Загрузка будет снижаться, если вы обходите запросы, потому что имя слишком длинное. В зависимости от того, как вы запрашиваете базу данных, LIKE или MATCH AGAINST и от того, как настроены ваши индексы, будет зависеть, насколько снизится нагрузка.