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

Question

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

К сожалению, я считаю, что это не стоит в каждом приложении. И именно поэтому у нас в целом есть паршивая безопасность. Взгляните на то, что специалист по безопасности Брюс Шнайер имеет said on this.

Answer 6

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

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

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

Answer 7

Не устранить ошибки, исправить ошибки.

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

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

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

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

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

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

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

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

Answer 8

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

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

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

1) изучение прецедентов;

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

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

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

На боковой ноте, если вы думаете только о OWASP Top Ten, вы проделали должную осмотрительность.