Отправная точка для построения безопасной архитектуры приложений для занятых разработчиков

Сегодня разработчикам программного обеспечения рекомендуется сосредоточиться на создании, и это здорово. Мы извлекаем выгоду из культуры производителей, отношения «всегда быть готовым», сотрудничества с открытым исходным кодом и множества приложений, которые помогают нам расставлять приоритеты и выполнять их с максимальной эффективностью. Мы находимся в среде постоянного творчества, где как команды, так и индивидуальные предприниматели могут быть максимально продуктивными.

Иногда такая головокружительная производительность проявляет свои недостатки.

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

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

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

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

Должна быть причина, по которой мы называем это «архитектурой» приложения, и мне нравится думать, что это потому, что архитектура программного обеспечения в некоторых основных отношениях схожа с архитектурой здания. (Или, по крайней мере, при моем абсолютном нулевом опыте создания зданий, каким я представляю себе довольно утилитарное здание.) Вот как я люблю резюмировать три основных момента построения безопасной архитектуры приложений:

  1. Раздельное хранилище
  2. Индивидуальная конфигурация
  3. Контролируемый доступ и круг пользователей

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

1. Раздельное хранилище

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

Когда дело доходит до наших файлов, нам легче всего понять это преимущество, если мы рассмотрим простую файловую структуру:

application/
├───html/
│ └───index.html
├───assets/
│ ├───images/
│ │ ├───rainbows.jpg
│ │ └───unicorns.jpg
│ └───style.css
└───super-secret-configurations/
└───master-keys.txt

В нашем упрощенном примере предположим, что все изображения нашего приложения хранятся в каталоге application/assets/images/. Когда один из наших пользователей создает профиль и загружает в него свое изображение, оно также сохраняется в этой папке. Имеет смысл, правда? Это изображение, и вот куда идут изображения. В чем проблема?

Если вы знакомы с навигацией по файловой структуре в терминале, возможно, вы уже видели этот синтаксис раньше: ../../. Две точки - удобный способ сказать: Перейти на один каталог вверх. Если мы выполним команду cd ../../ в каталоге images/ нашей простой файловой структуры выше, мы перейдем в assets/, а затем снова в корневой каталог application/. Это проблема из-за небольшой уязвимости, получившей название обход пути.

Хотя точечный синтаксис избавляет нас от набора текста, он также дает интересное преимущество, заключающееся в том, что на самом деле не нужно знать, что вызывается родительский каталог, чтобы перейти к нему. Рассмотрим сценарий полезной нагрузки атаки, доставленный в папку images/ нашего небезопасного приложения, который поднялся на один каталог с помощью cd ../, а затем повторно отправил все, что обнаружил, злоумышленнику. В конце концов, он достигнет корневого каталога приложения и получит доступ к папке super-secret-configurations/. Нехорошо.

Хотя, безусловно, должны быть приняты другие меры для предотвращения обхода пути и связанных с ним уязвимостей загрузки пользователей, самым простым предотвращением на сегодняшний день является разделение хранилища. Файлы и ресурсы основного приложения не следует объединять с другими данными, особенно с пользовательским вводом. Лучше всего хранить файлы, загруженные пользователями, а также журналы активности (которые могут содержать полезные данные и могут быть уязвимы для атак путем инъекций) отдельно от основного приложения.

Разделение может быть достигнуто несколькими способами, например, с помощью другого сервера, другого экземпляра, отдельного диапазона IP-адресов или отдельного домена.

2. Индивидуальная конфигурация

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

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

В частности, изучите компоненты архитектуры на наличие необслуживаемых областей, таких как:

  • Учетные записи по умолчанию, особенно с паролями по умолчанию, оставлены в эксплуатации;
  • Примеры веб-страниц, обучающих приложений или образцы данных, оставленные в приложении;
  • Ненужные порты, оставленные в обслуживании, или порты, оставленные открытыми для Интернета;
  • Неограниченно разрешенные методы HTTP;
  • Конфиденциальная информация хранится в автоматических журналах;
  • Разрешения, настроенные по умолчанию в управляемых службах; а также,
  • Списки каталогов или конфиденциальные типы файлов остаются доступными по умолчанию.

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

3. Контролируемый доступ и сфера действия пользователя

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

Сломанный контроль доступа включен в топ-10 OWASP, в котором более подробно описаны его различные формы. В качестве простого примера рассмотрим приложение с двумя уровнями доступа: администраторы и пользователи. Мы можем создать функцию для нашего приложения, такую ​​как возможность модерировать или блокировать пользователей, с намерением, чтобы только администраторы могли ее использовать. Если нам известно о возможности неправильной конфигурации или эксплойтов контроля доступа, мы можем принять решение о создании функции модерации в полностью отдельной области от доступного для пользователя пространства, например, в другом домене или как часть модели, которую пользователи не делись. Это значительно снижает риск того, что неправильная конфигурация управления доступом или уязвимость, связанная с повышением привилегий, может позволить пользователю впоследствии некорректно получить доступ к функции модерации.

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

Основы безопасности для максимальной выгоды

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