Бип-бип!

Вы слышите звук будильника. Первое, что вы видите после пробуждения, это уведомление. Вся база пользователей вашего приложения ХХХ проникла в Darknet. По данным GDPR (да-да, этот стандарт теперь действует и в Украине), вы являетесь контроллером и владельцем данных, поэтому теперь вам грозит ряд штрафов и судебных слушаний. Совсем не весело. 

Вы просматриваете журналы своего просочившегося веб-приложения с кофе в руке. Вот что вы, скорее всего, увидите:

День 1: SQL-инъекции

SQL-инъекция (SQLi) является одним из наиболее распространенных механизмов веб-атак, используемых злоумышленниками для кражи из базы данных. Это риск № 1 в Топ-10 самых критических рисков безопасности веб-приложений OWASP.

SQLi происходит, когда код, введенный в SQL-запрос, притворяется нормальной частью данных, а затем интерпретируется и выполняется как команда. SQLi часто используются для кражи данных. Вредоносные команды могут быть скрыты внутри запросов SQL, NoSQL, OS и LDAP. Любой источник данных может быть использован для такого рода атак. Список команд SQL-инъекций по сути совпадает со списком команд базы данных, в том числе с потенциально катастрофическими, такими как DROP TABLE.

Как определить, является ли ваше веб-приложение потенциально уязвимым для SQL-инъекций? Ваш сервер может выполнять запросы SQL..

Помимо шуток, чтобы начать защищать свое приложение от SQLi, вам нужно использовать:

• Инструменты автоматического предотвращения SQL-инъекций (например, Sqlmap или jSQL Injection);
• Проверка ввода, чтобы убедиться, что данные разрешены, имеют правильный формат и этот запрос разрешен для доступа к указанной таблице.
• Подготовленные заявления и хранимые процедуры.

Подумайте об использовании брандмауэра веб-приложений (WAF) или брандмауэра SQL, который помогает отфильтровывать вредоносные данные. WAF работает на уровне приложений, а брандмауэр SQL работает ближе к базе данных (поэтому у него больше доступа к необработанным данным).

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

Брандмауэры SQL имеют ряд преимуществ по сравнению с брандмауэром WAF, но они сложнее в использовании и не так много (хороших) брандмауэров SQL. Например, существует брандмауэр Oracle SQL, который является строго частью пакета Oracle. Если вы посмотрите на открытый исходный код -  комплект защиты базы данных Acra имеет встроенный межсетевой экран SQL (AcraCensor), который поддерживает фильтрацию SQL-инъекций для PostgreSQL и MySQL.

Бип-бип!

Будильник будит тебя на следующее утро. Первое, что вы видите, это то, что ваша пользовательская база просочилась через ваше веб-приложение. Снова. Что могло пойти не так в этот раз? Вы все исправили вчера, верно? 

День 2: Привилегированный доступ к базе данных

Что позволило злоумышленнику получить доступ к базе данных на этот раз? Возможные причины могут заключаться в том, что вы сделали что-то из следующего:

1. Сохранили комбинацию логин/пароль по умолчанию
2. Оставили публичные поля или таблицы в базе данных
3. Оставили общедоступные файлы конфигурации (например, файлы .env)
4. Оставили учетные данные для доступа к вашему серверу или базе данных.

Оставление стандартных или даже общедоступных учетных данных является типичной ошибкой, которая приводит к огромным утечкам данных, и даже более крупные компании были признаны виновными в этом. По данным поисковой системы IoT Shodan , неверно сконфигурированные базы данных MongoDB на общую сумму 24 ТБ корпоративных данных открыли ее для любого. 

Файл .env, оставленный общедоступным в корневой папке - еще один косяк.

Чтобы избежать таких очевидных, но потенциально катастрофических ошибок в вашем веб-приложении, убедитесь, что у вас нет открытых учетных данных в базе кода. Использование инструментов сканирования с открытым исходным кодом, таких как Сlouseau, может помочь вам найти забытые учетные данные в репозитории и даже в git истории.

Другая мера предосторожности, которую следует предпринять, чтобы отвлечь потенциальных злоумышленников, состоит в том, чтобы изменить логин по умолчанию и пароль root для вашей базы данных, а также изменить URL-адрес по умолчанию страницы администратора на что-то менее очевидное (например, с «/admin » или «/root » по умолчанию на что-то другое), например «/opensesame »).

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

Все сделано на сегодня? Будем надеяться.

Бип-бип!

Будильник будит тебя. Еще один день, и ваше приложение все еще пропускает конфиденциальные данные. Отчаявшись, вы спрашиваете себя - что теперь делать? То же, что и вчера - исправляйте больше уязвимостей в вашем веб-приложении.

День 3: забытые резервные копии, журналы, дампы SQL

Раскрытие всей вашей базы данных (или ее полной резервной копии), хранящейся где-то в сети в виде открытого текста - катастрофа. Если кто-то найдет резервную копию файла базы данных на вашем сервере, игра окончена.

Тем не менее, многие утечки данных начинаются с резервных копий, хранящихся в незашифрованном виде, и забываются где-то на сервере, чтобы их могли взять. Это типичный недосмотр. Например, даже WhatsApp использовал облачные резервные копии в виде открытого текста  - если пользователи Android настраивают облачное резервное копирование, WhatsApp хранит все свои сообщения и вложенные файлы на Google Диске в виде открытого текста. Другим примером является ныне несуществующий канадский гаджет-ритейлер NCIX, в котором хранились данные незашифрованных финансовых транзакций и данные кредитных карт более чем полумиллиона человек.

Журналы - это еще одно место, где нужно искать открытую партию открытого кода. Это может показаться ошибкой новичка, но это все же произошло с Twitter и MacOS от Apple.

Атака SQL-дампов, которая часто запускается с помощью SQL-инъекции, описанной в «Дне 1», позволяет злоумышленнику захватить содержимое вашей базы данных или ее резервную копию. 

К счастью, существует множество готовых инструментов (например, Everything CLI и Mysqldump-secure ) для шифрования дампов SQL, или вы можете написать свой собственный скрипт с использованием криптобиблиотек с открытым исходным кодом.

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

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

Надежный современный способ заключается в том, чтобы зашифровать данные на веб-стороне сервера (таким образом, чтобы приложение не могло расшифровать данные), а также передать и сохранить их в зашифрованной базе данных. Для расшифровки данных необходим отдельный прокси; он гарантирует, что приложение имеет разрешение на чтение именно этого фрагмента данных, обеспечивает защиту от SQL-инъекций и расшифровывает данные.

Чувствуя себя немного разбитым, но гораздо умнее, вы засыпаете, обретя новое вдохновение, чтобы глубже погрузиться в захватывающий мир шифрования на следующий день.

Бип-бип!

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

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