Почему я должен санировать ввод вручную, когда .NET "делает это" для меня?

Question

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

Чтение этого документа. Я вижу много предложений о вводе данных Sanitizing / Validation на стороне сервера, прежде чем управлять ими.

Ну, насколько я знаю, используя хранимые процедуры (для стороны БД) и .NET (для управления получением ответов), я вполне уверен.

Можете ли вы показать мне сценарий, в котором хранимые процедуры и .NET могут дать сбой (без очистки / проверки) и где я могу быть "небезопасным"?

Как я уже сказал, я имею в виду «безопасность», а не постоянство / точность данных! Там я согласен на дезинфекцию ввода ...

Answer 1

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

Из документа, на который вы ссылались:

String Fields

To validate string fields, such as names, addresses, tax identification numbers, and so on, use regular expressions to do the following:

    Constrain the acceptable range of input characters.
    Apply formatting rules. For example, pattern-based fields, such as tax identification numbers, ZIP codes, or postal codes, require specific patterns of input characters.
    Check lengths.

Если вы не ограничили / не проверили длину этой строки / типа ни на стороне клиента, ни на стороне сервера, искушенный злоумышленник может нарушить работу вашей системы, предоставив длинный ввод строк. Действительно, это проблема в Java (не уверен, что она применима к .NET / IIS, если предположить, что это потому, что .NET использует хеш-код для равенства, я тоже могу ошибаться).

Вот интересно, что у нас было пару дней назад здесь, на SO .

Если вы можете ограничить размер строки в качестве символов ограничения. Вы можете безопасно избежать этих проблем.

Answer 2

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

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

<script>var text="@Model.UserControlledData";</script>

Правила автоматического кодирования соответствуют html, а не строкам javascript, поэтомубудет небезопасным.

Answer 3

Если вы передаете свои данные стандартным объектам .NET Framework, то они должны обрабатывать свою собственную очистку. Вы должны думать о данных, которые вам нужны для очистки, как о всех данных, с которыми .NET не знает, как обращаться. то есть данные, для которых платформа .NET не знает, для чего она будет использоваться.

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

Как вы, в частности, упомянули XSS, это уязвимость, которой на самом деле подвержены стандартные веб-элементы управления .NET, если не активирован параметр проверки по умолчанию (см. http://www.asp.net/whitepapers/request-validation).). Это связано с тем, что веб-элементы управления .NET не следует автоматически кодировать символы HTML при установке свойства Text. Поэтому, если вы запускаете свой сайт без проверки запроса, вы должны убедиться, что все выходные данные правильно закодированы (это форма очистки вывода). Учитывая выбор, я бы разрабатывать с использованием инфраструктуры MVC, а не веб-форм, поскольку она упрощает использование очистки выходных данных HTML (например, использование скобок <%:%> автоматически закодирует HTML-вывод). Это позволяет вашему приложению корректно обрабатывать вредоносные (и не вредоносные) <script> тегов вводятся во вход без необходимости проверки, так как выходные данные должным образом очищены, поэтому, если ваше приложение защищено таким образом, проверка запросов может быть отключена, что является моим предпочтительным вариантом, так как тогда вы не манипулировать пользовательским вводом без необходимости. Например, если SO очистит входные данные и удалит теги <script>, я не смогу включить их в это сообщение.

Еще один тип очистки, который часто встречается в веб-приложениях, - это правильное форматирование строк, которые будут вставлены в JavaScript (например, символы одинарных и двойных кавычек). Короче говоря, вы защищаетесь от того, что пользователь вставляет вредоносный JavaScript через ввод, который будет отображаться для другого пользователя и выполняться, если не будет должным образом очищен, и при выполнении запрос будет выполняться как новый пользователь, который может иметь более высокий уровень безопасности. в приложении и возможны всевозможные повреждения.