что такое owasp top 10
Introduction
Welcome to the latest installment of the OWASP Top 10! The OWASP Top 10 2021 is all-new, with a new graphic design and an available one-page infographic you can print or obtain from our home page.
A huge thank you to everyone that contributed their time and data for this iteration. Without you, this installment would not happen. THANK YOU!
What’s changed in the Top 10 for 2021
There are three new categories, four categories with naming and scoping changes, and some consolidation in the Top 10 for 2021. We’ve changed names when necessary to focus on the root cause over the symptom.
Methodology
This installment of the Top 10 is more data-driven than ever but not blindly data-driven. We selected eight of the ten categories from contributed data and two categories from the Top 10 community survey at a high level. We do this for a fundamental reason, looking at the contributed data is looking into the past. AppSec researchers take time to find new vulnerabilities and new ways to test for them. It takes time to integrate these tests into tools and processes. By the time we can reliably test a weakness at scale, years have likely passed. To balance that view, we use an community survey to ask application security and development experts on the front lines what they see as essential weaknesses that the data may not show yet.
There are a few critical changes that we adopted to continue to mature the Top 10.
How the categories are structured
A few categories have changed from the previous installment of the OWASP Top Ten. Here is a high-level summary of the category changes.
Previous data collection efforts were focused on a prescribed subset of approximately 30 CWEs with a field asking for additional findings. We learned that organizations would primarily focus on just those 30 CWEs and rarely add additional CWEs that they saw. In this iteration, we opened it up and just asked for data, with no restriction on CWEs. We asked for the number of applications tested for a given year (starting in 2017), and the number of applications with at least one instance of a CWE found in testing. This format allows us to track how prevalent each CWE is within the population of applications. We ignore frequency for our purposes; while it may be necessary for other situations, it only hides the actual prevalence in the application population. Whether an application has four instances of a CWE or 4,000 instances is not part of the calculation for the Top 10. We went from approximately 30 CWEs to almost 400 CWEs to analyze in the dataset. We plan to do additional data analysis as a supplement in the future. This significant increase in the number of CWEs necessitates changes to how the categories are structured.
We spent several months grouping and categorizing CWEs and could have continued for additional months. We had to stop at some point. There are both root cause and symptom types of CWEs, where root cause types are like «Cryptographic Failure» and «Misconfiguration» contrasted to symptom types like «Sensitive Data Exposure» and «Denial of Service.» We decided to focus on the root cause whenever possible as it’s more logical for providing identification and remediation guidance. Focusing on the root cause over the symptom isn’t a new concept; the Top Ten has been a mix of symptom and root cause. CWEs are also a mix of symptom and root cause; we are simply being more deliberate about it and calling it out. There is an average of 19.6 CWEs per category in this installment, with the lower bounds at 1 CWE for A10:2021-Server-Side Request Forgery (SSRF) to 40 CWEs in A04:2021-Insecure Design. This updated category structure offers additional training benefits as companies can focus on CWEs that make sense for a language/framework.
How the data is used for selecting categories
In 2017, we selected categories by incidence rate to determine likelihood, then ranked them by team discussion based on decades of experience for Exploitability, Detectability (also likelihood), and Technical Impact. For 2021, we want to use data for Exploitability and (Technical) Impact if possible.
We downloaded OWASP Dependency Check and extracted the CVSS Exploit, and Impact scores grouped by related CWEs. It took a fair bit of research and effort as all the CVEs have CVSSv2 scores, but there are flaws in CVSSv2 that CVSSv3 should address. After a certain point in time, all CVEs are assigned a CVSSv3 score as well. Additionally, the scoring ranges and formulas were updated between CVSSv2 and CVSSv3.
In CVSSv2, both Exploit and (Technical) Impact could be up to 10.0, but the formula would knock them down to 60% for Exploit and 40% for Impact. In CVSSv3, the theoretical max was limited to 6.0 for Exploit and 4.0 for Impact. With the weighting considered, the Impact scoring shifted higher, almost a point and a half on average in CVSSv3, and exploitability moved nearly half a point lower on average.
There are 125k records of a CVE mapped to a CWE in the National Vulnerability Database (NVD) data extracted from OWASP Dependency Check, and there are 241 unique CWEs mapped to a CVE. 62k CWE maps have a CVSSv3 score, which is approximately half of the population in the data set.
For the Top Ten 2021, we calculated average exploit and impact scores in the following manner. We grouped all the CVEs with CVSS scores by CWE and weighted both exploit and impact scored by the percentage of the population that had CVSSv3 + the remaining population of CVSSv2 scores to get an overall average. We mapped these averages to the CWEs in the dataset to use as Exploit and (Technical) Impact scoring for the other half of the risk equation.
Why not just pure statistical data?
The results in the data are primarily limited to what we can test for in an automated fashion. Talk to a seasoned AppSec professional, and they will tell you about stuff they find and trends they see that aren’t yet in the data. It takes time for people to develop testing methodologies for certain vulnerability types and then more time for those tests to be automated and run against a large population of applications. Everything we find is looking back in the past and might be missing trends from the last year, which are not present in the data.
Therefore, we only pick eight of ten categories from the data because it’s incomplete. The other two categories are from the Top 10 community survey. It allows the practitioners on the front lines to vote for what they see as the highest risks that might not be in the data (and may never be expressed in data).
Why incidence rate instead of frequency?
There are three primary sources of data. We identify them as Human-assisted Tooling (HaT), Tool-assisted Human (TaH), and raw Tooling.
Tooling and HaT are high-frequency finding generators. Tools will look for specific vulnerabilities and tirelessly attempt to find every instance of that vulnerability and will generate high finding counts for some vulnerability types. Look at Cross-Site Scripting, which is typically one of two flavors: it’s either a more minor, isolated mistake or a systemic issue. When it’s a systemic issue, the finding counts can be in the thousands for a single application. This high frequency drowns out most other vulnerabilities found in reports or data.
TaH, on the other hand, will find a broader range of vulnerability types but at a much lower frequency due to time constraints. When humans test an application and see something like Cross-Site Scripting, they will typically find three or four instances and stop. They can determine a systemic finding and write it up with a recommendation to fix on an application-wide scale. There is no need (or time) to find every instance.
Suppose we take these two distinct data sets and try to merge them on frequency. In that case, the Tooling and HaT data will drown the more accurate (but broad) TaH data and is a good part of why something like Cross-Site Scripting has been so highly ranked in many lists when the impact is generally low to moderate. It’s because of the sheer volume of findings. (Cross-Site Scripting is also reasonably easy to test for, so there are many more tests for it as well).
In 2017, we introduced using incidence rate instead to take a fresh look at the data and cleanly merge Tooling and HaT data with TaH data. The incidence rate asks what percentage of the application population had at least one instance of a vulnerability type. We don’t care if it was one-off or systemic. That’s irrelevant for our purposes; we just need to know how many applications had at least one instance, which helps provide a clearer view of the testing is findings across multiple testing types without drowning the data in high-frequency results. This corresponds to a risk related view as an attacker needs only one instance to attack an application successfully via the category.
What is your data collection and analysis process?
We formalized the OWASP Top 10 data collection process at the Open Security Summit in 2017. OWASP Top 10 leaders and the community spent two days working out formalizing a transparent data collection process. The 2021 edition is the second time we have used this methodology.
We publish a call for data through social media channels available to us, both project and OWASP. On the OWASP Project page, we list the data elements and structure we are looking for and how to submit them. In the GitHub project, we have example files that serve as templates. We work with organizations as needed to help figure out the structure and mapping to CWEs.
We get data from organizations that are testing vendors by trade, bug bounty vendors, and organizations that contribute internal testing data. Once we have the data, we load it together and run a fundamental analysis of what CWEs map to risk categories. There is overlap between some CWEs, and others are very closely related (ex. Cryptographic vulnerabilities). Any decisions related to the raw data submitted are documented and published to be open and transparent with how we normalized the data.
We look at the eight categories with the highest incidence rates for inclusion in the Top 10. We also look at the Top 10 community survey results to see which ones may already be present in the data. The top two votes that aren’t already present in the data will be selected for the other two places in the Top 10. Once all ten were selected, we applied generalized factors for exploitability and impact; to help rank the Top 10 2021 in a risk based order.
Data Factors
There are data factors that are listed for each of the Top 10 Categories, here is what they mean:
Thank you to our data contributors
The following organizations (along with some anonymous donors) kindly donated data for over 500,000 applications to make this the largest and most comprehensive application security data set. Without you, this would not be possible.
Thank you to our sponsors
The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior and Just Eat.
🕵 Что такое Топ-10 OWASP и какие уязвимости веб-приложений наиболее опасны?
B1bikua
OWASP важен для организаций, потому что его рекомендации высоко ценятся проверяющими безопасность корпоративных систем аудиторами. Рекомендации проекта по защите приложений необходимо включить в жизненный цикл разработки программного обеспечения и использовать для формирования политик безопасности.
Отчет об уязвимостях OWASP формируется на основе консенсуса мнений экспертов по безопасности со всего мира. Он ранжирует риски на основе частоты дефектов, серьезности уязвимостей и их потенциального воздействия. Это дает разработчикам и специалистам по безопасности понимание наиболее серьезных рисков и позволяет им минимизировать возможные последствия эксплуатации уязвимостей злоумышленниками.
В последнем отчете OWASP перечислены 10 основных уязвимостей:
1. Инъекции
Инъекционные атаки можно предотвратить путем проверки и/или очистки отправленных пользователем данных. В первом случае подозрительные данные отклоняются полностью, а во втором производится очистка только их подозрительной части. Кроме того, администратор базы данных может установить специальные элементы управления, чтобы минимизировать объем информации, которую может раскрыть атака с использованием SQL-инъекций.
2. Нарушенная аутентификация
Веб-сайты часто имеют проблемы с механизмами аутентификации. Прежде всего связаны они с некорректным управлением сеансами, что может быть использовано злоумышленниками для получения доступа к учетным записям пользователей и учетным данным для входа.
OWASP Top 10 содержит целый список подобных уязвимостей:
Количество уязвимостей можно уменьшить путем внедрения многофакторной аутентификации, а также внедрения ограничений, делающих невозможности автоматизированные атаки грубой силы (например, путем перебора). Не менее важно отсутствие спешки и наличие у разработчиков времени на проверку изменений перед запуском в продакшен, а также внедрение процедур тестирования кода на безопасность. Также необходимо внедрить жесткую парольную политику и использовать безопасные диспетчеры сеансов.
3. Раскрытие критически важных данных
Основная причина риска раскрытия критически важных данных связана с отсутствием шифрования или с использованием ненадежных методов генерации и управления ключами, слабых алгоритмов шифрования, ненадежных способов хранения паролей и т.д. Кроме того, разработчики веб-приложений часто хранят конфиденциальные данные, даже если в этом нет необходимости.
4. Внешние объекты XML (XXE)
Атаки XXE нацелены на веб-приложения, которые анализируют расширяемый язык разметки (XML). Они возникают, когда ввод содержащего ссылку на внешний объект кода XML обрабатывается синтаксическим анализатором со слабой конфигурацией. Анализаторы XML часто по умолчанию уязвимы для XXE, а значит разработчики должны удалить уязвимость вручную.
Атаки XXE можно избежать, если веб-приложения принимают менее сложные формы данных (например, веб-токены JavaScript Object Notation (JSON)), исправляя синтаксические анализаторы XML или отключая использование внешних сущностей. Защититься от атак XXE можно, развернув шлюзы безопасности интерфейса прикладного программирования (API), виртуальные исправления и брандмауэры веб-приложений (WAF).
5. Нарушенный контроль доступа
Риск нарушения контроля доступа можно снизить, развернув концепцию наименее привилегированного доступа, регулярно проверяя серверы и веб-сайты, применяя MFA и удаляя с серверов неактивных пользователей и ненужные службы. Можно также защитить элементы управления доступом, используя токены авторизации при входе пользователей в веб-приложение и делая их недействительными после выхода из системы. Другие рекомендации включают регистрацию и отчеты об ошибках доступа, а также использование ограничения скорости для минимизации причиняемого автоматическими атаками ущерба.
6. Неправильная конфигурация безопасности
Неправильная конфигурация безопасности может быть где угодно: в приложениях и веб-серверах, базах данных, сетевых службах, пользовательском коде, фреймворках, предустановленных виртуальных машинах и контейнерах.
Конфигурацию безопасности можно исправить, изменив настройки веб-сервера или CMS по умолчанию, удалив неиспользуемые функции кода и контролируя данные пользователей и видимость пользовательской информации. Разработчики также должны удалить ненужную документацию, функции, структуры и образцы, сегментировать архитектуру приложений и автоматизировать проверку эффективности конфигураций и настроек веб-среды.
7. Межсайтовый скриптинг (XSS)
Предотвратить эксплуатацию уязвимостей XSS можно с помощью брандмауэров веб-приложений (WAF), в то время как разработчики могут снизить вероятность XSS-атак, отделяя ненадежные данные от активных браузеров. Это включает в себя использование фреймворков, которые избегают XSS по своей конструкции, использование очистки и проверки данных, избегание ненадежных данных запроса протокола передачи гипертекста (HTTP) и развертывание политики безопасности контента (CSP).
8. Небезопасная десериализация
Рекомендации OWASP по защите в отношении небезопасной десериализации касаются супер-файлов cookie, которые содержат сериализованную информацию о пользователях. Если злоумышленники могут успешно десериализовать объект, они могут предоставит себе роль администратора, сериализовать данные и поставить под угрозу все веб-приложения.
9. Использование компонентов с известными уязвимостями
Этого можно избежать с помощью виртуального исправления, которое защищает устаревшие веб-сайты от эксплуатации уязвимостей с помощью брандмауэров, систем обнаружения вторжений (IDS) и WAF. Эксплуатацию уязвимостей также можно предотвратить, сохранив только реально необходимые компоненты и удалив все неиспользуемые или не обслуживаемые. Лучшим методом будет установка компонентов из надежных источников и постоянное их обновление.
10. Недостаточно подробные журналы и слабый мониторинг
Успешную хакерскую атаку или утечку данных удается обнаружить далеко не всегда. Часто злоумышленники не только получают несанкционированный доступ к информационным системам, но хозяйничают в них месяцами или годами, оставаясь невидимыми. Чтобы этого не произошло, необходимо регистрировать и отслеживать поведение веб-приложения, чтобы своевременно распознать подозрительную активность и либо предотвратить атаку, любо минимизировать ее последствия.
OWASP Top Ten
The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
Globally recognized by developers as the first step towards more secure coding.
Companies should adopt this document and start the process of ensuring that their web applications minimize these risks. Using the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces more secure code.
Top 10 Web Application Security Risks
There are three new categories, four categories with naming and scoping changes, and some consolidation in the Top 10 for 2021.
Translation Efforts
2017 Completed Translations:
Historic:
2017 Release Candidate Translation Teams:
2013 Completed Translations:
2010 Completed Translations:
2021 Project Sponsors
The OWASP Top 10:2021 is sponsored by Secure Code Warrior.
2017 Project Sponsors
2003-2013 Project Sponsors
Thanks to Aspect Security for sponsoring earlier versions.
OWASP Top 10 2020 Data Analysis Plan
Goals
To collect the most comprehensive dataset related to identified application vulnerabilities to-date to enable analysis for the Top 10 and other future research as well. This data should come from a variety of sources; security vendors and consultancies, bug bounties, along with company/organizational contributions. Data will be normalized to allow for level comparison between Human assisted Tooling and Tooling assisted Humans.
Analysis Infrastructure
Plan to leverage the OWASP Azure Cloud Infrastructure to collect, analyze, and store the data contributed.
Contributions
We plan to support both known and pseudo-anonymous contributions. The preference is for contributions to be known; this immensely helps with the validation/quality/confidence of the data submitted. If the submitter prefers to have their data stored anonymously and even go as far as submitting the data anonymously, then it will have to be classified as “unverified” vs. “verified”.
Verified Data Contribution
Scenario 1: The submitter is known and has agreed to be identified as a contributing party.
Scenario 2: The submitter is known but would rather not be publicly identified.
Scenario 3: The submitter is known but does not want it recorded in the dataset.
Unverified Data Contribution
Scenario 4: The submitter is anonymous. (Should we support?)
The analysis of the data will be conducted with a careful distinction when the unverified data is part of the dataset that was analyzed.
Contribution Process
There are a few ways that data can be contributed:
Contribution Period
We plan to accept contributions to the new Top 10 from May to Nov 30, 2020 for data dating from 2017 to current.
Data Structure
The following data elements are required or optional.
The more information provided the more accurate our analysis can be.
At a bare minimum, we need the time period, total number of applications tested in the dataset, and the list of CWEs and counts of how many applications contained that CWE.
If at all possible, please provide the additional metadata, because that will greatly help us gain more insights into the current state of testing and vulnerabilities.
Metadata
CWE Data
If at all possible, please provide core CWEs in the data, not CWE categories.
This will help with the analysis, any normalization/aggregation done as a part of this analysis will be well documented.
If a contributor has two types of datasets, one from HaT and one from TaH sources, then it is recommended to submit them as two separate datasets.
HaT = Human assisted Tools (higher volume/frequency, primarily from tooling)
TaH = Tool assisted Human (lower volume/frequency, primarily from human testing)
Survey
Similarly to the Top Ten 2017, we plan to conduct a survey to identify up to two categories of the Top Ten that the community believes are important, but may not be reflected in the data yet. We plan to conduct the survey in May or June 2020, and will be utilizing Google forms in a similar manner as last time. The CWEs on the survey will come from current trending findings, CWEs that are outside the Top Ten in data, and other potential sources.
Process
At a high level, we plan to perform a level of data normalization; however, we will keep a version of the raw data contributed for future analysis. We will analyze the CWE distribution of the datasets and potentially reclassify some CWEs to consolidate them into larger buckets. We will carefully document all normalization actions taken so it is clear what has been done.
We plan to calculate likelihood following the model we developed in 2017 to determine incidence rate instead of frequency to rate how likely a given app may contain at least one instance of a CWE. This means we aren’t looking for the frequency rate (number of findings) in an app, rather, we are looking for the number of applications that had one or more instances of a CWE. We can calculate the incidence rate based on the total number of applications tested in the dataset compared to how many applications each CWE was found in.
In addition, we will be developing base CWSS scores for the top 20-30 CWEs and include potential impact into the Top 10 weighting.
Also, would like to explore additional insights that could be gleaned from the contributed dataset to see what else can be learned that could be of use to the security and development communities.
Что такое OWASP Top-10 и как использовать указанные риски и уязвимости
При управлении сайтом важно быть в курсе наиболее значимых уязвимостей и угроз безопасности. Рейтинг OWASP Top 10 — отличная отправная точка для ознакомления с самыми серьёзными угрозами для веб-приложений, существующими на данный момент.
Что такое OWASP?
OWASP (расшифровывается как Open Web Application Security Project) — это онлайн-сообщество, которое выпускает статьи на тему безопасности веб-приложений, а также документацию, различные инструменты и технологии.
Что такое OWASP Топ-10?
OWASP Топ-10 — это список из десяти самых распространённых на данный момент уязвимостей веб-приложений. Благодаря этому списку пользователи будут осведомлены о наиболее критичных рисках и угрозах, их последствиях и мерах противодействия. Обновляется список OWASP каждые три-четыре года (последний раз он был выпущен в 2018 году). Давайте познакомимся с ним поближе.
10 основных уязвимостей OWASP 2020 года:
Инъекционная атака
При инъекционной атаке злоумышленник внедряет недопустимые данные в веб-приложение с намерением заставить его сделать нечто, для чего приложение не было разработано/запрограммировано.
Возможно, наиболее распространённой разновидностью этой уязвимости системы безопасности является внедрение кода через SQL-запрос, использующий ненадёжные данные. Один из примеров от OWASP вы можете увидеть ниже:
String query = “SELECT * FROM accounts WHERE custID = ‘” + request.getParameter(“id”) + “‘”;
Главной причиной уязвимости, связанной с внедрением кода, является отсутствие проверки и очистки данных, используемых веб-приложением. Это означает, что подобная уязвимость может присутствовать практически в любом типе технологий.
Всё, что принимает параметры в качестве входных данных, потенциально может быть уязвимо для атаки путём внедрения кода.
Вот ещё один пример SQL-внедрения, затронувшего более полумиллиона сайтов, на которых был установлен плагин YITH WooCommerce Wishlist для WordPress:
Показанное выше SQL-внедрение может привести к серьёзной утечке конфиденциальных данных.
Как предотвратить внедрение кода?
Возможность предотвращения внедрения кода зависит от технологии, которую вы используете на своём сайте. Например, если вы используете WordPress, вы можете свести к минимуму возможные проблемы, ограничив количество установленных плагинов.
Если у вас есть специализированное веб-приложение и специальная команда разработчиков, вам остаётся лишь убедиться, что сформулированы требования к безопасности, которым ваши разработчики будут следовать при написании программного обеспечения. Это позволит им думать о безопасности на протяжении всего жизненного цикла проекта.
Вот технические рекомендации OWASP по предотвращению угрозы SQL-внедрения:
Из этих рекомендаций можно сделать два вывода:
Инъекционные атаки представляют собой серьёзный риск для владельцев сайтов, так как используют лазейки в системе безопасности для кражи конфиденциальной информации.
Нарушенная аутентификация
Некорректная аутентификация может позволить злоумышленнику использовать ручные и/или автоматические методы, чтобы попытаться получить контроль над любой учётной записью в системе или, что ещё хуже, полный контроль над системой.
Сайты с нарушенной аутентификацией очень распространены в сети. Нарушение аутентификации обычно связано с логическими проблемами, возникающими в механизме аутентификации приложения, такими как плохое управление сеансом, при котором происходит перечисление имён пользователей. В этом случае злоумышленник использует методы перебора, чтобы угадать данные пользователей системы.
Чтобы свести к минимуму риски, связанные с неработающей аутентификацией, не оставляйте общедоступной страницу входа администраторов:
Второй наиболее распространённой формой этой уязвимости является разрешение пользователям использовать подбор комбинации имени пользователя и пароля для этих страниц.
Типы некорректной аутентификации
Согласно OWASP Top-10, подобная уязвимость может проявляться во многих формах. Веб-приложение содержит неисправную аутентификацию, если оно:
Написание небезопасного программного обеспечения, содержащего подобные уязвимости, можно объяснить многими факторами, например отсутствием опыта у разработчиков, отсутствием требований к безопасности или спешка с выпуском программного обеспечения.
Как свести к минимуму уязвимости с нарушенной аутентификацией?
Чтобы избежать проблем, связанных с некорректной аутентификацией, убедитесь, что разработчики применяют передовые методы обеспечения безопасности сайтов. Поддержите их, предоставив доступ к внешним аудитам безопасности и достаточно времени для правильного тестирования кода перед развёртыванием приложения в рабочей среде.
Технические рекомендации OWASP заключаются в следующем:
Незащищённость критичных данных
Незащищённость критичных данных является одной из наиболее распространённых уязвимостей. Речь идёт в первую очередь о конфиденциальных данных, которые требуют особого внимания и защиты.
Примеры конфиденциальных данных
Некоторые конфиденциальные данные, требующие защиты:
Для любой организации жизненно важно понимать значимость защиты информации и конфиденциальности пользователей. Все компании должны соблюдать местные законы о конфиденциальности.
Ответственное отношение к сбору и обработке конфиденциальных данных стало более заметным после появления Общего регламента по защите данных (GDPR). Этот новый закон о конфиденциальности данных, вступивший в силу в 2018 году, определяет, как компании должны собирать, изменять, обрабатывать, хранить и удалять персональные данные.
Существует два типа данных:
Оба типа данных должны быть надёжно защищены.
Защита передаваемых данных
Один из способов защитить передаваемые данные на сайте — это наличие SSL сертификата.
SSL — это аббревиатура от Secure Sockets Layer. Это стандартная технология безопасности для установления зашифрованного соединения между сервером и браузером. Сертификаты SSL помогают защитить целостность данных, передаваемых между хостом (сервером или брандмауэром) и клиентом (браузером).
Каковы риски раскрытия конфиденциальных данных
Вот несколько примеров того, что может случиться при раскрытии конфиденциальных данных:
Почему раскрытие конфиденциальных данных так распространено?
За последние несколько лет раскрытие конфиденциальных данных стало одной из самых распространённых проблем во всём мире. Вот некоторые примеры утечек, которые привели к раскрытию конфиденциальных данных:
Отсутствие шифрования конфиденциальных данных — основная причина того, что эти атаки всё ещё происходят так часто. Даже зашифрованные данные могут быть взломаны из-за слабых:
Этой уязвимостью обычно очень сложно воспользоваться, однако последствия успешной атаки ужасны.
Как предотвратить раскрытие данных
Предотвратить раскрытие данных, согласно OWASP, можно, придерживаясь следующих правил:
Внешние объекты XML (XXE)
Как написано в Википедии, атака внешнего объекта XML — это тип атаки на приложение посредством анализа ввода XML. Эта атака происходит, когда ввод XML, содержащий ссылку на внешний объект, обрабатывается плохо настроенным синтаксическим анализатором XML.
Большинство синтаксических анализаторов XML по умолчанию уязвимы для XXE-атак. Ответственность за то, чтобы приложение не содержало этой уязвимости, лежит в основном на разработчике.
Каковы векторы атак на внешние объекты XML?
Согласно OWASP Top 10, основные направления атаки внешних объектов XML (XXE) включают использование:
Как предотвратить атаки внешних объектов XML
Для этого OWASP рекомендует:
Если эти способы контроля по каким-то причинам нереализуемы, рассмотрите возможность использования:
Нарушение контроля доступа
В области безопасности сайтов контроль доступа — это ограничение доступа посетителей к отдельным разделам или страницам.
Например, если у вас есть интернет-магазин, вам, вероятно, понадобится доступ к панели администратора, чтобы добавлять новые продукты или настраивать скидочные акции накануне праздников. Однако доступ к панели администратора вряд ли нужен кому-нибудь, кроме вас. Если остальные посетители вашего сайта будут иметь доступ к странице входа администратора, ваш интернет-магазин будет открыт для атак.
В наши дни это проблема почти всех основных систем управления содержимым (CMS). По умолчанию доступ к странице входа администратора предоставлен всем. В большинстве случаев не используется даже метод двухфакторной аутентификации (2FA).
Вышеизложенное должно заставить вас хорошо задуматься о безопасности разрабатываемого вами программного обеспечения.
Примеры нарушенного контроля доступа
Вот несколько примеров того, что мы включаем в понятие «доступ»:
Злоумышленники могут использовать недостатки авторизации в следующих целях:
Каковы риски нарушения контроля доступа?
Вот несколько примеров того, что, согласно OWASP, может случиться при нарушении контроля доступа:
pstmt.setString(1,request.getParameter(“acct”)); ResultSetresults =pstmt.executeQuery( );
Злоумышленник просто изменяет параметр «acct» в браузере, чтобы отправить любой номер учётной записи, который он хочет. В случае отсутствия надлежащей проверки злоумышленник может получить доступ к учётной записи любого пользователя:
Большинство разрабов знакомы с приведёнными выше сценариями, но помните, что уязвимости неработающего контроля доступа могут проявляться во многих формах и почти во всех существующих веб-технологиях.
Снижение рисков нарушения контроля доступа
Чтобы снизить риски, связанные с нарушением контроля доступа, вы можете сделать следующее:
Предотвращение нарушения контроля доступа
Чтобы избежать нарушения контроля доступа, необходимо при разработке и настройке программного обеспечения руководствоваться принципами безопасности. Вот почему важно контактировать с разработчиком и убеждаться в соблюдении им требований безопасности.
Технические рекомендации OWASP по предотвращению нарушения контроля доступа:
Небезопасная конфигурация
По своей сути перебор — это попытка ввода множества возможных комбинаций, но в принципе есть много вариантов этой атаки, что увеличивает её успешность. Самыми распространёнными ошибками, делающими возможной атаку на веб-приложение, являются:
Одна из наиболее распространённых ошибок веб-мастеров — сохранение настроек CMS по умолчанию.
Современные приложения CMS, будучи простыми в использовании, могут быть небезопасны для конечных пользователей. Большинство хакерских атак, безусловно, полностью автоматизированы, и злоумышленники полагаются на то, что у пользователей выставлены настройки по умолчанию. Это означает, что большое количество атак можно предотвратить, изменив при установке CMS настройки, выставленные по умолчанию.
Права доступа к файлам — ещё один пример настройки по умолчанию, которую можно и нужно усилить.
Где встречаются небезопасные конфигурации?
Неверные, с точки зрения безопасности, конфигурации могут быть на любом уровне стека приложения, включая:
Один из самых последних примеров неправильной конфигурации приложений — это серверы memcached, используемые для DDoS-атак на огромные сервисы в технологической индустрии.
Примеры сценариев атак, ставших возможными из-за небезопасной конфигурации
Как получить безопасные настройки
Чтобы предотвратить атаки, связанные с неправильными настройками безопасности, требуется:
Межсайтовый скриптинг (XSS)
Межсайтовый скриптинг (XSS) — широко распространённая уязвимость, которая затрагивает многие веб-приложения. XSS-атаки состоят из внедрения вредоносных клиентских скриптов на сайт с последующим использованием сайта в качестве распространителя.
Риски, связанные с XSS, заключаются в том, что он позволяет злоумышленнику внедрять контент на сайт и изменять способ его отображения, заставляя тем самым браузер жертвы выполнять при загрузке страницы код, предоставленный злоумышленником.
Уязвимость XSS присутствует примерно в двух третях всех приложений.
Как правило, уязвимости XSS требуют определённого типа взаимодействия со стороны пользователя, которое должно быть инициировано либо с помощью социальной инженерии, либо через посещение определённой страницы. Если уязвимость XSS не исправлена, она может быть очень опасной для любого сайта.
Примеры уязвимостей XSS
Представьте, что вы, находясь на своей панели администратора WordPress, добавляете новый пост. Если вы используете плагин с сохранённой уязвимостью XSS, хакер сможет заставить ваш браузер создать нового пользователя-администратора, пока вы находитесь в панели wp-admin. Кроме того, он может редактировать ваше сообщение и выполнять другие подобные действия.
Уязвимость XSS даёт злоумышленнику почти полный контроль над самым важным в настоящее время программным обеспечением компьютеров — браузерами.
Типы XSS
Согласно OWASP Top 10, существует три типа межсайтового скриптинга:
Снижение рисков XSS
Типичные XSS-атаки включают в себя кражу сеанса, захват учётной записи, обход MFA, замену DOM-узла, атаки на браузер пользователя, включая загрузку вредоносного программного обеспечения, кейлоггинг и другие атаки на стороне клиента.
Как предотвратить проблемы, вызванные XSS-уязвимостями
Превентивные меры по снижению вероятности XSS-атак должны включать отделение ненадёжных данных от активного содержимого браузера. OWASP даёт несколько практических советов о том, как этого добиться:
Небезопасная десериализация
В OWASP Top-10 отмечается, что эта уязвимость была добавлена в список на основании результатов отраслевого опроса, а не на основании исследования данных, поддающихся количественной оценке.
Каждому веб-разработчику следует смириться с тем фактом, что злоумышленники будут пытаться «играть» со всем, что взаимодействует с его приложением, — от URL-адресов до сериализованных объектов.
Чтобы упростить понимание некоторых ключевых понятий, познакомим вас с принятой терминологией:
Примеры сценариев десериализационной атаки
Злоумышленник изменяет сериализованный объект, чтобы получить права администратора:
Одним из векторов атаки, как вы видите, является суперфайл cookie, содержащий сериализованную информацию о вошедшем в систему пользователе. В этом файле cookie указана роль пользователя.
Если злоумышленник успешно десериализует данный объект, он затем изменит пользовательские права, предоставив себе роль администратора, и снова сериализует объект. Этот набор действий может поставить под угрозу всё веб-приложение.
Как предотвратить небезопасную десериализацию
Лучший способ защитить ваше веб-приложение от риска такого типа — не принимать сериализованные объекты из ненадёжных источников.
Если вы не можете этого сделать, OWASP Security предоставляет дополнительные технические рекомендации, которые вы можете попытаться реализовать:
Использование компонентов с известными уязвимостями
В наши дни даже простые сайты, такие как личные блоги, имеют множество зависимостей.
Мы все понимаем, что неспособность обновить каждую часть программного обеспечения на серверной и клиентской стороне сайта, без сомнения, рано или поздно создаст серьёзные риски для безопасности.
Например, в 2019 году 56% всех приложений CMS на момент их заражения были устаревшими.
Почему мы не обновляем наше программное обеспечение вовремя? Почему сегодня это всё ещё такая огромная проблема?
Есть несколько вариантов ответа на этот вопрос, например:
Это может звучать слишком драматично, но каждый раз, когда вы игнорируете предупреждение об обновлении, вы позволяете уже известной уязвимости выжить в вашей системе. Поверьте, киберпреступники быстро исследуют программное обеспечение и списки изменений.
Какой бы ни была причина использования устаревшего программного обеспечения в вашем веб-приложении, вы не можете оставить его незащищённым. И Sucuri, и OWASP рекомендуют виртуальные патчи в случаях, когда внесение исправлений невозможно.
Виртуальные патчи позволяют защитить устаревшие (или имеющие известные уязвимости) сайты от атак, предотвращая использование этих уязвимостей на лету. Обычно это делается с помощью брандмауэра и системы обнаружения вторжений.
Уязвимые приложения
В соответствии с рекомендациями OWASP приложения можно считать потенциально уязвимыми, если:
Как избежать использования компонентов с известными уязвимостями
Вот некоторые из способов избежать использования уязвимых компонентов:
Неэффективный мониторинг
Важность обеспечения безопасности сайта нельзя недооценивать. Хотя 100-процентная безопасность не является достижимой целью, есть способы держать ваш сайт под постоянным контролем, чтобы вы могли немедленно принять меры, когда что-то случится.
Отсутствие эффективного мониторинга может привести к увеличению ущерба от взлома сайта.
Примеры атак, ставших возможными из-за неэффективного мониторинга
Вот несколько примеров сценариев атак, причиной которых можно считать недостаточный мониторинг:
Как обеспечить эффективный мониторинг сайта
Ведение журналов аудита позволяет быть в курсе любых подозрительных изменений на вашем сайте. Журнал аудита — это документ, в котором регистрируются все события на сайте. Он позволяет обнаружить любые аномалии, чтобы вы могли вовремя обратиться к специалисту, который подтвердит или опровергнет взлом учётной записи.