Рубрики
Без рубрики

Как взломать незащищенное веб-приложение

Несколько советов, как разработать приложение, если вы хотите, чтобы вас взломали ;). Помеченный как безопасность, java.

В этой статье я хотел бы продемонстрировать, как легко получить конфиденциальную информацию из веб-приложения, которое… ну, не уделяет слишком много внимания безопасности. То, с чем я буду работать, – это образец Java-приложения, которое я создал в Spring Boot для демонстрационных целей. Но выполненные атаки действительны для любого другого языка программирования или фреймворка. Некоторые уязвимости и проблемы безопасности, которые будут продемонстрированы, включают:

Установка

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

Вы можете найти исходные тексты этого приложения в моем Github: https://github.com/rapasoft/hackme .

Атака №1: Человек в середине атаки

Представьте, что вы сидите в ресторане и хотели бы что-то проверить в приведенном выше приложении. Вы подключаетесь к Wi-Fi ресторана, открываете страницу входа в систему, вводите учетные данные и получаете нужную информацию (например, список конкретных сотрудников). Чего вы, возможно, сейчас не знаете, так это того, что ваши учетные данные были скомпрометированы. Давайте внимательно изучим страницу входа в систему:

Это приложение не использует SSL/TLS (например, нет https:// соединения). Это означает, что любая отправленная информация может быть просмотрена в виде обычного текста любым пользователем, имеющим доступ к связи между клиентом и сервером.

Это именно то, что происходит в так называемой атаке “Человек посередине” . Более конкретно, в этом случае ARP-подмена использовалась как способ отравления всей сети, чтобы злоумышленник знал обо всем, что происходит, и мог прослушивать все пакеты. Я не собираюсь вдаваться в подробности того, как работает ARP-подмена, но продемонстрирую это в этом видео:

Возможно, вам придется открыть это видео на Youtube в новом окне и на весь экран, чтобы увидеть более подробную информацию

Что вы можете видеть выше, так это то, что я запустил Ettercap , который представляет собой комплексный набор для атак MITM, и выполнил ARP-подмену в моей локальной сети. В то же время, когда пользователь (я через iPad) вводит учетные данные, они видны как в Ettercap, так и в Wireshark (инструмент для анализа сетевого трафика).

Атака №2: SQL-инъекция

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

Мы входим в систему, используя указанные выше учетные данные, и видим одно поле ввода с возможностью поиска по списку людей. При нажатии Поиск мы получим полный список людей. Если мы введем, например, “Fra”, мы получим отфильтрованные результаты на основе поиска. Что, если мы поместим туда какого-нибудь незаконного персонажа? Очевидно, что за этим приложением стоит какая-то база данных, поэтому давайте попробуем использовать символ ' :

Это не только провалилось, но мы видим, что Запрос POST завершился ошибкой с очень специфическим сообщением об ошибке, которое раскрывает структуру всего SQL-оператора. Мы можем видеть, что ГДЕ P.NAME КАК '%'%' используется в конце.

Опытному хакеру большего и не нужно. Настройка строки поиска может после нескольких попыток привести к таким результатам:

Инъекция в этом случае создала оператор union to select, который извлекает имена пользователей и пароли вместе с их ролью. Мало того, что это было успешно, нам удалось отобразить его в исходном клиентском приложении.

Теперь у нас есть учетные данные всех пользователей и их роли (отображаются целым числом в столбце “Возраст”). Если frame имеет роль 1, следовательно, r должен быть более важным пользователем с ролью 3.

Атака №3: Атака на слабо хэшированные пароли

Во время первой атаки мы узнали, что, вероятно, для этого приложения не установлена какая-либо политика паролей. Это дало бы нам надежду на то, что graves также не уделяет слишком много внимания безопасности.

Самый простой способ взломать хэш пароля, который использует недостаточный алгоритм хеширования (например, MD5 в данном случае), – это выполнить dictionary или радужный стол атака. Есть много возможностей, но самая простая из них – использовать интернет-сервисы , которые уже имеют большую базу данных комбинаций пароля и хэша:

Первый из них – frame , , второй - rgraves .

Вы можете видеть, что пароль для graves – это swordfish , а это значит, что он сейчас не понимает, насколько важно выбирать пароль без словаря ;). Теперь ничто не мешает нам войти в систему под именем этого пользователя и открыть раздел “администратор” и конфиденциальную информацию:

Не читайте это, если вы немец:)

Как это исправить?

Вы могли бы сказать, что все это можно было бы легко предотвратить. Вы могли бы сказать, что это были ошибки новичков . Что ж, это может быть правдой, но верно и то, что Проект безопасности открытых веб-приложений списки Инъекция как уязвимость № 1 в веб-приложениях (и так было уже несколько лет).

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

  • Всегда используйте SSL/TLS при отправке чего-либо на сервер . Это не обязательно должны быть учетные данные, в настоящее время это считается хорошей практикой в целом. Даже если у вас вообще нет никаких входных данных на вашей странице! Самый простой способ – предоставить сертификат с помощью таких сервисов, как Давайте зашифруем .
  • Помните, что самозаверяющие сертификаты могут смягчить проблему раскрытия данных, но не мешают злоумышленнику MITM полностью подделать весь сайт с помощью своего собственного самозаверяющего сертификата.
  • При работе с SQL-запросами всегда экранируйте параметры, полученные от клиента . Самый простой способ сделать это – использовать возможности вашего фреймворка, например, в Spring вы можете использовать NamedParameterJdbcTemplate , что также хорошо для удобства чтения.
  • Будь параноиком. Проверяйте любой пользовательский ввод. Опять же, в Java/Spring world вы можете добавить правила проверки, используя JSR-380 реализацию проверки bean, например Спящий режим проверки и аннотировать параметры, например @Pattern(регулярное выражение) Имя строки предотвратило бы ввод ' .
  • Регистрируйте любые попытки ввести неверный ввод в приложении. Более того, в случае ошибки не предоставляйте клиенту никакой информации, относящейся к конкретной реализации .
  • Улучшите свою аутентификацию.
    • Если возможно, используйте по крайней мере 2-факторную аутентификацию .
    • Не используйте пользовательские алгоритмы хранения паролей или шифрования. Это чрезвычайно трудно сделать самостоятельно, и вы обязательно потерпите неудачу. Существуют проверенные решения, такие как BCrypt .
  • Читайте и добавляйте в закладки ТОП-10 OWASP . Начните с этого, а затем просмотрите их список лучших практик.

Я надеюсь, что вы нашли эту статью не только информативной, но и занимательной. С нетерпением ждем ваших комментариев!

Оригинал: “https://dev.to/rapasoft/how-to-hack-unsecure-web-application-371c”

Читайте ещё по теме: