在ASP.NET Web应用程序中,使用集成Windows身份验证,会话是否与Windows身份相关联？
换句话说,如果我登录(使用IWA)到应用程序,并且应用程序在我的会话中存储了一些"东西",这个东西是否仅由会话ID访问？例如,如果恶意某人设法窃取我的会话ID,但不是我的凭据,那么他可以访问我的会话内容吗？或者是这个会话只能访问相同的身份,要求两者的会话ID和窗户的身份来访问它？
asp.net iis windows-authentication session-management session-hijacking
我最近阅读了一篇关于使ASP.NET会话在这里更安全的文章,起初它似乎非常有用.
以前我一直在会话中存储用户的IP地址,然后在每个后续请求中确保请求的IP等于存储的IP.
本文中的代码还通过检查IP地址来保护会话,除了它存储包含用户IP作为会话cookie一部分的散列消息验证代码.它会在每次请求时创建一个哈希MAC两次,我想这会让事情变慢一些.
我已经可以看到他们的代码中存在一个潜在的缺陷:如果你以某种方式获得了用于生成MAC的密钥,那么你可以使用自己的IP生成一个有效的MAC - 你甚至不必伪造IP会议开始了.
对于一个简单的问题来说,这似乎是一个过于复杂的解决方案,它不仅会产生更大的开销,而且比普通的方法更容易受到攻击 - 除非我完全忽略了这一点.
那么,为什么这种方法比我一直使用的更简单的方法更安全？
稍作一提,作者还指出,您不应该在比较中使用整个IP地址,因为如果某个用户的IP位于代理后面,则会更改每个请求.如果你检查X_FORWARDED_FOR,情况仍然如此吗？
谢谢!
我正在试图弄清楚如何防止会话劫持.这就是我在想的事情:
与用户标识会话一起,也添加用户代理和用户IP会话.每次加载页面时,都会检查这些会话以查看它们是否匹配 - 这是否足够？例如:
<?php
$userIp = $_SESSION['userIp'];
$userAgent = $_SESSION['userAgent'];
if ($userIp != $_SERVER['REMOTE_ADDR'] || $userAgent != $_SERVER['HTTP_USER_AGENT'] {
session_destroy();
}
?>
谢谢.
前几天发生了一件非常奇怪和令人尴尬的事情,我没有言语来形容发生的事情.
我的应用程序在Tomcat 7上运行与JSF 2.1,Hibernate 4,Spring Security集成的Spring 3.我通过电话与C级别的重要人员同时在同一页面上同时处于测试环境中.当他的页面出现我的个人帐户详细信息时,他开始导航到我正在浏览的页面.我不相信他,所以我走到他的办公室,果然,他不知何故登录了我的帐户,他没有密码.
该应用程序将保护患者的健康信息,因此我被命令向C级提供已发生事件的完整报告,但我无法确定这是如何实现的.我搜索了代码库,没有得到什么.我试图在多个场合重现确切的场景,但从未能够重现它.我甚至没有一个受过教育的猜测,我很满意.
我想也许在Tomcat应用程序上下文实现中存储的会话上可能存在一些不安全的线程操作,但如果它不可重现,我无法证明这一点.我还认为,由于Spring Security在其他请求和转发之前作为过滤器运行,可能其中一个servlet过滤器受到干扰.另外两个是我最近添加的Primefaces文件上传过滤器和Omnifaces SEO过滤器.
Omnifaces过滤器实际上干扰了Primefaces文件上传过滤器,我不得不修改它的配置,所以它们中的两个会很好地相互配合,所以我仍然觉得这也许是可能的.
Spring Security是否存在导致类似问题的已知错误？Tomcat是否存在与ApplicationContext意外服务错误会话状态有关的已知问题？是否有其他人遇到过类似的问题或对此有一些独特的见解？
编辑:发布后不久我发现了这个,仅在几天前发布:
会话混淆 - apache httpd与mod_jk,tomcat,spring security - 提供其他用户的数据
这几乎与我在Tomcat面前拥有Apache httpd + mod_jk插件的设置完全一样,所以我肯定不是疯了:)
更新:
我能够在没有mod_jk或Apache的情况下在我的开发环境中重现这个问题,所以我可以可靠地将其排除在外作为罪魁祸首.
tomcat hibernate spring-security session-hijacking omnifaces
嗨大家可以任何人在会话固定,会话重播和会话劫持攻击之间给出明显的区别,我已阅读了很多文章,但会议劫持和会话重播攻击之间的问题仍然不明确.....
提前致谢
security session session-fixation session-hijacking session-replay
我正在研究我的网站的安全性，我会理解为什么应该谨慎使用 session_regenerate_id。在 php 手册文档（https://www.php.net/manual/fr/function.session-regenerate-id.php）中，他们说：
目前，session_regenerate_id 不能很好地处理不稳定的网络，例如移动和 WiFi 网络。因此，您可能会通过调用 session_regenerate_id 遇到丢失的会话。
您不应立即销毁旧会话数据，而应使用销毁时间戳并控制对旧会话 ID 的访问。否则，页面的并发访问可能会导致状态不一致，或者您可能丢失了会话，或者可能导致客户端（浏览器）端竞争条件并可能创建许多不必要的会话 ID。立即删除会话数据也会禁用会话劫持攻击检测和预防。
我不明白为什么这个函数可能意味着失去连接。我们向服务器发送请求，他更改 SID（使用旧值初始化 $_SESSION 并在 save_file 位置创建一个文件），以便他可以向客户端发送 cookie。
任何人都可以向我解释我们可以在哪里丢失会话？我真的很困惑，但我会理解这个问题以解决这个问题......
在此先谢谢大家:D
Ps：我也看过https://www.php.net/manual/fr/function.session-regenerate-id.php上的文档，我不明白第二个例子：
function my_session_start() {
session_start();
if (isset($_SESSION['destroyed'])) {
if ($_SESSION['destroyed'] < time()-300) {
// Ne devrait pas se produire habituellement. Cela pourrait être une
// attaque ou en raison d'un réseau instable. Supprimez tout l'état
// d'authentification de cette session utilisateurs.
remove_all_authentication_flag_from_active_sessions($_SESSION['userid']);
throw(new DestroyedSessionAccessException);
}
if (isset($_SESSION['new_session_id'])) {
// Pas encore complètement expiré. …在过去的几天里,它一直在我的脑海中运行,但我读了一些关于如何使PHP会话更安全的文章.几乎所有这些文章都说你需要在会话中使用额外的盐来保存useragent.像这样的东西:
$fingerprint = md5('SECRET-SALT'.$_SERVER['HTTP_USER_AGENT']);
盐会使攻击者更难以劫持或任何会话.但为什么每次检查时都加盐:
md5('SECRET-SALT'.$_SERVER['HTTP_USER_AGENT']) == $_SESSION [ 'fingerprint' ]
因此,为什么盐会使它更安全,因为攻击者仍然只需要使用者(相对来说是一小组不同的使用者)和sessionid？
可能是我忽略的小东西,但无法弄明白,让我疯狂哈哈
谢谢!
我们最近遇到了一个问题,其中用户A可能无意中劫持了用户B的会话,该用户B试图在(几乎)与用户A同时访问控制器生成的下载.
我们仍然不能100%确定实现这一目标所需的所有条件,但我们可以在生产和登台环境中可靠地重现问题.这些环境的重要细节如下.
Application Server:Phusion Passenger 5.0.21或5.0.24(意思是我们尝试了两个版本并且都重现了这个问题)
框架:Rails 4.2.4
语言:Ruby 2.2.3
操作系统:CentOS 6
有趣的是,我们可以不使用重现此问题的Phusion客运4.0.53.
它可能看起来太简单了,但这就是必要的.
这就是某人的会话被无意中劫持所需要的一切.(看起来轮盘赌A或B的会话是否被劫持,虽然它可能不像看起来那么随机.)
我们知道用户的会话已被劫持,因为我们可以看到页面上显示的当前会话的用户名和姓.
每次,一个用户"成为"另一个用户.
如果用户访问角色不同,则还意味着您现在可能具有不同的访问级别.例如,有人可能突然成为管理员,如果这是他们无意中被劫持的会话....
最初似乎Phusion Passenger是导致此问题的唯一因素,因为当我们切换回版本4时,此问题不再出现.
在一些代码改变之后,我们确定我们的控制器代码中的方法似乎导致了这个问题的发生.
这是一个示例Controller方法,它将在Phusion Passenger 5.0.21或5.0.24上生成此问题:
def sample_method
respond_to do |format|
format.csv {
headers.merge!({'Cache-Control'=>'must-revalidate, post-check=0, pre-check=0'})
render :text => proc { |response, output|
100.times do |i|
output.write("This is line #{i}\n")
end
}
}
end
end
似乎我们对Cache-Control的修改可能已经很好地解决了这个问题.
也许我们不应该对此进行修改,但我们希望有人可能会深入了解缓存控制参数如何能够突然让我们陷入不同的会话.
为了测试这个,你必须有一个映射到Controller#sample_method的路由,你必须有一个按钮可以点击下载这个文件.
我意识到我们正在指定我们想要一个CSV并且没有返回CSV,但在这种情况下我用proc替换了我们的实际CSV,因为我们的CSV是在一个单独的类中生成的.
上面列出的环境中的上述代码将重现该问题.
我们使用Devise gem进行用户身份验证.如果您要设置测试应用程序以尝试重现此问题,则需要设置Devise和两个帐户.
顺便说一句,你还需要在两台独立的计算机上安排两个人来测试它.您既需要同时登录系统,也要同时尝试多次点击该按钮. …
ruby session ruby-on-rails session-hijacking ruby-on-rails-4
这篇文章指出
如果您的站点在共享Web服务器上运行,请注意同一服务器上的任何其他用户都可以轻松查看任何会话变量.
在像GoDaddy这样的大型主机上,是否真的没有针对此的保护措施？这真的很容易吗？如果这很容易,我主机上其他用户的会话变量在哪里,我可以查看它们？
搜索启用httpOnly获取cookie的可能方法,我找不到任何.但话又说回来,像Firebug,Add'N Edit Cookie等浏览器插件如何获得cookie？攻击者不能这样做吗？
所以我的问题是,使用javascript获取启用了httpOnly的请求的cookie是否真的非常不可能？
p/s:是的我知道httpOnly不会阻止XSS攻击.我也知道这对嗅探器来说是徒劳的.让我们只关注javascript,类似警报(document.cookie)类型/ pre httpOnly时代.
我阅读了很多关于使用Flash,Javascript等进行跨站点脚本编写的内容,并且还发现了一些列表,其中包含一个允许从任何服务器访问的crossdomain.xml的网站.例如,flickr.com信任所有域.
有人可以解释一下为什么这似乎是安全的并且不会导致会话劫持等攻击？是因为那些crossdomain.xml仅在子域上有效,而攻击者无法获取会话密钥吗？
我是否必须做一些特殊的事情以避免使用Kohana框架进行会话劫持？我假设会话仅使用Kohana会话库进行操作