аутентификация — я хочу выяснить, как куки / переменные сеанса взаимодействуют для проверки сеанса пользователя

—Я экспериментировал с файлами cookie / идентификаторами сеансов, и у меня возникли некоторые проблемы с перевариванием концепций.
Я работаю над дистрибутивом Debian. Использование Burp для захвата / изменения запросов / ответов. То, что я знаю, ниже.

а. Файлы cookie сохраняются в базе данных клиентского компьютера по адресу /root/.mozilla/firefox/pya18ecc.default/cookies.sqlite. В таблице moz_cookies. Я использую sqlite3 для доступа к базе данных.

б. Переменные сеанса хранятся в / var / lib / PHP5 на сервере.

Код PHP на СЕРВЕРЕ ниже

<?php
require_once 'login.php';

$connection = new mysqli($db_hostname,$db_username,$db_password,$db_database);
if($connection->connect_error) die ($connect->connect_error);

if (isset($_SERVER['PHP_AUTH_USER']) &&
isset($_SERVER['PHP_AUTH_PW']))
{
$username = mysql_entities_fix($connection,$_SERVER['PHP_AUTH_USER']);
$password = mysql_entities_fix($connection,$_SERVER['PHP_AUTH_PW']);

$query = "SELECT * FROM user WHERE username = '$username'";

$result = $connection->query($query);

if(!$result) die ($connection->error);
elseif ($result->num_rows)
{
$row = $result->fetch_array(MYSQLI_NUM);
$result->close();
$salt1="!@#$";
$salt2="$#@!";
$token = hash('ripemd128',"$salt1$password$salt2");

if($token == $row[3])
{
session_start();
$_SESSION['username'] = $username;
$_SESSION['password'] = $password;
$_SESSION['forename'] = $row[0];
$_SESSION['surname'] = $row[1];
echo "$row[0] $row[1] : Hi '$row[0]' you are logged
in as '$row[2]'";
die("<p><a href = continue.php> CLICK HERE TO CONTINUE</a></p>");
}
else    {die("Invalid Username/ Password Combination");}
}
else
{
die("Invalid Username/ Password Combination");
}
}
else
{
header('WWW-Authenticate: Basic realm="Restricted Section"');
header('HTTP/1.0 401 Unauthorized');
die("Please enter your username and password to Login");
}
$connection->close();
function mysql_entities_fix($connection,$var)
{
return htmlentities(mysql_entities_string($connection,$var));
}
function mysql_entities_string($connection,$var)
{
if (get_magic_quotes_gpc()) $var = stripslahes($var);
return $connection->real_escape_string($var);

}
?>
  1. Когда я отправляю запрос (1), это выглядит так.

Запрос (1)

 GET /ses3.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Linux i686;      rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
  1. Ответ (1) является страницей входа (обычная HTTP-аутентификация)

Ответ (1)

HTTP/1.0 401 Unauthorized
Date: Sat, 28 Mar 2015 07:27:44 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.36-0+deb7u3
WWW-Authenticate: Basic realm="Restricted Section"Vary: Accept-Encoding
Content-Length: 48
Connection: close
Content-Type: text/html

Please enter your username and password to Login

—-До сих пор не было обмена идентификаторами сеансов или куки. (Если я не прав, подскажите?)

  1. Я ответил с именем пользователя и паролем, и запрос (2)

Запрос (2)

GET /ses3.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0     Iceweasel/31.5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Authorization: Basic YnNtaXRoOm15c2VjcmV0

—- При пересылке вышеупомянутого запроса я вижу, что я получил идентификатор сеанса: cl5mi7tbhdnobpv8kkau7thjo6 в / var / lib / PHP5 даже до пересылки ответа (2). Это потому что сервер
создал то же самое и готов отправить его в ответ (2)

  1. Ответ (2)

Ответ (2)

HTTP/1.1 200 OK
Date: Sat, 28 Mar 2015 07:36:13 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.36-0+deb7u3
Set-Cookie: PHPSESSID=cl5mi7tbhdnobpv8kkau7thjo6; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-    revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 117
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

Bill Smith : Hi 'Bill' you are logged
in as 'bsmith'<p><a href = continue.php> CLICK HERE TO CONTINUE</a></p>

—-Теперь, проверяя SELECT * FROM moz_cookies, я не вижу никаких файлов cookie, которые сохраняются на клиентском компьютере. Так где они спасаются? (Это мой первый вопрос)

  1. Затем я удалил переменную сеанса «cl5mi7tbhdnobpv8kkau7thjo6» с сервера и снова ударил
    кнопка обновления в браузере клиента. Запрос (3) / ответ (3) ниже

Запрос (3)

GET /ses3.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: PHPSESSID=cl5mi7tbhdnobpv8kkau7thjo6
Authorization: Basic YnNtaXRoOm15c2VjcmV0
Connection: keep-alive
Cache-Control: max-age=0

Ответ (3)

HTTP/1.1 200 OK
Date: Sat, 28 Mar 2015 07:50:01 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.36-0+deb7u3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 117
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

Bill Smith : Hi 'Bill' you are logged
in as 'bsmith'<p><a href = continue.php> CLICK   HERE TO CONTINUE</a></p>

——Теперь сервер снова получил ту же переменную сеанса, установленную в / var / lib / PHP5. Разве сервер не должен распознавать переменную сеанса? Кроме того, если это происходит из-за сохраненных файлов cookie, то почему я не могу увидеть их в таблице moz_cookies ….. Пожалуйста, объясните? (Это мой второй вопрос)

1

Решение

До сих пор не было обмена идентификаторами сеансов или куки. (Если я не прав, подскажите?)

Нет, это правильно. Пока здесь, session_start не был вызван, поэтому нет файлов cookie сеанса для обмена.

Теперь сервер снова получил ту же переменную сеанса, установленную в / var / lib / PHP5. Разве сервер не должен распознавать переменную сеанса?

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

Что я нахожу странным, так это то, что данные также все еще там (я не мог воспроизвести это поведение). Я думаю, что вы на самом деле повторно отправляете форму?

Кроме того, если это происходит из-за сохраненных файлов cookie, то почему я не могу увидеть их в таблице moz_cookies?

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

Разное

Я знаю, что это всего лишь тестовый скрипт, но все же:

  • подготовленные заявления рекомендуются для простого побега.
  • не храните незашифрованные пароли в сессиях).
  • не повторять пользовательский ввод без проверки.
  • Хеши должны быть специфичными для пользователя, а не для конкретного сайта.
  • htmlentities защищает от XSS, а не от внедрения SQL, и поэтому должен применяться при отображении данных, а не при вставке их в базу данных.
1

Другие решения

Несколько вопросов для рассмотрения:

  1. Файлы cookie могут храниться на диске или в памяти. Как они хранятся, зависит от настроек браузера (например, режим приватного просмотра в Firefox) и настроек сервера (см. PHP документы по обработке сессий).

  2. HTTP-соединения могут быть кэшированы с помощью заголовка Keep-Alive.

Похоже, вы настроены на сохранение идентификаторов сеансов на сервере в файле, но cookie браузера хранится в памяти, а не в файле, поэтому вы видите файл PHP, а не файл cookie Firefox.

Что касается того, почему сервер распознает идентификатор сеанса, даже если вы удалили файл, похоже, что происходит то, что PHP знает, что сеанс аутентифицирован, то есть он должен кэшироваться в оперативной памяти на сервере. (Гуру PHP может быть в состоянии заполнить специфику механики сессии).

После получения запроса 3, PHP ищет файл идентификатора сеанса и, когда он не видит его, он записывает файл снова, потому что он знает, что сеанс действителен. Это ожидаемое поведение, потому что если вы хотите удалить сеанс, вы, как программист PHP, должны делать это на PHP, а не удалять файл идентификатора сеанса за кулисами.

Вы заметите, что клиент отправил идентификатор сеанса с запросом 3. Клиент будет отправлять cookie идентификатора сеанса с каждым запросом, но сервер не должен отвечать инструкцией Set-Cookie снова во время этого сеанса. Браузер теперь имеет cookie с идентификатором сессии и может отправлять его с каждым запросом, поэтому дополнительная аутентификация не требуется.

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

Получение идентификатора сеанса может или не может быть тривиальной задачей для злоумышленника в зависимости от многих факторов. Если, например, компьютер жертвы скомпрометирован вирусом или другим вредоносным ПО, контролируемым злоумышленником, злоумышленник, вероятно, запихнет компьютер жертвы в этот момент и может сделать все, что захочет, включая получение идентификатора сеанса. Другие атаки используют атаки межсайтовых скриптов (XSS), чтобы обмануть браузер жертвы в разглашении идентификатора сеанса.

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

2

По вопросам рекламы [email protected]