уязвимость веб приложений это
10 распространенных уязвимостей безопасности веб-приложений и способы их предотвращения
Проблемы веб-безопасности стали общей проблемой современного бизнеса. Количество киберпреступлений значительно увеличилось за последние несколько лет. В 2017 году ущерб от кибератак оценивался в 1,4 миллиарда долларов, а в 2020 году — в 4,2 миллиарда долларов.
Веб-приложения являются одной из самых популярных целей хакерских атак, поскольку они обеспечивают легкий доступ для более широкой аудитории, что позволяет быстрее распространять вредоносный код.
В этой статье мы рассмотрим наиболее распространенные уязвимости в веб-приложениях и возможные решения для их предотвращения.
Понимание распространенных уязвимостей веб-приложений
Хотя веб-приложения предоставляют компаниям множество преимуществ, они часто вызывают опасения из-за отсутствия у разработчиков опыта в области безопасности. В 2017 году некоммерческая организация OWASP, которая пытается улучшить глобальную безопасность программного обеспечения, составила список из 10 основных проблем безопасности в веб-приложениях. Хотя с тех пор прошло 4 года, эти подводные камни все еще широко распространены и наносят значительный ущерб компаниям. Вот наиболее важные уязвимости, о которых следует знать, чтобы предоставить своим клиентам надежные и безопасные настраиваемые веб-приложения.
1. Инъекция
Инъекция — это процесс, когда ненадежные или нефильтрованные данные проникают на сервер или браузер как часть запроса. Инъекции бывают разных видов: SQL, NoSQL, LDAP, OS и другие. Однако запросы SQL являются наиболее частой целью злонамеренных действий. Отправляя неотфильтрованные данные через SQL-запрос, злоумышленники получают доступ к важным данным приложения. В результате они могут выполнять административные операции, получать доступ к личной информации пользователя, кредитным картам, паролям и т. Д.
Профилактика
2. Сломанная аутентификация
Аутентификация — это процесс, который проверяет личность пользователя, связывая входящую информацию с набором учетных данных, таких как биометрические данные, пароль и другие. Сломанная аутентификация, напротив, означает, что идентификатор сеанса или учетные данные пользователя были похищены.
Сломанная аутентификация может быть вызвана недостаточной защитой учетных данных пользователя, слабым паролем и логином, передачей идентификатора сеанса в виде URL-адреса и другими причинами.
Профилактика
3. Раскрытие конфиденциальных данных
Этот тип проблем безопасности веб-приложений связан с раскрытием конфиденциальной информации клиентов, такой как номера телефонов, информация об учетной записи, номера кредитных карт и т.д. Уязвимость, связанная с раскрытием данных, является тревожным сигналом для компаний, поскольку она может привести к более серьезным последствиям. такие как нарушенная аутентификация, инъекция, атаки посредника или другие типы атак.
Профилактика
4. Внешние объекты XML (XXE)
Атаки XXE нацелены на веб-приложения, обрабатывающие ввод XML. Обычно это происходит из-за старых или плохо настроенных процессоров XML. Воспользовавшись этой уязвимостью, хакеры могут получить доступ к внутренним и внешним системам для выполнения подделки запросов на стороне сервера (SSRF).
Профилактика
5. Нарушенный контроль доступа
Нарушение управления доступом — это тип уязвимости веб-приложения, когда пользователи могут выполнять некоторые действия, к которым у них не должно быть доступа. Разработчики со злонамеренными намерениями могут использовать его для подключения к другим учетным записям пользователей, изменения информации внутри них, просмотра конфиденциальных данных и, в худшем случае, получения полного контроля над приложением. Уязвимости контроля доступа обычно возникают из-за плохого функционального тестирования и отсутствия автоматического обнаружения.
Профилактика
6. Неверная конфигурация безопасности
Неправильная конфигурация безопасности — одна из распространенных проблем веб-приложений. Это проблема, связанная с отсутствием реализации контроля безопасности или проблемами, вызванными ошибками безопасности. Большинство приложений имеют эту уязвимость из-за неполных конфигураций, конфигураций по умолчанию, которые оставались неизменными в течение долгого времени, незашифрованных файлов, ненужных запущенных служб и т. Д. Неправильная конфигурация безопасности может привести к серьезным утечкам данных, которые запятнают репутацию компании и приведут к значительным финансовым потерям.
Nissan North American — одна из недавних жертв хакерской атаки, вызванной уязвимостью неправильной конфигурации. Серьезная утечка данных произошла из-за неправильно настроенного сервера Git компании, который был защищен учетными данными по умолчанию (имя пользователя и пароль) admin / admin.
Профилактика
7. Межсайтовый скриптинг (XSS)
Уязвимость XSS позволяет хакерам выполнять вредоносные сценарии в браузере пользователя. Их можно выполнить по вставленной ссылке. Если пользователь нажимает на нее, злоумышленник может получить доступ к важным функциям (веб-камера, местоположение и т. Д.), Захватить сеанс, перенаправить пользователя на опасные веб-сайты и т. Д.
Профилактика
8. Небезопасная десериализация
Когда дело доходит до небезопасной десериализации, ненадежные данные наносят ущерб веб-приложению из-за удаленного выполнения вредоносного кода, обхода аутентификации и изменения логики приложения.
Профилактика
9. Использование компонентов с известными уязвимостями
Сложность обнаружения уязвимостей заключается в сложности веб-приложения. Современная разработка веб-приложений во многом зависит от различных фреймворков, библиотек, API и т.д. Которые, в свою очередь, состоят из других элементов, которые могут стать целью хакерской атаки, а также самого приложения.
В последнее время было много шума вокруг охотника за ошибками, Алекса Бирсана, которому удалось взломать Apple, Microsoft и других крупных технологических гигантов, воспользовавшись уязвимостью «путаница зависимостей». Он обнаружил, что многие компании используют как частные, так и публичные зависимости. Итак, он предположил, что вредоносный код может быть загружен в общедоступную зависимость, но под именем частной. Он также понял, что в случае частной и общественной зависимости приоритет будет отдаваться последней. Таким образом, ему удалось успешно распространить свой вредоносный код. К счастью, у него были добрые намерения, и он предупреждал компании об их слабостях.
Профилактика
10. Недостаточное ведение журнала и мониторинг
Недостаточное ведение журнала и мониторинг позволяют злоумышленникам оставаться незамеченными, пытаясь достичь своих вредоносных целей. Эта уязвимость является наиболее частой причиной, по которой компании не могут устранить утечки данных. Более того, недостаточное ведение журнала и мониторинг может привести к дальнейшим проникновениям в систему и огромным потерям.
Профилактика
Заключение
Безопасность — ключевая особенность разработки современных веб-приложений. Чтобы оставаться конкурентоспособными на рынке, компании должны предлагать новые решения безопасности. Чтобы противостоять хакерам и предоставлять своим клиентам надежные и безопасные приложения.
Однако большая часть безопасности веб-приложений зависит от осведомленности разработчиков о киберугрозах и запланированного мониторинга действий приложения. Таким образом, если ваши инженеры-программисты обладают достаточными знаниями о наиболее распространенных уязвимостях безопасности веб-приложений, это поможет вам защитить свое веб-приложение и создать лучший имидж компании.
Безопасность веб-приложений: от уязвимостей до мониторинга
Уязвимости веб-приложений возникают тогда, когда разработчики добавляют небезопасный код в веб-приложение. Это может происходить как на этапе разработки, так и на этапе доработки или исправления найденных ранее уязвимостей. Недостатки часто классифицируются по степени критичности и их распространенности. Объективной и наиболее популярной классификацией уязвимостей считается OWASP Top 10. Рейтинг составляется специалистами OWASP Project и актуализируется каждые 3-4 года. Текущий релиз выпущен в 2017 году, а следующий ожидается в 2020-2021.
Распространенные уязвимости
Для начала рассмотрим типовые уязвимости, которым подвержены многие веб-приложения.
Инъекции
Как и полагается, атаки класса «Инъекции» занимают лидирующую строчку рейтинга OWASP Top 10, встречаясь практически повсеместно и являясь крайне разнообразными в реализации. Уязвимости подобного класса начинаются SQL-инъекциями, в различных его вариациях, и заканчивая RCE — удаленным выполнением кода.
Межсайтовый скриптинг — уязвимость, встречающаяся на данный момент куда реже, чем раньше, если верить рейтингу OWASP Top 10, но несмотря на это не стала менее опасной для веб-приложений и пользователей. Особенно для пользователей, ведь атака XSS нацелена именно на них. В общем случае злоумышленник внедряет скрипт в веб-приложение, который срабатывает для каждого пользователя, посетившего вредоносную страницу.
LFI/RFI
Уязвимости данного класса позволяют злоумышленникам через браузер включать локальные и удаленные файлы на сервере в ответ от веб-приложения. Эта брешь присутствует там, где отсутствует корректная обработка входных данных, которой может манипулировать злоумышленник, инжектировать символы типа path traversal и включать другие файлы с веб-сервера.
Атаки через JSON и XML
Веб-приложения и API, обрабатывающие запросы в формате JSON или XML, также подвержены атакам, поскольку такие форматы имеют свои недостатки.
JSON (JavaScript Object Notation) — это облегченный формат обмена данными, используемый для связи между приложениями. Он похож на XML, но проще и лучше подходит для обработки с помощью JavaScript. Многие веб-приложения используют этот формат для обмена данными между собой и сериализации/десериализации данных. Некоторые веб-приложения также используют JSON для хранения важной информации, например, данных пользователя. Обычно используется в RESTful API и приложениях AJAX.
JSON чаще всего ассоциируется с API, тем не менее, часто используется даже в обычных и хорошо известных веб-приложениях. Например, редактирование материалов в WordPress производится именно через отправку запросов в формате JSON:
JSON Injection
Простая инъекция JSON на стороне сервера может быть выполнена в PHP следующим образом:
Простая инъекция JSON на стороне клиента может быть выполнена следующим образом:
JSON Hijacking
Захват JSON — атака, в некотором смысле похожая на подделку межсайтовых запросов (CSRF), при которой злоумышленник старается перехватить данные JSON, отправленные веб-приложению с веб-сервера:
XML External Entity
Атака внешней сущности XML (XXE) — это тип атаки, в котором используется широко доступная, но редко используемая функция синтаксических анализаторов XML. Используя XXE, злоумышленник может вызвать отказ в обслуживании (DoS), а также получить доступ к локальному и удаленному контенту и службам. XXE может использоваться для выполнения подделки запросов на стороне сервера (SSRF), заставляя веб-приложение выполнять запросы к другим приложениям. В некоторых случаях c помощью XXE может даже выполнить сканирование портов и удаленное выполнение кода.
XML (Extensible Markup Language) — очень популярный формат данных. Он используется во всем: от веб-сервисов (XML-RPC, SOAP, REST) до документов (XML, HTML, DOCX) и файлов изображений (данные SVG, EXIF). Для интерпретации данных XML приложению требуется анализатор XML, известный как XML-процессор. XML можно использовать не только для объявления элементов, атрибутов и текста. XML-документы могут быть определенного типа. Тип указывается в самом документе, объявляя определение типа. Анализатор XML проверяет, соответствует ли XML-документ указанному типу, прежде чем обрабатывать документ. Вы можете использовать два варианта определений типов: определение схемы XML (XSD) или определение типа документа (DTD). Уязвимости XXE встречаются в последнем варианте. Хотя DTD можно считать устаревшими, но он все еще широко используются.
Фактически, объекты XML могут поступать практически откуда угодно, включая внешние источники (отсюда и название XML External Entity). При этом, XXE может стать разновидностью атаки подделки запросов на стороне сервера (SSRF). Злоумышленник может создать запрос, используя URI (известный в XML как системный идентификатор). Если синтаксический анализатор XML настроен для обработки внешних сущностей, а по умолчанию многие популярные анализаторы XML на это настроены, веб-сервер вернет содержимое файла в системе, потенциально содержащего конфиденциальные данные.
Злоумышленник, разумеется, не ограничивается системными файлами. Можно легко заполучить и другие локальные файлы, включая исходный код, если известно расположение файлов на сервере или структура веб-приложения. Атаки на внешние объекты XML могут позволить злоумышленнику выполнять HTTP-запросы к файлам в локальной сети т.е. доступным только из-за брандмауэра.
Уязвимости веб-приложений: под ударом пользователи
В 70% веб-сайтов есть критически опасные уязвимости, позволяющие злоумышленникам получать доступ к сайту и причинять серьёзные неприятности не только его владельцу, но и многочисленным пользователям. По средствам разработки самыми дырявыми оказались в 2015 году приложения на Java, значительно возросла доля ресурсов с уязвимостями высокой степени риска на базе серверов Microsoft IIS. При этом использование автоматизированного анализатора исходного кода позволяет выявить в 3 раза больше опасных уязвимостей, чем ручные методы анализа.
Такие выводы содержатся в исследовании компании Positive Technologies на основе статистики, собранной в ходе работ по анализу защищенности веб-приложений в 2015 году. Сравнение с данными аналогичных исследований 2014 и 2013 годов дает возможность оценить динамику развития современных веб-приложений с точки зрения ИБ. В данной статье представлены основные результаты исследования.
Источники и методика
Ежегодно специалисты Positive Technologies изучают около 250—300 веб-приложений в рамках различных работ, начиная от инструментального сканирования и заканчивая анализом исходного кода. По итогам выполненных проектов в 2015 году было выделено 30 веб-приложений, для которых проводился углубленный анализ с наиболее полным покрытием проверок. При этом учитывались только те уязвимости, которые были подтверждены путем проведения проверок на тестовом стенде.
Оценка защищенности проводилась методами черного, серого и белого ящиков — как вручную (с использованием вспомогательных автоматизированных средств), так и с помощью автоматизированного анализатора кода. Метод черного ящика означает исследование сайта от лица внешнего атакующего без дополнительной информации о системе со стороны владельца. Метод серого ящика аналогичен методу черного ящика, но в качестве нарушителя рассматривается пользователь, обладающий определенными привилегиями в системе. Метод белого ящика использует все необходимые данные о системе, включая исходный код приложений.
В настоящей статистике приведены только уязвимости, связанные с ошибками в коде и конфигурации веб-приложений. Уязвимости классифицировались согласно угрозам по WASC TC v. 2, за исключением категорий Improper Input Handling и Improper Output Handling, поскольку они реализуются в рамках множества других атак. Степень риска уязвимостей оценивалась согласно CVSS v. 2.
Исследованные приложения принадлежали компаниям, представляющим телекомы (23%), промышленность (20%), СМИ (17%), IT-компании (17%), финансы (13%) и государственные организации (10%).
Большинство веб-приложений, вошедших в выборку, разработаны на Java (43%) и PHP (30%), также встречались приложения, созданные с использованием технологий ASP.NET, Perl, ABAP, 1С и других. Приложения работали под управлением серверов Nginx (34%), Microsoft IIS (19%), Apache Tomcat (14%) и WebLogic (14%), а также под Apache и SAP NetWeaver Application Server. Примерно половина исследованных ресурсов (53%) представляли собой продуктивные системы, уже доступные пользователям через интернет, вторую половину составляли тестовые площадки, находящиеся в процессе разработки или приемки в эксплуатацию.
Самые популярные уязвимости
Недостатки как минимум среднего уровня риска были обнаружены во всех исследованных приложениях. При этом в 70% рассмотренных систем были обнаружены критически опасные уязвимости. В течение последних трех лет доля таких систем растет: в 2014 году их было 68%, в 2013 – только 61%.
Большинство исследованных приложений позволяют атаковать пользователей. В коде 80% ресурсов обнаружена уязвимость среднего уровня риска «Межсайтовое выполнение сценариев» (Cross-Site Scripting, XSS). В результате эксплуатации данной уязвимости злоумышленник может внедрить в браузер пользователя произвольные HTML-теги, включая сценарии на языке JavaScript и других языках, и таким образом получить значение идентификатора сессии атакуемого и совершить иные неправомерные действия, например фишинговые атаки.
На втором месте — утечка информации (Information Leakage): уязвимость обнаружена в каждом втором веб-приложении. 47% веб-сайтов также содержат уязвимости, связанные с отсутствием защиты от подбора учетных данных (Brute Force). Наиболее распространенным недостатком высокого уровня риска в 2015 году стала уязвимость «Внедрение внешних сущностей XML» (XML External Entities). Уязвимость позволяет злоумышленнику получить содержимое файлов, расположенных на атакуемом сервере, либо совершать запросы в локальную сеть от имени атакуемого сервера.
Средства разработки: Java не лучше PHP
В исследованиях прошлых лет PHP-приложения как правило были более уязвимы, чем системы, разработанные с помощью ASP.NET и Java. Однако на сегодняшний день картина изменилась: 69% Java-приложений подвержены критически опасным уязвимостям, а для PHP-систем данный показатель составил 56%, что ниже уровня 2013 года на 20%.
Каждое веб-приложение на PHP в среднем содержит 9,1 критически опасных уязвимостей, приложение на Java — 10,5. Для всех других языков программирования и средств разработки в среднем на каждую систему приходится лишь 2 критически опасные уязвимости.
Уязвимость «Межсайтовое выполнение сценариев» оказалась наиболее распространенной для всех языков программирования. Доля приложений, подверженных уязвимости «Внедрение операторов SQL», сократилась по сравнению с 2014 годом: тогда уязвимость была выявлена в 67% веб-ресурсов, разработанных на PHP, а сейчас встречается только в 22%.
Дырявые сервера на Microsoft IIS
Доля ресурсов с уязвимостями высокой степени риска на базе Microsoft IIS значительно возросла по сравнению с предыдущими годами и достигла максимального значения. Зато доля уязвимых сайтов под управлением Nginx снизилась (с 86% до 57%), тоже самое с Apache Tomcat (с 60 до 33%).
Веб-приложения с уязвимостями высокой степени риска (по типу веб-сервера)
Для большинства веб-серверов самой распространенной ошибкой администрирования является утечка информации. Данный недостаток был обнаружен во всех исследованных приложениях под управлением серверов Microsoft IIS. На втором месте — отсутствие защиты от подбора учетных данных.
Сайты банков и IT-компаний под угрозой
Как и в пошлом году, на всех банковских сайтах обнаружены критически опасные уязвимости. Аналогичная ситуация наблюдается в сфере IT. Положительная динамика отмечена лишь для приложений промышленных и телекоммуникационных компаний.
Доли приложений с уязвимостями высокого уровня риска для различных отраслей экономики
Рабочие системы защищены ненамного лучше тестовых
Доля уязвимых приложений, уже находящихся в эксплуатации, очень велика: более половины (63%) подвержены критически опасным уязвимостям. Такие недостатки могут позволить нарушителю получить полный контроль над системой (например, в случае загрузки произвольных файлов или выполнения команд), а также получать чувствительную информацию (например, в результате эксплуатации уязвимостей «Внедрение операторов SQL», «Внедрение внешних сущностей XML» и других). Также нарушитель может проводить успешные атаки типа «отказ в обслуживании».
Максимальный уровень риска обнаруженных уязвимостей для тестовых и продуктивных систем (доли уязвимых систем)
Анализ исходного кода лучше выявляет опасные уязвимости
Доля систем, подверженных критически опасным уязвимостям, которые были обнаружены методом черного ящика, существенно ниже, чем аналогичный показатель для сайтов, где анализировали исходные коды приложения. Однако даже для метода черного и серого ящика доля систем с опасными уязвимостями довольно велика (59%). Таким образом, отсутствие у атакующего доступа к исходным кодам не делает веб-приложения защищенными.
Доли систем с уязвимостями разной степени риска по методу тестирования
При этом среднее количество уязвимостей различного уровня риска на одну систему, выявленных методом белого ящика, существенно выше, чем при тестировании методами черного и серого ящиков.
Среднее количество обнаруженных уязвимостей на одну систему
В рамках исследования было также проведено сравнение результатов работ, осуществленных методом белого ящика вручную либо с использованием автоматизированного сканера. В среднем в каждой системе выявлено около 15 критически опасных уязвимостей в случае использования анализатора кода (учитывались только подтвержденные уязвимости), и всего 4 уязвимости — ручными методами.
Среднее количество выявленных уязвимостей определенного уровня риска на одну систему разными методами
Таким образом, анализ защищенности методом белого ящика существенно эффективнее других методов, при которых не анализируется исходный код приложения. При этом автоматизированный анализ кода оказывается достаточно эффективным, особенно если учесть объемы кода современных приложений, где используется множество библиотек.
В целом полученные данные свидетельствуют о необходимости регулярно проводить работы по анализу защищенности веб-приложений. Важно осуществлять такой анализ на всех стадиях разработки, а также регулярно (например, дважды в год) в процессе эксплуатации систем. Кроме того, приложения, уже находящихся в эксплуатации, нуждаются в эффективной защите от атак: более половины таких ресурсов (63%) оказались подвержены критически опасным уязвимостям. Эти недостатки могут привести не только к разглашению важных данных, но и к полной компрометации системы, либо выводу ее из строя. Для защиты от таких атак рекомендуется применять межсетевые экраны уровня приложений.
OWASP TOP-10: практический взгляд на безопасность веб-приложений
Хабр, привет! Мы — Иван Притула и Дмитрий Агапитов, занимаемся разработкой решений, которые делают жизнь людей проще и комфортнее. Сегодня мы хотим представить один из наших новых сервисов – это платежный агрегатор SimplePay. Все что мы делаем продиктовано мучительной невозможностью мириться с несовершенством в целом, и несовершенством конкретных программных решений в частности. Именно в погоне за совершенством и рождаются наши продукты. Стараемся мы изо всех сил, а уж насколько мы близки, судить не нам.
Чтобы Всем было интереснее, мы не будем рекламировать свой сервис (ну если только чуть-чуть). Вместо этого, мы подготовили первую серию публикаций, которая будет посвящена такой увлекательной и крайне актуальной теме, как безопасность Web-приложений. Мы постараемся раскрыть опасности, сопутствующие любому действующему интернет-проекту и простым языком донести всю важность ответственного подхода к рутинным, казалось бы, мелочам в вопросах безопасности данных. Надеемся наши статьи будут не бесполезны для Вас. Уверены, так Вы узнаете нас гораздо лучше.
SimplePay — это современный высокотехнологичный агрегатор платежей. Компания создана в 2014г., зарегистрирована в г. Москве и ведет свою деятельность в соответствии с законодательством Российской Федерации. Наша основная задача, это обеспечение простой, удобной возможности организации приема платежей на интернет-сайтах компаний, вне зависимости от сферы деятельности, масштаба бизнеса и наличия подготовленного технического персонала.
Мы предлагаем следующие услуги:
Безопасность веб-приложений
Современный мир несет в себе тысячи угроз и потенциальных опасностей буквально на каждом шагу и в каждый момент времени. Всемирная сеть, ставшая неотъемлемой частью нашей жизни, не является исключением.
Киберпреступность сейчас развита как никогда – ведь почти каждая компания имеет свой сайт в интернете, а злоумышленник в сети может легко оставаться абсолютно анонимным.
При этом все компании, имеющие сайт в интернете, делятся на три типа:
Акцент на возможности практического применения сделан не случайно. Мы считаем, что недостаточно знать теорию для понимания истинного масштаба угрозы – ведь уязвимости, которые выглядят не очень страшно в теории, зачастую могут нести катастрофические для бизнеса последствия.
Количество угроз растет пропорционально росту бизнеса, однако как показала многолетняя практика, 99% атак происходят через десяток стандартных ошибок валидации входящих данных, либо обнаруженные уязвимости в установленных компонентах программного обеспечения сторонних производителей, либо банально, по халатности системных администраторов, использующих настройки и пароли, установленные по-умолчанию.
Классификацией векторов атак и уязвимостей занимается сообщество OWASP (Open Web Application Security Project). Это международная некоммерческая организация, сосредоточенная на анализе и улучшении безопасности программного обеспечения.
OWASP создал список из 10-и самых опасных векторов атак на Web-приложения, этот список получил название OWASP TOP-10 и в нем сосредоточены самые опасные уязвимости, которые могут стоить некоторым людям больших денег, или подрыва деловой репутации, вплоть до потери бизнеса.
В этой вводной статье мы пробежимся по списку OWASP TOP-10, а далее в рамках серии наших статей «Теория и практика защиты Web-приложений» подробно рассмотрим каждый из перечисленных векторов атак, методы практической эксплуатации, степень опасности на примерах реального бизнеса, а также методы практической защиты Web-приложений и Web-сервисов.
Мы постараемся вести изложение максимально доступно, с целью донести информацию не только и не столько до технических специалистов, но также до собственников и управляющих бизнеса, которые, порой, пребывают в счастливом неведении, пока их не сломали злоумышленники, и занимаются онлайн-бизнесом, не ведая о серьезнейшей опасности, нависшей над ними.
1. Инъекции — Injections
Все данные, как правило, хранятся в специальных базах, обращения к которым строятся в виде запросов, чаще всего написанных на специальном языке запросов SQL (Structured Query Language – структурированный язык запросов).
Приложения используют SQL-запросы для того, чтобы получать, добавлять, изменять или удалять данные, например при редактировании пользователем своих личных данных или заполнении анкеты на сайте. При недостаточной проверке данных от пользователя, злоумышленник может внедрить в форму Web-интерфейса приложения специальный код, содержащий кусок SQL-запроса.
Такой вид атаки называется инъекция, в данном случае самый распространённый — SQL-инъекция. Это опаснейшая уязвимость, позволяющая злоумышленнику получить доступ к базе данных и возможность читать/изменять/удалять информацию, которая для него не предназначена.
Например, изменить вместе с именем и фамилией баланс своего счета, посмотреть баланс чужого счета, или же, похитить конфиденциальные личные данные.
Эта уязвимость является следствием недостаточной проверки данных, поступающих от пользователя. Это позволяет злоумышленнику «подсунуть», например, в веб-формы, специально подготовленные запросы, которые «обманут» приложение и позволят прочитать или записать нелегитимные данные.
В целом эта разновидность атак имеет общее название «Ошибки валидации», к ней относятся далеко не только SQL-инъекции и мы будем упоминать этот вектор еще не раз.
2. Недочеты системы аутентификации и хранения сессий (Broken Authentication and Session Management)
Для того, чтобы отличать одного пользователя от другого, web-приложение использует так называемые сессионные куки. После того, как Вы ввели логин и пароль и приложение вас авторизовало, в хранилище браузера сохраняется специальный идентификатор, который браузер в дальнейшем предъявляет серверу при каждом запросе страницы вашего web-приложения. Именно так web-приложение понимает, что Вы это именно Вы.
В случае, если ваш идентификатор украдет злоумышленник, а в системе не были реализованы проверки, скажем IP-адреса сессии, или проверки наличия более одного соединения в одной сессии, злоумышленник сможет получить доступ в систему с правами вашего аккаунта. А если это интернет-банк или кабинет платежной системы, о последствиях такого несанкционированного доступа Вы можете легко догадаться сами.
3. Межсайтовый скриптинг – XSS (Cross Site Scripting)
Межсайтовый скриптинг – еще одна ошибка валидации пользовательских данных, которая позволяет передать JavaScript код на исполнение в браузер пользователя. Атаки такого рода часто также называют HTML-инъекциями, ведь механизм их внедрения очень схож с SQL-инъекциями, но в отличие от последних, внедряемый код исполняется в браузере пользователя. Чем это чревато?
Во-первых, злоумышленник может украсть вашу сессионную cookie, последствия чего были описаны во втором пункте, буквально парой абзацев выше. Нужно отметить, что далеко не все серверы приложений уязвимы к данному типу атак, об этом мы отдельно поговорим в пункте под номером 5.
Во-вторых, могут быть украдены данные, вводимые в формы на зараженной странице. А это могут быть конфиденциальные персональные данные, или, что еще хуже, данные кредитной карты вместе с CVC-кодом.
В третьих, через JavaScript можно изменять данные, расположенные на странице, например, там могут быть реквизиты для банковского перевода, которые злоумышленник с удовольствием подделает и заменит подставными.
4. Небезопасные прямые ссылки на объекты (Insecure Direct Object References)
Данный вид уязвимости является также следствием недостаточной проверки пользовательских данных. Суть ее заключается в том, что при выводе каких-либо конфиденциальных данных, например личных сообщений или учетных карточек клиентов, для доступа к объекту используется идентификатор, который передается в открытом виде в адресной строке браузера, И не реализована проверка прав доступа к объектам. Например, есть страница, которая отображает личное сообщение и она имеет адрес вида:
Перебирая число после «id=» можно будет читать чужие личные сообщения. Эксплуатация данной уязвимости очень проста и не требует вообще никаких специальных навыков – достаточно лишь перебирать число в адресной строке браузера и наслаждаться результатом. Как ни парадоксально, но этой детской болезни, порой были подвержены достаточно крупные европейские платежные системы.
5. Небезопасная конфигурация (Security Misconfiguration)
Безопасность Web-приложения требует наличия безопасной конфигурации всех компонентов инфраструктуры: компонентов приложения (таких как фреймворки – frameworks), веб-сервера, сервера баз данных и самой платформы. Настройки компонентов сервера по-умолчанию зачастую небезопасны и открывают возможности к атакам. Например, кража сессионной cookie через JavaScript при XSS-атаке становится возможна благодаря выключенной по-умолчанию настройке cookie_http only.
При правильной настройке сервера и включенной опции cookie_httponly, получить сессионную cookie через JavaScript невозможно, но зачастую эта простая и важная настройка отсутствовала в таких критично важных местах, как личные кабинеты платежных систем.
Еще один пример детской уязвимости – использование настроек по-умолчанию в серверах баз данных, таких как Redis, Memcached и других – закрытая служба может быть доступна на публичном IP-адресе сервера, и/или использовались пароли, установленные производителем по-умолчанию. Это позволяет злоумышленнику запросто читать и изменять данные, в числе которых, нередко бывают и сессионные cookies (чем это чревато – мы уже знаем) и выводимые пользователям в браузер данные (что позволяет еще и XSS-атаку применить).
Кроме того, программное обеспечение должно быть в актуальном состоянии: уязвимости находят каждый день в самых различных программных компонентах – операционной системе, web-серверах, серверах баз данных, почтовых серверах и т.д. И даже если ваше приложение правильно написано и тщательно проверяет все входящие данные, и вообще, хорошо защищено, это не означает что в один прекрасный момент не найдется уязвимость в вашей ОС или Web-сервере.
6. Незащищенность критичных данных (Sensitive Data Exposure)
Многие веб-приложения не защищают конфиденциальные данные, такие как кредитные карты и учетные данные для аутентификации. Злоумышленники могут украсть или модифицировать такие слабо защищенные данные для использования в своих корыстных целях.
Самый простой пример – передача данных по протоколу HTTP. Дело в том, что данные передаваемые по протоколу HTTP никак не шифруются, а при прохождении данных от компьютера пользователя до Web-сервера, данные пройдут достаточно много различных узлов: маршрутизатор офиса или домашний роутер, маршрутизатор провайдера, маршрутизатор на канале, маршрутизатор в дата-центре хостинг-провайдера сервера и так далее. На каждом из этих узлов может затаиться зловред, так называемый сниффер, программа, которая считывает весь трафик и передает злоумышленнику. А последний просматривает полученные данные на предмет персональных данных и данных кредитных карт.
Такие данные должны передаваться исключительно по протоколу HTTPS, о чем должна гласить соответствующая надпись в адресной строке браузера:
Еще одна задача SSL-сертификата (а именно так называется специальный ключ, при помощи которого осуществляется проверка подлинности и шифрование в HTTPS) – подтвердить, что он выдан именно для данного сайта. В случае, если сертификат просрочен или подделан, Вы увидите следующую картину:
Другой пример – отсутствие шифрования критичных данных, таких как пароли или номера кредитных карт. В случае, если данные зашифрованы, то даже в случае получения несанкционированного доступа на сервер, злоумышленник не сможет украсть критичные данные. К паролям, в частности, должна применяться необратимая хеш-функция – расшифровать шифрограмму при этом не возможно и проверка пароля происходит путем формирования шифрограммы введенного пароля и сравнения ее с имеющейся в базе.
7. Отсутствие функций контроля доступа (Missing Function Level Access Control)
Суть уязвимости, как следует из названия, заключается в отсутствии проверки наличия надлежащего доступа к запрашиваемому объекту.
Большинство веб-приложений проверяют права доступа, прежде чем отобразить данные в пользовательском интерфейсе. Тем не менее, приложения должны выполнять те же проверки контроля доступа на сервере при запросе любой функции. Ведь есть еще множество вспомогательных служебных запросов, которые, зачастую отправляются в фоновом режиме асинхронно, при помощи технологии AJAX.
Если параметры запроса не достаточно тщательно проверяются, злоумышленники смогут подделать запрос для доступа к данным без надлежащего разрешения.
Частный, и пожалуй, самый распространенный случай данной уязвимости мы уже рассмотрели в 4 пункте нашей статьи – отсутствие проверки пользователя в личных сообщениях.
8. Межсайтовая подделка запроса (Cross-Site Request Forgery, CSRF/XSRF)
Вектор атаки CSRF, также известный как XSRF, позволяет злоумышленнику выполнять от имени жертвы действия на сервере, где не реализованы дополнительные проверки.
Например, в некоторой платежной системе для перевода средств на другой аккаунт, есть страница вида:
demobank.com/transfer_money.jsp?transfer_amount=1000&transfer_account=123456789
где transfer_amount – сумма для перевода и transfer_account – номер аккаунта, куда должны быть переведены средства.
Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на вышеуказанную страницу платежной системы. Как результат – деньги уйдут на счет злоумышленника, после чего, вероятно, будут оперативно обменяны на Bitcoin или переведены в другую безвозвратную платежную систему, и получить их назад уже не получится.
Предполагается, что жертва должна была предварительно пройти аутентификацию в платежной системе и должна быть открыта активная сессия (скажем, страница платежной системы открыта в другой вкладке браузера).
Решается проблема достаточно просто и об этом мы расскажем в отдельной статье, посвященной CSRF.
9. Использование компонентов с известными уязвимостями (Using Components with Known Vulnerabilities)
Зачастую web-приложения написаны с использованием специальных библиотек или «фреймворков» (англ – framework), которые поставляются сторонними компаниями. В большинстве случаев эти компоненты имеют открытый исходный код, а это означает, что они есть не только у вас, но и у миллионов людей во всем мире, которые штудируют их исходный код, в том числе, и на предмет уязвимостей. И нужно отметить, что делают они это отнюдь не безуспешно.
Также уязвимости ищут (и находят) в более низкоуровневых компонентах системы, таких как сервер базы данных, web-сервер, и наконец, компоненты операционной системы вплоть до ее ядра.
Очень важно использовать последние версии компонентов и следить за появляющимися известными уязвимостями на сайтах типа securityfocus.com.
10. Непроверенные переадресации и пересылки (Unvalidated Redirects and Forwards)
Web-приложения зачастую переадресуют пользователя с одной страницы на другую. В процессе могут использоваться ненадлежащим образом проверяемые параметры с указанием страницы конечного назначения переадресации.
Без соответствующих проверок, атакующий может использовать такие страницы для переадресации жертвы на подложный сайт, который, к примеру, может иметь очень схожий или неотличимый интерфейс, но украдет ваши данные кредитной карты или другие критичные конфиденциальные данные.
Этот вид уязвимостей, также как и многие другие перечисленные выше, является разновидностью ошибок проверки входящих данных (input validation).
Вместо заключения
Мы рассмотрели основные виды уязвимостей из OWASP TOP-10 в общем виде, постарались рассказать о них максимально простым языком, а также показать на простых практических примерах, какие риски несут для вашего бизнеса те или иные векторы атак.
В первую очередь эта статья была рассчитана на собственников интернет-проектов и молодых разработчиков. В дальнейших статьях мы осветим более подробно каждый из упомянутых векторов атак, уже с развернутыми техническими подробностями и наглядными примерами, и конечно же, способами защиты.
Если Вы – собственник бизнеса, мы надеемся, что ваше понимание рисков, связанных с IT-безопасностью стало более полным, а следующие статьи могут стать отличным пособием для ваших IT-специалистов.