Текст книги "Безопасность веб-приложений. Исчерпывающий гид для начинающих разработчиков"

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

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

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

Существует также множество ситуаций, когда можно с полной уверенностью сказать об отслеживании трафика, например при использовании интернета в отеле и на работе или при подключении к любой сети, где производится Deep Packet Inspection (глубокая проверка пакетов).

СОВЕТ. Deep Packet Inspection означает обработку данных, которая проверяет передаваемые по сети пакеты (данные), что приводит к таким действиям, как блокирование, перенаправление и протоколирование[23]23
  Технология Deep Packet Inspection: en.wikipedia.org/wiki/Deep_packet_inspection.


[Закрыть].

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

Теперь, когда мы убедились, что всегда нужно использовать HTTPS, определим Правило:

Необходимо разрешать доступ к сайту только через HTTPS. Если кто-то пытается использовать HTTP-соединение, следует перенаправить соединение на HTTPS. Это можно сделать с помощью заголовков безопасности в коде или серверных настроек, о чем было рассказано ранее в разделе «Заголовки безопасности: ремни безопасности для веб-приложений».

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

О других передовых практиках в этой области можно узнать в главе 3 «Проектирование защиты».

СОВЕТЫ ПО TLS

Рекомендации по применению TLS находятся на bettercrypto.org/#webservers и https://ssl-config.mozilla.org/.

Получить помощь в настройке совместимости можно на wiki.mozilla.org/Security/Server_Side_TLS.

Проверить конфигурацию можно на testssl.sh.

Разработчики пишут комментарии (обычный невыполняемый текст по всему коду), чтобы помочь себе и другим понять, что происходит в программе. Однако иногда такие комментарии содержат то, чего там не должно быть: пароли баз данных или другие секреты, сведения о компании или пользователях, которыми не следует делиться, или иную конфиденциальную информацию. Комментарии, помещенные во внешний код (JavaScript, HTML, CSS), не всегда удаляются во время упаковки, и реверс-инженер легко может их найти. Поэтому никогда нельзя разглашать конфиденциальные сведения в комментариях. Никогда.

СОВЕТ. Существует множество инструментов, доступных для CI/CD-конвейера или для сканирования репозитория, которые ищут секретную информацию в коде. Всегда используйте один из них!

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

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

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

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

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

Википедия[24]24
  Технический долг: en.wikipedia.org/wiki/Technical_debt.


[Закрыть]

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

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

Когда Боб работал в этом отделе, у них произошел очень серьезный инцидент, связанный с безопасностью. Он подслушал, как разработчики рассказывали команде безопасности, что цикл выпуска новой функции равняется 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). В отличие от других бесплатных онлайн-инструментов, он не передает информацию канадскому правительству.

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

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

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

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

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

СОВЕТ. Дополнительную информацию о возможных оповещениях и регистрировании можно посмотреть на сайте cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html.

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

Когда в веб-приложении используется веб-прокси, то он размещает себя после выполнения JavaScript-приложения, но до того, как запрос будет отправлен по сети на веб-сервер. Тот, кто использует веб-прокси, может легко изменить HTTP-запрос до того, как он покинет компьютер, и таким образом обойти любую проверку ввода или санитизацию, записанную в JavaScript. Из рис. 2.4 становится ясно, почему проверка безопасности или санитизация должны выполняться на стороне сервера: слишком легко обойти защиту безопасности в JavaScript.

Рис. 2.4. Как прокси-сервер перехватывает веб-трафик

Второе, что необходимо обеспечить при формировании проверки, – это «список разрешенного» или «список одобренного» (белый список) вместо «списка блокировки» (черного списка). Злоумышленники и тестировщики на проникновения показали, что они способны регулярно обходить списки блокировки с относительной легкостью, творчески используя незаблокированные опции ввода. Количество различных способов, которыми кто-то может ввести одинарную кавычку (символ, наиболее часто используемый в атаках внедрения SQL-кода) в поле ввода, просто поражает воображение. Вместо того чтобы пытаться блокировать длинный список различных типов атак, можно составить список разрешенных элементов. «Белый список» пишется с помощью регулярных выражений (regex), и все, что им не соответствует, будет запрещено. Например, если вы хотите разрешить ввод только a – z и A – Z для имени пользователя, можно употребить следующее выражение: ^[a-zA-Z]{1,10}$.

ВНИМАНИЕ. Regex иногда становится объектом атак типа «отказ в обслуживании» (DoS), поскольку его выполнение требует больших ресурсов. Поэтому приложение должно предупреждать о многократном вызове данной функции.

Если приложение имеет различные типы доступа для различных типов пользователей, то есть когда речь идет об управлении доступом на основе ролей (Role Based Access Control, RBAC), необходимо определиться с ними на этапе разработки требований. Не следует менять их по мере разработки системы, так как это усложняет работу с ней. RBAC является частью авторизации (AuthZ).

Нужно также определить, какие методы либо системы аутентификации (AuthN) и идентификации следует использовать: как система будет проверять личность пользователей? Как будет устанавливаться личность? Нужно ли отслеживать ее в нескольких системах или только на сайте? Принимать решения по всем этим вопросам лучше всего на этапе разработки требований, но также допустимо и на этапе проектирования.

СОВЕТ. Внедрите автоматизированный набор тестов, чтобы проверять соответствие реализации AuthZ. Автоматизация тестов позволит чаще проводить проверки AuthZ, чтобы убедиться в отсутствии случайных изменений.

При работе с базой данных приложение дает ей указание выполнить действия от его имени. Это может быть запрос на чтение, запись, обновление или удаление, но суть в том, что приложение обращается непосредственно к базе данных. Ни один человек или приложение не должны иметь возможность напрямую обращаться к вашей базе данных, кроме вашего приложения, вашей команды разработчиков программного обеспечения или вашего администратора базы данных. При атаке SQL или NoSQL злоумышленник пытается напрямую обратиться к базе данных, отправляя ей команды для выполнения нужных ему действий, а не запрограммированных инструкций. Такая атака называется инъекционной и является угрозой номер один по степени риска для любого веб-приложения (согласно Топ-10 OWASP, подробно описанному в главе 5).

При использовании параметризованных запросов (в SQL они называются хранимыми процедурами) мы отправляем параметры и имя запроса, который хотим выполнить, в базу данных, а не создаем код путем объединения пользовательского ввода для создания строки, которую затем отправляем в базу данных как команду. Разница в том, что в случае параметризованных запросов, если злоумышленник попытается добавить свой код через пользовательский ввод, приложение отправит его в одном из параметров и он не сработает. Так происходит потому, что параметры интерпретируются базой данных как данные, а не как код, что делает инъекционные атаки практически невозможными.

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