D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Авторство: hackeryaroslav
Источник: xss.is
Функциональные возможности веб-сайта
Полноценный веб-сайт состоит из множества функциональных элементов, которые работают вместе. Обеспечение безопасности каждой функциональности требует отдельной проверки на наличие потенциальных уязвимостей. Уязвимости представляют собой слабые места, которые могут привести к пагубным последствиям. После тестирования каждой функциональности в отдельности необходимо оценить уязвимости безопасности, возникающие при взаимодействии нескольких функциональных возможностей. Этот процесс комплексного тестирования будет значительно более управляемым, если начать его на ранних этапах разработки. При создании веб-сайта очень важно учитывать потенциальные уязвимости, связанные с планируемой реализацией.
В этой статье представлены два ключевых функционала сайта: вход в систему и написание отзывов.
Вход в систему
Возможность создания учетной записи для последующего входа в систему является основополагающей особенностью любого веб-сайта. Функциональность входа в систему в основном состоит из двух частей. Во-первых, это пользовательский интерфейс, который обычно включает поля ввода имени пользователя/электронной почты и пароля. Этот аспект функциональности часто подвержен таким атакам, как SQL-инъекции . Вторая часть включает в себя хранение информации для входа в базу данных, которая может быть уязвима для атак, использующих слабые места в криптографии, такие как радужные таблицы. В данной статье основное внимание уделяется уязвимости пользовательского интерфейса к потенциальным атакам.
Перед тем как начнем...
SQL-инъекции, также известные как SQLI, - это распространенный вектор атаки, использующий вредоносный SQL-код для манипуляций с базой данных на внутреннем уровне, чтобы получить доступ к информации, которая не предназначалась для отображения.
Подделка межсайтовых запросов (CSRF) - это атака, которая заставляет аутентифицированных пользователей отправлять запрос в веб-приложение, против которого они в данный момент аутентифицированы. CSRF-атаки используют доверие веб-приложения к аутентифицированному пользователю.
Методология
Тут представлена реализация функциональности входа в систему. В нем также представлены атаки SQL-инъекций, направленные на функциональность входа в систему, а также соответствующие контрмеры. Кроме того, описывается реализация функциональности обзора, включая инициирование CSRF-атаки и использование сканирования ввода на стороне клиента в качестве контрмеры.
Реализация функциональности входа в систему
Для изучения различных механизмов защиты от атак SQL-инъекций был создан минималистичный веб-сайт. На сайте была размещена форма с двумя полями ввода: одно для имени пользователя, другое для пароля. Для этого использовались PHP, HTML и подключение к базе данных MySQL через XAMPP. База данных содержала одну таблицу с информацией о входе для одного пользователя.
Для установки соединения с базой данных использовался следующий PHP-код:
PHP: Скопировать в буфер обмена
Код:
<?php
$host = "localhost";
$username = "root";
$password = "";
$db = "logindb";
$con = mysqli_connect($host, $username, $password, $db);
Для создания формы входа в систему был использован следующий PHP-код:
HTML: Скопировать в буфер обмена
Код:
<html>
<body>
<form action="logincheck.php" method="POST">
username: <input type="text" name="username"><br>
password: <input type="password" name="password"><br>
<input type="submit" name="submit">
</form>
</body>
</html>
PHP: Скопировать в буфер обмена
Код:
<?php
// включить подключение к базе данных
include_once 'includes/dbh.php';
// Получение входных данных пользователя
$uname_input = $_POST["username"];
$pword_input = $_POST["password"];
// SQL-запрос для поиска совпадающих учетных данных
$sql = "SELECT * FROM users WHERE username =
'$uname_input' AND password = '$pword_input';";
$result = mysqli_query($con, $sql);
$resultcheck = mysqli_num_rows($result);
if($resultcheck > 0){ // строка с совпадающими учетными данными
echo 'Вход принят';
}else{
echo 'Неверное имя пользователя или пароль';
}
Этот код получает данные от пользователя и создает SQL-запрос с введенными значениями. Затем он проверяет, нашел ли запрос совпадение или нет, и выводит результат на экран. В реальном сценарии пользователь должен пройти аутентификацию и войти в систему. SQL - это подъязык данных, используемый для доступа к реляционным базам данных, управляемым системами управления реляционными базами данных (СУБД). При вводе значений в два поля ввода формы входа в систему SQL используется для поиска введенных учетных данных в базе данных. Однако данная реализация уязвима для атак SQL-инъекций, что делает ее примером того, как не следует проводить проверку логина.
Для тестирования в базу данных была вставлена одна таблица, содержащая одного пользователя с именем пользователя "user1" и паролем "password123". После ввода правильной информации для входа в систему выдается "Вход принят" . После ввода любых других учетных данных появляется сообщение "Неверное имя пользователя или пароль".
SQL-запрос
SQL-запрос - это запрос, отправляемый в базу данных для манипулирования или получения данных [12]. Когда пользователь пытается войти в систему, в базу данных отправляется запрос для поиска подходящего имени пользователя и пароля. Примером запроса для функции входа в систему может быть:
PHP: Скопировать в буфер обмена
Код:
SELECT * FROM Users WHERE username = ’$_POST["username"]’
AND password = ’$_POST["password"]’
PHP: Скопировать в буфер обмена
’$_POST["username"]
и
PHP: Скопировать в буфер обмена
’$_POST["password"]
Имя пользователя и пароль, введенные пользователем, вставляются в запрос с помощью $_POST. Запрос выбирает все столбцы из таблицы с именем Users и фильтрует записи на основе введенных учетных данных. Если имя пользователя и пароль совпадают, пользователь входит в систему. Хотя SQL-запросы могут быть более сложными, основная идея атак с использованием SQL-инъекций остается прежней.
Атаки SQL-инъекций направлены на поля ввода, используемые в SQL-запросах, что делает функции входа в систему уязвимыми для таких атак. Эти атаки предполагают внедрение SQL-запросов или их частей через пользовательский ввод, что позволяет воспринимать вводимые данные как SQL-код. В зависимости от целей атакующего это может привести к серьезному ущербу - от отсутствия последствий до очень серьезных последствий. Если аутентификация не проходит, атакующий может получить несанкционированный доступ к конфиденциальной информации о пользователе, хранящейся в базе данных, и, возможно, получить дополнительные привилегии. Например, успешный вход в систему в качестве администратора.
Атака 1 - обход аутентификации
В рамках первой атаки осуществляется вход в систему, подставляя имя другого пользователя, которое известно. Для успешного взлома необходимо пройти две проверки:
PHP: Скопировать в буфер обмена
Код:
$username = '$_POST["username"]';
$password = '$_POST["password"]';
Обычно имена пользователей известны публично, в то время как пароли остаются секретом. Таким образом, предполагается, что мы можем знать имена всех пользователей.
Сложность заключается в обходе проверки пароля при входе под чужим именем. В данной атаке целью является удаление проверки пароля. Для этого нам необходимо использовать возможность SQL создавать комментарии в коде. Вводя:
SQL: Скопировать в буфер обмена
'Юзер' --
В поле ввода имени пользователя, SQL-запрос для проверки входа будет выглядеть так:
SQL: Скопировать в буфер обмена
SELECT * FROM Users WHERE username = 'Юзер'
В данном запросе "Юзер" - это любое действительное имя пользователя в базе данных.
Исключив проверку пароля, можно успешно войти в систему под именем "Юзер". Это работает потому, что первая кавычка, введенная нами, закрывает первую кавычку в коде проверки имени пользователя.
Чтобы избежать ошибок, связанных с оставленной кавычкой, мы вставляем одну кавычку после "Юзер" и комментируем исходную. Двойной дефис служит символом комментария в SQL, весь текст после него рассматривается как комментарий, а не код. В результате исходная кавычка и вся проверка пароля из запроса удаляются, обеспечивая успешный вход.
Атака 2 - Обход аутентификации
Данная атака предполагает вход в систему под учётной записью первого пользователя в базе данных. Для входа под первым пользователем необходимо, чтобы запрос сразу соответствовал введённым учетным данным. Однако проблема заключается в том, что сами учетные данные неизвестны. Атака будет осуществлена от имени первого пользователя, даже если его имя неизвестно. Для этого в поле ввода имени пользователя вводится следующее:
SQL: Скопировать в буфер обмена
’ OR true --
Заменяя валидное имя пользователя на вышеуказанную строку, атакующий войдет в систему под первым пользователем из базы данных. Запрос будет выглядеть следующим образом:
SQL: Скопировать в буфер обмена
SELECT * FROM Users WHERE username = ’’ OR true
Добавив двойной дефис в конце, проверка пароля будет полностью удалена, так как он будет распознан как комментарий, а не код. Теперь проверка имени пользователя всегда верна, поскольку проверка пароля была удалена. Это происходит из-за булевого выражения, которое всегда будет истинным:
SQL: Скопировать в буфер обмена
username == ’’ OR true
Атака 3 - Основанная на ошибках
Когда пользователь может вводить данные, которые вызывают сообщение об ошибке, высока вероятность возможности атак методом SQL-инъекций. Это происходит потому, что ввод содержит символ, который не будет интерпретироваться как обычный текст, что является корневой причиной возможности SQL-инъекций. Атаки SQL-инъекций, основанные на ошибках, направлены на получение максимальной информации о базе данных через сообщения об ошибках. Они могут быть использованы эффективно, когда отрицательная проверка ввода является единственным источником защиты. Символы, которые не проходят валидацию, могут также иметь другое значение для базы данных. Например, символ "обратного слеша" может быть использован для экранирования закрывающей кавычки в поле ввода имени пользователя, что приведет к ошибке в синтаксисе SQL. Ввод символа "обратного слеша" в поле ввода имени пользователя вызовет следующее сообщение об ошибке:
SQL: Скопировать в буфер обмена
Код:
Fatal error: Uncaught mysqli_sql_exception: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ’’\’ AND password = ’’’ at line 2 in C:\dir\dir\SQL_article\logincheck.php:10
Stack trace: #0 C:\dir\dir\SQL_article\logincheck.php(10): mysqli_query(Object(mysqli), ’SELECT * FROM u...’) #1 {main}
thrown in C:\dir\dir\SQL_article\logincheck.php on line 10
Поскольку сайт, использованный в этой статье, находится на локальном хосте, это сообщение об ошибке, вероятно, предоставит больше информации, чем атакующий мог бы получить с живого веб-сайта. Но если атакующий увидит это сообщение об ошибке, оно предоставит ключевую информацию для дальнейших атак, такую как: используемая база данных - MySQL, запрос ввода не экранирован, и раскрывается информация о запросе, используемом для обработки ввода.
CSRF в функционале отзывов
Для оценки возможности проведения атаки CSRF в функционале отзывов был реализован простой механизм отзывов. В этом разделе представлены детали его реализации, а также атака CSRF.
Аналогично функционалу входа в систему, было установлено подключение к базе данных с использованием следующего кода:
PHP: Скопировать в буфер обмена
Код:
<?php
$host = "localhost";
$username = "root";
$password = "";
$db = "reviews";
$con = mysqli_connect($host, $username, $password, $db);
?>
Код указывает, что база данных размещена локально, за ним следуют стандартное имя пользователя и пароль для XAMPP. База данных названа "reviews" и подключается с использованием mysqli_connect().
Реализация функционала отзывов
Был реализован минималистичный веб-сайт с возможностью написания и удаления отзывов
Веб-сайт содержит одно поле для написания отзыва, а также кнопку отправки. Все доступные отзывы в базе данных будут отображены под кнопкой отправки. Внизу находится кнопка удаления, которая удаляет все отзывы.
Код начинается с поля ввода и кнопки отправки, который выглядит следующим образом:
HTML: Скопировать в буфер обмена
Код:
<html>
<body>
<form action="insert.php" method="POST">
review: <input type="text" name="review"><br>
<input type="submit" >
</form>
</body>
</html>
Когда нажимается кнопка отправки, информация отправляется в insert.php, который вставляет отзыв в базу данных, а затем возвращает страницу на исходную страницу CSRF.php. Один отзыв должен иметь возможность быть вставленным, и ему будет присвоен айди 1.
Для отображения всех отзывов на экране был реализован следующий код:
PHP: Скопировать в буфер обмена
Код:
<?php
echo "отзывы:";
$sql = "SELECT * FROM reviews"; // извлечь все отзывы
$result = mysqli_query($con, $sql);
while ($row = mysqli_fetch_assoc($result)){
echo $row['review'];
}
?>
Код выбирает все отзывы из базы данных, содержащей отзывы, и затем выводит их.
Для удаления отзыва была реализована следующая кнопка:
HTML: Скопировать в буфер обмена
Код:
<html>
<body>
<form action="delete.php" method="POST">
<input type="submit" value="Delete" name="delete"><br>
</form>
</body>
</html>
Когда нажимается эта кнопка, запускается delete.php, который удаляет все отзывы
CSRF
Межсайтовая подделка запроса (CSRF) — часто встречаемая атака на веб-приложения. Атака CSRF происходит, когда злонамеренный сайт заставляет веб-браузер пользователя выполнить нежелательное действие на доверенном сайте. Эти виды атак часто сложно обнаружить и защититься от них, поскольку с точки зрения сайта они выглядят нормально. Атаки CSRF могут иметь серьезные последствия, поскольку злоумышленник сможет подделать запросы на сайте, выдавая себя за другого пользователя. Это становится возможным благодаря тому, что протоколы HTTP отправляют файлы cookie с каждым запросом на сервер. Файлы cookie состоят из данных, хранящихся в браузере и отправляемых с каждым запросом на сервер. Они используются для различных функциональностей, таких как получение информации для последующего взаимодействия между браузером и сервером без повторного запроса той же информации. Они также используются для подтверждения того, что два запроса были отправлены из одного и того же браузера. Если атакующий получает этот файл cookie сеанса, он может быть аутентифицирован как другой пользователь. Будучи аутентифицированным как другой пользователь, этот пользователь может быть вынужден выполнять нежелательные действия, и при этом он может и не подозревать об этом. Для понимания того, как работают атаки CSRF, рассмотрим рисунок

На шаге 1 пользователь аутентифицируется на веб-сайте, в данном случае с именем "Abc.com". На шаге 2 создается и сохраняется файл cookie сеанса веб-браузера пользователя. На шаге 3 злоумышленник встраивает поддельный запрос в гиперссылку. Задачей злоумышленника является обмануть пользователя, заставив его кликнуть по гиперссылке. Это часто делается с использованием социальной инженерии, например, отправкой гиперссылки по электронной почте. На шаге 4 пользователь кликает по ссылке. На шаге 5 поддельный запрос отправляется на "Abc.com" с использованием файлов cookie сеанса пользователя. На шаге 6 "Abc.com" выполняет поддельный запрос, и, в зависимости от цели злоумышленника, могут происходить различные вещи, такие как перевод денег злоумышленнику.
При размещении отзыва на веб-сайте будет выполнен HTTP-запрос POST для сохранения отзыва. GET и POST - два метода отправки форм, при которых информация в полях формы отправляется на сервер. Запросы GET менее безопасны и видны всем в URL. Запросы GET более уязвимы для атак, таких как атаки CSRF. Однако и использование запросов POST не предотвращает атаки CSRF. Файлы cookie отправляются в HTTP-запросах, и атака будет использовать это. Самой ценной информацией из файла cookie для злоумышленника является аутентифицированная личность пользователя. Это происходит потому, что, имея к ней доступ, злоумышленник может проводить различные атаки.
Инициация атаки CSRF через написание отзыва
Этот раздел пояснит, как атака CSRF может быть запущена при написании отзыва для того, чтобы другие пользователи могли его увидеть. Более точно, будет оценено, может ли быть выполнен шаг 4 на рисунке выше при написании отзыва.
Вместо написания обычного отзыва напишем альтернативный отзыв.
Этот отзыв кажется призывающим пользователей щелкнуть по ссылке и является примером использования социальной инженерии для обмана людей, что позволяет злоумышленнику выполнить атаку CSRF. По всей видимости, ссылка с именем "МойСуперОтзыв" перенаправит пользователя на полный отзыв. Ссылку можно создать, не отображая фактический URL, имея базовые знания HTML. Если нет проверки ввода, злоумышленник может вставить HTML-код в отзыв. Это позволяет ему скрыть URL с текстом "МойСуперОтзыв", используя атрибут "href". Вот как на самом деле выглядел отзыв злоумышленника перед его публикацией на сайте:
"Нажмите здесь, чтобы увидеть мой полный отзыв -> <a href="ПодозрительныйСайт.com">МойСуперОтзыв</a>"
Указана ссылка на "ПодозрительныйСайт.com", которая может быть URL веб-сайта злоумышленника. Еще один способ размещения зловредной ссылки - использовать тег изображения. Как только пользователь щелкает по ссылке, атака CSRF может быть выполнена. Когда пользователь кликает на ссылку, его перенаправляет на вредоносный веб-сайт злоумышленника. В этот момент могут произойти разные вещи в зависимости от целей злоумышленника, привилегий пользователя на сайте и т.д.
На вредоносном веб-сайте злоумышленник может включить реальный отзыв, чтобы не вызывать подозрений о том, что происходит атака. Поскольку пользователь исследует вредоносный веб-сайт, атака CSRF уже произошла в фоновом режиме, и пользователь об этом не подозревает. Как упоминалось ранее, файл cookie сеанса всегда отправляется с HTTP-запросами. Это также означает, что, когда пользователь посещает веб-сайт, созданный злоумышленником, файл cookie пользователя также отправляется на этот сайт. Единственное, что требуется от пользователя для успешной атаки, - это то, чтобы он был аутентифицирован на предыдущем веб-сайте с настоящими отзывами. Для того чтобы веб-сайт мог идентифицировать пользователей, будет предоставлен действительный файл cookie сеанса при входе в систему.
Краткое саммари:
В данной статье рассмотрены атаки SQL-инъекций и CSRF на веб-приложения. В частности, подробно описаны три вида атак SQL-инъекций. Далее освещена тема CSRF, представлен пример его возможной инициации через функционал написания отзывов.
Благодарность:
Благодарю за внимание к статье и интерес к теме веб-хакинга. Вопросы, комментарии и обсуждения приветствуются.