MeetupStandup/5. For developers

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