diff --git a/5. For developers b/5. For developers new file mode 100644 index 0000000..025cae6 --- /dev/null +++ b/5. For developers @@ -0,0 +1,180 @@ +5.1 Рабочее место. + В процессе работы над проектом важно соблюдать "правила гигены", + которыми мы часто пернебрегаем - рабочая машина должна быть защищена паролем, + жесткий диск или хотя бы каталог пользователя должен быть зашифрован (настраивается + во всех современных ОС), в macOS - FileVault, в Windows - BitLocker, в Linux - LUKS, + ecryptFS, encFS... Когда отходите от компьютера важно блокировать его (закрывать + крышку). Не стоит заряжать чужие телефоны и вставлять чужие флешки. Своевременно оновляйте + систему и ПО. Всегда стоит придерживаться правил и инструкций по безопасности компании, в + которой вы работаете - таким образом вы не только помогаете безопасникам, но и снимаете + с себя ответственность за утечки. Никогда не устанавливайте пиратское ПО - во-первых, + вы не можете быть уверены в чистоте кряка - в лучшем случае там может быть майнер, в + худшем - прикрепленный msfpayload. Если для работы нужна какая-то программа - + просите, чтобы вам предоставили лицензию. +5.2 Телефоны и свои устройства. + В некоторых компаниях может быть запрещено использовать телефон для рабочей + коммуникации. Это связано не с вредностью руководства компании, а с реальными угрозами - + телефон может быть утерян или украден, современные ОС не защищены от сбора информации сторонними + приложениями. Телефон должен быть зашифрован, установлен пароль на запуск. +5.3 Коммуникация в команде + Важно понимать, какую рабочую информацию по каким каналам можно или нельзя передаввать. + При наличии корпоративного мессенджера вся рабочая коммуникация должна вестись через него. + Важно ограничить использоваение личных мессенджеров до минимума - "Выйди на связь, пожалуйста", + "Прочитай, что я тебе написал в Слаке", "Идем обедать?". В качестве корпоративного мессенджера + лучшем решением будет 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. +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/ на что-нибудь друое +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 diff --git a/6. For administrators b/6. For administrators new file mode 100644 index 0000000..9ad19c5 --- /dev/null +++ b/6. For administrators @@ -0,0 +1,28 @@ +6.1 Docker + https://blog.aquasec.com/docker-security-best-practices + - Помните, что при использовании 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 \ No newline at end of file diff --git a/Main.txt b/Main.txt index 7b06caf..b4a127e 100644 --- a/Main.txt +++ b/Main.txt @@ -30,8 +30,29 @@ 4.8 Cross-Site Request Forgery - 1.5 минуты 4.9 SQL Injection - 1.5 минуты 4.10 Insufficient Authorization - 1.5 минуты -5. Просто интересные факты - 8 минут - 5.1 +5. Безопасность для разработчика + 5.1 Рабочее место. Политика безопасности. Пиратское ПО + 5.2 Работа с телефона + 5.3 Коммуникация в команде + 5.4 Хранение паролей и кодов авторизации, передача паролей по сети. Хранение ключей. Хранение ключей в git. Системы для хранения ключей + 5.5 Package management и Security + 5.5.1 Управление пакетами в ОС + 5.5.2 Python - pip, easy_install, virtualenv + 5.5.3 NodeJS + 5.5.4 PHP +6. Безопасность для системного администратора + 6.1 Docker + 6.1.1 Эскалация привилегий и выход из контейнера + 6.1.2 Образы с dockerhub + 6.2 Kubernetes + 6.3 Bare-metal security + 6.3.1 SSH - ключи и fail2ban + 6.3.2 Firewall + 6.3.3 Эскалация привилегий + 6.4 Конфигурирование веб-серверов + 6.5 Реверс-прокси и CDN +7. Просто интересные факты - 8 минут + 6.1 ... - 5.n -6. Вопросы и ответы. + 6.n +8. Вопросы и ответы.