Список 10 основных уязвимостей OWASP — Возможно, вы используете его неправильно

Что входит в список 10 основных уязвимостей OWASP?

Впервые выпущенный в 2004 году проектом Open Web Application Security Project, ныне известный список OWASP Top 10 Vulnerabilities (включенный в нижнюю часть статьи), вероятно, является самым близким к набору заповедей, который когда-либо приходило сообществу разработчиков к набору заповедей о том, как для обеспечения безопасности своих продуктов.

Согласно OWASP, в этом списке представлены наиболее актуальные угрозы безопасности программного обеспечения на сегодняшний день, что вызовет удивление у многих, кто недоумевает, почему SQL-инъекции все еще вызывают такую ​​озабоченность спустя столько лет. Они оценивают типы уязвимостей на основе четырех критериев: легкость использования, распространенность, обнаруживаемость и влияние на бизнес. Интересно, что OWASP заявляет, что они фактически не учитывают в своем уравнении вероятность того, что злоумышленники попытаются воспользоваться определенной уязвимостью.

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

Однако после долгих дебатов они предложили свой список того, что, по их мнению, касается самого широкого круга организаций, хотя и не в каком-то конкретном порядке.

Со временем список 10 основных уязвимостей OWASP был принят многими организациями в качестве стандарта передового опыта и требований, устанавливая в некотором смысле стандарт для разработки. Одним из хорошо известных сторонников этого списка являются стандарты обработки платежей PCI-DSS.

К сожалению, поскольку список OWASP Top 10 Vulnerabilities стал доступен более широкой аудитории, его истинные намерения как руководства были неверно истолкованы, что навредило разработчикам, а не помогло. Так как же нам понять цель этого списка и на самом деле поощрять разработчиков кодировать более безопасно?

Понимание обновлений списка 2017 года

С тех пор они обновили и изменили порядок записей, добавляя некоторые новые типы уязвимостей по мере их актуальности, даже если другие были исключены из списка. Новые версии были выпущены в 2010, 2013 и 2017 годах. Новый список был составлен после долгого и напряженного исследования, в ходе которого было рассмотрено более 50 000 приложений и проанализировано около 2,3 миллиона уязвимостей.

Постоянные подписчики списка заметят, что наряду с некоторыми изменениями в порядке — несмотря на то, что инъекционные атаки остаются на первом месте — в обновленной версии 2017 года семейства OWASP Top 10 Vulnerabilities появилось несколько новичков.

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

Другим важным изменением здесь, в версии 2017 года, является объединение небезопасных прямых ссылок на объекты A4 и отсутствующего контроля доступа на функциональном уровне A7, что создает унифицированную неработающую уязвимость контроля доступа и подчеркивает необходимость надлежащего контроля над тем, кто может и не может получить доступ к учетным записям и данные.

Неверная интерпретация списка 10 основных уязвимостей OWASP

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

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

Как человек, который твердо верит в левый подход к безопасности, я, что неудивительно, полностью согласен с разочарованием Ноблоха в том, что многие восприняли список OWASP Top 10 как инструмент FUD, а не как набор руководящих принципов, для которых он предназначался. быть.

Сложные отраслевые подходы к безопасности

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

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

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

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

Чем является и чем не является список 10 основных уязвимостей OWASP

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

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

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

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

Для многих разработчиков основная цель сосредоточена на том, чтобы заставить продукт работать, и меньше внимания уделяется тому, является ли он безопасным. Это не их вина.

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

Практические шаги для улучшения безопасности

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

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

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

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

Интеграция технологий для расширения возможностей разработчиков

Ярким примером того, как технологии сдвига влево могут помочь разработчикам использовать OWASP Top 10, является запись под номером 9, которая предостерегает от использования компонентов с известными уязвимостями. Одна из наиболее распространенных проблем, возникающих в этой области, заключается в том, чтобы получить представление о том, что находится в компонентах с открытым исходным кодом, которые они добавили в свой продукт.

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

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

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

Будьте гарантом безопасности в вашей организации

На основании того, что я прочитал OWASP Top 10 и комментариев Кноблоха, этот список следует рассматривать как инструмент, позволяющий командам включать безопасность в свои мыслительные процессы при кодировании, настройке и поставке своих продуктов.

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

Если вы хотите оставаться актуальным, станьте активистом и используйте список OWASP Top 10 как способ начать разговор, а не угрожать. В конце концов, вы можете обнаружить, что с медом вы ловите больше (О)ОС, чем с уксусом.

Официальный список 10 основных уязвимостей OWASP

А1. Внедрение — недостатки внедрения, такие как внедрение SQL, NoSQL, ОС и LDAP, возникают, когда ненадежные данные отправляются интерпретатору как часть команды или запроса. Враждебные данные злоумышленника могут заставить интерпретатор выполнить непреднамеренные команды или получить доступ к данным без надлежащей авторизации.

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

A3. Раскрытие конфиденциальных данных. Многие веб-приложения и API не защищают должным образом конфиденциальные данные, такие как финансы, здравоохранение и персональные данные. Злоумышленники могут украсть или изменить такие слабо защищенные данные для совершения мошенничества с кредитными картами, кражи личных данных или других преступлений. Конфиденциальные данные могут быть скомпрометированы без дополнительной защиты, такой как шифрование при хранении или передаче, и требуют особых мер предосторожности при обмене с браузером.

A4. Внешние объекты XML (XXE). Многие старые или плохо настроенные процессоры XML оценивают ссылки на внешние объекты в документах XML. Внешние объекты могут использоваться для раскрытия внутренних файлов с помощью обработчика URI файлов, внутренних общих файловых ресурсов, внутреннего сканирования портов, удаленного выполнения кода и атак типа «отказ в обслуживании».

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

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

A7. Межсайтовый скриптинг (XXS). Ошибки XSS возникают всякий раз, когда приложение включает ненадежные данные на новую веб-страницу без надлежащей проверки или экранирования или обновляет существующую веб-страницу данными, предоставленными пользователем, с помощью браузера. API, который может создавать HTML или JavaScript. XSS позволяет злоумышленникам выполнять сценарии в браузере жертвы, которые могут перехватывать сеансы пользователей, искажать веб-сайты или перенаправлять пользователя на вредоносные сайты.

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

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

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

Первоначально опубликовано на сайте resources.whitesourcesoftware.com.