php sodium что это
libsodium – простая в использовании библиотека программного обеспечения для шифрования
Sodium – это новая, простая в использовании библиотека программного обеспечения для шифрования, дешифрования, подписей, хэширования паролей и многое другое.
Это переносимый, устанавливаемый, упакованный форк NaCl, с совместимым API и расширенный API для улучшения удобства использования еще больше.
Его цель – предоставить все основные операции, необходимые для создания криптографических инструментов более высокого уровня.
Sodium поддерживает множество компиляторов и операционных систем, включая Windows (с MingW или Visual Studio, x86 и x64), iOS, Android, а также Javascript и Webassembly.
Установка библиотеки программного обеспечения libsodium для шифрования
Sodium – это общая библиотека с независимым от машины набором заголовков, поэтому ее можно легко использовать сторонними проектами.
Библиотека построена с использованием autotools, что упрощает ее упаковку.
Установка тривиальна, и как компиляция, так и тестирование могут использовать преимущества нескольких процессорных ядер.
Загрузите tarball of libsodium, желательно последнюю стабильную версию, затем следуйте инструкции:
Поскольку разные файлы скомпилированы для разных классов ЦП и для предотвращения нежелательных оптимизаций рекомендуется избегать оптимизации времени соединения (LTO).
В Linux, если процесс зависает на шаге проверки, ваша система PRG может быть неправильно выбрана.
Пожалуйста, ознакомьтесь с примечаниями в разделе «usagе», чтобы узнать, как это можно сделать.
Использование библиотеки шифрования libsodium
ключение отдельных заголовков не требуется и не рекомендуется.
Затем функцию sodium_init () следует вызывать перед любой другой функцией.
Безопасно называть sodium_инит () несколько раз или из разных потоков; он немедленно вернет 1, ничего не сделав, если библиотека уже была инициализирована.
Руководство по написанию защищённых PHP-приложений в 2018-м
Приближается 2018 год, и технари — в частности веб-разработчики — должны отбросить многие старые методики и верования в сфере разработки защищённых PHP-приложений. Особенно это относится ко всем, кто не верит, что такие приложения вообще возможны.
Это руководство — дополнение к электронной книге PHP: The Right Way с сильным уклоном в безопасность, а не общие вопросы программирования на PHP (вроде стиля кода).
Содержание
Версии PHP
Вкратце: ничего не поделаешь, но в 2018-м вы будете пользоваться PHP 7.2, а в начале 2019-го — планировать перейти на 7.3.
PHP 7.2 вышел 30 ноября 2017 г.
На момент написания статьи только PHP 7.1 и 7.2 активно поддерживаются разработчиками языка, а для PHP 5.6 и 7.0 ещё примерно год будут выходить патчи безопасности.
В некоторых ОС есть долговременная поддержка уже не поддерживаемых версий PHP, но это считается в целом порочной практикой. Например, бэкпортирование патчей безопасности без инкрементирования номеров версий затрудняет оценку системы безопасности только по версии PHP.
Соответственно, вне зависимости от обещаний вендоров всегда старайтесь использовать только активно поддерживаемую версию PHP, если это возможно. Если даже вы какое-то время будете работать с версией, для которой выходят только патчи безопасности, регулярные обновления версий избавят вас от многих неприятных сюрпризов.
Управление зависимостями
Вкратце: используйте Composer.
Composer — это шедевральное решение по управлению зависимостями в PHP-экосистеме. В книге PHP: The Right Way целый раздел посвящён началу работы с Composer, очень рекомендуем его прочесть.
Если вы не пользуетесь Composer для управления зависимостями, то рано или поздно (надеюсь — поздно, но, скорее всего, рано) окажетесь в ситуации, когда одна из библиотек, от которой вы зависите, сильно устареет, а преступники начнут активно эксплуатировать уязвимости в старых версиях.
Важно: не забывайте обновлять свои зависимости по мере разработки ПО. К счастью, это можно сделать одной строкой:
Если вы делаете что-то особенное, требующее использования PHP-расширений (написанных на С), то вы не можете установить их с помощью Composer. Вам также потребуется PECL.
Рекомендуемые пакеты
Вне зависимости от того, что вы создаёте, наверняка эти зависимости будут вам полезны. Это в дополнение к тому, что рекомендует большинство PHP-разработчиков (PHPUnit, PHP-CS-Fixer и т. д.).
roave/security-advisories
Пакет Roave security-advisories использует репозиторий Friends of PHP, чтобы ваш проект не зависел от любых пакетов с известными уязвимостями.
Или можете загрузить свой файл composer.lock в Sensio Labs в качестве стандартной процедуры автоматической оценки на уязвимости, чтобы получать предупреждения о любых устаревших пакетах.
vimeo/psalm
Psalm — инструмент статичного анализа, помогающий определять возможные баги в вашем коде. Хотя есть и другие хорошие инструменты (например, замечательные Phan и PHPStan), но если вам нужна поддержка PHP 5, то Psalm — один из лучших инструментов статичного анализа для PHP 5.4+.
Использовать Psalm просто:
Если вы впервые применяете этот код к имеющейся базе данных, то увидите много красных отметок. Если вы не создаёте приложение масштаба WordPress, то маловероятно, что вам придётся совершить подвиг Геркулеса, чтобы пройти все эти тесты.
Вне зависимости от того, какой инструмент статичного анализа вы выбрали, рекомендуем внедрить его в рабочий процесс непрерывной интеграции (если это возможно), чтобы инструмент запускался после каждого изменения кода.
HTTPS и безопасность в браузере
В 2018-м сайтам уже будет непозволительно работать по незащищённому HTTP. К счастью, можно было бесплатно получить TLS-сертификаты и автоматически обновлять их благодаря протоколу ACME и сертификационной компании Let’s Encrypt.
Интегрировать ACME в свой веб-сервер — пара пустяков.
Вы могли подумать: «Ладно, у меня есть TLS-сертификат. Теперь нужно потратить несколько часов на поиск конфигурации, чтобы сайт стал безопасным и быстрым».
Нет! Mozilla вам поможет. Для создания рекомендованных шифронаборов для своей аудитории можете использовать генератор конфигураций.
HTTPS (HTTP через TLS) совершенно безальтернативен, если хотите сделать свой сайт безопасным. Использование HTTPS моментально исключает несколько видов атак на ваших пользователей (внедрение контента «человек посередине», перехват данных, атаки повтором и манипуляции с сессиями ради подмены пользователя).
Заголовки безопасности
Хотя применение HTTPS на вашем сервере даёт много преимуществ по безопасности и производительности, можно пойти ещё дальше и воспользоваться другими функциями браузера по повышению безопасности. Большинство из них подразумевает отправку с контентом заголовков HTTP-ответов.
Аналогично, если вы используете встроенные PHP-свойства управления сессиями (что рекомендуется), то, возможно, захотите вызвать session_start() :
Тогда ваше приложение при отправке идентификационных кук будет использовать только безопасные HTTPS-флаги, что предотвратит успешные XSS-атаки с помощью кражи пользовательских кук, они будут отправляться только по HTTPS. Пару лет назад мы уже писали о безопасных PHP-сессиях.
Целостность подресурсов
Однажды в будущем вы станете работать над проектом, использующим CDN для выгрузки традиционных Javascript/CSS-фреймворков и библиотек в центральное расположение. Неудивительно, что специалисты по безопасности предсказали очевидную проблему: если много сайтов используют CDN для предоставления части своего содержимого, то взлом CDN и подмена данных позволит внедрять произвольный код на тысячи (если не миллионы) сайтов.
Поэтому придумали целостность подресурсов (subresource integrity).
Целостность подресурсов (SRI) позволяет закреплять хеш содержимого файла, которое вам должна предоставить CDN. Текущая реализация SRI позволяет использовать только криптографические хеш-функции, поэтому злоумышленники не смогут сгенерировать вредоносные версии контента, приводящие к таким же хешам, как у оригинальных файлов.
Взаимосвязи документов
Не делайте так
Это позволит example.com получить контроль над текущей страницей.
Делайте так
Разработка защищённых PHP-приложений
Если безопасность ПО для вас в новинку, можете начать с введения A Gentle Introduction to Application Security.
Многие специалисты по безопасности с самого начала обращают внимание разработчиков на ресурсы вроде OWASP Top 10. Но многие распространённые уязвимости можно считать особыми случаями одних и тех же высокоуровневых проблем (код/данные не разделены адекватно, ошибочная логика, небезопасная операционная среда, сломанные криптографические протоколы).
Мы считаем, что, если прививать неофитам в безопасности более простое, более фундаментальное представление о проблемах безопасности и их решениях, это поможет в долгосрочной перспективе улучшить ситуацию с безопасностью.
Взаимодействие с базами данных
Если вы сами пишете SQL-запросы, проверьте, что вы используете подготовленные выражения (prepared statements) и что любая предоставляемая сетью или файловой системой информация передаётся в виде параметров, а не конкатенируется в строку запроса. Также удостоверьтесь, что вы избегаете эмулированных подготовленных выражений.
НЕ ДЕЛАЙТЕ ТАК:
В базах данных есть и другие слои абстракций, предоставляющие эквивалентный уровень безопасности (EasyDB под капотом использует PDO, но любыми способами старается отключить эмулирование подготовленных выражений в пользу настоящих подготовленных выражений, чтобы предотвратить проблемы). Пока вводимые пользователями данные не могут влиять на структуру запросов (это относится и к хранимым процедурам) — вы в безопасности.
Загрузка файлов
Принимать пользовательские файлы рискованно, но это можно делать безопасно, если принять ряд предосторожностей. В частности, закрыть прямой доступ к загружаемым файлам, чтобы они не могли быть исполнены или интерпретированы.
Загружаемые файлы должны иметь атрибуты «только для чтения» или «только для чтения или записи» и никогда не быть исполняемыми.
Лучше хранить их в отдельной директории, к которой нет прямого доступа (например, /var/www/example.com-uploaded/ ), чтобы они случайно не выполнялись как серверные скрипты и не открывали дверь удалённому исполнению кода.
Более чистое решение — переместить свою корневую директорию для файлов на один уровень вниз (т. е. в /var/www/example.com/public ).
Другая проблема загружаемых файлов связана с их безопасным скачиванием.
Межсайтовый скриптинг (XSS)
В идеальном мире предотвратить XSS было бы так же легко, как и SQL-внедрение. У нас был бы простой в использовании API для отделения структуры документа от его содержимого.
К сожалению, в реальном мире большинство веб-разработчиков генерируют длинный HTML и отправляют его в HTTP-ответе. Это характерно не только для PHP, просто таковы реалии веб-разработки.
Закрытие XSS-уязвимостей — задача вполне решаемая. Однако содержимое раздела о браузерной безопасности неожиданно обретает большую важность. Вкратце:
Подделка межсайтовых запросов (CSRF)
Подделка межсайтовых запросов — это разновидность атаки с подменой делегата: можно обмануть пользовательский браузер и заставить его выполнить вредоносный HTTP-запрос с повышенными пользовательскими привилегиями.
В целом эта проблема легко решается:
Мы написали библиотеку Anti-CSRF, которая идёт ещё дальше:
Если ваш фреймворк не заботится о CSRF-уязвимостях, то применяйте Anti-CSRF.
В скором будущем куки SameSite позволят прекращать CSRF-атаки с гораздо меньшими усилиями.
XML-атаки (XXE, XPath-внедрения)
Есть две основные уязвимости, проявляющиеся в приложениях, которые много обрабатывают XML:
XXE-атаки, помимо прочего, могут использоваться как стартовая площадка для эксплойтов локального/удалённого внедрения файлов.
Ранние версии Google Docs были уязвимы к XXE-атакам, но они мало известны за пределами бизнес-приложений, обрабатывающих большие объёмы XML.
Главное, что нужно сделать для защиты от XXE-атак:
XPath-внедрение очень похоже на SQL-внедрение, только здесь речь идёт об XML-документах.
К счастью, в PHP-экосистеме редко возникают ситуации, когда вводимые пользователями данные передаются в XPath-запросе.
К сожалению, это также означает, что лучшее доступное решение (для заранее скомпилированных и параметризованных XPath-запросов) в PHP-экосистеме отсутствует.
Рекомендуем использовать белые списки разрешённых символов для любых данных, имеющих отношение к XPath-запросам.
Белые списки безопаснее чёрных.
Десериализация и внедрение PHP-объектов
Если вы передаёте в unserialize() недоверенные данные, то напрашиваетесь на два варианта развития событий:
Многие разработчики предпочитают использовать вместо этого JSON-сериализацию, что является заметным улучшением безопасности ПО. Но имейте в виду, что json_decode() уязвима для DDoS-атак посредством хеш-коллизий. К сожалению, полное решение проблемы хеш-DOS в PHP ещё предстоит найти.
Полностью защититься от этих атак поможет мигрирование с djb33 на Siphash с назначением 1 в качестве старшего бита для хеша строкового входного значения, 0 для целочисленного и с заранее запрошенным ключом, его предоставит CSPRNG.
К сожалению, создатели PHP не готовы частично пожертвовать производительностью, которой они добились в PHP 7, поэтому трудно убедить их отказаться от djb33 (очень быстрого, но небезопасного) в пользу SipHash (тоже быстрого, хотя и не как djb33, но куда более безопасного). Значительное снижение производительности может даже помешать разработке будущих версий, что не пойдёт на пользу безопасности.
Поэтому лучше поступать так:
Хеширование паролей
Подробнее: Как в 2016-м безопасно хранить пользовательские пароли
Безопасное хранилище паролей раньше было темой активной дискуссии, но сегодня его просто реализовать, особенно в PHP:
Вам даже не нужно знать, какой там алгоритм, потому что если вы используете самую свежую версию PHP, то будете использовать и самые последние технологии, а пользовательские пароли будут автоматически обновлены, как только окажется доступен новый алгоритм по умолчанию.
Если интересно: с PHP 5.5 по 7.2 алгоритмом по умолчанию является bcrypt. В будущем его могут заменить Argon2, победителем в Соревновании по хешированию паролей.
Если до этого вы не использовали API password_* и вам нужно мигрировать легаси-хеши, то сделайте это именно так. Многие компании, например Yahoo, поступили неправильно. Похоже, недавно причиной бага с iamroot у Apple стала некорректная реализация обновления легаси-хешей.
Криптография общего назначения
Мы много писали на эту тему:
Для криптографии на уровне приложения всегда выбирайте библиотеку Sodium (libsodium). Если вам нужно поддерживать PHP ниже 7.2 (вплоть до 5.2.4), можете использовать sodium_compat и притвориться, что пользователи тоже применяют 7.2.
В особых случаях из-за выбранных алгоритмов и взаимозаменяемости вам могут понадобиться другие библиотеки. Если сомневаетесь, проконсультируйтесь у криптографа по поводу выбора шифра и у инженера по шифрованию по поводу безопасности реализации.
Особые случаи
Вы получили представление, как в 2018-м нужно создавать защищённые PHP-приложения. Давайте теперь рассмотрим некоторые специфические случаи.
Шифрование с возможностью поиска
Многим хочется иметь шифрованные базы данных с возможностью поиска, но считается, что их трудно реализовать. По ссылке выше вы найдёте статью, в которой мы последовательно ведём читателя по разработке такой БД. В частности:
На любом шаге вы можете идти на компромиссы в зависимости от того, что в вашем случае оправдано.
Аутентификация на основе токенов без побочных каналов
Если говорить о базах данных (предыдущий раздел): вы знали, что запросы SELECT теоретически могут быть источником утечек информации о тайминге?
Простые меры защиты:
Даже если воспользоваться утечкой данных о тайминге для кражи половины токена, оставшаяся половина потребует брутфорс-атаки.
Разработка защищённых API
Мы написали SAPIENT, Secure API ENgineering Toolkit, чтобы упростить задачу межсерверного аутентификационного обмена сообщениями. Sapient позволяет шифровать и/или аутентифицировать сообщения с помощью шифрования на основе общего (shared) или публичного ключа в дополнение к средствам безопасности HTTPS.
Это позволяет с помощью Ed25519 аутентифицировать и отвечать на API-запросы или шифровать сообщения для целевого сервера, которые можно расшифровать лишь с помощью секретного ключа на принимающем сервере, даже несмотря на атаку «человек посередине» в сочетании с фальшивой/скомпрометированной сертификационной организацией.
Поскольку тело каждого HTTP-сообщения аутентифицируется с помощью безопасного шифрования, его можно использовать вместо протоколов, оперирующих токенами с проверкой состояния (например, Oauth). Но если говорить о самом шифровании, то прежде чем делать что-то нестандартное, всегда нужно быть уверенными в том, что выбранный вами алгоритм проанализирован специалистами.
Вся используемая в Sapient криптография предоставлена шифровальной библиотекой Sodium.
Дополнительно почитать:
Paragon Initiative Enterprises уже использует Sapient во многих своих продуктах (включая open source проекты) и продолжит расширять портфолио пользователей Sapient.
Безопасное журналирование событий с помощью Chronicle
Chronicle — криптографический журнал, обновляемый только путём добавления новых записей. Он основан на использующей хеш-цепочки структуре данных, свойства которой, безо всяких излишеств, привлекают многие компании в стан технологии «блокчейна».
Помимо более изощрённых способов применения такого журнала, Chronicle превосходно себя проявляет в SIEM, поскольку вы можете отправлять важные с точки зрения безопасности события в личный журнал, после чего они становятся неизменяемыми.
Если ваш Chronicle настроен на перекрёстную запись (cross-sign) суммарного хеша в другие экземпляры Chronicle и/или если есть другие экземпляры, сконфигурированные на репликацию содержимого вашего Chronicle, то атакующему будет крайне сложно подделать ваши журналы событий безопасности.
С помощью Chronicle вы получите надёжность блокчейна без распространённых проблем с приватностью, производительностью или масштабируемостью.
Для публикации данных в локальный Chronicle можно использовать любой API, совместимый с Sapient, но самое простое решение — Quill.
Несколько слов от автора
Проницательный читатель мог заметить, что мы много ссылаемся на собственные работы (статьи и open source проекты), но мы ссылаемся не только на свои работы.
Наша компания с самого основания в начале 2015-го пишет библиотеки для обеспечения безопасности и участвует в повышении защищённости экосистемы PHP.
Мы много путешествуем, и наш инженер по безопасности (чьи недавние усилия по использованию более сильной криптографии в ядре PHP только что отразились в PHP 7.2), по его собственному признанию, не слишком силён в генерировании хайпа или интереса к своей работе. Наверняка вы не слышали и о половине инструментов или библиотек, созданных нами за эти годы.
Но мы не можем стать пионерами во всех направлениях, поэтому везде, где это возможно, связываемся с экспертами индустрии, которые, как нам кажется, больше ориентируются на общественное благо, чем на мелкий эгоизм. Поэтому большая часть раздела, посвящённого безопасности в браузере, снабжена ссылками на работы Скотта Хелме (Scott Helme) и компании. Он вложил много сил в то, чтобы эти новые возможности по обеспечению безопасности стали доступны и понятны разработчикам.
Конечно, это не исчерпывающее руководство. Существует почти столько же способов писать небезопасный код, сколько способов самого написания кода. Безопасность — это больше мышление, чем цель. Мы надеемся, что с помощью всего сказанного и приведённых ниже источников разработчики с сегодняшнего дня смогут создавать защищённые PHP-приложения.
Источники
Если вы уже изучили всё предложенное и хотите больше, почитайте курируемый нами список по изучению безопасности приложений.
Если вы считаете, что адекватно пишете безопасный код, и хотите покритиковать нас с точки зрения инженера по безопасности, то именно такую услугу мы и предлагаем своим клиентам.
Если вы работаете в компании, которая заинтересована в оценке соответствия требованиям (PCI-DSS, ISO 27001 и т. д.), можете нанять нас для аудита своего исходного кода. Мы работаем гораздо более дружественно к разработчикам, чем другие консультанты по безопасности.
Ниже — список источников от PHP-сообщества и сообщества по информационной безопасности.
PHP Encryption with Libsodium
What Is Libsodium?
Libsodium, also known as Sodium, is a powerful cryptography library. It is a portable, cross-compilable, installable, and packageable fork of NaCl, a famous cryptographic tool designed by Prof. D.J. Bernstein. If you need to enable PHP encryption/decryption, you can use Libsodium.
What Algorithms Are in Libsodium?
The Libsodium library is an “opinionated” cryptography library. This means the algorithms in Sodium have been selected and cannot be changed.
The library uses some of the most robust algorithms available, including:
If you need to use different algorithms — for instance, if you need to ensure compatibility with existing cryptosystems — you need to look for a different library, such as OpenSSL.
Libsodium Is Designed to Prevent Side-Channel Attacks
Apart from the selection of the best algorithms available, Sodium, and NaCl, were designed to prevent side-channel attacks. This is a very good point for security because the majority of attacks are based on issues in the implementations, rather than weaknesses in the algorithm itself.
Just to give you an idea, one of the most successful side-channel attacks in history was performed by Adi Shamir, Eran Tromer, and Dag Arne Osvik in 2006. The attack was aimed to discover, in **65 milliseconds,** the secret key used in widely deployed software for hard-disk encryption. (Here is the extended article.)
PHP Encryption With Libsodium
Developers can use Sodium for PHP encryption and decryption with PHP 7.2 and newer without an extension. If you want to use Sodium with PHP 7.0 or 7.1, you need to install a PECL extension.
Libsodium vs. OpenSSL
When comparing Libsodium vs. OpenSSL with the chart below, you can see that there are many differences between the two cryptographic libraries.
| Libsodium | OpenSSL | |
|---|---|---|
| Development Language | C | C |
| Software License | ISC License | Apache License, BSD License |
| Last Updated | December, 2017 | March, 2020 |
| Code Size | 44 kSLOC | 472 kSLOC |
| Key Generation/Exchange | ECDH | ECDH, DH, DSA, RSA |
| Elliptic Curve Cryptography | NIST | NIST, SECG, ECC Brainpool, ECDSA, ECDH, Curve25519, EdDSA, GOST R 34.10 |
| Public Key Cryptography Standards | n/a | PKCS#1, PKCS#5, PKCS#8, PKCS#12, ASN.1 |
| Hash Functions | SHA-2 | MD5, SHA-1, SHA-2, SHA-3, RIPEMD-160, Tiger, Whirlpool, GOST, BLAKE2 |
| MAC Algorithms | HMAC-SHA2, Poly1305-AES, BLAKE2-MAC | HMAC-MD5, HMAC-SHA1, HMAC-SHA2, Poly1305-AES |
| Block Cipher Algorithms | AES | AES, Camellia, 3DES, Blowfish, CAST5, IDEA, GOST 28147-89/GOST R 34.12-2015 ARIA |
| Cipher Modes | CTR, GCM | ECB, CBC, OFB, CFB, CTR, CCM, GCM, OCB, XTS, AES-Wrap, Stream |
| Stream Ciphers | Salsa20, ChaCha | RC4, ChaCha |
Libsodium Examples
Here are six examples for using the Sodium cryptography library:
Libsodium PHP String Encrypt Example
The Sodium APIs are quite simple to use. Just to give you an idea, here’s example code on how to encrypt a PHP string with a shared-key:
And here how to authenticate a message (without encryption):
To see more PHP code examples, see the slides from this ZendCon and OpenEnterprise presentation.
Want to learn how Zend by Perforce can help you with your security strategy?