我正在测试安全漏洞的Web应用程序，并且遇到以下两种情况。Web应用程序安全
使用代理，我拦截所有通过应用程序的请求并保存所有的cookie。使用这些保存的Cookie，我可以在不同的计算机上恢复会话，并在没有任何进一步身份验证的情况下访问用户的个人信息。我认为任何管理员都可以提供这类服务，并获得网络上所有用户的个人信息。
与情况1相同，但即使在原始用户已正确注销后，我仍能够在其他机器上恢复会话。即即使在原始用户注销并且客户端上的所有与会话相关的cookie被删除之后，会话似乎仍然在服务器上有效。
我相当确定情况2是Web应用程序中的安全漏洞。我想知道情况1是否也可以在技术上被认为是Web应用程序中的漏洞。如果是这样，有什么方法可以解决这个问题？
案例1. 这是不是一个真正的安全漏洞，系统管理员可以恢复您的会话，因为它通常可以使系统管理员来恢复密码散列值和尝试破解他们或创造一些安全漏洞来对付他们的用户。
虽然认为系统管理员可以尝试恢复会话可能是无害的，但上游可能并非如此（在互联网的其他地方连接某人），并且通常认为实施所有用户登录/ HTTPS中的敏感活动。
只是对上面的回复发表评论，当通过HTTPS使用cookie时，它不可能在计算机外部恢复它们（如在中间人中）。
案例2 这不是一个真正的安全缺陷。在考虑这种情况时，你认为案例1，这不应该发生在第一个地方（有人嗅你的饼干）。
注： 除了确保通过HTTPS登录名/敏感的活动，它可能是明智的，整个网站在同一个域中进行加密，因为它是可以注入流量的客户端暴露自己的cookie，如果一些同一个域上的页面未加密。
当用户没有主动注销时，很难从服务器上删除用户标识（单击Web应用程序中删除标识的按钮）。如果用户只关闭该页面，则服务器不知道用户已登录并认为用户标识仍然有效。
您可以将用户关联到一个ip，这使攻击者难以窥探cookie并使用它们从不同的ip中使用它们，但它在普通用户子网中不起作用，因为在NAT中，子网中的所有机器都具有相同的外部IP。
注意： 使用自签名加密有危险。虽然它可以保护用户免受外部嗅探，但是对于某些人来说，轻松诱骗不注意的用户登录您的应用程序的欺骗版本。我使用WAP上的专属门户做到了这一点。
如您所描述的，SSL有助于防止中间人攻击。
你可以在会话中存储一个变量，包含用户的IP，用户代理等或它们的散列，并检查它的每一个请求，如果它被劫持，劫持者将不得不伪造这些变量。不完美但有帮助。
我知道只有一个（1）网站在配置文件页面有一个会话管理器。你可以看到你还在哪里登录，选择任何或全部，然后注销。
某些内容管理系统允许最大登录时间。根据用户使用您的页面的方式（例如：用户永远不会在页面上停留超过3分钟），您可以将此值设置得非常低。
这不是Web应用程序中的技术漏洞。但是，网络应用程序是委托解决这些问题的委任方。
关于案例1是否为漏洞的问题，当然是这样。为什么？因为您的系统的设计，实施或操作存在缺陷或缺陷，可能会被利用来违反系统的安全策略，而这正是脆弱性的确切定义。
为了解决这个问题，我通常会做的是记录成功登录所发送的用户代理。我引用它，然后每当用户想要从服务器获取任何内容时，我会检查当前用户代理是否与登录时发送的用户代理相匹配。
您可以将其与IP地址相结合，并检查这两个参数是否在请求之间发生变化，如果确实如此，那么很可能有人会劫持cookie。
if (($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT'])))
die("{ 'succes': false , 'text' : 'Please re-log in.');