Анализ веб-безопасности и безопасности API на примерах уязвимостей

В постоянно развивающемся мире технологий новые модные словечки и термины часто появляются как маркетинговые уловки, призванные привлечь внимание потенциальных потребителей. Как профессионалы в области кибербезопасности, для нас крайне важно выйти за рамки шумихи и понять основные понятия этих терминов. В этом длинном чтении HackerNoon мы углубимся в различия и сходства между веб-безопасностью и безопасностью API, сравнив десятку лучших OWASP 2021 и десятку лучших API OWASP 2019, чтобы пролить свет на причину разделения. В заключение мы подчеркнем, что устаревшие веб-приложения по сути являются устаревшими API, и подчеркнем, что их защита — это, по сути, один и тот же процесс.

Обоснование разделения или IDOR/BOLA Tweens

Несмотря на частичное совпадение, разделение между веб-безопасностью и безопасностью API все же имеет под собой основания. Основное различие заключается в том, как проектируются, разрабатываются и используются веб-приложения и API.

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

Уникальная природа API-интерфейсов означает, что они сталкиваются с особыми проблемами безопасности, которые могут быть не столь актуальными для традиционных веб-приложений. Например, нарушенная авторизация на уровне объекта (BOLA) является более серьезной проблемой в API, чем в веб-приложениях, где небезопасные прямые ссылки на объекты (IDOR) являются более распространенной уязвимостью. Различие между BOLA и IDOR заключается в том, что BOLA специально нацелена на API, а IDOR фокусируется на веб-приложениях. Однако с технической точки зрения эти две проблемы совершенно одинаковы.

Классические веб-инъекции и API-инъекции

Чтобы лучше понять разницу между Web Security и API Security, давайте подробнее рассмотрим две распространенные уязвимости, связанные с внедрением: внедрение SQL для веб-приложений и внедрение объектов для API. Эти примеры продемонстрируют уникальные проблемы, с которыми сталкивается каждый из них, и предоставят ценную информацию об их соответствующих требованиях к безопасности.

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

codedef get_user_data(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    result = execute_query(query)
    return result

В этом примере введенный пользователем user_id напрямую встроен в SQL-запрос, что делает его уязвимым для атак с внедрением SQL-кода. Злоумышленник может предоставить вредоносный user_id, например 1 ИЛИ 1=1, в результате чего запрос вернет все записи пользователей.

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

codeconst express = require('express');
const app = express();
const bodyParser = require('body-parser');
app.use(bodyParser.json());

app.post('/api/users', (req, res) => {
    const userData = req.body;
    const newUser = new User(userData);
    newUser.save()
        .then(result => res.status(201).send(result))
        .catch(err => res.status(400).send(err));
});

В этом примере конечная точка API принимает полезные данные JSON, представляющие новый пользовательский объект. Однако он не проверяет и не очищает входные данные должным образом, что позволяет злоумышленнику потенциально манипулировать структурой объекта, внедрять вредоносные данные или даже выполнять произвольный код на сервере. Например, злоумышленник может отправить полезную нагрузку, содержащую вредоносный оператор $where в приложении MongoDB, что приведет к выполнению произвольного кода JavaScript на сервере.

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

Веб-XSS и XSS для API

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

Вот простой пример небезопасного кода в веб-приложении:

<!-- unsafe_form.html -->
<form action="/submit_comment" method="post">
    <input type="text" name="comment" />
    <input type="submit" value="Submit" />
</form>

<!-- unsafe_comment_display.html -->
<div>
    <%= user_comment %>
</div>

В этом случае пользовательский ввод, например комментарий, не очищается перед помещением в HTML-код страницы. Злоумышленник может отправить комментарий с вредоносным кодом JavaScript, например <script>alert('XSS')</script>, который затем будет запущен в браузере любого, кто просматривает комментарий.

Для API-интерфейсов атаки XSS обычно не имеют большого значения, поскольку API-интерфейсы обычно не предоставляют пользователям права на HTML-контент. Но проблемы XSS могут иметь значение для API, использующих аутентификацию на основе файлов cookie. Злоумышленник может использовать уязвимость XSS в веб-приложении, чтобы украсть файл cookie аутентификации пользователя и получить неправильный доступ к API.

Посмотрите на этот пример:

// API endpoint using cookie-based authentication
app.post('/api/comments', (req, res) => {
    const comment = req.body.comment;
    const user_id = req.cookies.user_id;

    // Check user_id from the cookie for authentication and authorization
    // ...

    // Save the comment without proper input sanitization
    saveComment(user_id, comment)
        .then(() => res.status(201).send())
        .catch(err => res.status(400).send(err));
});

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

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

Одной из проблем защиты API от XSS-атак является то, что брандмауэры веб-приложений (WAF) часто предназначены для блокировки только веб-XSS. Эти брандмауэры могут быть не так эффективны при блокировании API XSS, что может привести к бреши в безопасности. Чтобы решить эту проблему, разработчикам следует рассмотреть возможность использования инструментов и методов безопасности, специфичных для API, в дополнение к традиционным мерам веб-безопасности.

Заключение

Как мы видели, и веб-приложения, и API-интерфейсы сталкиваются с уникальными проблемами безопасности, но они также имеют некоторые общие уязвимости. Полагаться исключительно на брандмауэры веб-приложений (WAF) для обеспечения безопасности может быть недостаточно, поскольку они часто предназначены для защиты веб-приложений от атак XSS, но могут не сработать, когда речь идет о безопасности API.

Чтобы лучше защитить свои веб-приложения и API, важно рассмотреть возможность использования решения для обеспечения безопасности API в дополнение к традиционным мерам веб-безопасности. Не все современные инструменты безопасности API могут легко заменить WAF, но некоторые из них предлагают комплексный подход, объединяя защиту веб-приложений и API (WAAP) с их передовым решением безопасности API. Это позволяет обеспечить надежную защиту как веб-приложений, так и API.

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