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

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

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

Несколько примеров реализации принципа наименьших привилегий:

Сервисная учетная запись, которая вызывает базу данных из приложения, должна иметь только права CRUD (CRUD – акроним, обозначающий четыре базовые функции, используемые при работе с базами данных: создание (англ. create), чтение (read), модификация (update), удаление (delete)), но никак не права владельца базы данных (DBO)).

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

Создание отдельной сервисной учетной записи для каждого используемого приложением API. Каждая из них должна иметь только те права, которые необходимы для выполняемых ею задач (например, только для команд «select» или «read», если предполагается, что она будет только возвращать данные, а не изменять их).

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

СОВЕТ. Реализацией принципа наименьших привилегий является использование во всех возможных случаях сервисной учетной записи с доступом только для чтения вместо учетной записи со всеми CRUD-правами.

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

Следует:

• шифровать все данные в состоянии покоя (пока они находятся в базе данных);

• шифровать все данные при передаче (на пути к пользователю, базе данных, API и т. д.);

• никому не доверять: проверять (при особых обстоятельствах санитизировать) все данные, даже из собственной базы данных;

• шифровать (и, если нужно, экранировать) все выходные значения;

• перед и регулярно после использования проверять все библиотеки и сторонние компоненты на наличие известных уязвимостей (так как постоянно появляются новые уязвимости и версии);

• использовать все подходящие заголовки безопасности;

• использовать необходимые безопасные параметры cookie;

• классифицировать и маркировать все хранимые, собираемые и создаваемые приложением данные;

• хешировать и солить все пароли пользователей. Соль должна состоять не менее чем из 28 символов;

• хранить все секреты приложения в тайнике;

• обеспечить повсеместное использование сервисных учетных записей (не личных аккаунтов) при работе внутри приложения;

• обеспечить использование менеджеров паролей всеми членами команды и запретить повторное использование паролей;

• избегать изменений паролей по расписанию или через определенный промежуток времени, кроме случаев взлома или подозрительной активности;

• разрешать доступ к интернет-сайтам общего пользования только через HTTPS. Перенаправлять с HTTP на HTTPS. Желательно применять это требование как к внутренним, так и к внешним приложениям;

• обеспечить использование последней версии TLS для шифрования (в настоящее время 1.3);

• никогда не использовать жесткое кодирование. Никогда;

• никогда не размещать конфиденциальную информацию (в том числе строки соединения и пароли) в комментариях, ее необходимо хранить в тайнике;

• использовать функции безопасности, встроенные в платформу. Например, криптографию и шифрование, функции управления сессиями или функции санитизации ввода. Не следует писать собственные функции, если платформа предоставляет свои;

• использовать только последнюю (или предыдущую) версию платформы и поддерживать ее в актуальном состоянии. Технический долг = долг безопасности;

• при загрузке файлов следовать рекомендациям OWASP: сканировать все загружаемые файлы с помощью бесплатного инструмента AssemblyLine, предоставляемого Канадским центром безопасности коммуникаций (Communications Security Establishment, CSE);

• обеспечить регистрацию всех ошибок (исключая конфиденциальную информацию) и включить оповещение о возникновении ошибок, связанных с обеспечением безопасности;

• обеспечить выполнение всех проверок ввода (и его санитизацию) на стороне сервера с использованием «белого списка» (не «черного списка»);

• обеспечить тестирование безопасности приложения перед релизом (подробнее об этом в следующих главах);

• перед релизом приложения выполнить моделирование угроз, речь о котором будет идти в главе 3 в разделе «Моделирование угроз»;

• выполнить проверку кода (в частности, функций безопасности) приложения перед релизом;

• убедиться в том, что приложение отлавливает все ошибки и производит аварийное завершение работы правильно (никогда не переходит в неизвестное состояние);

• обеспечить, чтобы все ошибки предоставляли пользователю только общую информацию, а не информацию из трассировки стека, ошибки запроса или другую технически специфическую информацию;

• определить специфику доступа на основе ролей в требованиях к проекту;

• определить конкретные методы аутентификации и системы идентификации в требованиях к проекту;

• использовать только параметризованные запросы и никогда – встраиваемые SQL/NоSQL;

• избегать передачи имеющих какое-либо значение переменных в параметрах URL;

• обеспечить соблюдение принципа наименьших привилегий в приложении, особенно в отношении доступа к базе данных и API;

• минимизировать поверхность атаки, когда это возможно;

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

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

• убедиться, что пароли пользователей приложения длинные, но не обязательно сложные. Чем длиннее пароль, тем лучше. Следует также поощрять использование кодовых фраз;

• с помощью специальных сервисов проверять, не были ли новые пароли пользователей ранее взломаны.

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

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

• Назовите два дополнительных возможных требования безопасности для веб-приложения (не упомянутых в списке).

• Назовите два дополнительных возможных требования безопасности для операционной системы автомобиля.

• Назовите два дополнительных возможных требования безопасности для «умного тостера».

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

• Какое требование безопасности является наиболее важным для вас или вашей организации? Почему?

• Если бы вам нужно было убрать одно из упомянутых в этой главе требований из проекта веб-приложения, какое бы это было требование? Почему?

ПРИМЕЧАНИЕ. Напоминаем, что раздел «Ответы» в конце книги не предоставляет полную информацию. Более подробные ответы на вопросы можно получить во время их обсуждения с коллегой или другом. Присоединяйтесь к моему сообществу, чтобы принять участие в онлайн-дискуссии, или посмотрите видео с обсуждениями на youtube.com/shehackspurple.

Глава 3
Безопасность при проектировании ПО

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

Рис. 3.1. Жизненный цикл разработки системы

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

Безопасность через проектирование (англ. Secure by design) в программной инженерии означает, что безопасность программного обеспечения реализуется с самого начала его проектирования. При таком подходе вредоносные действия, направленные против приложения, воспринимаются как нечто само собой разумеющееся и внимание уделяется минимизации воздействия обнаруженных уязвимостей безопасности или недопустимого пользовательского ввода.

Википедия[25]25
  «Безопасность через проектирование»: Wikipedia.org.


[Закрыть]

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

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

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

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

Ошибкой проектирования называется ошибка в конструкции приложения, позволяющая пользователю выполнять действия, на которые у него нет разрешения (то есть вредоносные или повреждающие приложение действия). Это ошибка, проблема проектирования. Использование концепции проектирования безопасного ПО, требования безопасности к проектам и моделирование угроз позволяют избежать или минимизировать возможности возникновения ошибок проектирования.

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

Рис. 3.2. Ошибки проектирования и дефекты безопасности

Чем позже в жизненном цикле разработки системы будет устранена ошибка, тем дороже она обойдется. В одной статье онлайн-журнала Slashdot говорится, что ошибка, обнаруженная на этапе требований, может стоить $1, на этапе проектирования – $10, на этапе кодирования – $100, на этапе тестирования – $1000, а после релиза – еще больше[26]26
  Из статьи онлайн-журнала Slashdot: ошибка, обнаруженная на этапе требований, стоит $1, на этапе проектирования – $10, на этапе кодирования – $100, на этапе тестирования – $1000: developers.slashdot.org/story/03/10/21/0141215/software-defects-do-late-bugs-really-cost-more.


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

Рис. 3.3. Примерная стоимость исправления ошибок и дефектов безопасности в жизненном цикле разработки системы

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

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

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

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

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

Рис. 3.4. Сдвиг влево

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

В главе 2 «Требования безопасности» мы уже определили, что все создаваемые, собираемые, сохраняемые и обрабатываемые приложением данные должны классифицироваться и маркироваться. Замечательно, а что теперь?

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

ПРИМЕЧАНИЕ. «Несекретные» – это не конфиденциальные по своей природе данные. «Общедоступные» данные могут быть опубликованы для общественности (им присвоен такой уровень чувствительности, согласно которому их могут увидеть все).

ВНИМАНИЕ. Если данные в приложении содержат государственную тайну, необходимо следовать правилам, установленным правительством, а не данному руководству.

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

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

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

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

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

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

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

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

По возможности следует установить оповещения об обнаружении утечки похожих на ваши данных в интернет. Вы же не хотите узнать такую информацию, прочитав газету, а хотите получить ее раньше, чем СМИ. Можно настроить такие оповещения вручную или воспользоваться услугами, предлагаемыми поставщиками систем безопасности. Будет полезно настроить оповещения в различных социальных сетях, поисковых системах и платформах обмена данными по ключевым словам (что приведет к ложным срабатываниям, поэтому будьте готовы к определенному «шуму»). Некоторые правительственные организации помогают компаниям – резидентам своих стран отследить утечки. Узнайте у своего правительства, какие виды услуг или помощи они могут предложить. В Канаде эта группа называется Канадский центр кибербезопасности (CCCS, англ. Canadian Center for Cyber Security) (cyber.gc.ca[27]27
  Canadian Center for Cyber Security: cyber.gc.ca.


[Закрыть]), ранее известный как Канадский центр реагирования на киберинциденты (CCIRC).

В других странах действуют:

• Люксембург: www.circl.lu [28]28
  Люксембург: www.circl.lu.


[Закрыть];

• Япония: www.jpcert.or.jp/english/at/2020.html [29]29
  Япония: www.jpcert.or.jp/english/at/2020.html.


[Закрыть];

• Великобритания (Отчет об угрозах): www.ncsc.gov.uk [30]30
  Великобритания (Отчет об угрозах): www.ncsc.gov.uk.


[Закрыть];

• Соединенные Штаты Америки: www.us-cert.gov/ncas/alerts [31]31
  Соединенные Штаты Америки: www.us-cert.gov/ncas/alerts.


[Закрыть];

• Новая Зеландия (Оповещения): www.cert.govt.nz/it-specialists [32]32
  Новая Зеландия (Оповещения): www.cert.govt.nz/it-specialists.


[Закрыть].

Узнать о предложениях вашего правительства можно с помощью местного центра реагирования на киберинциденты (CIRT, англ. Cyber Incident Response Team).

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