Фильтрация выхода или входа?

Question

Фильтрация выхода или входа?

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

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

Но при получении данных вы просто используете необработанные данные из базы данных.

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

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

Теперь данные фильтруются в зависимости от контекста, например, я могу получить данные из базы данных в виде html-документа в виде простого экранированного текста, либо в виде html, либо в любом другом месте.

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

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

Таким образом, вместо «фильтрации ваших входов», возможно, следует «проверить ваши входы, отфильтровать ваши выводы».

так что мне идти с «Проверка и фильтрация входных данных» или «Проверка и фильтрация входных данных»?

Answer 1

Не существует общей «фильтрации» для ввода и вывода.

Подтвердите ваш ввод, экранируйте ваш вывод.То, как вы это сделаете, зависит от контекста.

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

Экранирование - это вопрос контекста, и оно действительно имеет смысл, когда вы делаете что-то с данными, которые могут быть отравлены путем введения определенныхперсонажи.Избегайте символов HTML в данных, которые вы отправляете в браузер.Escape-символы SQL в данных, которые вы отправляете в базу данных.Избегайте кавычек, когда вы пишете данные внутри тегов JavaScript <script>.Просто помните о том, как данные, с которыми вы имеете дело, будут интерпретироваться системой, которой вы их передаете, и соответственно избегать.

Answer 2

Для меня это звучит как семантика. В любом случае важно помнить, что в систему не попадают плохие данные.

Выполнение фильтрации вывода вместо фильтрации ввода требует SQL-инъекции.

Answer 3

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

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

Если вы выполняете только фильтрацию выходных данных,вы можете оставить себя открытыми для внедрения SQL-кода и других атак на стороне сервера.

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