From 24b7d3291da0ec73677d55d3f06e73bbcb0a28ea Mon Sep 17 00:00:00 2001 From: IY Date: Wed, 11 Sep 2019 19:31:35 +0300 Subject: [PATCH] formating --- 5. For developers | 348 +++++++++++++++++++++--------------------- 6. For administrators | 69 ++++----- 2 files changed, 209 insertions(+), 208 deletions(-) diff --git a/5. For developers b/5. For developers index 025cae6..31003b3 100644 --- a/5. For developers +++ b/5. For developers @@ -1,180 +1,180 @@ 5.1 Рабочее место. - В процессе работы над проектом важно соблюдать "правила гигены", - которыми мы часто пернебрегаем - рабочая машина должна быть защищена паролем, - жесткий диск или хотя бы каталог пользователя должен быть зашифрован (настраивается - во всех современных ОС), в macOS - FileVault, в Windows - BitLocker, в Linux - LUKS, - ecryptFS, encFS... Когда отходите от компьютера важно блокировать его (закрывать - крышку). Не стоит заряжать чужие телефоны и вставлять чужие флешки. Своевременно оновляйте - систему и ПО. Всегда стоит придерживаться правил и инструкций по безопасности компании, в - которой вы работаете - таким образом вы не только помогаете безопасникам, но и снимаете - с себя ответственность за утечки. Никогда не устанавливайте пиратское ПО - во-первых, - вы не можете быть уверены в чистоте кряка - в лучшем случае там может быть майнер, в - худшем - прикрепленный msfpayload. Если для работы нужна какая-то программа - - просите, чтобы вам предоставили лицензию. + В процессе работы над проектом важно соблюдать "правила гигены", + которыми мы часто пернебрегаем - рабочая машина должна быть защищена паролем, + жесткий диск или хотя бы каталог пользователя должен быть зашифрован (настраивается + во всех современных ОС), в macOS - FileVault, в Windows - BitLocker, в Linux - LUKS, + ecryptFS, encFS... Когда отходите от компьютера важно блокировать его (закрывать + крышку). Не стоит заряжать чужие телефоны и вставлять чужие флешки. Своевременно оновляйте + систему и ПО. Всегда стоит придерживаться правил и инструкций по безопасности компании, в + которой вы работаете - таким образом вы не только помогаете безопасникам, но и снимаете + с себя ответственность за утечки. Никогда не устанавливайте пиратское ПО - во-первых, + вы не можете быть уверены в чистоте кряка - в лучшем случае там может быть майнер, в + худшем - прикрепленный msfpayload. Если для работы нужна какая-то программа - + просите, чтобы вам предоставили лицензию. 5.2 Телефоны и свои устройства. - В некоторых компаниях может быть запрещено использовать телефон для рабочей - коммуникации. Это связано не с вредностью руководства компании, а с реальными угрозами - - телефон может быть утерян или украден, современные ОС не защищены от сбора информации сторонними - приложениями. Телефон должен быть зашифрован, установлен пароль на запуск. + В некоторых компаниях может быть запрещено использовать телефон для рабочей + коммуникации. Это связано не с вредностью руководства компании, а с реальными угрозами - + телефон может быть утерян или украден, современные ОС не защищены от сбора информации сторонними + приложениями. Телефон должен быть зашифрован, установлен пароль на запуск. 5.3 Коммуникация в команде - Важно понимать, какую рабочую информацию по каким каналам можно или нельзя передаввать. - При наличии корпоративного мессенджера вся рабочая коммуникация должна вестись через него. - Важно ограничить использоваение личных мессенджеров до минимума - "Выйди на связь, пожалуйста", - "Прочитай, что я тебе написал в Слаке", "Идем обедать?". В качестве корпоративного мессенджера - лучшем решением будет self-hosted, чуть худшим - арендованный платный мессенджер вроде Mattermost. - Категорически нельзя передавать в мессенджерах пароли и ключи, если это не предусмотрено политикой. + Важно понимать, какую рабочую информацию по каким каналам можно или нельзя передаввать. + При наличии корпоративного мессенджера вся рабочая коммуникация должна вестись через него. + Важно ограничить использоваение личных мессенджеров до минимума - "Выйди на связь, пожалуйста", + "Прочитай, что я тебе написал в Слаке", "Идем обедать?". В качестве корпоративного мессенджера + лучшем решением будет self-hosted, чуть худшим - арендованный платный мессенджер вроде Mattermost. + Категорически нельзя передавать в мессенджерах пароли и ключи, если это не предусмотрено политикой. 5.4 Пароли и ключи - Пароли не должны храниться в текстовом файле на рабочем столе и уж тем более не должны - передаваться по сети или храниться в git. Для хранения паролей можно использовать менеджер паролей, - наиболее распространенный и доверенный менеджер паролей - это KeePass и его реализации. Есть так же - вариантыы self-hosted облачных менеджеров паролей вроде Bitwarden. Для передачи - паролей следует использовать сервисы эфемерных сообщений и end-to-end-шифрование. Все используемые ключи - должны храниться и управляться в централизованных системах по типу HashiCorp Vault. - Важно использовать для SSH только ключи типа ECDSA, если используется Legacy то RSA максимально - возможной длины - 4096, ключи должны быть защищены паролем на машине пользователя. Для хранения - зашифрованной инфрмации в VCS должна использоватся криптография, будь то git-crypt, git-secrets или - ansible vault для DevOps. Передавать ключи для расшифровки таких вещей можно посредством Keybase.io, - PrivateBin и аналогов, в зависимости от политики компании. Следует также подумать о self-hosted решениях - вроде GitLab, Gitea, self-hosted PrivateBin. + Пароли не должны храниться в текстовом файле на рабочем столе и уж тем более не должны + передаваться по сети или храниться в git. Для хранения паролей можно использовать менеджер паролей, + наиболее распространенный и доверенный менеджер паролей - это KeePass и его реализации. Есть так же + вариантыы self-hosted облачных менеджеров паролей вроде Bitwarden. Для передачи + паролей следует использовать сервисы эфемерных сообщений и end-to-end-шифрование. Все используемые ключи + должны храниться и управляться в централизованных системах по типу HashiCorp Vault. + Важно использовать для SSH только ключи типа ECDSA, если используется Legacy то RSA максимально + возможной длины - 4096, ключи должны быть защищены паролем на машине пользователя. Для хранения + зашифрованной инфрмации в VCS должна использоватся криптография, будь то git-crypt, git-secrets или + ansible vault для DevOps. Передавать ключи для расшифровки таких вещей можно посредством Keybase.io, + PrivateBin и аналогов, в зависимости от политики компании. Следует также подумать о self-hosted решениях + вроде GitLab, Gitea, self-hosted PrivateBin. 5.5 Управление пакетами - В современных ОС, кроме Windows, используется система управления пакетами, которая позволяет - устанавливать и обновлять ПО - brew, apt, rpm и т. д.. Важно понимать, что всегда есть небольшой - риск компрометации пакетов. В Arch/Manjaro есть так же AUR, в который любой желающий может положить свой - скрипт сборки. Часто при управлении пакетами люди игнорируют правила безопасности. При установке ПО из - репозиториев системы важно обращать внимание на ошибки цифровых подписей (возможно компрометация), при - добавлении сторонних репозиториев - внимательно смотреть, правильно ли скопировался с экрана адрес, - обращать внимание на криптографические ключи. В случае установки с AUR - желательно глазами посмотреть, - что за сборочный скрипт и что он делает и откуда качает (как правило они небольшие). Хорошей практикой - может быть установка ПО с официального сайта в обход систем управления пакетами. В Windows ПО должно - устанавливаться только с официальных сайтов или доверенных зеркал. Никаких торрентов и форумов со сборками. -5.5.1 Python - https://res.cloudinary.com/snyk/image/upload/v1551550455/Python_Security_Best_Practices_Cheat_Sheet__rev.pdf - - Использовать Python 3, поскольку 2019 год - последний год поддержки Python 2. - - Испсользовать Pipenv для изоляции и управления пакетами. Не использовтаь устаревшие easy_install, не - менеджить пакеты глобально, не допускать путаницы в системе и понимать свой PATH. - - Сканировать свой код при помощи утилиты Bandit. Можно автоматизировать, интегрировав её с CI/CD - - Внимательно вводить import и имена пакетов при установке. - - Библиотека requests требует осторожного обращения. Обязательно использовать certifi, всегда - обновлять его до последней версии - - Форматирование строк - нужно быть внимательным. Необходимо экранировать и ограничить возможность иъекции - исполняемого кода. Обратить внимание на класс Template в string для ввода пользователя. - - Не использовать пакеты, у которых отсутствует лицензия - они могут быть скомпрометированы. - - Использовать pickle.load. Не десериализировать код из недоверенных источников по возможности - - Следить за уязвимостями - - Рекомендуемый ресурс: https://snyk.io - - Проверять сайты на безопасность при помощи https://www.ponycheckup.com/ - - Всегда использовать последние версии пакетов, особенно Django. - - Admin URL нужно поменять с /admin/ на что-нибудь друое + В современных ОС, кроме Windows, используется система управления пакетами, которая позволяет + устанавливать и обновлять ПО - brew, apt, rpm и т. д.. Важно понимать, что всегда есть небольшой + риск компрометации пакетов. В Arch/Manjaro есть так же AUR, в который любой желающий может положить свой + скрипт сборки. Часто при управлении пакетами люди игнорируют правила безопасности. При установке ПО из + репозиториев системы важно обращать внимание на ошибки цифровых подписей (возможно компрометация), при + добавлении сторонних репозиториев - внимательно смотреть, правильно ли скопировался с экрана адрес, + обращать внимание на криптографические ключи. В случае установки с AUR - желательно глазами посмотреть, + что за сборочный скрипт и что он делает и откуда качает (как правило они небольшие). Хорошей практикой + может быть установка ПО с официального сайта в обход систем управления пакетами. В Windows ПО должно + устанавливаться только с официальных сайтов или доверенных зеркал. Никаких торрентов и форумов со сборками. + 5.5.1 Python + https://res.cloudinary.com/snyk/image/upload/v1551550455/Python_Security_Best_Practices_Cheat_Sheet__rev.pdf + Использовать Python 3, поскольку 2019 год - последний год поддержки Python 2. + Испсользовать Pipenv для изоляции и управления пакетами. Не использовтаь устаревшие easy_install, не + менеджить пакеты глобально, не допускать путаницы в системе и понимать свой PATH. + Сканировать свой код при помощи утилиты Bandit. Можно автоматизировать, интегрировав её с CI/CD + Внимательно вводить import и имена пакетов при установке. + Библиотека requests требует осторожного обращения. Обязательно использовать certifi, всегда + обновлять его до последней версии + Форматирование строк - нужно быть внимательным. Необходимо экранировать и ограничить возможность иъекции + исполняемого кода. Обратить внимание на класс Template в string для ввода пользователя. + Не использовать пакеты, у которых отсутствует лицензия - они могут быть скомпрометированы. + Использовать pickle.load. Не десериализировать код из недоверенных источников по возможности + Следить за уязвимостями + Рекомендуемый ресурс: https://snyk.io + Проверять сайты на безопасность при помощи https://www.ponycheckup.com/ + Всегда использовать последние версии пакетов, особенно Django. + Admin URL нужно поменять с /admin/ на что-нибудь друое 5.5.2 NodeJS - https://github.com/goldbergyoni/nodebestpractices#6-security-best-practices - Для управления пакетами nodejs обычно используют npm, но ещё и nvm, а поверх зачастую и yarn. NPM - - сложная и нестабильная система, в которой зачастую приходится просто очищать папку node_modules. Чем - больше слоев абстракции, тем меньше контроля, меньше контроля - больше векторов для атак, важно найти - баланс, при котором комфортно работать, но контроль над зависимостями сохраняется. В NPM есть встроенные - средства для прокерки на наличие уязвимых зависимостей - при сборке пакетов он подсказывает, сколько - уязвимостей. Не стоит игнорировать эти сообщения - следует минимизирвоать их количество, насколько это - возможно. С NPM так же важно следить за PATH и понимать, что и откуда компилируется, какие зависимости - чем и как управляются. При наличии своих патчей их необходимо вовремя обновлять. - - Применять правила безопасности линтера. Используйте связанные с безопасностью плагины для линтеров, - такие как eslint-plugin-security, для выявления уязвимостей и проблем безопасности как можно раньше. Это - может помочь выявить слабые места безопасности, такие как использование eval, вызов дочернего процесса - или импорт модуля со строковым литералом (например, пользовательский ввод). - - Ограничение одновременных запросов с использованием промежуточного программного обеспечения. - DOS-атаки очень популярны и относительно просты в проведении. Внедрите ограничение скорости с помощью - внешней службы, такой как облачные балансировщики нагрузки, облачные брандмауэры, nginx, - rate-limiter-flexible или (для небольших и менее важных приложений) промежуточное программное обеспечение - с ограничением скорости (например, express-rate-limit) - - Предотвращение уязвимостей при внедрении запросов с помощью библиотек ORM / ODM.Чтобы предотвратить - внедрение SQL / NoSQL и другие злонамеренные атаки, всегда используйте ORM / ODM или библиотеку - базы данных, которая экранирует данные или поддерживает именованные или индексированные параметризованные запросы, - а также проверяет вводимые пользователем данные для ожидаемых типов. Никогда не используйте - строки шаблонов JavaScript или конкатенацию строк для ввода значений в запросы, поскольку это открывает - для вашего приложения широкий спектр уязвимостей. Все авторитетные библиотеки доступа к данным Node.js - (например, Sequelize, Knex, mongoose) имеют встроенную защиту от атак с использованием инъекций. - - Отрегулируйте заголовки ответа HTTP для повышения безопасности. Ваше приложение должно использовать - безопасные заголовки, чтобы предотвратить использование злоумышленниками распространенных атак, таких - как межсайтовый скриптинг (XSS), клик-джеккинг и другие злонамеренные атаки. Их можно легко настроить - с помощью таких модулей, как helm. - - Постоянно и автоматически проверять наличие уязвимых зависимостей. В экосистеме npm для проекта - характерно наличие множества зависимостей. Зависимости всегда следует - контролировать при обнаружении новых уязвимостей. Используйте такие инструменты, как npm audit или snyk, - чтобы отслеживать, отслеживать и исправлять уязвимые зависимости. - - Избегайте использования криптографической библиотеки Node.js для обработки паролей, используйте Bcrypt. - Пароли или секреты (ключи API) должны храниться с использованием безопасной [хеша с солью, - такой как bcrypt, которая должна быть предпочтительным выбором по сравнению с реализацией - JavaScript из-за соображений производительности и безопасности. - - Вывод HTML, JS, CSS должен экранироваться. Ненадежные данные, которые отправляются в браузер, могут - выполняться вместо того, чтобы просто отображаться - XSS - - Обязательная валидация схемы входящих JSON. Проверяйте содержимое тела входящих запросов и убедитесь, - что она соответствует схеме. Можно использовать облегченные схемы проверки на основе JSON, такие как - jsonschema или joi. - - Необходимо поддерживать черные списики JWT. При использовании веб-токенов JSON (например, с - Passport.js) по умолчанию отсутствует механизм для отзыва доступа к выданным токенам. - Как только вы обнаружите какое-либо злонамеренное действие пользователя, у вас не будет возможности - помешать получить хакеру доступ к системе, если у них есть действующий токен, поэтому необходимо иметь возможность - создания черных списков. - - Необходимо уделить внимание предотвращению атак типа bruteforce. Необходимо ограничить количество неудачных - попыток входа с одним логином или с одного IP. - - NodeJS никогда не должен запускаться от root. - - Необходимо ограничивать размер содержимого входящих данных, используя реверс-прокси или используя ПО посередине. - Чем больше запрос, тем дольше ваш отдельный поток обрабатывает его. Это возможность для злоумышленников поставить - серверы на колени без огромного количества запросов (атаки DOS / DDOS). Уменьшите это, ограничивая размер тела входящих - запросов (например, используя, межсетевой экран, ELB) или настраивая экспресс-анализатор тела для приема только - данных небольшого размера. - - Избегайте eval. eval - это зло, так как он позволяет выполнять пользовательский код JavaScript во время выполнения. - Это не только проблема производительности, но и важная проблема безопасности из-за вредоносного кода JavaScript, - который может быть получен из пользовательского ввода. Другой особенностью языка, которую следует избегать, - является конструктор new Function. setTimeout и setInterval также никогда не должны передавать динамический код JavaScript. - - Предотвратите зло RegEx от перегрузки вашего потока. Регулярные выражения, будучи удобными, представляют реальную угрозу - для приложений JavaScript в целом и платформы Node.js в частности. Пользовательский ввод для сопоставления текста - может потребовать значительного количества циклов ЦП для обработки. Обработка RegEx может быть неэффективной до такой - степени, что один запрос, который проверяет 10 слов, может заблокировать весь цикл событий на 6 секунд и вызвать - 100% загрузку ЦП. По этой причине предпочитайте сторонние пакеты валидации, такие как validator.js, вместо - написания собственных шаблонов регулярных выражений, или используйте safe-regex для обнаружения - уязвимых шаблонов регулярных выражений. - - Избегайте загрузки модуля с использованием переменной. Избегайте необходимости / импорта другого файла с - путем, указанным в качестве параметра, из-за опасений, что он мог возникнуть из-за ввода пользователя. - Это правило может быть расширено для доступа к файлам в целом (например, fs.readFile ()) или для доступа - к другим чувствительным ресурсам с помощью динамических переменных, происходящих из пользовательского - ввода. Линтер Eslint-plugin-security linter ловить такие шаблоны. - - Запускайте небезопасный код в песочнице. Когда задается задача запустить внешний код, который выдается - во время выполнения (например, плагин), используйте любую среду исполнения «песочницы», которая изолирует - и защищает основной код от плагина. Это может быть достигнуто с помощью выделенного процесса (например - , cluster.fork ()), безсерверной среды или выделенных пакетов npm, которые действуют как песочница. - - Будьте особенно осторожны при работе с дочерними процессами. Избегайте использования дочерних процессов, - когда это возможно, а также проваряйте валидацию входных данных, чтобы избежать атак с использованием shell injection, - если это необходимо. Используйте child_process.execFile, который по определению будет выполнять - только одну команду с набором атрибутов и не позволит расширять параметры оболочки. - - Скрывайте информацию об ошибках от клиента. Встроенный экспресс-обработчик ошибок по умолчанию скрывает - детали ошибок. Однако велики шансы на то, что вы реализуете свою собственную логику обработки ошибок с помощью - пользовательских объектов Error (которые многие считают наилучшей практикой). Если вы это сделаете, убедитесь, - что не вернули весь объект Error клиенту, который может содержать некоторые важные сведения о приложении. - Настроить 2FA для npm и yarn. - - Измените настройки промежуточного программного обеспечения сеанса. У каждого веб-фреймворка и технологии - есть свои известные недостатки - они сообщают злоумышленнику, какой фреймворк используется. Использование параметров - по умолчанию для промежуточного программного обеспечения сеансов может подвергнуть ваше приложение атакам, - направленным на модули и фреймворки, аналогично заголовку X-Powered-By. Попробуйте скрыть все, что идентифицирует - и раскрывает ваш софтверный стек. - - Избегайте DOS-атак, явно указав, когда процесс должен крашнуться. Процесс Node завершится сбоем, если ошибки - не будут обработаны. Многие лучшие практики даже рекомендуют выходить, даже если ошибка была обнаружена и обработана. - - Предотвращение небезопасных перенаправлений. Перенаправления, которые не проверяют пользовательский ввод, могут - позволить злоумышленникам запускать фишинговый код, красть учетные данные пользователя и выполнять другие вредоносные действия. - - Избегайте публикации кюлчей в npm registry. Следует принять меры предосторожности, чтобы избежать риска случайной - публикации секретов в репозиториях npm. Файл .npmignore может использоваться для внесения в черный список - определенных файлов или папок, или массив файлов в файле package.json может выступать в качестве белого списка. -5.5.3 PHP - https://www.cloudways.com/blog/php-security/ - - Обратить внимание на безопасность вашей CMS. Топ самых небезопасных CMS: WordPress, Joomla, Magento, Durpal. - - Обязательно обновить PHP до последней версии. Существуют утилиты, проверяющие код PHP на совместимость с последними - версиями, такие как PHP Compatibility Checker, PHP MAR, Phan. - - Для предотвращения атак типа XSS следует разобраться в htmlspecialchars, помнить про существование ENT_QUOTES, атрибуты, - кодирование схем URI, кодирование кода. - - Добавляйте слои защиты. Избыточность повышает безопасность. Добавляя больше - слоев, вы даете себе больше шансов поймать злонамеренный ввод, который может пробиться через первоначальную защиту. - - Используйте шаблоны Laravel Blade для автоматического экранирования. - - Используйте библиотеки для нормализации входящих данных: PHP HTML Purifier, .NET HTML Sanitizer, OWASP Java HTML Sanitizer, - Python Bleach. - - Используйте PHPUnit для проведения Unit-тестов - - Используйте Redis в качестве обработчика сессий PHP для предотвращения перехвата сессий - - Важно скрыть служебные файлы от браузера пользователя - - Установите лимит для загрузки файлов \ No newline at end of file + https://github.com/goldbergyoni/nodebestpractices#6-security-best-practices + Для управления пакетами nodejs обычно используют npm, но ещё и nvm, а поверх зачастую и yarn. NPM - + сложная и нестабильная система, в которой зачастую приходится просто очищать папку node_modules. Чем + больше слоев абстракции, тем меньше контроля, меньше контроля - больше векторов для атак, важно найти + баланс, при котором комфортно работать, но контроль над зависимостями сохраняется. В NPM есть встроенные + средства для прокерки на наличие уязвимых зависимостей - при сборке пакетов он подсказывает, сколько + уязвимостей. Не стоит игнорировать эти сообщения - следует минимизирвоать их количество, насколько это + возможно. С NPM так же важно следить за PATH и понимать, что и откуда компилируется, какие зависимости + чем и как управляются. При наличии своих патчей их необходимо вовремя обновлять. + Применять правила безопасности линтера. Используйте связанные с безопасностью плагины для линтеров, + такие как eslint-plugin-security, для выявления уязвимостей и проблем безопасности как можно раньше. Это + может помочь выявить слабые места безопасности, такие как использование eval, вызов дочернего процесса + или импорт модуля со строковым литералом (например, пользовательский ввод). + Ограничение одновременных запросов с использованием промежуточного программного обеспечения. + DOS-атаки очень популярны и относительно просты в проведении. Внедрите ограничение скорости с помощью + внешней службы, такой как облачные балансировщики нагрузки, облачные брандмауэры, nginx, + rate-limiter-flexible или (для небольших и менее важных приложений) промежуточное программное обеспечение + с ограничением скорости (например, express-rate-limit) + Предотвращение уязвимостей при внедрении запросов с помощью библиотек ORM / ODM.Чтобы предотвратить + внедрение SQL / NoSQL и другие злонамеренные атаки, всегда используйте ORM / ODM или библиотеку + базы данных, которая экранирует данные или поддерживает именованные или индексированные параметризованные запросы, + а также проверяет вводимые пользователем данные для ожидаемых типов. Никогда не используйте + строки шаблонов JavaScript или конкатенацию строк для ввода значений в запросы, поскольку это открывает + для вашего приложения широкий спектр уязвимостей. Все авторитетные библиотеки доступа к данным Node.js + (например, Sequelize, Knex, mongoose) имеют встроенную защиту от атак с использованием инъекций. + Отрегулируйте заголовки ответа HTTP для повышения безопасности. Ваше приложение должно использовать + безопасные заголовки, чтобы предотвратить использование злоумышленниками распространенных атак, таких + как межсайтовый скриптинг (XSS), клик-джеккинг и другие злонамеренные атаки. Их можно легко настроить + с помощью таких модулей, как helm. + Постоянно и автоматически проверять наличие уязвимых зависимостей. В экосистеме npm для проекта + характерно наличие множества зависимостей. Зависимости всегда следует + контролировать при обнаружении новых уязвимостей. Используйте такие инструменты, как npm audit или snyk, + чтобы отслеживать, отслеживать и исправлять уязвимые зависимости. + Избегайте использования криптографической библиотеки Node.js для обработки паролей, используйте Bcrypt. + Пароли или секреты (ключи API) должны храниться с использованием безопасной [хеша с солью, + такой как bcrypt, которая должна быть предпочтительным выбором по сравнению с реализацией + JavaScript из-за соображений производительности и безопасности. + Вывод HTML, JS, CSS должен экранироваться. Ненадежные данные, которые отправляются в браузер, могут + выполняться вместо того, чтобы просто отображаться - XSS + Обязательная валидация схемы входящих JSON. Проверяйте содержимое тела входящих запросов и убедитесь, + что она соответствует схеме. Можно использовать облегченные схемы проверки на основе JSON, такие как + jsonschema или joi. + Необходимо поддерживать черные списики JWT. При использовании веб-токенов JSON (например, с + Passport.js) по умолчанию отсутствует механизм для отзыва доступа к выданным токенам. + Как только вы обнаружите какое-либо злонамеренное действие пользователя, у вас не будет возможности + помешать получить хакеру доступ к системе, если у них есть действующий токен, поэтому необходимо иметь возможность + создания черных списков. + Необходимо уделить внимание предотвращению атак типа bruteforce. Необходимо ограничить количество неудачных + попыток входа с одним логином или с одного IP. + NodeJS никогда не должен запускаться от root. + Необходимо ограничивать размер содержимого входящих данных, используя реверс-прокси или используя ПО посередине. + Чем больше запрос, тем дольше ваш отдельный поток обрабатывает его. Это возможность для злоумышленников поставить + серверы на колени без огромного количества запросов (атаки DOS / DDOS). Уменьшите это, ограничивая размер тела входящих + запросов (например, используя, межсетевой экран, ELB) или настраивая экспресс-анализатор тела для приема только + данных небольшого размера. + Избегайте eval. eval - это зло, так как он позволяет выполнять пользовательский код JavaScript во время выполнения. + Это не только проблема производительности, но и важная проблема безопасности из-за вредоносного кода JavaScript, + который может быть получен из пользовательского ввода. Другой особенностью языка, которую следует избегать, + является конструктор new Function. setTimeout и setInterval также никогда не должны передавать динамический код JavaScript. + Предотвратите зло RegEx от перегрузки вашего потока. Регулярные выражения, будучи удобными, представляют реальную угрозу + для приложений JavaScript в целом и платформы Node.js в частности. Пользовательский ввод для сопоставления текста + может потребовать значительного количества циклов ЦП для обработки. Обработка RegEx может быть неэффективной до такой + степени, что один запрос, который проверяет 10 слов, может заблокировать весь цикл событий на 6 секунд и вызвать + 100% загрузку ЦП. По этой причине предпочитайте сторонние пакеты валидации, такие как validator.js, вместо + написания собственных шаблонов регулярных выражений, или используйте safe-regex для обнаружения + уязвимых шаблонов регулярных выражений. + Избегайте загрузки модуля с использованием переменной. Избегайте необходимости / импорта другого файла с + путем, указанным в качестве параметра, из-за опасений, что он мог возникнуть из-за ввода пользователя. + Это правило может быть расширено для доступа к файлам в целом (например, fs.readFile ()) или для доступа + к другим чувствительным ресурсам с помощью динамических переменных, происходящих из пользовательского + ввода. Линтер Eslint-plugin-security linter ловить такие шаблоны. + Запускайте небезопасный код в песочнице. Когда задается задача запустить внешний код, который выдается + во время выполнения (например, плагин), используйте любую среду исполнения «песочницы», которая изолирует + и защищает основной код от плагина. Это может быть достигнуто с помощью выделенного процесса (например + cluster.fork ()), безсерверной среды или выделенных пакетов npm, которые действуют как песочница. + Будьте особенно осторожны при работе с дочерними процессами. Избегайте использования дочерних процессов, + когда это возможно, а также проваряйте валидацию входных данных, чтобы избежать атак с использованием shell injection, + если это необходимо. Используйте child_process.execFile, который по определению будет выполнять + только одну команду с набором атрибутов и не позволит расширять параметры оболочки. + Скрывайте информацию об ошибках от клиента. Встроенный экспресс-обработчик ошибок по умолчанию скрывает + детали ошибок. Однако велики шансы на то, что вы реализуете свою собственную логику обработки ошибок с помощью + пользовательских объектов Error (которые многие считают наилучшей практикой). Если вы это сделаете, убедитесь, + что не вернули весь объект Error клиенту, который может содержать некоторые важные сведения о приложении. + Настроить 2FA для npm и yarn. + Измените настройки промежуточного программного обеспечения сеанса. У каждого веб-фреймворка и технологии + есть свои известные недостатки - они сообщают злоумышленнику, какой фреймворк используется. Использование параметров + по умолчанию для промежуточного программного обеспечения сеансов может подвергнуть ваше приложение атакам, + направленным на модули и фреймворки, аналогично заголовку X-Powered-By. Попробуйте скрыть все, что идентифицирует + и раскрывает ваш софтверный стек. + Избегайте DOS-атак, явно указав, когда процесс должен крашнуться. Процесс Node завершится сбоем, если ошибки + не будут обработаны. Многие лучшие практики даже рекомендуют выходить, даже если ошибка была обнаружена и обработана. + Предотвращение небезопасных перенаправлений. Перенаправления, которые не проверяют пользовательский ввод, могут + позволить злоумышленникам запускать фишинговый код, красть учетные данные пользователя и выполнять другие вредоносные действия. + Избегайте публикации кюлчей в npm registry. Следует принять меры предосторожности, чтобы избежать риска случайной + публикации секретов в репозиториях npm. Файл .npmignore может использоваться для внесения в черный список + определенных файлов или папок, или массив файлов в файле package.json может выступать в качестве белого списка. + 5.5.3 PHP + https://www.cloudways.com/blog/php-security/ + Обратить внимание на безопасность вашей CMS. Топ самых небезопасных CMS: WordPress, Joomla, Magento, Durpal. + Обязательно обновить PHP до последней версии. Существуют утилиты, проверяющие код PHP на совместимость с последними + версиями, такие как PHP Compatibility Checker, PHP MAR, Phan. + Для предотвращения атак типа XSS следует разобраться в htmlspecialchars, помнить про существование ENT_QUOTES, атрибуты, + кодирование схем URI, кодирование кода. + Добавляйте слои защиты. Избыточность повышает безопасность. Добавляя больше + слоев, вы даете себе больше шансов поймать злонамеренный ввод, который может пробиться через первоначальную защиту. + Используйте шаблоны Laravel Blade для автоматического экранирования. + Используйте библиотеки для нормализации входящих данных: PHP HTML Purifier, .NET HTML Sanitizer, OWASP Java HTML Sanitizer, + Python Bleach. + Используйте PHPUnit для проведения Unit-тестов + Используйте Redis в качестве обработчика сессий PHP для предотвращения перехвата сессий + Важно скрыть служебные файлы от браузера пользователя + Установите лимит для загрузки файлов \ No newline at end of file diff --git a/6. For administrators b/6. For administrators index 0fdf0ab..676ce37 100644 --- a/6. For administrators +++ b/6. For administrators @@ -1,34 +1,35 @@ -6.1 Docker +6.9 For adminnistrators + 6.1 Docker https://blog.aquasec.com/docker-security-best-practices - - Помните, что при использовании FROM наследуются все проблемы исходного имиджа - - Нельзя хардкодить credentials внутри имиджей - для управления такими вещами следует использовать + Помните, что при использовании FROM наследуются все проблемы исходного имиджа + Нельзя хардкодить credentials внутри имиджей - для управления такими вещами следует использовать соответствующие решения - - Следует помнить, что контейнеры - это не секьюрити-решение и все контейнеры и сам демон бегут + Следует помнить, что контейнеры - это не секьюрити-решение и все контейнеры и сам демон бегут от рута и соответственно, есть возможность повышения привилегий и выхода за пределы контейнера https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/ - хорошим вариантом будет настройка профиля AppArmor для защиты основной системы на уровне ядра. - - Обратите внимание на сложность и большое количество абстракций - - Проверяйте образы, скачанные с dockerhub, не доверяйте вслепую - - Ограничивайте доступные ресурсы для контейнеров - - Необходимо использовать SECCOMP для ограничения доступа - - Необходимо периодически мониторить активность конетйнеров - - Необходимы правила менеджмента жизненных циклов контейнеров - - Контейнеры должны находиться на отдельном разделе - - Необходима грамотная настройка сети для контейнеров - - legacy registry и Userland Proxy должен быть отключен - - В случае удаленного доступа необходимо использовать TLS для демона - - Включите логгирование на уровне хотя бы INFO - - Делайте HEALTHCHECK в контейнере - - Запретите setuid и setgid в образах - - COPY более безопасный, чем ADD - - По возможности не используйте привилегированные контейнеры - - Настройте container restart policy - - Используйте отдельный network namespace для контейнеров - - Не открывайте устройства с хоста напрямую в контейнер - - Проверьте настройки cgroups + Обратите внимание на сложность и большое количество абстракций + Проверяйте образы, скачанные с dockerhub, не доверяйте вслепую + Ограничивайте доступные ресурсы для контейнеров + Необходимо использовать SECCOMP для ограничения доступа + Необходимо периодически мониторить активность конетйнеров + Необходимы правила менеджмента жизненных циклов контейнеров + Контейнеры должны находиться на отдельном разделе + Необходима грамотная настройка сети для контейнеров + legacy registry и Userland Proxy должен быть отключен + В случае удаленного доступа необходимо использовать TLS для демона + Включите логгирование на уровне хотя бы INFO + Делайте HEALTHCHECK в контейнере + Запретите setuid и setgid в образах + COPY более безопасный, чем ADD + По возможности не используйте привилегированные контейнеры + Настройте container restart policy + Используйте отдельный network namespace для контейнеров + Не открывайте устройства с хоста напрямую в контейнер + Проверьте настройки cgroups -6.2 Kubernets - - K8s всегда должен быт обновлен до последней версии. Новые функции безопасности - а + 6.2 Kubernets + K8s всегда должен быт обновлен до последней версии. Новые функции безопасности - а не только исправления ошибок - добавляются в каждое ежеквартальное обновление, и чтобы воспользоваться ими, мы важно использовать последнюю стабильную версию. Самое лучшее, что можно сделать, - это запустить последнюю версию с самыми последними исправлениями, @@ -36,7 +37,7 @@ труднее по мере усложнения архитектуры кластера и при обновления возможны остановки подов и падения, поэтому планируйте обновление как минимум раз в квартал. Использование Kubernetes as a service может сделать обновление очень простым. - - Необходимо использовать RBAC. Контролируйте, кто может получить доступ к API Kubernetes и какие + Необходимо использовать RBAC. Контролируйте, кто может получить доступ к API Kubernetes и какие разрешения они имеют с помощью управления доступом на основе ролей (RBAC). RBAC обычно включается по умолчанию в Kubernetes 1.6 и более поздних версиях (позже для некоторых управляемых провайдеров), но если вы обновились с тех пор и не изменили свою конфигурацию, вам нужно будет дважды проверить @@ -51,31 +52,31 @@ им наименьший набор разрешений, необходимых для каждого сайта использования. Это лучше, чем предоставление слишком широких разрешений учетной записи по умолчанию для пространства имен. Большинству приложений вообще не нужен доступ к API; Для них можно установить «false» для automountServiceAccountToken. - - Выносите чувствительные процессы в отдельный namespace, чтобы ограничить потенциальное влияние компрометации. + Выносите чувствительные процессы в отдельный namespace, чтобы ограничить потенциальное влияние компрометации. Такой подход снижает риск доступа к чувствительному приложению через менее защищенное приложение, которое совместно использует среду выполнения контейнера или хост. Например, учетные данные Kubelet скомпрометированного узла обычно могут получить доступ к содержимому секретов, только если они используются подами, бегущими на данной ноде -- если поды с чувствительными секретами бегут на разных нодах кластера, у злоумышленника будет больше возможностей украсть их. - - Безопасно храните данные доступа. Чувствительные метаданные, такие как учетные данные администратора kubelet, + Безопасно храните данные доступа. Чувствительные метаданные, такие как учетные данные администратора kubelet, могут быть украдены или использованы не по назначению для повышения привилегий в кластере. Например, в недавнем раскрытии информации о багах Shopify подробно рассказывалось о том, как пользователь смог повысить привилегии, вызвав на микросервисе утечку информации из службы метаданных облачного провайдера. Функция сокрытия метаданных в GKE изменяет механизм развертывания кластера, чтобы избежать этого, рекомендуется использовать его до тех пор, пока он не будет заменен постоянным решением. Подобные контрмеры могут быть необходимы в других средах - - Создайте и настройте Network Policies. Сетевые политики позволяют вам контролировать доступ к сети внутрь и наружу для + Создайте и настройте Network Policies. Сетевые политики позволяют вам контролировать доступ к сети внутрь и наружу для ммикросервисов. Чтобы использовать их, вам необходимо убедиться, что у вас есть сетевой провайдер, который поддерживает этот ресурс; с некоторыми управляемыми провайдерами Kubernetes, такими как Google Kubernetes Engine (GKE), вам нужно будет вручную включить данную функциюю. (Для включения сетевых политик в GKE потребуется небольшое обновление, если кластер уже создан). После того, как это будет сделано, начните с некоторой базовой сетевые политики по умолчанию, например блокировка трафика из других пространств имен по умолчанию. - - Задайте Pod Security Policy для всего кластера. PSP устанавливает стандартные значения для микросервисов в кластере. + Задайте Pod Security Policy для всего кластера. PSP устанавливает стандартные значения для микросервисов в кластере. Подумайте об определении политики и включении Pod Security Policy - инструкции могут отличаться в зависимости от вашего облачного провайдера или модели развертывания. Для начала можно отключить NET_RAW, чтобы заблокировать определенные классы сетевых спуфинговых атак. - - Повысьте безопасность нод. Ограничте доступ к чувствительным портам, ткаим кака 10250 и 10255, минимизируйте + Повысьте безопасность нод. Ограничте доступ к чувствительным портам, ткаим кака 10250 и 10255, минимизируйте доступ к машинам. - - Включите журнал аудита. Многие облачные провайдеры предоставляют возможность настройк алертов при неудачных + Включите журнал аудита. Многие облачные провайдеры предоставляют возможность настройк алертов при неудачных попытках входа, желательно их влючить. - - Проведите бенчмарк. https://www.cisecurity.org/benchmark/kubernetes/ - - Даже если вы не используете Rancher, почитайте инструкцию по харденингу https://rancher.com/docs/rancher/v2.x/en/security/hardening-2.2/ + Проведите бенчмарк. https://www.cisecurity.org/benchmark/kubernetes/ + Даже если вы не используете Rancher, почитайте инструкцию по харденингу https://rancher.com/docs/rancher/v2.x/en/security/hardening-2.2/ и бенчмаркингу https://releases.rancher.com/documents/security/latest/Rancher_Benchmark_Assessment.pdf \ No newline at end of file