Стратегии безопасного хранения и передачи данных.

Эта статья является частью серии. В предыдущей статье описаны стратегии предотвращения недостатков памяти. Вы можете получить к нему доступ здесь: https://medium.com/@paul_io/security-code-review-101-memory-adf0543926ee

О конфиденциальности

Пользователи доверяют разработчикам свои данные. Чтобы заслужить и сохранить их доверие, мы должны использовать меры безопасности, защищающие данные от несанкционированного доступа. Конфиденциальность является одним из трех неотъемлемых элементов Информационной безопасности, также известной как триада ЦРУ (Конфиденциальность, Целостность и Доступность).

К сожалению, послужной список не очень хороший. Количество пользовательских записей, раскрытых в США, исчислялось миллиардами в 2016 и 2017 годах. 2018 год, вероятно, будет таким же, как только будет подсчитан окончательный подсчет.

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

Однако как минимум одно из взломов 2017 года было вызвано программным недочетом. Взлом системы кредитных рейтингов компании Equifax стал причиной почти 10% ущерба: 146 миллионов записей. Атака использовала уязвимость OGNL Injection в библиотеке Apache Struts и последующую невозможность исправления уязвимых систем. О недостатках Injection вы можете прочитать в одной из предыдущих статей этой серии.

Обнаружение нарушений данных во время проверки кода

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

  • Хранение конфиденциальной информации в открытом виде — CWE 312
  • Использование одностороннего хеширования без соли — CWE 759
  • Передача конфиденциальной информации открытым текстом — CWE 319
  • Использование сломанного или рискованного криптографического алгоритма — CWE 327

Мы рассмотрим несколько примеров этих недостатков и способы их предотвращения с помощью передовых методов обеспечения безопасности программного обеспечения.

Уникальная идентификация данных без знания данных

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

Но что, если вам все же нужно работать с данными? Например, что, если вы хотите проверить пароль пользователя без сохранения фактического значения пароля?

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

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

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

"ABCDEFG" + "-32524..." -> sha256("ABCDEFG-32524...") -> 97AF3...
 original     salt

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

Давайте посмотрим на следующие фрагменты кода. Можете ли вы обнаружить недостаток безопасности?

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

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

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

Защита передачи данных

Хеширование может быть эффективным способом защиты данных, но что, если злоумышленник сможет перехватить данные до того, как они будут преобразованы? Что, если они смогут перехватить данные еще до того, как они попадут в приложение?

Вплоть до 2018 года основные новостные агентства, такие как CNN или FOX NEWS, были доступны по незашифрованным URL-адресам. Это адреса сайтов, которые начинаются с http:// .

Одним из факторов, который, возможно, побудил многие сайты изменить это поведение, было добавление сообщения Not Secure в адресную строку популярного браузера Google Chrome для всех http:// адресов.

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

Протоколы безопасности связи, обозначенные https:// URL-адресами, предотвращают атаки человек посередине, шифруя передачу и проверяя личность двух сторон, участвующих в обмене данными.

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

Давайте посмотрим на пример кода. Можете ли вы определить код, который небезопасно передает данные?

Если вы идентифицировали нижний пример как небезопасный, вы были правы. Обратите внимание, что URL-адрес имеет префикс http://, что означает, что данные передаются в виде открытого текста. Взглянув немного вправо, вы можете заметить две части конфиденциальной информации, передаваемой в URL-адресе.

Обратите внимание, что хранение конфиденциальной информации в URL-адресе является плохой практикой, даже если URL-адрес начинается с https:// . Это связано с тем, что URL-адрес может быть непреднамеренно добавлен в закладки, отправлен третьей стороне или сохранен в журналах веб-сервера.

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

Обратимое шифрование

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

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

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

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

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

Давайте взглянем на некоторые примеры кода, написанного на Node.js. Можете ли вы определить уязвимый фрагмент?

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

Подводя итог

Некоторые ключевые выводы из этой статьи:

  • По возможности используйте безопасное хеширование для преобразования данных таким образом, чтобы их нельзя было отменить.
  • Обеспечение безопасной связи между клиентами и серверами
  • Шифрование конфиденциальных данных в базах данных для предотвращения кражи физических данных и смягчения SQL-инъекций.
  • Храните ключи шифрования в KMS
  • Уязвимости, которые позволяют выполнять код на сервере, могут по-прежнему раскрывать данные, несмотря на шифрование, поэтому все методы безопасного кодирования являются методами защиты данных.

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

Полный обзор кода безопасности, серия 101