iy
/
MeetupStandup
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

formating

This commit is contained in:
IY 2019-09-11 19:31:35 +03:00
parent cfd56e9de4
commit 24b7d3291d
2 changed files with 209 additions and 208 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

348
5. For developers
View File

@ -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 для предотвращения перехвата сессий
- Важно скрыть служебные файлы от браузера пользователя
- Установите лимит для загрузки файлов
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 для предотвращения перехвата сессий
Важно скрыть служебные файлы от браузера пользователя
Установите лимит для загрузки файлов

69
6. For administrators
View File

@ -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