Owasp web security testing guide

Защита Web-приложений

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

Защита сетевого уровня (хостинга) Web-приложений является проторенной дорожкой и представляет собой ряд несложных действий, которые необходимо выполнить. Однако сетевой экран не обеспечивает защиты самих Web-приложений. Ахиллесовой пятой в защите онлайновой информации является уровень приложений. Уязвимости приложений, возникшие вследствие ошибок в коде и использования слабых приемов программирования, постоянно эксплуатируются хакерами и послужили причиной ряда крупнейших утечек данных, произошедших в недавнем прошлом. В марте 2008 года была похищена информация о 134 миллионах кредитных карт процессинговой компании Heartland Payment Systems; причиной послужила уязвимость Web-приложения, которую хакеры использовали для внедрения SQL-кода и установки вредоносного ПО. В 2012 году компания Yahoo! несколько раз пострадала от утечек данных, причиной которых послужило использование уязвимостей в Web-приложениях; в результате внедрения SQL-кода и межсайтового скриптинга были украдены пароли более чем от 450 тысяч учетных записей пользователей.

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

Классификация шаблонов компьютерных атак CAPEC

Рисунок 3. Граф связей записи CAPEC-112 в разных представлениях.

Таблица 2. Пример описания шаблона атаки.

API Security Top 10 2019

Here is a sneak peek of the 2019 version:

• API1:2019 Broken Object Level Authorization

  APIs tend to expose endpoints that handle object identifiers, creating a wide
  attack surface Level Access Control issue. Object level authorization checks
  should be considered in every function that accesses a data source using an
  input from the user.

• API2:2019 Broken User Authentication

  Authentication mechanisms are often implemented incorrectly, allowing
  attackers to compromise authentication tokens or to exploit implementation
  flaws to assume other user’s identities temporarily or permanently.
  Compromising system’s ability to identify the client/user, compromises API
  security overall.

• API3:2019 Excessive Data Exposure

  Looking forward to generic implementations, developers tend to expose all
  object properties without considering their individual sensitivity, relying on
  clients to perform the data filtering before displaying it to the user.

• API4:2019 Lack of Resources & Rate Limiting

  Quite often, APIs do not impose any restrictions on the size or number of
  resources that can be requested by the client/user. Not only can this impact
  the API server performance, leading to Denial of Service (DoS), but also
  leaves the door open to authentication flaws such as brute force.

• API5:2019 Broken Function Level Authorization

  Complex access control policies with different hierarchies, groups, and roles,
  and an unclear separation between administrative and regular functions, tend
  to lead to authorization flaws. By exploiting these issues, attackers gain
  access to other users’ resources and/or administrative functions.

• API6:2019 Mass Assignment

  Binding client provided data (e.g., JSON) to data models, without proper
  properties filtering based on a whitelist, usually lead to Mass Assignment.
  Either guessing objects properties, exploring other API endpoints, reading the
  documentation, or providing additional object properties in request payloads,
  allows attackers to modify object properties they are not supposed to.

• API7:2019 Security Misconfiguration

  Security misconfiguration is commonly a result of unsecure default
  configurations, incomplete or ad-hoc configurations, open cloud storage,
  misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin
  resource sharing (CORS), and verbose error messages containing sensitive
  information.

• API8:2019 Injection

  Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when
  untrusted data is sent to an interpreter as part of a command or query. The
  attacker’s malicious data can trick the interpreter into executing unintended
  commands or accessing data without proper authorization.

• API9:2019 Improper Assets Management

  APIs tend to expose more endpoints than traditional web applications, making
  proper and updated documentation highly important. Proper hosts and deployed
  API versions inventory also play an important role to mitigate issues such as
  deprecated API versions and exposed debug endpoints.

• API10:2019 Insufficient Logging & Monitoring

  Insufficient logging and monitoring, coupled with missing or ineffective
  integration with incident response, allows attackers to further attack
  systems, maintain persistence, pivot to more systems to tamper with, extract,
  or destroy data. Most breach studies demonstrate the time to detect a breach
  is over 200 days, typically detected by external parties rather than internal
  processes or monitoring.

Security Misconfigurations

At its core, brute force is the act of trying many possible combinations, but there are many variants of this attack to increase its success rate. Here are the most common:

• Unpatched flaws
• Default configurations
• Unused pages
• Unprotected files and directories
• Unnecessary services

One of the most common webmaster flaws is keeping the CMS default configurations.

Today’s CMS applications (although easy to use) can be tricky from a security perspective for the end users. By far, the most common attacks are entirely automated. Many of these attacks rely on users to have only default settings.

This means that a large number of attacks can be mitigated by changing the default settings when installing a CMS.

There are settings you may want to adjust to control comments, users, and the visibility of user information. The file permissions are another example of a default setting that can be hardened.

Where can security misconfiguration happen?

Misconfiguration can happen at any level of an application stack, including:

• Network services
• Platform
• Web server
• Application server
• Database
• Frameworks
• Custom code
• Pre-installed virtual machines
• Containers
• Storage

One of the most recent examples of application misconfigurations is the memcached servers used to DDoS huge services in the tech industry.

Examples of Security Misconfiguration Attack Scenarios

According to OWASP, these are some examples of attack scenarios:

• Scenario #1: The application server comes with sample applications that are not removed from the production server.

  These sample applications have known security flaws that attackers use to compromise the server. If one of these applications is the admin console and default accounts weren’t changed, the attacker logs in with default passwords and takes over.

• Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. They find and download the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.
• Scenario #3: The application server’s configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws, such as component versions. They are known to be vulnerable.
• Scenario #4: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows stored sensitive data to be accessed within cloud storage.

Approaches to web application security

Perfect security for a web application may be impossible, but there are plenty of ways to minimize the risk of external threats. Here we have looked at each of the most popular vectors for attacking applications. To stay safe, we urge deploying protection to reduce your risk profile and ability of an attacker to exploit vulnerabilities. One important step is the Secure Development Lifecycle (SDL). This is a difficult and time-consuming process that requires substantial changes in development workflows. Full implementation of SDL requires substantial investments both of finances (purchasing additional software) and of staff (hiring skilled security specialists).

Here are our core recommendations for securing web applications:

Use a source code analyzer. This software catches code vulnerabilities and weak spots early on, in order to correct them closer to the beginning of the development process. Most code analyzers can protect your application from OWASP Top 10 vulnerabilities.

Check out the demonstration of PT Application Inspector analyzing source code and finding the vulnerabilities.

Here is the breakdown of these vulnerabilities.

Figure 2. Breakdown of vulnerabilities

• Deploy a web application firewall (WAF) to protect your site. This will keep the web application safe even if it contains vulnerabilities or new threats to it appear. A WAF can stop known attacks on the levels of application and business logic. What’s more, it detects exploitation of zero-day vulnerabilities, prevents attacks on users, and analyzes and correlates events when reconstructing attack chains. Ideally, a WAF should integrate with external security information and event management (SIEM) and anti-DDoS solutions. Integrating a WAF with automated source code analysis enables virtual patching, which closes off vulnerabilities even before they have been fixed in code.
• Regularly assess the security of your web applications and fix any vulnerabilities found. When possible, opt for white-box analysis (assessment with full access to application source code). Assessments should be performed at all stages of the site lifecycle, and not only at the last minute prior to going live.
• Do not use out-of-date web server, OS, CMS, or library versions. Regularly update your systems and install the most current patches.
• Record and investigate cyberincidents. Determining the source of a threat in a timely way allows minimizing the risks.

Заключение

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

Сегодня защита Web-приложений с использованием общепринятых стандартов и методов, таких как OWASP Top 10, а также использование инструментов поиска уязвимостей, таких как IBM Rational AppScan, являются необходимой практикой.

Похожие темы

• Оригинал статьи: Scan your app to find and fix OWASP Top 10 2013 vulnerabilities (EN).
• В библиотеке OpenSSL была обнаружена критическая уязвимость CVE-2014-0160 (EN), известная как Heartbleed.
• Получите дополнительную информацию и указания по работе с последним списком OWASP
  Top 10 (EN).
• Проект Open Web Application Security Project (OWASP) (EN) – это основанное в 2011 году Open Source-сообщество, занимающееся разработкой бесплатных руководств по защите приложений.
• Используйте для тестирования уязвимостей демонстрационное Web-приложение от IBM.
• Подделка межсайтовых запросов (CSRF) (EN) может заставить конечного пользователя выполнять нежелательные действия в Web-приложении, в котором он аутентифицирован.
• Присоединяйтесь к сообществу Security On developerWorks (EN) и знакомьтесь с руководствами, статьями, видеофайлами и демонстрационными материалами, которые можно найти в библиотеке сообщества.
• Познакомьтесь с блогом Security On developerWorks (EN), в котором вы найдете информацию о различных руководствах, статьях и демонстрационных видеоматериалах.
• Подпишитесь на еженедельный информационный бюллетень Security On developerWorks (EN), чтобы быть в курсе последних новостей.
• Следите за материалами блога @dwsecurity (EN) в Твиттере и получайте обновления раздела Security портала developerWorks в реальном времени.
• Узнайте больше о IBM
  Rational AppScan (EN) – передовом инструменте для поиска уязвимости в Web-приложениях.
• Используйте в вашем следующем open source проекте ознакомительные версии программного обеспечения IBM (EN), которые можно загрузить с сайта или заказать на DVD.