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