черные списки и белые списки во входной фильтрации и проверке формы - PullRequest
3 голосов
/ 24 августа 2010

Какой подход является предпочтительным для очистки входных данных от пользователя?

спасибо!

Ответы [ 7 ]

3 голосов
/ 24 августа 2010

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

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

3 голосов
/ 24 августа 2010

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

Кстати, этот ответ предполагает, что вы имеете в виду дезинфекцию как предотвращение инъекции SQL.

2 голосов
/ 15 мая 2014

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

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]');  
  }  
}
1 голос
/ 25 июля 2013

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

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

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

Проверка данных OWASP

Руководство по внедрению SQL OWASP

1 голос
/ 02 мая 2012

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

  1. Черный список против ограничения белого списка

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

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

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

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

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

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

1 голос
/ 24 августа 2010

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

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

0 голосов
/ 24 августа 2010

Ответ обычно таков:

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

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

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

...