- PVSM.RU - https://www.pvsm.ru -
Приближается 2018 год, и технари — в частности веб-разработчики — должны отбросить многие старые методики и верования в сфере разработки защищённых PHP-приложений. Особенно это относится ко всем, кто не верит, что такие приложения вообще возможны.
Это руководство — дополнение к электронной книге PHP: The Right Way [1] с сильным уклоном в безопасность, а не общие вопросы программирования на 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.
Соответственно, вне зависимости от обещаний вендоров всегда старайтесь использовать только активно поддерживаемую [2] версию PHP, если это возможно. Если даже вы какое-то время будете работать с версией, для которой выходят только патчи безопасности, регулярные обновления версий избавят вас от многих неприятных сюрпризов.
Вкратце: используйте Composer.
Composer [3] — это шедевральное решение по управлению зависимостями в PHP-экосистеме. В книге PHP: The Right Way целый раздел посвящён началу работы с Composer [4], очень рекомендуем его прочесть.
Если вы не пользуетесь Composer для управления зависимостями, то рано или поздно (надеюсь — поздно, но, скорее всего, рано) окажетесь в ситуации, когда одна из библиотек, от которой вы зависите, сильно устареет, а преступники начнут активно эксплуатировать уязвимости в старых версиях.
Важно: не забывайте обновлять свои зависимости [5] по мере разработки ПО. К счастью, это можно сделать одной строкой:
composer update
Если вы делаете что-то особенное, требующее использования PHP-расширений (написанных на С), то вы не можете установить их с помощью Composer. Вам также потребуется PECL.
Вне зависимости от того, что вы создаёте, наверняка эти зависимости будут вам полезны. Это в дополнение к тому, что рекомендует большинство PHP-разработчиков (PHPUnit, PHP-CS-Fixer и т. д.).
Пакет Roave security-advisories [6] использует репозиторий Friends of PHP [7], чтобы ваш проект не зависел от любых пакетов с известными уязвимостями.
composer require roave/security-advisories:dev-master
Или можете загрузить свой файл [8] composer.lock
в Sensio Labs в качестве стандартной процедуры автоматической оценки на уязвимости, чтобы получать предупреждения о любых устаревших пакетах.
Psalm [9] — инструмент статичного анализа, помогающий определять возможные баги в вашем коде. Хотя есть и другие хорошие инструменты (например, замечательные Phan [10] и PHPStan [11]), но если вам нужна поддержка PHP 5, то Psalm — один из лучших инструментов статичного анализа для PHP 5.4+.
Использовать Psalm просто:
# Version 1 doesn't exist yet, but it will one day:
composer require --dev vimeo/psalm:^0
# Only do this once:
vendor/bin/psalm --init
# Do this as often as you need:
vendor/bin/psalm
Если вы впервые применяете этот код к имеющейся базе данных, то увидите много красных отметок. Если вы не создаёте приложение масштаба WordPress, то маловероятно, что вам придётся совершить подвиг Геркулеса, чтобы пройти все эти тесты.
Вне зависимости от того, какой инструмент статичного анализа вы выбрали, рекомендуем внедрить его в рабочий процесс непрерывной интеграции (если это возможно), чтобы инструмент запускался после каждого изменения кода.
Вкратце: HTTPS, который нужно тестировать [12], и заголовки безопасности [13].
В 2018-м сайтам уже будет непозволительно работать по незащищённому HTTP. К счастью, можно было бесплатно получить TLS-сертификаты и автоматически обновлять их благодаря протоколу ACME и сертификационной компании Let's Encrypt [14].
Интегрировать ACME в свой веб-сервер — пара пустяков.
Вы могли подумать: «Ладно, у меня есть TLS-сертификат. Теперь нужно потратить несколько часов на поиск конфигурации, чтобы сайт стал безопасным и быстрым».
Нет! Mozilla вам поможет [19]. Для создания рекомендованных шифронаборов [20] для своей аудитории можете использовать генератор конфигураций.
HTTPS (HTTP через TLS) совершенно безальтернативен, если хотите сделать свой сайт безопасным. Использование HTTPS моментально исключает несколько видов атак на ваших пользователей (внедрение контента «человек посередине», перехват данных, атаки повтором и манипуляции с сессиями ради подмены пользователя).
Хотя применение HTTPS на вашем сервере даёт много преимуществ по безопасности и производительности, можно пойти ещё дальше и воспользоваться другими функциями браузера по повышению безопасности. Большинство из них подразумевает отправку с контентом заголовков HTTP-ответов.
Content-Security-Policy
Expect-CT
Expect-CT
: https://scotthelme.co.uk/a-new-security-header-expect-ct/ [23]. enforce
, max-age=30
, а когда удостоверитесь, что заголовок не мешает работе сервиса, увеличьте max-age
. Referrer-Policy
Referrer-Policy
. same-origin
или no-referrer
, пока не будет причины передавать больше информации. Strict-Transport-Security
max-age=30
, а потом увеличьте значение (например, до 31536000
), когда будете уверены, что ничего не сломается. X-Content-Type-Options
Content-Type
. nosniff
, если только вам не нужно поведение по умолчанию (например, для скачивания файлов). X-Frame-Options
DENY
(или SAMEORIGIN
, но только если используете элементы <frame>
) X-XSS-Protection
1; mode=block
Аналогично, если вы используете встроенные PHP-свойства управления сессиями (что рекомендуется), то, возможно, захотите вызвать session_start()
:
session_start([
'cookie_httponly' => true,
'cookie_secure' => true
]);
Тогда ваше приложение при отправке идентификационных кук будет использовать только безопасные HTTPS-флаги, что предотвратит успешные XSS-атаки с помощью кражи пользовательских кук, они будут отправляться только по HTTPS. Пару лет назад мы уже писали о безопасных PHP-сессиях [25].
Однажды в будущем вы станете работать над проектом, использующим CDN для выгрузки традиционных Javascript/CSS-фреймворков и библиотек в центральное расположение. Неудивительно, что специалисты по безопасности предсказали очевидную проблему: если много сайтов используют CDN для предоставления части своего содержимого, то взлом CDN и подмена данных позволит внедрять произвольный код на тысячи (если не миллионы) сайтов.
Поэтому придумали целостность подресурсов (subresource integrity).
Целостность подресурсов (SRI) позволяет закреплять хеш содержимого файла, которое вам должна предоставить CDN. Текущая реализация SRI позволяет использовать только криптографические хеш-функции, поэтому злоумышленники не смогут сгенерировать вредоносные версии контента, приводящие к таким же хешам, как у оригинальных файлов.
Реальный пример: Bootstrap v4-alpha использует SRI в примере кода их CDN [26].
<link
rel="stylesheet"
href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.6/css/bootstrap.min.css"
integrity="sha384-rwoIResjU2yc3z8GV/NPeZWAv56rSmLldC3R/AZzGRnGxQQKnKkoFVhFQhNUwEyJ"
crossorigin="anonymous"
/>
<script
src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.6/js/bootstrap.min.js"
integrity="sha384-vBWWzlZJ8ea9aCX4pEW3rVHjgjt7zpkNpZk+02D9phzyeVkE+jo0ieGizqPLForn"
crossorigin="anonymous"
></script>
Веб-разработчики часто задают гиперссылкам атрибут target
(например, target="_blank"
для открытия ссылки в новом окне). Но если вы не передаёте также тэг rel="noopener"
, то позволите целевой странице получить контроль над исходной страницей [27].
Не делайте так
<a href="http://example.com" target="_blank">Click here</a>
Это позволит example.com
получить контроль над текущей страницей.
Делайте так
<a href="https://example.com" target="_blank" rel="noopener noreferrer">Click here</a>
В новом окне открывается example.com
, но не получает контроля над текущим окном.
Для дальнейшего изучения [28].
Если безопасность ПО для вас в новинку, можете начать с введения A Gentle Introduction to Application Security.
Многие специалисты по безопасности с самого начала обращают внимание разработчиков на ресурсы вроде OWASP Top 10 [29]. Но многие распространённые уязвимости можно считать особыми случаями одних и тех же высокоуровневых проблем (код/данные не разделены адекватно, ошибочная логика, небезопасная операционная среда, сломанные криптографические протоколы).
Мы считаем, что, если прививать неофитам в безопасности более простое, более фундаментальное представление о проблемах безопасности и их решениях, это поможет в долгосрочной перспективе улучшить ситуацию с безопасностью.
Подробнее: Предотвращение SQL-внедрений в PHP-приложениях [30]
Если вы сами пишете SQL-запросы, проверьте, что вы используете подготовленные выражения (prepared statements) и что любая предоставляемая сетью или файловой системой информация передаётся в виде параметров, а не конкатенируется в строку запроса. Также удостоверьтесь, что вы избегаете эмулированных подготовленных выражений.
Лучший выбор — EasyDB [31].
НЕ ДЕЛАЙТЕ ТАК:
/* Небезопасный код: */
$query = $pdo->query("SELECT * FROM users WHERE username = '" . $_GET['username'] . "'");
Делайте так:
/* Защищено от SQL-внедрений: */
$results = $easydb->row("SELECT * FROM users WHERE username = ?", $_GET['username']);
В базах данных есть и другие слои абстракций, предоставляющие эквивалентный уровень безопасности (EasyDB под капотом использует PDO, но любыми способами старается отключить эмулирование подготовленных выражений в пользу настоящих подготовленных выражений, чтобы предотвратить проблемы). Пока вводимые пользователями данные не могут влиять на структуру запросов (это относится и к хранимым процедурам) — вы в безопасности.
Подробнее: Как безопасно разрешать пользователям загружать файлы [32]
Принимать пользовательские файлы рискованно, но это можно делать безопасно, если принять ряд предосторожностей. В частности, закрыть прямой доступ к загружаемым файлам, чтобы они не могли быть исполнены или интерпретированы.
Загружаемые файлы должны иметь атрибуты «только для чтения» или «только для чтения или записи» и никогда не быть исполняемыми.
Если на вашем сайте корневая директория для документов /var/www/example.com
, то не надо хранить загружаемые файлы в /var/www/example.com/uploaded_files
.
Лучше хранить их в отдельной директории, к которой нет прямого доступа (например, /var/www/example.com-uploaded/
), чтобы они случайно не выполнялись как серверные скрипты и не открывали дверь удалённому исполнению кода.
Более чистое решение — переместить свою корневую директорию для файлов на один уровень вниз (т. е. в /var/www/example.com/public
).
Другая проблема загружаемых файлов связана с их безопасным скачиванием.
image/
в MIME-типе [33]. X-Content-Type-Options
. .php
или .phtml
, может исполнить произвольный код, обратившись к файлу напрямую в браузере, и получить полный контроль над сервером. Будьте осторожны.Подробнее: Всё, что вам нужно знать о предотвращении межсайтового скриптинга в PHP [34]
В идеальном мире предотвратить XSS было бы так же легко, как и SQL-внедрение. У нас был бы простой в использовании API для отделения структуры документа от его содержимого.
К сожалению, в реальном мире большинство веб-разработчиков генерируют длинный HTML и отправляют его в HTTP-ответе. Это характерно не только для PHP, просто таковы реалии веб-разработки.
Закрытие XSS-уязвимостей — задача вполне решаемая. Однако содержимое раздела о браузерной безопасности [35] неожиданно обретает большую важность. Вкратце:
echo htmlentities($string, ENT_QUOTES | ENT_HTML5, 'UTF-8');
— это безопасный и эффективный способ остановить все XSS-атаки на страницу, использующую UTF-8, но при этом весь HTML будет запрещён. Подделка межсайтовых запросов — это разновидность атаки с подменой делегата: можно обмануть пользовательский браузер и заставить его выполнить вредоносный HTTP-запрос с повышенными пользовательскими привилегиями.
В целом эта проблема легко решается:
Мы написали библиотеку Anti-CSRF [37], которая идёт ещё дальше:
Если ваш фреймворк не заботится о CSRF-уязвимостях, то применяйте Anti-CSRF.
В скором будущем куки SameSite позволят прекращать CSRF [38]-атаки с гораздо меньшими усилиями.
Есть две основные уязвимости, проявляющиеся в приложениях, которые много обрабатывают XML:
XXE-атаки, помимо прочего [39], могут использоваться как стартовая площадка для эксплойтов локального/удалённого внедрения файлов.
Ранние версии Google Docs были уязвимы к XXE-атакам, но они мало известны за пределами бизнес-приложений, обрабатывающих большие объёмы XML.
Главное, что нужно сделать для защиты от XXE-атак:
libxml_disable_entity_loader(true);
XPath-внедрение [40] очень похоже на SQL-внедрение, только здесь речь идёт об XML-документах.
К счастью, в PHP-экосистеме редко возникают ситуации, когда вводимые пользователями данные передаются в XPath-запросе.
К сожалению, это также означает, что лучшее доступное решение (для заранее скомпилированных и параметризованных XPath-запросов) в PHP-экосистеме отсутствует.
Рекомендуем использовать белые списки разрешённых символов для любых данных, имеющих отношение к XPath-запросам.
<?php
declare(strict_types=1);
class SafeXPathEscaper
{
/**
* @param string $input
* @return string
*/
public static function allowAlphaNumeric(string $input): string
{
return preg_replace('#[^A-Za-z0-9]#', '', $input);
}
/**
* @param string $input
* @return string
*/
public static function allowNumeric(string $input): string
{
return preg_replace('#[^0-9]#', '', $input);
}
}
// Usage:
$selected = $xml->xpath(
"/user/username/" . SafeXPathEscaper::allowAlphaNumeric(
$_GET['username']
)
);
Белые списки безопаснее чёрных.
Подробнее: Безопасная (де)сериализация в PHP [41]
Если вы передаёте в unserialize()
недоверенные данные, то напрашиваетесь на два варианта развития событий:
Многие разработчики предпочитают использовать вместо этого JSON-сериализацию, что является заметным улучшением безопасности ПО. Но имейте в виду, что json_decode()
уязвима для DDoS-атак посредством хеш-коллизий [42]. К сожалению, полное решение проблемы хеш-DOS в PHP ещё предстоит найти [43].
Полностью защититься от этих атак поможет мигрирование с djb33 на Siphash с назначением 1 в качестве старшего бита для хеша строкового входного значения, 0 для целочисленного и с заранее запрошенным ключом, его предоставит CSPRNG.
К сожалению, создатели PHP не готовы частично пожертвовать производительностью, которой они добились в PHP 7, поэтому трудно убедить их отказаться от djb33 (очень быстрого, но небезопасного) в пользу SipHash (тоже быстрого, хотя и не как djb33, но куда более безопасного). Значительное снижение производительности может даже помешать разработке будущих версий, что не пойдёт на пользу безопасности.
Поэтому лучше поступать так:
unserialize()
. sodium_crypto_auth()
и sodium_crypto_auth_verify()
с секретным ключом, известным только серверу. sodium_crypto_sign()
, а затем проверяйте с помощью sodium_crypto_sign_open()
и стороннего публичного ключа. Подробнее: Как в 2016-м безопасно хранить пользовательские пароли [44]
Безопасное хранилище паролей раньше было темой активной дискуссии, но сегодня его просто реализовать, особенно в PHP:
$hash = password_hash($password, PASSWORD_DEFAULT);
if (password_verify($password, $hash)) {
// Authenticated.
if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
// Rehash, update database.
}
}
Вам даже не нужно знать, какой там алгоритм, потому что если вы используете самую свежую версию PHP, то будете использовать и самые последние технологии, а пользовательские пароли будут автоматически обновлены, как только окажется доступен новый алгоритм по умолчанию.
Что бы вы ни делали, не делайте так, как WordPress [45].
Если интересно: с PHP 5.5 по 7.2 алгоритмом по умолчанию является bcrypt. В будущем его могут заменить Argon2, победителем в Соревновании по хешированию паролей [46].
Если до этого вы не использовали API password_*
и вам нужно мигрировать легаси-хеши, то сделайте это именно так [47]. Многие компании, например Yahoo [48], поступили неправильно. Похоже, недавно причиной бага [49] с iamroot
у Apple стала некорректная реализация обновления легаси-хешей.
Мы много писали на эту тему:
Для криптографии на уровне приложения всегда выбирайте библиотеку Sodium (libsodium). Если вам нужно поддерживать PHP ниже 7.2 (вплоть до 5.2.4), можете использовать sodium_compat [56] и притвориться, что пользователи тоже применяют 7.2.
В особых случаях из-за выбранных алгоритмов и взаимозаменяемости вам могут понадобиться другие библиотеки. Если сомневаетесь, проконсультируйтесь у криптографа по поводу выбора шифра и у инженера по шифрованию по поводу безопасности реализации.
Вы получили представление, как в 2018-м нужно создавать защищённые PHP-приложения. Давайте теперь рассмотрим некоторые специфические случаи.
Подробнее: Building Searchable Encrypted Databases with PHP and SQL [57]
Многим хочется иметь шифрованные базы данных с возможностью поиска, но считается, что их трудно реализовать. По ссылке выше вы найдёте статью, в которой мы последовательно ведём читателя по разработке такой БД. В частности:
На любом шаге вы можете идти на компромиссы в зависимости от того, что в вашем случае оправдано.
Подробнее: Сплит-токены: протоколы аутентификации на основе токенов без побочных каналов [58]
Если говорить о базах данных (предыдущий раздел): вы знали, что запросы SELECT теоретически могут быть источником утечек информации о тайминге?
Простые меры защиты:
Даже если воспользоваться утечкой данных о тайминге для кражи половины токена, оставшаяся половина потребует брутфорс-атаки.
Подробнее: С помощью Sapient закаливаем ваши PHP API [59]
Мы написали SAPIENT [60], Secure API ENgineering Toolkit, чтобы упростить задачу межсерверного аутентификационного обмена сообщениями. Sapient позволяет шифровать и/или аутентифицировать сообщения с помощью шифрования на основе общего (shared) или публичного ключа в дополнение к средствам безопасности HTTPS.
Это позволяет с помощью Ed25519 аутентифицировать и отвечать на API-запросы или шифровать сообщения для целевого сервера, которые можно расшифровать лишь с помощью секретного ключа на принимающем сервере, даже несмотря на атаку «человек посередине» в сочетании с фальшивой/скомпрометированной сертификационной организацией.
Поскольку тело каждого HTTP-сообщения аутентифицируется с помощью безопасного шифрования, его можно использовать вместо протоколов, оперирующих токенами с проверкой состояния (например, Oauth). Но если говорить о самом шифровании, то прежде чем делать что-то нестандартное, всегда нужно быть уверенными в том, что выбранный вами алгоритм проанализирован специалистами.
Вся используемая в Sapient криптография предоставлена шифровальной библиотекой Sodium.
Дополнительно почитать:
Paragon Initiative Enterprises уже использует Sapient во многих своих продуктах (включая open source проекты) и продолжит расширять портфолио пользователей Sapient.
Подробнее: Chronicle заставит задуматься, нужна ли вам технология блокчейна [64]
Chronicle [65] — криптографический журнал, обновляемый только путём добавления новых записей. Он основан на использующей хеш-цепочки структуре данных, свойства которой, безо всяких излишеств, привлекают многие компании в стан технологии «блокчейна».
Помимо более изощрённых способов применения такого журнала, Chronicle превосходно себя проявляет в SIEM, поскольку вы можете отправлять важные с точки зрения безопасности события в личный журнал, после чего они становятся неизменяемыми.
Если ваш Chronicle настроен на перекрёстную запись (cross-sign) суммарного хеша в другие экземпляры Chronicle и/или если есть другие экземпляры, сконфигурированные на репликацию содержимого вашего Chronicle, то атакующему будет крайне сложно подделать ваши журналы событий безопасности.
С помощью Chronicle вы получите надёжность блокчейна без распространённых проблем с приватностью, производительностью или масштабируемостью.
Для публикации данных в локальный Chronicle можно использовать любой API, совместимый с Sapient [66], но самое простое решение — Quill [67].
Проницательный читатель мог заметить, что мы много ссылаемся на собственные работы (статьи и open source проекты), но мы ссылаемся не только на свои работы.
Это неслучайно.
Наша компания с самого основания в начале 2015-го пишет библиотеки для обеспечения безопасности и участвует в повышении защищённости экосистемы PHP.
Мы много путешествуем, и наш инженер по безопасности (чьи недавние усилия по использованию более сильной криптографии в ядре PHP только что отразились в PHP 7.2), по его собственному признанию, не слишком силён в генерировании хайпа или интереса к своей работе. Наверняка вы не слышали и о половине инструментов или библиотек, созданных нами за эти годы.
Но мы не можем стать пионерами во всех направлениях, поэтому везде, где это возможно, связываемся с экспертами индустрии, которые, как нам кажется, больше ориентируются на общественное благо, чем на мелкий эгоизм. Поэтому большая часть раздела, посвящённого безопасности в браузере, снабжена ссылками на работы Скотта Хелме (Scott Helme [68]) и компании. Он вложил много сил в то, чтобы эти новые возможности по обеспечению безопасности стали доступны и понятны разработчикам.
Конечно, это не исчерпывающее руководство. Существует почти столько же способов писать небезопасный код, сколько способов самого написания кода. Безопасность — это больше
Если вы уже изучили всё предложенное и хотите больше, почитайте курируемый нами список по изучению безопасности приложений [70].
Если вы считаете, что адекватно пишете безопасный код, и хотите покритиковать нас с точки зрения инженера по безопасности, то именно такую услугу мы и предлагаем [71] своим клиентам.
Если вы работаете в компании, которая заинтересована в оценке соответствия требованиям (PCI-DSS, ISO 27001 и т. д.), можете нанять нас для аудита своего исходного кода [72]. Мы работаем гораздо более дружественно к разработчикам, чем другие консультанты по безопасности.
Ниже — список источников от PHP-сообщества и сообщества по информационной безопасности.
Автор: AloneCoder
Источник [81]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/php-2/270790
Ссылки в тексте:
[1] PHP: The Right Way: http://www.phptherightway.com/
[2] использовать только активно поддерживаемую: http://php.net/supported-versions.php
[3] Composer: https://getcomposer.org/
[4] началу работы с Composer: http://www.phptherightway.com/#dependency_management
[5] обновлять свои зависимости: http://www.phptherightway.com/#updating-your-dependencies
[6] Roave security-advisories: https://github.com/Roave/SecurityAdvisories
[7] Friends of PHP: https://github.com/FriendsOfPHP/security-advisories
[8] загрузить свой файл: https://github.com/FriendsOfPHP/security-advisories#checking-for-vulnerabilities
[9] Psalm: https://github.com/vimeo/psalm
[10] Phan: https://github.com/phan/phan
[11] PHPStan: https://github.com/phpstan/phpstan
[12] который нужно тестировать: https://www.ssllabs.com/
[13] заголовки безопасности: https://securityheaders.io/
[14] Let's Encrypt: https://letsencrypt.org/
[15] Caddy: https://caddyserver.com/
[16] Apache: https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd.html
[17] отличные инструкции: https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-16-04
[18] Nginx: https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/
[19] Mozilla вам поможет: https://mozilla.github.io/server-side-tls/ssl-config-generator/
[20] рекомендованных шифронаборов: https://wiki.mozilla.org/Security/Server_Side_TLS
[21] CSP-Builder: https://github.com/paragonie/csp-builder
[22] введение в заголовки политик безопасности содержимого: https://scotthelme.co.uk/content-security-policy-an-introduction/
[23] https://scotthelme.co.uk/a-new-security-header-expect-ct/: https://scotthelme.co.uk/a-new-security-header-expect-ct/
[24] Scott Helme прекрасно описывает работу с заголовками: https://scotthelme.co.uk/a-new-security-header-referrer-policy/
[25] безопасных PHP-сессиях: https://paragonie.com/blog/2015/04/fast-track-safe-and-secure-php-sessions
[26] Bootstrap v4-alpha использует SRI в примере кода их CDN: https://v4-alpha.getbootstrap.com/
[27] позволите целевой странице получить контроль над исходной страницей: https://mathiasbynens.github.io/rel-noopener/
[28] Для дальнейшего изучения: https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever
[29] OWASP Top 10: https://www.owasp.org/index.php/Top_10_2017-Top_10
[30] Предотвращение SQL-внедрений в PHP-приложениях: https://paragonie.com/blog/2015/05/preventing-sql-injection-in-php-applications-easy-and-definitive-guide
[31] EasyDB: https://github.com/paragonie/easydb
[32] Как безопасно разрешать пользователям загружать файлы: https://paragonie.com/blog/2015/10/how-securely-allow-users-upload-files
[33] несмотря на вводящий в заблуждение префикс: https://github.com/w3c/svgwg/issues/266
[34] Всё, что вам нужно знать о предотвращении межсайтового скриптинга в PHP: https://paragonie.com/blog/2015/06/preventing-xss-vulnerabilities-in-php-everything-you-need-know
[35] раздела о браузерной безопасности: https://paragonie.com/blog/2017/12/2018-guide-building-secure-php-software#browser-security
[36] HTML Purifier: http://htmlpurifier.org/
[37] Anti-CSRF: https://github.com/paragonie/anti-csrf
[38] SameSite позволят прекращать CSRF: https://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/
[39] помимо прочего: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
[40] XPath-внедрение: https://www.owasp.org/index.php/XPATH_Injection
[41] Безопасная (де)сериализация в PHP: https://paragonie.com/blog/2016/04/securely-implementing-de-serialization-in-php
[42] уязвима для DDoS-атак посредством хеш-коллизий: http://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-revisited.html
[43] ещё предстоит найти: https://bugs.php.net/bug.php?id=70644
[44] Как в 2016-м безопасно хранить пользовательские пароли: https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016
[45] не делайте так, как WordPress: https://paragonie.com/blog/2016/08/on-insecurity-popular-open-source-php-cms-platforms#wordpress-password-storage
[46] Соревновании по хешированию паролей: https://password-hashing.net/
[47] именно так: https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#legacy-hashes
[48] Yahoo: https://www.theregister.co.uk/2016/12/15/yahoos_password_hash/
[49] бага: https://objective-see.com/blog/blog_0x24.html
[50] Корректное использование шифрования и аутентификации: https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly
[51] Как безопасно генерировать случайные строковые и числа в PHP: https://paragonie.com/blog/2015/07/how-safely-generate-random-strings-and-integers-in-php
[52] Руководство по выбору правильной криптографической библиотеки для вашего PHP-проекта: https://paragonie.com/blog/2015/11/choosing-right-cryptography-library-for-your-php-project-guide
[53] Не используйте Base64-кодировку для паролей: https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-password-cryptography-decoded
[54] Криптографически безопасная PHP-разработка: https://paragonie.com/blog/2017/02/cryptographically-secure-php-development
[55] Libsodium: функции с похожими именами и варианты их использования: https://paragonie.com/blog/2017/06/libsodium-quick-reference-quick-comparison-similar-functions-and-which-one-use
[56] sodium_compat: https://github.com/paragonie/sodium_compat
[57] Building Searchable Encrypted Databases with PHP and SQL: https://paragonie.com/blog/2017/05/building-searchable-encrypted-databases-with-php-and-sql
[58] Сплит-токены: протоколы аутентификации на основе токенов без побочных каналов: https://paragonie.com/blog/2017/02/split-tokens-token-based-authentication-protocols-without-side-channels
[59] С помощью Sapient закаливаем ваши PHP API: https://paragonie.com/blog/2017/06/hardening-your-php-powered-apis-with-sapient
[60] SAPIENT: https://github.com/paragonie/sapient
[61] Sapient: https://github.com/paragonie/sapient/tree/master/docs
[62] Sapient: https://github.com/paragonie/sapient/blob/master/docs/Tutorial.md
[63] Sapient: https://github.com/paragonie/sapient/blob/master/docs/Specification.md
[64] Chronicle заставит задуматься, нужна ли вам технология блокчейна: https://paragonie.com/blog/2017/07/chronicle-will-make-you-question-need-for-blockchain-technology
[65] Chronicle: https://github.com/paragonie/chronicle
[66] API, совместимый с Sapient: https://paragonie.com/blog/2017/12/2018-guide-building-secure-php-software#secure-api-sapient
[67] Quill: https://github.com/paragonie/quill
[68] Scott Helme: https://scotthelme.co.uk/
[69] мышление: http://www.braintools.ru
[70] курируемый нами список по изучению безопасности приложений: https://github.com/paragonie/awesome-appsec
[71] услугу мы и предлагаем: https://paragonie.com/services
[72] нанять нас для аудита своего исходного кода: https://paragonie.com/blog/2017/06/why-you-want-paragon-initiative-enterprises-audit-your-code
[73] Qualys SSL Labs: https://www.ssllabs.com/ssltest
[74] Report-URI: https://report-uri.com/
[75] The PHP Security Advent Calendar: https://www.ripstech.com/php-security-calendar-2017
[76] RIPSTech: https://www.ripstech.com/
[77] Snuffleupagus: https://snuffleupagus.readthedocs.io/
[78] Suhosin: https://github.com/sektioneins/suhosin
[79] PHP Delusions: https://phpdelusions.net/
[80] Have I Been Pwned?: https://haveibeenpwned.com/
[81] Источник: https://habrahabr.ru/post/344696/?utm_campaign=344696
Нажмите здесь для печати.