---我一直在尝试Cookie/session ID，在理解这些概念时遇到了一些困难。我正在开发Debian发行版。使用Burp捕获/更改请求/响应。我所知道的在下面。
a。Cookie存储在客户端机器数据库的/root/.mozilla/ffirefox/pya18ecc.default/Cookies.sqlite中。在moz_Cookies表中。我正在使用sqlite3来访问数据库。
b。会话变量存储在服务器上的/var/lib/PHP5中。
SERVER上的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）
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）是一个登录页面（基本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
----在此之前，没有会话ID或cookie的交换。（如果我错了，提示我？）
- 我用用户名和密码回应，请求（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
----在转发上述请求时，我观察到，甚至在转发响应之前，我就已经在/var/lib/PHP5中收到了会话id:cl5mi7tbhdnobpv8kkau7thjo6（2）。那是因为服务器已经创建了相同的，并准备在响应（2）中转发
- 响应（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保存在客户端m/c上。那么，他们在哪里获救呢？（这是我的第一个问题）
- 接下来，我从服务器中删除了会话变量"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表下看到它们。。。。。请解释一下？（这是我的第二个问题）
Cookie可以存储在磁盘或内存中。它们的存储方式取决于浏览器设置（例如Firefox中的私人浏览模式）和服务器设置（请参阅有关会话处理的PHP文档）。
HTTP连接可以使用Keep-Alive标头进行缓存。
看起来你被设置为将服务器上的会话ID存储在一个文件中，但浏览器cookie存储在内存中，而不是文件中，这就是为什么你看到的是PHP文件，而不是Firefox cookie文件。
至于为什么即使删除了文件，服务器也能识别会话id，看起来是因为PHP知道会话已经过身份验证，这意味着它必须缓存在服务器的RAM中。（PHP大师可能能够填写会话机制的细节）。
在收到请求3后，PHP会查找会话id文件，当它没有看到时，它会再次写入该文件，因为它知道会话是有效的。这是预期的行为，因为如果你想删除会话，作为PHP程序员，你应该用PHP来做，而不是在后台删除会话id文件。
您会注意到客户端发送了带有请求3的会话id。客户端将在每次请求时发送会话id cookie，但服务器在此会话期间不应再次使用Set cookie指令进行响应。浏览器现在拥有会话id cookie，并且可以随每个请求一起发送，因此不需要进一步的身份验证。
这种策略的弱点在于，它可能会留下会话劫持的可能性。如果攻击者可以从您的浏览器获取会话id cookie，他们可以使用您的凭据对服务器执行命令。
获取会话id对攻击者来说可能是一项琐碎的任务，也可能不是，这取决于许多因素。例如，如果受害者的计算机被攻击者控制的病毒或其他恶意软件破坏，攻击者可能会在此时打开受害者的计算机，并可以为所欲为，包括获取会话id。其他攻击使用跨站点脚本（XSS）攻击诱骗受害者的浏览器泄露会话id。
有针对XSS和会话劫持的特定防御措施，同样，这个主题相当复杂，值得详细研究。例如，一个更安全的会话可能会使用一次性令牌，该令牌会随着每次响应而更改，尽管使用异步HTTP调用可能会使该策略变得复杂。
在此之前，没有会话ID或cookie的交换。（如果我错了，提示我？）
不，这是正确的。在此之前，尚未调用session_start，因此没有会话cookie可供交换。
现在，服务器在/var/lib/PHP5下再次获得了相同的会话变量集。服务器不应该不识别会话变量吗？
它可能应该，但事实并非如此。我认为正在发生的事情：当客户端发送会话id时，服务器很乐意使用它，即使它还不知道。这可以（在理论上）用于会话固定，这就是为什么建议每次会话中的某些内容发生变化时重新生成id（在实践中，默认情况下，session.use_trans_sid设置为0，这使得会话固定不那么成问题）。
我觉得奇怪的是，数据仍然存在（我无法复制这种行为）。我的猜测是，你实际上是在重新提交表格？
此外，如果发生这种情况是因为保存了Cookie，那么为什么我不能在moz_Cookies表下看到它们呢
我的猜测是，cookie仍在浏览器内存中。你有没有尝试过同样的方法，但通过浏览器界面删除了cookie？
其他
我知道这只是一个测试脚本，但仍然：
- 建议使用准备好的语句而不是简单的转义
- 不要在会话中存储明文密码）
- 不要回复未初始化的用户输入
- 散列应该是特定于用户的，而不是特定于站点的
- htmlentities可以防止XSS，而不是SQL注入，因此应该在回显数据时应用，而不是在将数据插入数据库时应用