Стоит ли снижать риски безопасности в каждом приложении?

Question

Как веб-разработчики наши приложения уязвимы для ряда дыр в безопасности (xss, SQL-впрыскивает, и т.д ...). Я твердо верю, что если вы пишете приложение, оно должно быть защищен от всех этих известных уязвимостей. Однако мне тяжело убедить мою команду (и руководство), что это стоит усилий.

Это заставляет меня задаться вопросом, при каких условиях следует вести борьбу за безопасность? Какие факторы, которые следует учитывать при определении того, какие уязвимости безопасности смягчить и что игнорировать?

Answer 1

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

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

Answer 2

Не устраняйте уязвимости, исправляйте их.

Если у вас есть SQL-инъекция, это потому, что ваш уровень доступа к базе данных неверен. Внедрение стратегии смягчения последствий, такой как фильтрация параметров с помощью ключевых слов, таких как «SELECT» или «; DROP DATABASE '- неправильная вещь. Вместо этого перейдите к методу доступа к базе данных, который автоматически экранирует входящие параметры соответствующим образом для соответствующей базы данных. Тогда вы не только исправите проблему, но и убедитесь, что приложение работает правильно, когда сталкивается с «O'Reilly» или другими данными о проблеме.

Если у вас есть HTML-инъекция, ведущая к XSS, ваша шаблонная стратегия поощряет вас выводить неэкранированный текст вслепую. Не пытайтесь смягчить ситуацию, обнаруживая и отклоняя «<» в данных, вы пропустите некоторые поля и не будете знать обо всех особых случаях, не говоря уже о том, что у кого-то может быть веская причина для ввода «< ». Вместо этого исправьте это, изменив систему шаблонов или стиль так, чтобы каждый раз, когда вы выводите текст, вы всегда обходились без HTML как само собой разумеющееся, даже если данные «не могут» содержать специальные символы. </p>

Относительно того, какие проблемы безопасности вы можете игнорировать, это зависит от вашего бизнеса и от того, насколько клиенты полагаются на него. В целом, существует четыре уровня компромисса, влияющих на веб-приложения (о которых я предполагаю, что вы говорите, когда упоминаете инъекцию SQL и XSS):

1. Компрометация на уровне сервера. Обычно из-за плохо защищенных учетных записей оболочки и FTP, но также из-за обширных компромиссов на уровне приложений. Приложения, выполняющие system () с предоставленными пользователем данными, часто подвергаются такой серьезной угрозе, как и инъекции SQL, когда база данных представляет собой плохо сконфигурированный SQL Server (использующий xp_cmdshell). Злоумышленник может получить доступ к оболочке на сервере и может с удовольствием рассылать множество спама и попыток взлома на другие серверы. Это неприемлемо для любого бизнеса.

2. Компрометация на уровне приложения. Обычно SQL-инъекция. Атакующий может считывать или удалять любую информацию о клиентах из базы данных и иным образом мешать работе приложения. Это приемлемо, если это в значительной степени игрушечное приложение, и ваши клиенты примут умирание своих данных, или если доступ к приложению закрыт, доступен только для избранных доверенных лиц / клиентов.

3. Компрометация на уровне данных. Обычно HTML-инъекция в XSS. Злоумышленник может разместить на своем сайте iframe, указывающий на уязвимость в браузере, которая позволяет размещать вредоносное ПО на компьютерах людей, просматривающих страницу с устаревшим программным обеспечением. Это приемлемо, если вы не даете ни малейшего представления о безопасности своих клиентов или, опять же, если приложение закрыто для общего доступа.

4. Компромисс на уровне пользователя. Обычно непроверенные формы действий, приводящие к атакам между сайтами и запросами-подделками. Приемлемо, если ваше приложение вряд ли будет достаточно интересным для злоумышленников, чтобы попробовать его.

В целом индустрия в настоящее время находится где-то на уровне 3. Приложения, обеспечивающие атаки уровня 1, теперь редки; дыры уровня 2 встречаются чаще, но это проблемы, о которых большинство авторов знают и знают, что должны их исправить. Дырки 3-го уровня очень распространены, и тактика предотвращения всех возможных HTML-инъекций широко не соблюдается. Сегодня дыры 4-го уровня затрагивают, вероятно, большинство веб-приложений.

Answer 3

К сожалению, я думаю, что ответ заключается в том, что это не стоит того в каждом приложении. И именно поэтому у нас вообще паршивая охрана. Посмотрите, что эксперт по безопасности Брюс Шнайер сказал об этом .

Answer 4

Полный анализ безопасности - это не только анализ угроз, но и их причин. Давайте рассмотрим пример SQL-инъекции. Что если ваша учетная запись для доступа к базе данных может только ЧИТАТЬ, но никогда не записывать в базу данных? Теперь SQL-инъекция не может нанести вред вашей базе данных. Тем не менее, у вас все еще есть проблема, что запросы SELECT можно манипулировать, чтобы получить доступ к большему количеству необходимых результатов. Это проблема? Возможно, да, но это другая проблема, потому что вы можете каким-то образом фильтровать данные на выходе.

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

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

Answer 5

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

Answer 6

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

Для каждой переменной, которую вы получаете в качестве входных данных, применяйте самые строгие правила фильтрации, которые имеют смысл: Если Вы получаете идентификатор страницы, тогда is_integer (myvariable) && myvariable> 0; это правильная проверка.

Процесс безопасности - это процесс управления рисками, который проходит по следующим направлениям:

1) Изучите вариант использования;

2) Подумайте обо всех возможных рисках;

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

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

В дополнение к этому, если вы просто думаете о OWASP Top Ten , вы провели должную проверку.

Answer 7

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

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

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

Answer 8

Это всегда очень сложный вопрос. Я бы сказал, что это зависит от доступности веб-сайта. Если у него будет широкая аудитория, лучше всего защитить все стандартные элементы - xss, sql injects и т. Д. В дополнение к этому следует серьезно рассмотреть, какие другие методы могут быть заблокированы с минимальными затратами. Если на сайте мало трафика с минимальным объемом доступа, я бы не стал беспокоиться, если бы он не был конфиденциальной информацией.

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