Они не так бессерверны, как кажется, и не более безопасны, чем другие приложения.

Что такое бессерверное приложение?

Для запуска традиционного веб-приложения вам необходимо установить ОС, настроить веб-сервер, установить CMS и подготовить базу данных. Вы должны заботиться об инфраструктуре, емкости и обслуживании серверов, пока работает ваше приложение.

Что, если бы вы могли сосредоточиться только на разработке своего приложения и не думать об инфраструктуре? Это именно то, что вы можете сделать в бессерверной архитектуре. Вы пишете свой код и публикуете его на облачных серверах, таких как AWS Lambda, Cloudflare Workers или Google Cloud Functions. Ваш код будет работать на облачных серверах, а ваш поставщик облачных услуг управляет инфраструктурой и обслуживанием.

Облачные компании, предоставляющие бессерверные услуги, предлагают различные их формы. Возьмите FaaS в качестве примера. В этой модели разработки облачные провайдеры позволяют вам писать приложение в виде небольших отдельных функций. Вот почему эта услуга называется «Функция как услуга» (FaaS). Этот подход поддерживает популярные архитектуры, такие как JAMstack (JavaScript, API и разметка). JAMStack состоит из статических страниц (разметки), которые интегрируются с серверной частью посредством использования API-интерфейсов в бессерверных приложениях.

💡 PaaS — это еще одна бессерверная облачная служба, в которой вы контролируете все приложение. Это контрастирует с FaaS, который имеет архитектуру, управляемую событиями. В FaaS ваше приложение (функция) выполняется при определенных событиях, таких как входящие запросы.

Бессерверная безопасность

Модель разработки без сервера имеет множество преимуществ, таких как экономическая эффективность, эластичность и производительность. Но бессерверные приложения не более безопасны по сравнению с традиционными приложениями. Облачные провайдеры, такие как Amazon AWS, позаботятся об уязвимостях ОС и платформ, но у вас нет доступа к серверам, и вы не можете использовать классические решения для обеспечения безопасности, такие как IDS/IPS, требующие установки на конечных точках.

Кроме того, в бессерверной архитектуре все приложение состоит из большего количества небольших компонентов, что означает большее количество точек входа, что приводит к увеличению поверхности атаки.

Разработка и запуск бессерверного приложения зависит от стандартов облачного провайдера. Это означает, что один и тот же код нельзя использовать в другом облачном провайдере без изменений.

Конфиденциальность — еще одна проблема в бессерверных приложениях из-за использования общих ресурсов и доступа внешних сотрудников в общедоступной бессерверной облачной инфраструктуре.

Уязвимости в бессерверных приложениях

Уязвимости безопасности затрагивают различные уровни любого приложения, такие как ОС, веб-сервер, база данных и само приложение. В бессерверных архитектурах поставщик облачных услуг заботится обо всей безопасности инфраструктуры. Таким образом, вы не будете беспокоиться о неправильных настройках безопасности и проблемах типа Уязвимость устаревшего сервера. Но безопасность приложения по-прежнему является вашей обязанностью в модели разработки без сервера. И, к сожалению, многие уязвимости относятся к прикладному уровню. Такие уязвимости, как:

Это общие уязвимости, которые входят в топ-10 списка OWASP. Мы рассмотрели некоторые из них в таких статьях, как распространенные веб-уязвимости и защита вашего экспресс-приложения NodeJ. Далее мы рассмотрим уязвимости, которые менее известны, но более характерны для бессерверных приложений.

Отсутствует контроль доступа на функциональном уровне

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

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

Раскрытие конфиденциальных данных

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

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

Небезопасная прямая ссылка на объект (IDOR)

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

Здесь идентификатор сотрудника, переданный в Serverless API, является ссылкой на запись о сотруднике в базе данных. И эта ссылка напрямую контролируется пользователем. Если такие ссылки легко угадать, вы рискуете перечислить свои данные.

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

Внедрение языка шаблонов

Обычный способ отображения HTML-страниц с использованием шаблона заключается в вычислении выражения типа 2+2 и отображении результатов (4) в выходных данных. Внедрение языка шаблона или внедрение языка выражений происходит, когда пользователь может изменить выражение, используемое в шаблоне.

Компоненты с известными уязвимостями

Бессерверные приложения обычно создаются на языках JavaScript (или TypeScript) или Python. Разработчики на Python или JavaScript обычно используют множество сторонних пакетов для выполнения различных задач. Эти пакеты могут иметь уязвимости, и их использование может сделать ваше бессерверное приложение уязвимым.

Чтобы уменьшить уязвимости компонентов, убедитесь, что вы используете обновленную версию любой библиотеки, и запустите тесты безопасности, чтобы найти уязвимые пакеты.

💡 В NodeJs вы можете использовать npm audit для поиска уязвимостей в пакетах npm. Подробнее читайте в разделе Защита вашего проекта NodeJ JavaScript.

Заключение

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

Мы рассмотрели некоторые распространенные уязвимости в бессерверных приложениях, но вы должны знать, что эти уязвимости не являются полными и даже не ограничиваются бессерверными приложениями. Таким образом, тестирование безопасности ваших веб-приложений является важной задачей для их защиты. Для обеспечения безопасности бессерверных приложений требуется решение DevSecOps, в котором разработчики, операционная группа и специалисты по безопасности тесно сотрудничают.