Пять вопросов, которые следует задать себе перед созданием веб-проекта

Есть миллион причин провала технологических проектов. Неправильно просчитанные бизнес-модели, завышенный спрос или растущие расходы – вот что вы называете. Но за свою профессиональную жизнь я видел немало проектов с блестящими идеями и хорошим потенциалом, которые терпели крах из-за, казалось бы, незначительных ошибок и оплошностей. И я думаю, что эта причина самая горькая из всех, по крайней мере для меня как разработчика. В этой статье я хочу поделиться своим опытом и проанализировать проблемы и задачи, с которыми сталкиваются бэкенд-разработчики, работая над веб-приложениями. Я выделю ключевые моменты, которые часто упускают из виду, и объясню, как устранить эти препятствия с максимальной эффективностью. Уверен, это поможет вам минимизировать риски и существенно повысить шансы вашего проекта на успех.

1. Хранятся ли в вашем коде какие-либо секреты?

Как бы очевидно это ни звучало, этот момент имеет решающее значение: никогда не храните конфиденциальную или чувствительную информацию в исходном коде. Нарушения могут привести к финансовым потерям и другим серьезным проблемам. Конфиденциальная информация, которую никогда не следует хранить в коде, включает в себя:

• Ключи API и токены доступа к внутренним или внешним сервисам
• Пароли и данные учетной записи, включая пароли базы данных и системы администратора.
• Ключи шифрования
• Файлы конфигурации с конфиденциальными данными
• Ответы на контрольные вопросы, такие как девичья фамилия матери или имя домашнего животного.

Вместо хранения такой информации в коде проекта используйте переменные среды. Для более безопасных систем рассмотрите возможность использования надежных решений для секретного хранения, таких как Хранилище ХашиКорп . Менеджер секретов AWS или Секреты GitHub тоже может быть полезно. Выбор инструментов секретного хранения зависит от таких факторов, как тип и размер проекта, опыт команды и стек технологий.

Если вы считаете, что хранение конфиденциальной информации в коде приложения не является серьезной проблемой, подумайте вот о чем: только в 2022 году GitHub обнаружил более 1,7 миллиона потенциальных секретов выставлены в публичных репозиториях. Представьте себе, сколько таких фрагментов данных может существовать в частных проектах, где разработчики не подозревают о потенциальных утечках, пока они не произойдут.

Решение: проверьте свой проект прямо сейчас

Если у вас уже есть проект и вы беспокоитесь о секретах в своем коде, есть удобные решения, которые принесут вам душевное спокойствие. Ручные проверки могут занять много времени, поэтому автоматизация имеет ключевое значение. Полезные инструменты включают в себя:

• ТрюфельСвинья : ищет секреты в репозиториях Git путем сканирования истории коммитов на предмет ключей API и других конфиденциальных данных.
• GitLeaks : Обнаруживает жестко закодированные секреты, такие как пароли, ключи API и токены, в репозиториях git.
• GitGuardian : работает в вашей локальной или CI-среде для поиска более 350 типов секретов и других уязвимостей безопасности.
• Расширенная безопасность GitHub : автоматически сканирует репозитории на предмет известных типов секретов и предупреждает вас, если таковые будут обнаружены.

Эти инструменты — лишь несколько примеров; другие популярные варианты включают в себя СонарКуб и Галочка . Оба предлагают платные и бесплатные решения для удовлетворения различных потребностей и бюджетов. Цель здесь не в том, чтобы перечислить все доступные инструменты, а в том, чтобы подчеркнуть существование этих проблем и потенциальных решений. Признание проблемы – это половина дела. Теперь важно выделить время для решения этой проблемы и выбрать подходящие инструменты для ваших нужд.

2. Что вы знаете о своих библиотечных лицензиях?

Удивительно, но эта тема редко обсуждается, а некоторые разработчики даже не подозревают, что использование сторонних решений может привести к юридическим проблемам и существенным проблемам для их компании. Не верите мне? Представьте себе такой сценарий: разработчик небольшой компании включает библиотеку, распространяемую под Стандартная общественная лицензия GNU Affero (AGPL) в коммерческом веб-продукте. В качестве лицензии с авторским левом AGPL требует, чтобы любое программное обеспечение, использующее код, выпущенный под ней, распространялось на тех же условиях. Это означает, что весь код вашего веб-приложения, включая уникальные разработки, должен быть открытым и доступным для бесплатного использования и модификации. Поскольку наш пример продукта является коммерческим, предоставление доступа к его исходному коду может серьезно подорвать конкурентное преимущество и бизнес-модель компании.

Серьезные проблемы также могут возникнуть в проектах, использующих библиотеки с лицензиями, которые явно запрещают коммерческое использование. И не становится лучше, если лицензии вообще нет: на самом деле отсутствие лицензии представляет собой существенную проблему, поскольку любой код по умолчанию защищен авторским правом. Лицензии дают пользователям право использовать код при определенных условиях, но без лицензии вообще нет юридических оснований для использования кода, даже если он общедоступен.

Стоит отметить, что вопросы лицензирования могут затронуть вас по-разному в зависимости от вашей юрисдикции: этот вопрос особенно актуален для стран, подписавших международные соглашения об авторском праве. Например, Бернская конвенция по охране литературных и художественных произведений, один из основных международных договоров в этой области, в настоящее время насчитывает около 180 стран-участниц. Таким образом, использование кода без явного разрешения будет означать нарушение закона об авторском праве и может привести к юридическим баталиям во многих местах по всему миру. Однако это не значит, что вам следует переехать в «комфортную» страну только для того, чтобы нарушить все писаные и неписаные правила. Давайте уважать друг друга, и если кто-то не хочет, чтобы его разработки использовались в определенных целях, лучше не делать этого, даже с человеческой точки зрения.

Решение: используйте автоматические проверки и обновления.

Как видите, вопросы лицензирования и авторских прав сложны. Чтобы заранее обезопасить себя и свою компанию, лучше всего проверить лицензии используемых вами библиотек и программного обеспечения. Для библиотек это не так уж сложно; современные пакетные менеджеры уже имеют для этого инструменты. Например, в PHP-композиторе это можно сделать с помощью команды ` лицензии композитора `, в Python pip через ` pip-лицензии `, а в Голанге вы можете получить эту информацию через ` лицензии `.

И не забывайте вызывать эти команды при обновлении зависимостей (еще лучше автоматизировать эти проверки), ведь в новых версиях лицензия подключаемой библиотеки может меняться.

3. Ограничен ли доступ к вашей разрабатываемой версии?

В веб-разработке обычно имеется несколько версий проекта, таких как разработка (dev), обеспечение качества (QA), подготовка и производство. Я часто сталкивался со сценариями, когда версии для разработки/QA и промежуточные версии сайта или веб-проекта были доступны любому пользователю в Интернете. Вызывает тревогу то, что тестовые версии иногда могут индексироваться поисковыми системами более эффективно, чем основная версия, что обычно вредит продукту.

Основная проблема здесь заключается в том, что тестовые версии могут содержать ошибки или конфиденциальную, возможно, даже компрометирующую информацию. Кроме того, бета-версии обычно более уязвимы для взлома, чем финальная версия. Это означает, что их доступность увеличивает риск получения злоумышленником доступа к конфиденциальным данным, внутреннему коду или даже самому серверу. Это особенно актуально, если вы разрабатываете серверную часть для чего-то вроде мобильного приложения, поскольку несанкционированный доступ к тестовым версиям API может быть чрезвычайно опасным.

Помимо угроз безопасности, дубликаты веб-страниц могут негативно повлиять на рейтинг в поисковых системах. Поисковые системы, такие как Google, могут рассматривать эти дубликаты как нежелательный контент, потенциально снижая рейтинг исходных страниц вашего проекта или даже полностью удаляя их из индекса.

Решение: Разработайте свою стратегию безопасности с самого начала.

Не экономьте на доменах. Если вам нужна тестовая версия, доступная онлайн, купите специально для нее отдельный домен. Эта простая, но эффективная мера снижает риски безопасности, поскольку злоумышленники обычно сначала проверяют субдомены. Размещение тестовой версии на любом поддомене основного ресурса делает ее легкой добычей.

Ограничить доступ ко всем тестовым версиям. Убедитесь, что версии для разработки, контроля качества, промежуточные версии и другие версии не являются общедоступными. Например, настройте их так, чтобы они были доступны только через VPN. Это снижает вероятность несанкционированного доступа, даже если тестовый домен станет известен злоумышленникам.

Защитите тестовые версии от индексирования. Даже если ваши тестовые версии доступны только через VPN и размещены на отдельных секретных доменах, защитите их от индексации поисковыми системами с помощью файла robots.txt или метатегов noindex. Этот шаг имеет решающее значение, поскольку поисковые системы иногда могут находить и индексировать эти страницы неожиданным образом.

4. Ваш настоящий IP-адрес скрыт? Неиспользуемые порты закрыты?

Существуют правила безопасности, которые многие разработчики склонны игнорировать, несмотря на то, что они критически важны и созданы на основе тяжело усвоенных уроков. Одно из таких правил — всегда скрывать реальный IP-адрес вашего проекта. Если IP-адрес ваших серверов можно определить по имени домена, это может привести к нескольким проблемам, таким как:

• DDoS-атаки. Зная реальный IP-адрес вашего проекта, злоумышленники могут запустить распределенную атаку типа «отказ в обслуживании» (DDoS) на ваш сервер. Например, Усиление отражения DNS Атака может перегрузить ваш сервер огромным объемом ответов от общедоступных DNS-серверов, что сделает ваш сервис недоступным для пользователей и приведет к значительным финансовым потерям.

  
  

• Выявление потенциальных уязвимостей. Серьезные хакеры, а не только любители, могут сканировать открытые порты и доступное в сети программное обеспечение, чтобы найти и использовать слабые места. Даже такие известные сервисы, как MongoDB, сталкивались с серьезными утечками данных из-за неправильной конфигурации. Многих из этих проблем можно было бы избежать, просто скрыв настоящий IP-адрес.

Решение: усложнить жизнь потенциальному злоумышленнику

Скрывая реальный IP-адрес вашего сервера, вы значительно усложняете атаку злоумышленников на вашу систему. Использование сети доставки контента (CDN) или служб защиты от DDoS может быть здесь очень эффективным. Популярные варианты включают в себя ОблакоВспышка , который бесплатно предлагает возможности CDN и защиту от DDoS, а также такие услуги, как Имперва (ранее Incapsula), предоставляющий аналогичные функции и Кратор , который специализируется на защите веб-приложений с помощью брандмауэра веб-приложений, но это может повлечь за собой дополнительные расходы.

Хотя эти инструменты могут значительно повысить безопасность, есть дополнительные соображения, которые следует учитывать:

• Утечка IP-адреса заголовка электронной почты. Если вы используете свой основной сервер для отправки электронных писем, реальный IP-адрес может быть раскрыт в заголовках электронных писем, что сведет на нет ваши усилия по обеспечению безопасности.

  
  

• История IP и запросы Whois: такие услуги, как История DNS или Whois-запрос может раскрыть исторические IP-адреса, связанные с доменом. Если ваш реальный IP-адрес когда-либо был привязан к вашему рабочему домену, вам следует его изменить.

  
  

• Защита от DDoS и конечные точки API. Будьте осторожны при использовании защиты от DDoS для доменов, выступающих в качестве конечных точек API. Системы защиты могут вводить этапы проверки пользователей, которые могут нарушить работу ваших клиентских приложений, заменяя ответы JSON/XML кодом HTML.

  
  

• Исходящие запросы API. Когда ваш сервер отправляет запросы к сторонним API, он может непреднамеренно раскрыть свой IP-адрес. Использование прокси-серверов для таких запросов может помочь, поскольку сменить прокси-сервер проще, чем бороться с последствиями атаки.

Важно помнить, что сокрытие реального IP-адреса вашего проекта не является панацеей. Закрытие портов, используемых вашим программным обеспечением, из внешней сети крайне важно везде, где это возможно. Изменение стандартных портов — спорная практика; некоторые эксперты утверждают, что это усложняет настройку без существенных преимуществ. Часто предпочтительнее настроить программное обеспечение для взаимодействия через сокеты Unix вместо сетевых TCP-соединений (если и ваш проект, и программное обеспечение работают на одном сервере). Такой подход не только увеличивает скорость взаимодействия, но и повышает безопасность, устраняя необходимость в открытых портах.

Для систем управления базами данных (СУБД) или других внутренних служб на отдельных серверах убедитесь, что доступ ограничен определенными IP-адресами, которые вы строго контролируете. Такая настройка предотвращает несанкционированный доступ к критически важным системам, добавляет дополнительный уровень безопасности и минимизирует риски внешних атак и утечек данных.

5. Обновляете ли вы зависимости проекта и программное обеспечение?

Этот совет довольно прост, но, опять же, его часто упускают из виду: регулярно обновляйте зависимости вашего проекта и серверное программное обеспечение. Устаревший и уязвимый код — мечта злоумышленников, которые могут легко его использовать.

Решение: автоматизируйте обновления.

Вам не нужно обновлять все вручную; многие инструменты автоматизации могут помочь. Например, Депендабот на GitHub автоматически обнаруживает устаревшие или уязвимые зависимости и предлагает обновления.

Автоматизация обновления сертификатов безопасности также имеет решающее значение. Если вы используете Давайте зашифруем сертификатов, вы можете автоматизировать их продление с помощью Сертбот . Сертификаты с истекшим сроком действия могут причинить настоящую боль, но автоматизировать их продление — простая задача.

\Тот же принцип применим и к серверному программному обеспечению. Если вы работаете с Linux, особенно с дистрибутивами на базе Debian/Ubuntu, Автоматические обновления легко справится с задачей. Для более крупных проектов с множеством серверов можно использовать такие инструменты, как Анзибль , Шеф-повар , Кукольный , или Соль доступны.

Последние мысли

Приведенные здесь советы — лишь малая часть того, что нужно помнить бэкэнд-разработчикам. Я решил выделить важные, но менее часто обсуждаемые темы по сравнению с распространенными, такими как SQL-инъекция или CSRF атаки.

Для более глубокого понимания безопасности веб-приложений рассмотрите возможность изучения Фонд OWASP , некоммерческая организация, предлагающая ценные ресурсы. Первая десятка OWASP В документе, доступном на их веб-сайте, перечислены наиболее распространенные и критические риски безопасности веб-приложений. Вы также найдете информацию о менее известных, но не менее опасных атаках.

Я считаю, что сообщество разработчиков должно быть одновременно знающим и готовым делиться идеями и опытом. Поэтому приглашаю всех поделиться своими наблюдениями и комментариями, которые ценны для всех, кто занимается backend-разработкой!