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

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

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

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

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

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

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

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

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/. Это проблема из-за маленькой уязвимости, получившей название Path traversal .

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

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

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

2. Подгонянная Конфигурация

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

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

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

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

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

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

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

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

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

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

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

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