Python, NPM, PHP, Docker сделал, нужно вычитать и проверить

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

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

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. Вопросы и ответы.