标签: sessionid

是32位,还是64位或128位或更大？

我想知道在成功登录后重新生成会话ID是否真的是一种好的做法,而不仅仅是一种货物崇拜行为.

如果我理解正确理论它应该防止会话劫持(或者至少使其变得更难),但是我无法真正看到如果有人可以窃取登录前会话,那么什么会阻止网络钓鱼者再次使用重新生成的会话.

我不关注Spring(我目前甚至不使用Java),我对它的优缺点感兴趣.

我正在尝试编写一个包装器,它将脚本作为会话负责人执行.我对linux命令的行为感到困惑setsid.考虑这个脚本,称为test.sh:

#!/bin/bash
SID=$(ps -p $$ --no-headers -o sid)
if [ $# -ge 1 -a $$ -ne $SID ] ; then
  setsid bash test.sh
  echo pid=$$ ppid=$PPID sid=$SID parent
else
  sleep 2
  echo pid=$$ ppid=$PPID sid=$SID child
  sleep 2
fi

输出因执行或来源而异:

$ bash
$ SID=$(ps -p $$ --no-headers -o sid)
$ echo pid=$$ ppid=$PPID sid=$SID
pid=9213 ppid=9104 sid= 9104
$ ./test.sh 1 ; sleep 5
pid=9326 ppid=9324 sid= 9326 child
pid=9324 ppid=9213 sid= 9104 parent
$ . …

我们有一个Android应用程序,要求用户输入Captcha的答案.Captcha是在我们的服务器上生成的.回复时,会将其发送到服务器进行验证.

问题是,因为我必须在请求Captcha之后关闭HttpURLConnection,然后发现回复正在服务器上的另一个会话上运行.因此,Captcha检查失败,因为它取决于会话.

有没有办法保持连接活着或者我应该遵循不同的路径？我知道在相应的iPhone应用程序中,它们保持"连接",因此具有相同的sessionid.

编辑:

    CookieManager cookieManager = new CookieManager();  
    CookieHandler.setDefault(cookieManager);

    URL urlObj = new URL(urlPath);
    conn = (HttpURLConnection) urlObj.openConnection();

    if (urlPath.toLowerCase().startsWith("https:")) {
        initializeHttpsConnection((HttpsURLConnection) conn);
    }
    conn.setRequestMethod("POST");
    conn.setRequestProperty("Content-Language", "en-US");
    conn.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
    conn.setRequestProperty("Content-Length", Integer.toString(bodyData.length));
    if (_sessionIdCookie != null) {
        conn.setRequestProperty("Cookie", _sessionIdCookie);
    }
    // Connect
    conn.setDoInput(true);
    conn.setDoOutput(true);
    conn.connect();

我的应用程序可以控制用户权限,因为并非所有用户都可以访问完整的网站.此时,特定用户的所有权限都存储在他的会话中,因为在每次回发后搜索数据库都会出现问题.

问题是,当我删除权限时,用户仍然可以访问该页面,并且只有当他关闭浏览器时,更新才会生效.

有没有办法按ID杀死特定的应用程序会话,强制用户再次登录？

我已经通过php手册阅读了这个问题,这似乎是一个很常见的问题,但我还没有找到解决方案.我在数据库中保存会话.我的代码如下:

// session
$_SESSION['userID'] = $user->id;        
header('Location: /subdirectory/index.php');

然后在index.php的顶部session_start(),我有var_dumped $ _SESSION全局,而userID不在那里.正如我所说,我看了PHP手册(http://php.net/manual/en/function.session-write-close.php)并没有session_write_close或session_regenerate_id(true)为我工作.有人知道解决方案吗？

编辑:我的文件顶部有session_start().当我在头重定向之前var_dump会话全局时,我在那里看到userID,但是在另一个文件中没有,这是在这个脚本的子目录中

UPDATE

我们最终与Acunetix团队的一些程序员进行了会面,他们意识到他们的代码中可能存在一些错误,这些错误导致它在扫描中显示为一个问题而不是实际问题.普遍的共识是忽略扫描结果并使用开箱即用的ASP.NET会话ID生成,因为它应该对我们的站点足够安全.

@Vasile Bujac,因为你的答案是唯一一个,并提到使用ASP.NET标准解决方案,我把它作为答案,但感谢大家的帮助.

我们在工作时使用Acunetix的Retina扫描仪对我们的应用程序进行安全扫描.它告诉我们,我们的会话ID不够随机且太可预测.我不确定ASP.NET默认情况下如何生成会话ID(我认为它仍然是GUID？),但我继续实现了扩展SessionIDManager类并重写CreateSessionID和Validate方法以使用Guid的方法正如本MSDN文章中所述.

虽然这使得它稍微随机,但仍然没有产生Acunetix的"期望"效果.我甚regenerateExpiredSessionId="true"至将属性添加到web.config并且没有任何效果.我有一种感觉,我可能需要刻意打电话Session.Abandon()来真正清除会话并获得一个新ID.问题是我必须在用户登录之前调用它,因为它是唯一一种知道用户正在开始新会话的防故障方式.所以我无法在会话中设置任何内容,直到下一页加载了Abandon方法的工作方式,这意味着中间页面不是很理想,但可以做到这一点.

有没有人经历过这个或成功实施过修复？

另外,仅仅是一个FYI,我们不使用成员资格/表单身份验证,我们只是在有人登录时创建一个新的自定义用户类,并将其保存在会话中供以后使用.

来自Acunetix的报告:

CWE-330 CAPEC-59 OWASP2007-A7

描述: 表现出低熵("随机性")的会话令牌通常容易受到预测攻击.不安全令牌可能是由于伪随机数生成器,基于时间的值,静态值或基于用户属性(用户名或用户ID)的值不足造成的.这意味着攻击者可以在短时间内监视应用程序并收集它创建的会话令牌后猜测有效的会话令牌.如果攻击者为另一个用户确定了有效的会话令牌,则可以查看,修改或删除任意用户的数据,而无需猜测受害者的用户名或密码.因此,推断有效会话令牌的能力使攻击者能够绕过登录页面并避免暴力破解帐户的需要.此外,即使受害者当前未登录到应用程序,静态令牌也可以使攻击者能够定位用户.这增加了攻击者可以攻击的受害者群.

会话令牌应使用强大的随机数生成器创建,并从大量数字中收集.例如,如果操作系统的rand()函数可以产生统计上均匀分布的32位值,那么它通常就足够了.会话令牌不佳是增量的,依赖于用户的帐户ID,仅使用时间戳,或具有其他高度确定性的信息.保护会话令牌安全性的其他方法是始终通过SSL传输它们,在一段时间后自动使令牌到期,并在用户退出应用程序时显式使令牌到期.

建议:如果会话值表现出强烈的随机性,但是从一小部分值中选择,则攻击者更有可能简单地猜测一个有效的令牌.通过实现几种互补技术,可以改进Web应用程序的会话管理:

• 确保令牌值至少为32位,特别是对于具有大量并发用户和大量每日页面请求的应用程序.
• 熵源的比特大小(随机值)比实际会话令牌的比特大小更重要.例如,MD5哈希值产生128位值.但是,增量值,时间戳或8位随机数的MD5哈希值都是不安全的,因为可以很容易地预测随机值的来源.因此,128位大小不代表会话令牌的准确度量.熵源的最小大小为32位,但对于每小时超过10,000个并发用户的站点,可能需要更大的池(48或64位).
• 在大多数情况下,应用程序生成的令牌(例如,ASP.NET_SessionId,ASPSESSIONID,JSPSESSIONID,PHPSESSIONID)提供足够大的随机值以防止会话预测攻击.应用程序应使用这些会话管理算法,除非对自定义会话机制进行了彻底的审查和测试.
• 使用服务器端对象跟踪与会话令牌关联的用户属性,以防止用户冒充攻击.如果应用程序没有严格地将用户的会话令牌与该用户的配置文件信息相关联,则攻击者可能能够通过操纵客户端值来查看任意信息.例如,如果应用程序设置强会话令牌,但基于"UserId"cookie执行SQL查询,则攻击者只需修改"UserId"cookie即可模拟其他人.如果将"UserId"值与服务器端会话对象相关联,则应用程序将更安全,因为攻击者无法修改该值.
• 当用户退出应用程序或预定的不活动时间后,会话令牌到期.我们建议对会话令牌使用20分钟超时,但这在很大程度上取决于应用程序的类型和预期用法.

我在本地运行Weblogic 10.3,并对它生成的sessionId有疑问.当我打印session.getId()时,我看到类似于此的东西:

BBp9TAACMTglQ2TDFAKR4tpyXg73LZDQJ2PtT9x8htG1tWY122aa!869187422!1308677666322

这些惊叹号及其后面是什么,特别是第二对:!1308677666322？看起来有时服务器会附加它,有时却不会.我相信如果我使用相同的浏览器第二次登录我的应用程序,weblogic会附加它.这个cookie是否以某种方式相关？

1.-我正在使用报告服务,有时ASP.NET session has expired or could not be found当我尝试加载报告时出现此错误.

2.-我意识到,即使用户是相同的,Session.SessionID属性也会更改时出现此错误.如果它没有改变,则加载报告.我的意思是,如果我多次刷新报告,只要Session.SessionID与最后一个相同,就会加载报告.

3.-Microsoft文档说:

使用基于cookie的会话状态时,在使用Session对象之前,ASP.NET不会为会话数据分配存储空间.结果,为每个页面请求生成新的会话ID,直到访问会话对象.如果您的应用程序需要整个会话的静态会话ID,您可以在应用程序的Global.asax文件中实现Session_Start方法,并将数据存储在Session对象中以修复会话ID,或者您可以在您的另一部分使用代码应用程序在Session对象中显式存储数据.

如果您的应用程序使用无cookie会话状态,则会在第一个页面视图上生成会话ID,并为整个会话维护该会话ID.

关键是我不能使用无cookie会话状态,因为我需要cookie.

我该怎么做才能避免这个错误？或者我该怎么做才能避免Session.SessionID在每个请求上更改？

我想Session.SessionID在URL中使用as文件名和查询字符串.我想知道它的格式是否适合这些应用程序.例如,您不能在文件名中使用'?'或使用'<'字符.

SessionID格式字符串对文件名和查询字符串是否安全？