ИССЛЕДОВАНИЕ ЧУВСТВИТЕЛЬНЫХ ДАННЫХ, УЯЗВИМЫХ К АТАКЕ НА САЙТЕ ПРОДУКТА

XXIV Международный конкурс научно-исследовательских и творческих работ учащихся
Старт в науке

Личный портфель

ИССЛЕДОВАНИЕ ЧУВСТВИТЕЛЬНЫХ ДАННЫХ, УЯЗВИМЫХ К АТАКЕ НА САЙТЕ ПРОДУКТА

Елембаев-Беломорских Р.Е. 1
1МАОУ "ГИМНАЗИЯ №17" Г. ПЕРМИ
Петрова В.И. 1
1МАОУ "ГИМНАЗИЯ №17" Г. ПЕРМИ
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

ВВЕДЕНИЕ

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

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

Объект исследования: проектная деятельность по исследованию данных, уязвимых к атаке на сайте продукта.

Предмет исследования: исследование данных, уязвимых к атаке на сайте продукта.

Цель – обнаружение уязвимости и получение данных пользователя, достаточных для контроля аккаунта.

Задачи:

  1. Изучение видов кибератак

  2. Анализ сайта продукта на наличие потенциальных уязвимостей

  3. Анализ сайта продукта на наличие чувствительных данных

  4. Получение чувствительных данных через уязвимость

  5. Оценка результата

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

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

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ АТАК НА ВЕБ-СИСТЕМЫ

1.1 Отказ в обслуживании (Dos, DDoS-атаки)

Denial of Service, или «Отказ в обслуживании», — это перегрузка информационной системы, в которой работает сервисы, с помощью сетевых запросов. При этом сами запросы на сетевом уровне осуществляются с одного компьютера и нацелены на конкретный виртуальный сервер или домен.

DDoS-атаки приводят к простоям, из-за которых компании несут материальные и нематериальные издержки. Например, если из-за перегрузки нелегитимным трафиком интернет-магазин становится недоступен, компания теряет деньги, которые потенциально можно был заработать на продажах. А также — тратит средства на восстановление систем.

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

Как правило, жертвами крупных DDoS атак становятся:

  • Корпорации и государственные учреждения: агрегаторы (маркетплейсы), сайты крупных компаний, отраслевых министерств и др.

  • Финансовые учреждения: сайты и серверы, порталы банков, бирж, управляющих и инвестиционных компаний.

  • Медицинские учреждения: больницы, медицинские центры и пр.

  • IoT устройства: онлайн-кассы, системы «Умный дом» и пр.

1.2 Межсайтовый скриптинг (XSS)

Межсайтовый скриптинг (XSS), атака с использованием межсайтовых сценариев – атака, при которой злоумышленник загружает в базу данных веб-сайта вредоносный клиентский код (скрипт JavaScripts, реже HTML, VBScript, ActiveX, Flash). Атаки XSS разделяют на три категории: сохраненные (постоянные), отраженные (непостоянные), основанные на DOM.

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

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

Благодаря успешной атаке, злоумышленник может:

  • похитить конфиденциальные данные пользователя: историю посещений, информацию по платежным картам, личную переписку и т.д.;

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

  • получить авторизационные данные любого зарегистрированного на сайте пользователя;

  • разместить на ресурсе посторонний, противозаконный или компрометирующий контент, внести изменения в уже имеющееся содержание (пресс-релизы, статьи, описания товаров и т.д.);

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

1.3 Атака с использованием SQL-инъекции

SQL (Structured Query Language) — это язык прог­рамми­рова­ния, который поч­ти пов­семес­тно исполь­зует­ся для работы с базами дан­ных. В час­тнос­ти, он при­гож­дает­ся при раз­работ­ке сай­тов. Давай пос­мотрим, как выг­лядит типич­ный сце­нарий его при­мене­ния.

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

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

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

Таким образом, механизм атаки с использованием SQL injection построен на незнании или игнорировании разработчиками простых правил безопасности при создании приложений. Для предотвращения таких угроз, важно тщательно проверять и обрабатывать все данные, вводимые пользователями, используя параметризованные запросы и другие методы защиты от внедрения вредоносного кода.

Последствия:

  • Кража данных и конфиденциальной информации: Злоумышленник может получить доступ к личным данным пользователей, финансовой информации и другим чувствительным сведениям. Это может привести к потерям, как для самих пользователей, так и для компании.

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

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

  • Падение репутации: Образ компании становится негативным, когда клиенты узнают о хищениях данных или других последствиях уязвимостей. Это может привести к утрате доверия и снижению клиентской базы.

  • Юридические последствия: в зависимости от законодательства, компания может столкнуться с серьёзными юридическими последствиями, если будет доказано, что она не предприняла надлежащих мер для защиты данных.

Выводы по главе 1:Проанализировав данные о веб-атаках, межсайтовый сприптинг(xss) оказался самым простым для эмуляции, вторым по сложности была атака с использованием sql-инъекции. Xss использует вредоносный код на javascript и базируется на DOM-модели, что делает её наиболее понятной и возможной для реализации.

ГЛАВА 2. Исследование чувствительных данных, уязвимых к атаке

2.1 Структура запросов

Простой пример запроса:

Рис.1. Строение GET запроса

В первой строчке указаны метод запроса — GET, путь к ресурсу — /path и версия протокола —  HTTP/1.0.

Далее идёт блок заголовков. Заголовки — это пары ключ: значение, каждая из которых записывается с новой строки и разделяется двоеточием. Они передают дополнительные данные и настройки от клиента к серверу и обратно. 

HTTP — это текстовый протокол, поэтому и все данные передаются в виде текста. Заголовки можно отделить друг от друга только переносом строки. Нельзя использовать запятые, точку с запятой, или другие разделители. Всё, что идет после имени заголовка с двоеточием и до переноса строки, будет считаться значением заголовка.

Последствия:

  • Content-Type — стандартный заголовок. Показывает, в каком формате будут передаваться данные в теле запроса или ответа.

  • Content-Length — сообщает длину контента в теле запроса в байтах.

  • X-Custom-Header — пользовательские заголовки, начинающиеся с произвольными именем. Через них реализуется специфическая логика обработки для конкретного сервера. Если веб-сервер не поддерживает такие заголовки, то он проигнорирует их.

Клиенту зачастую недостаточно просто отправить запрос на сервер. Во многих случаях надо дождаться ответа и понять, как сервер обработал запрос. Для этого были придуманы статусы ответов. Это трёхзначные числовые коды с небольшими текстовыми обозначениями. Их можно увидеть в терминале или браузере. Сами коды делятся на 5 классов:

  • Информационные ответы: коды 100–199

  • Успешные ответы: коды 200–299

  • Редиректы: коды 300–399

  • Клиентские ошибки: коды 400–499

  • Серверные ошибки: коды 500–599

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

Данные на сервер можно передавать через тело запроса и через так называемую строку запроса Query String(query-параметры). Это параметры формата ключ=значение, которые располагаются в пути к ресурсу:

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

Рис.1. Пример GET запроса с параметрами

Приведу пример GET запроса с использованием query-параметра на сайте продукта. Здесь использовалось два параметра, а именно ‘type’ и ‘subject’. Меняющимся был параметр ‘subject’, отвечающий за сортировку по выбранному предмету.

Рис.2. GET запрос с параметрами на сайте продукта

2.2 Анализ сайта продукта на наличие уязвимостей

Если значение в параметре меняется – то, возможно, оно уязвимо к атакам. Существуют разные типы атак через query-параметр, например: open-redirect, внедрение sql, xss, засорение параметров и т.д. Первым делом я решил посмотреть реакцию на xss атаку.

По популярности она занимает 4 место и фиксировалась в более, чем 58% систем.

Рис.3. Рейтинг популярных веб-атак

Существует три типа xss (по вектору):

  1. Отражённые (непостоянные)

  2. Хранимые (постоянные)

  3. DOM-модели

Первым делом я решил посмотреть, встречается ли значение ‘1038’ в исходном html коде. Это значение было в 4 тегах, и я решил приписать к query-параметру дополнительные кавычки и символ закрывающегося тега.

Рис.4. Значение query-параметра в теге исходного кода

По результатам проверки в двух из четырех тегах моя приписка экранировалась, а в двух других считалась как html код. Далее я решил добавить новое событие ‘onmouseover’ и при его выполнении выполнять javascript код ‘alert(1)’.

При наведении на тег, в котором содержался query-параметр, срабатывал javascript код, выводящий диалоговое окно на экран.

Рис.5. Значение query-параметра в теге исходного кода

Чтобы javascipt код выполнился при наведении курсора на любую часть страницы, а не только туда, где есть уязвимый тег – можно увеличить размер тега до размеров экрана, прописав дополнительный стиль css: “width:100vw, height:100wh, position:absolute, top:0, left:0”.

Наличие xss уязвимости подтверждено, значит можно попробовать отправить GET запрос на страницу личного кабинета и получить ответ. Запрос был успешен (код 200), удалось получить страницу личного кабинета пользователя в формате текста html разметки.

Рис.6. Получение ответа на запрос к личному кабинету

В коде полученной страницы (из body) были получены следующие данные о пользователе:

  • Фамилия, имя, отчество

  • Ссылка на фото

  • Email (при наличии)

  • Город

  • Секретный ключ

Если email отсутствует – его можно добавить через дополнительный запрос, а затем навсегда привязать к аккаунту пользователя, поскольку после его активации смена становится недоступна.

Рис.7. Привязка почты к акканту

При дальнейшем изучении страниц на сайте я заметил, что на странице со сменой пароля при его изменении старый пароль не требуется. Следовательно, его можно поменять через POST запрос, прописываемый в query-параметре.

Рис.8. Страница смены пароля

2.3 Получение данных, используя сайт-песочницу

Остаётся лишь получить значение почты пользователя через запрос на сайт-песочницу. Но возникает проблема - CORS не даёт этого сделать.

CORS (Cross-Origin Resource Sharing) — это система, которая позволяет обойти это ограничение под строгими условиями. Это не какой-то дополнительный программный продукт или плагин, а стандарт, который реализуют сервер и браузер для безопасного выполнения запросов к разным доменам.

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

  1. Вместо запроса fetch на сайт-песочницу я создал тег img

  2. С помощью функции concat объединил src сайта-песочницы и полученный emal

  3. Указал в атрибуте src нового тега img указал сформированную ссылку

  4. Добавил тег на сраницу при загрузке

Рис.9. Значение почты на сайте-песочнице

Осталось собрать URL запрос воедино, соединив все ранее созданные запросы. URL принял следующий вид:

  1. На первом месте закрывающие кавычки “

  2. Fetch на изменение почты

  3. Fetch на получение данных

  4. Fetch на смену пароля

  5. Fetch (через тег img) на отправку значения почны на сайт песочницу

  6. Sltyle css для растяжения тега A на весь экран

  7. Закрывающий тег >

Далее я совместил куски запросов воедино и получился итоговый параметр ‘subject’, который отправлялся в GET запросе. Получилась итоговая ссылка злоумышленника, при нажатии на которую жертва бы теряла полный доступ к аккаунту.

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

Рис.10. Строение конечного url

Для входа в аккаунт требуется email или логин и пароль. Я выяснил, что получить почту пользователя или установить свою возможно, как и поменять изменить пароль на другой. Гипотеза подтвердилась.

Рис.11. Страница входа на сайте продукта

ЗАКЛЮЧЕНИЕ

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

Поставленная цель – обнаружение уязвимости и получение данных пользователя, достаточных для контроля аккаунта достигнута.

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Курсы углубленного платного обучения языкам программирования Фреймворкам. [Электронный ресурс] – URL: https://www.udemy.com/

2. Сайт о программировании на C#, .NET, Java, Python, Golang, Dart, Flutter, мобильной разработке на Android, iOS, Xamarin, веб-разработке на ASP.NET, PHP и JavaScript, Node.js и React. [Электронный ресурс] – URL: https://metanit.com/

3. Сайт для публикации аналитических статей и мыслей, связанных с информационными технологиями [Электронный ресурс] – URL: https://habr.com/

4. Система вопросов и ответов о программировании [Электронный ресурс] – URL: https://stackoverflow.com/

Просмотров работы: 252