Элементы безопасности платформы

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

Опытные тестировщики на проникновение в веб-приложения и инженеры по безопасности приложений всегда могут рассказать парочку историй о разработчике программного обеспечения, который решил «создать собственную криптографию». Вместо того чтобы использовать функции криптографии платформы, он решил, что либо закодирует значение в base64 (возможно, несколько раз), либо напишет собственную функцию для перепутывания значений. К сожалению таких разработчиков, самые простые задачи в соревновании «Захват флага» (Capture the Flag, CTF) часто связаны с обнаружением подобных простых и неадекватных попыток защиты, то есть обычно такую «защиту» легко обнаружить и обойти.

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

Технический долг = Долг безопасности

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

Википедия

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

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

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

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

Загрузка файлов

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

Алиса помнит, как ей было стыдно, когда она случайно принесла на работу вирус. Дома она пользуется Mac, на работе – Windows. Однажды она принесла на работу USB-накопитель с любимой музыкой, которую скачала дома. После подключения флешки к рабочему компьютеру начался запуск EXE-файла, который Алиса не заметила… В мгновение ока команда безопасности была у ее стола.

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

Принимая загруженный пользователем файл, необходимо предполагать худшее: проверьте его тип и размер, переименуйте файл, не позволяйте пользователю задавать путь к месту его расположения и храните его в безопасном месте вдали от остальных частей приложения и веб-сервера. Приняв файл, просканируйте его хотя бы одним инструментом. Если подразделение позволяет, разрешите загрузку только определенных, менее опасных типов файлов. Например, можно принимать JPG, TXT и PNG, но блокировать PDF или EXE.

Серия памяток OWASP, проект с открытым исходным кодом под эгидой Открытого проекта по безопасности веб-приложений (англ. Open Web Application Security Project), содержит обширный список мер предосторожности, которые необходимо предпринять при разрешении загрузки файлов. Список будет очень полезен тем, кто пишет эту функциональность с нуля: cheatsheetseries.owasp.org/cheatsheets/Protect_FileUpload_Against_Malicious_File.html.

Загрузки вредоносных файлов являются настолько серьезной и важной темой, что канадское правительственное подразделение по кибербезопасности – Канадский центр безопасности коммуникаций (CSE) – создало и выложило в открытый доступ бесплатный инструмент для проверки загружаемых файлов под названием AssemblyLine (cyber.gc.ca/en/assemblyline). В отличие от других бесплатных онлайн-инструментов, он не передает информацию канадскому правительству.