blacklisting vs whitelisting в форме фильтрации и проверки формы

Question

, который является предпочтительным подходом к дезинфекции входных данных, поступающих от пользователя?

спасибо!

Answer 1

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

Кстати, этот ответ если вы хотите ограничить входы в поля формы, такие как телефонные номера или имена :) @posterBelow

Answer 2

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

BTW, этот ответ предполагает, что вы имеете в виду санитирование, как в предотвращении внедрения sql.

Answer 3

Ответ в целом, это зависит.

Для входов с четко определенными параметрами (скажем, эквивалентом выпадающего меню) я бы выделил белый список параметров и проигнорировал все, что не было одним из них.

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

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

Answer 4

WL - наилучшая практика против BL, когда это практически возможно.

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

Answer 5

Позвольте мне объяснить ваш вопрос несколькими вопросами и ответами.

1. ограничение Черный список Белый список В.С.

   я. Обработка данных Blacklist XSS и SQL Injection проверяет желаемый ввод на список отрицательных входных данных. В основном можно составить список всех отрицательных или плохих условий и проверить, что полученный вход не является одним из плохих или отрицательных условий.

   ii. Операция «Белый список XSS» и «Обработка SQL-запросов» проверяет желаемый ввод на список возможных правильных входных данных. Для этого нужно составить список всех хороших/положительных входных значений/условий и проверить, что введенный вход является одним из правильных условий.

2. Какой из них лучше иметь?

   i. Злоумышленник будет использовать любые возможные средства для доступа к вашему приложению. Это включает в себя попытку всех отрицательных или плохих условий, различные методы кодирования и добавление вредоносных входных данных в действительные данные. Считаете ли вы, что можете думать обо всех возможных неудачных перестановках?

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

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

Answer 6

Как правило, это лучше всего использовать белый список проверки, так как это проще, чтобы принимать только символы, которые вы знаете, должны пойти туда, к примеру, если у вас есть поле, где пользователь вводит его/ее телефонный номер, который вы могли бы просто сделать регулярное выражение и проверить, что полученные значения - это только числа, отбросить все остальное и просто сохранить числа. Обратите внимание, что вы также должны продолжить проверку полученных чисел. Черный список проверка слабее, потому что опытный злоумышленник может обходить свои функции проверки или отправить значение, что функция не ожидала, от OWASP «дезинфицировать с Blacklist»:

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

Поймите, что эта проверка является лишь первой защитой перед атакой. Для XSS вы всегда должны «бежать» на свой выход, чтобы вы могли печатать любой символ, но они экранированы, что означает, что они изменены на их объект HTML, и, таким образом, браузер знает, что это данные, а не то, что анализатор должен интерпретировать таким образом, фактически отключая все XSS-атаки. Для SQL-инъекций удалите все данные перед их сохранением, старайтесь никогда не использовать динамические запросы, поскольку они являются самым простым типом запроса для использования. Попробуйте использовать параметризованные процедуры хранения. Также не забудьте использовать подключения, относящиеся к тому, что должно делать соединение. Если для подключения требуется только чтение данных, создайте учетную запись db только с привилегиями «Чтение», это зависит в основном от ролей пользователей. Для получения дополнительной информации, пожалуйста, проверьте ссылки, откуда эта информация извлекается из:

Data Validation OWASP

Guide to SQL Injection OWASP

Answer 7

Я думаю, что белый список является искомым подход, однако я никогда не встречал проверки HTML формы реального белого списка. Например вот это Symfony 1.x форма с проверкой из documentation:

class ContactForm extends sfForm 
{ 
    protected static $subjects = array('Subject A', 'Subject B', 'Subject C'); 

    public function configure() 
    { 
    $this->setWidgets(array( 
     'name' => new sfWidgetFormInput(), 
     'email' => new sfWidgetFormInput(), 
     'subject' => new sfWidgetFormSelect(array('choices' => self::$subjects)), 
     'message' => new sfWidgetFormTextarea(), 
    )); 
    $this->widgetSchema->setNameFormat('contact[%s]'); 

    $this->setValidators(array( 
     'name' => new sfValidatorString(array('required' => false)), 
     'email' => new sfValidatorEmail(), 
     'subject' => new sfValidatorChoice(array('choices' => array_keys(self::$subjects))), 
     'message' => new sfValidatorString(array('min_length' => 4)), 
    )); 
    } 
} 

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

Гипотетический белый список будет выглядеть примерно так:

class ContactController { 
    /** 
    * @input("name", type = "string", singleLine = true, required = false) 
    * @input("email", type = "email") 
    * @input("subject", type = "string", alternatives = ['Subject A', 'Subject B', 'Subject C']) 
    * @input("message", type = "string", range = [4,]) 
    */ 
    public function post(Inputs $inputs){ 
     //automatically validates inputs 
     //throws error when an input is not on the list 
     //throws error when an input has invalid value 
    } 
} 

/** 
* @controller(ContactController) 
* @method(post) 
*/ 
class ContactForm extends sfFormX { 

    public function configure(InputsMeta $inputs) 
    { 
    //automatically binds the form to the input list of the @controller.@method 
    //throws error when the @controller.@method.@input is not defined for a widget 
    $this->addWidgets(
     new sfWidgetFormInput($inputs->name), 
     new sfWidgetFormInput($inputs->email), 
     new sfWidgetFormSelect($inputs->subject), 
     new sfWidgetFormTextarea($inputs->message) 
    ); 
    $this->widgetSchema->setNameFormat('contact[%s]'); 
    } 
}