.webp)
.webp)
Open Web Application Security Project содержит список самых актуальных проблем безопасности веб-приложений, и он постоянно обновляется.
Что такое OWASP?
The Open Web Application Security Project, или OWASP, - это международная некоммерческая организация, которая занимается вопросами безопасности веб-приложений. Один из основных принципов OWASP заключается в том, что все их материалы являются общедоступными, и их можно найти на их веб-сайте. Это дает возможность всем желающим повысить уровень безопасности своих веб-приложений. Материалы, которые они предлагают, включают документацию, инструменты, видео и форумы. По нашим предположениям, их самым известным проектом является OWASP Top-10.
Что такое OWASP Top-10?
OWASP Top-10 – это отчет, который постоянно обновляется и в котором в общих чертах описываются проблемы безопасности веб-приложений с акцентом на 10 самых важных. Отчет составлен группой экспертов по безопасности со всего мира. OWASP называет Top-10 «предупреждающим документом» и рекомендует всем компаниям взять его на вооружение в своей работе, чтобы свести к минимуму и/или устранить угрозы безопасности.
Ниже приведены угрозы безопасности, которые описаны в отчете OWASP Top-10 за 2017 год.
Инъекционная атака
Инъекционные атаки происходят в тот момент, когда ненадежные данные отправляются интерпретатору кода через форму ввода данных или какими-то другими путями. Например, злоумышленник может ввести код базы данных SQL в форму, которая предполагается для ввода имени пользователя. Если данная форма не защищена как положено, то это приведет к выполнению этого кода SQL. Такая атака известна как атака путем внедрения кода SQL, или SQL-инъекция.
Инъекционные атаки можно предотвратить путем проверки и/или очистки данных, которые отправляет пользователь. (Проверка подразумевает отклонение подозрительных данных, а очистка – удаление подозрительных частей данных.) Кроме того, администратор баз данных может настроить элементы управления для того, чтобы свести к минимуму объем информации, который может быть получен в результате инъекционной атаки.
Нарушенная аутентификация
Уязвимости в системах аутентификации (входа) могут позволить злоумышленникам получить доступ к учетным записям пользователей или даже скомпрометировать всю систему с помощью учетной записи администратора. Например, злоумышленник может взять список с тысячами известных комбинаций имени пользователя и пароля, которые были получены во время утечки данных, и написать скрипт, чтобы попробовать все эти комбинации в системе входа с целью проверить, есть ли среди них те, которые работают.
Некоторые стратегии устранения уязвимостей в аутентификации подразумевают использование двухфакторной аутентификации (2FA - two-factor authentication), а также ограничения или задержки повторных попыток входа в систему с помощью ограничения скорости.
Раскрытие конфиденциальных данных
Если веб-приложение никак не защищает конфиденциальные данные, такие как финансовые сведения и пароли, то злоумышленники могут получить доступ к этим данным и использовать их в гнусных целях. Один из самых популярных методов кражи конфиденциальной информации – это атака «по пути».
Потенциальный риск раскрытия данных можно минимизировать, если зашифровать все конфиденциальные данные и отключить кэширование* любой такой информации. Кроме того, разработчики веб-приложений должны позаботиться о том, чтобы без необходимости конфиденциальные данные в приложениях не хранились.
*Кэширование – это способ временного хранения данных для их повторного использования. Например, веб-браузеры часто кэшируют веб-страницы, так что, если пользователь повторно посещает эти страницы в течение какого-то фиксированного промежутка времени, у браузера нет необходимости снова загружать их из Интернета.
Атака на внешние сущности XML (XEE – XML External Entities)
Это атака на веб-приложение, которое анализирует ввод XML*. Этот ввод может иметь ссылки на внешние сущности, которые пытаются использовать уязвимость в синтаксическом анализаторе. Под «внешней сущностью» в данном контексте подразумевается устройство хранения, например, жесткий диск. Синтаксический анализатор XML можно обманным путем заставить отправить данные неавторизованной внешней сущности, которая в свою очередь может передать эти данные злоумышленнику.
Лучший способ предотвратить XEE-атаки – это передавать веб-приложению данные менее сложного типа, например, JSON**, или хотя бы исправить синтаксические анализаторы XML и перестать использовать внешние сущности в XML-приложении.
*XML, или Extensible Markup Language (что переводится как «расширяемый язык разметки») – это язык разметки, который является удобным для восприятия человеком и машиночитаемым. Поскольку он довольно сложный и у него есть уязвимости с точки зрения безопасности, его постепенно перестают использовать.
**Нотация объектов JavaScript, или JSON – это тип простой и удобной для восприятия человеком нотации, которую часто используют для передачи данных через Интернет. Несмотря на то, что изначально он был создан для JavaScript, JSON не зависит от языка и может интерпретироваться различными языками программирования.
Нарушенное управление доступом
Управление доступом относится к системе, которая контролирует доступ к информации или функциям. Неисправные средства контроля доступа позволяют злоумышленникам обходить авторизацию и выполнять какие-то задачи, как если бы они были пользователями с привилегиями, например, администраторами. Например, веб-приложение может позволить пользователю поменять учетную запись, в которую он вошел, просто изменив часть URL-адреса без какой-либо дополнительной проверки.
Средства управления доступом можно защитить с помощью маркеров авторизации*, которые должны использовать веб-приложения, и строгого контроля за ними.
*Многие службы, когда пользователь входит в систему, предоставляют маркеры авторизации. Каждый привилегированный запрос, который делает пользователь, требует, чтобы у этого пользователя был маркер авторизации. Это безопасный способ убедиться, что пользователь является тем, за кого себя выдает, и при этом не нужно вводить свои учетные данные для входа в систему.
Неверная конфигурация безопасности
Неверная конфигурация безопасности – это самая распространенная уязвимость из данного списка, и она часто является результатом того, что в приложении используются конфигурации по умолчанию или отображаются чересчур подробные сообщения об ошибках. Например, приложение может показать пользователю излишне содержательное сообщение об ошибке, что может помочь в выявлении уязвимостей в приложении. Этого можно избежать, удалив все функции в коде, которые не используются, и сделав так, чтобы сообщения об ошибках были более общего характера.
Межсайтовый скриптинг
Уязвимости, связанные с межсайтовым скриптингом возникают тогда, когда веб-приложение разрешает пользователям добавлять пользовательский код в URL-адрес или на веб-сайт, который будут видеть и другие пользователи. Эту уязвимость можно использовать для того, чтобы запустить вредоносный код JavaScript в браузере жертвы атаки. Например, злоумышленник может отправить жертве письмо по электронной почте от доверенного банка, в котором будет находиться ссылка на веб-сайт этого банка. Эта ссылка может содержать вредоносный код JavaScript, добавленный в конце URL-адреса. Если сайт этого банка не защищен как следует от межсайтового скриптинга, то этот вредоносный код запуститься в веб-браузере жертвы, когда она перейдет по ссылке.
Для того, чтобы смягчить последствия межсайтового скриптинга, рекомендуется избегать ненадежных HTTP-запросов, а также проверять и/или пользовательский контент. Также современные среды разработки, такие как ReactJS и Ruby on Rails, имеют определенную встроенную защиту от межсайтового скриптинга.
Небезопасная десериализация
Целью этой угрозы является множество веб-приложений, которые часто сериализуют и десериализуют данные. Сериализация – это получение объектов из кода приложения и их преобразование в формат, который можно использовать для других целей, например, для сохранения данных на диск или потоковой передачи данных. Десериализация – это противоположный процесс, то есть преобразование сериализованных данных обратно в объекты, которые сможет использовать приложение. Сериализация чем-то похожа на упаковку мебели в коробки, когда вы переезжаете, а десериализация, соответственно, - на распаковку этих коробок и сборку мебели после того, как вы уже переехали. В таком контексте небезопасную десериализацию можно представить, как, если бы грузчики повредили содержимое коробок до того, как их распакуют.
Небезопасная десериализация – это результат десериализации данных из ненадежных источников, и она может привести к серьезным последствиям, таким как DDoS-атаки и атаки с целью выполнения кода. Несмотря на то, что можно предпринять некоторые шаги, чтобы найти злоумышленников, например, обеспечить контроль за десериализацией и проводить проверки соответствия типов, единственным надежным способом защититься от подобного рода проблем – запретить десериализацию из ненадежных источников.
Использование компонентов с известными уязвимостями
Многие современные веб-разработчики в своих веб-приложениях используют такие компоненты, как библиотеки и фреймворки. Эти компоненты – это части программного обеспечения, которые помогают разработчикам избежать лишней работы и обеспечить приложение необходимой функциональностью; распространенный пример таких компонентов - «клиентские» фреймворки, такие как React, и небольшие библиотеки, которые используются для общих условных обозначений или А/В тестирования. Некоторые злоумышленники ищут уязвимости именно в этих компонентах, чтобы потом иметь возможность организовывать атаки. Некоторые их самых популярных компонентов используются сотнями тысяч веб-сайтов; злоумышленник, который найдет брешь в системе безопасности хотя бы одного из этих компонентов, сможет сделать сотни тысяч сайтов уязвимыми для эксплойтов.
Разработчики компонентов регулярно предоставляют исправления и обновления для устранения известных уязвимостей, но разработчики веб-приложений не всегда используют исправленные или самые последние версии компонентов в своих приложениях. Чтобы минимизировать риск запуска компонентов с известными уязвимостями, разработчикам следует удалять из своих проектов компоненты, которые они не используют, а также брать компоненты только из надежного источника и постоянно их обновлять.
Неудовлетворительное ведение системного журнала и невыполнение оперативного контроля
Многие веб-приложения предпринимают не достаточное количество действий для того, чтобы можно было обнаружить утечку данных. Среднее время обнаружения утечки составляет примерно 200 дней с момента, как она произошла. У злоумышленников есть достаточно времени, чтобы нанести ущерб, прежде чем, их обнаружат. OWASP рекомендует разработчикам вести системные журналы и выполнять оперативный контроль, а также составлять планы реагирования на нарушения, чтобы знать, что делать когда их приложение атаковали.
