开发类似于ASP.NET会话的系统时要考虑的安全因素

一个有趣的想法……我想首先想到的是不要,不是因为它已经完成了,而是因为从一开始它是一个坏主意。但我不会和你讨论会议的利弊,所以我的答案是……

让我们按令牌的“类型”来细分:

• 随机标识符标记

任何人都可以简单地“猜”出其中的一个,但是它们既快又容易使用。由于会话通常是短期的,所以这通常不是一个主要问题。也是一个很好的解决方案,因为它们的大小很小(22字节base64编码的guid,或32字节十六进制)

你写道: “我将考虑使用RNGCryptoServiceProvider生成的512字节值的行中的某些内容。”

是的,看起来512字节的ID是很酷的;但是,即使128位的值(16字节)也有很多种可能(一年内服务器处理不了的请求太多)。不要将此作为主要防御,而是假定ID不是秘密。

• PKI加密和签名数据

这很好地“隐藏”了通过传输的信息。你需要吗?值得花这么多开销吗?除了计算/验证开销之外,数据流的数量也有成本。它更安全吗?可能吧,但最终它就像随机ID一样容易被窃取。

始终假定其他人可以获取会话ID/令牌

这就是你应该集中精力的地方,因为如果我能把我的cookie给别人,而我的帐户仍然是安全的,那么只有这样会话才是安全的。也就是说,我不知道有100%的方法可以做到这一点,没有客户证书,甚至有问题。

在Web请求世界中,一个请求包含两个客户机标识信息。客户端IP地址和用户代理。问题是这些值可以为会话更改。因此,一种方法是在每次这些更改时重新提示进行验证,或者对每个不同的值进行验证。

是的,我知道一个用户代理很容易伪造,客户机IP地址也可能被欺骗;但是,在一天结束时,你让别人更难攻击。这是安全的重点,因为没有什么是绝对安全的。

更多建议

• 对于高度敏感的数据,您应该快速超时会话(<5分钟)。

• 显然,由于许多原因,SSL是必须的

• SSL支持从不写入磁盘或持久化的“安全cookie”。这会使会话ID难以获取。

• 密钥循环可以有效地使用,如果您在每次访问时生成一个新的会话密钥(如CRIS Lively建议的那样),那么您需要保持会话ID的最后n个数字是活动的。因此,如果n=5,在5次请求之后,我的原始会话ID将不再有效。

• 向其他人学习,阅读,并在其他主要网站的现有帐户上进行黑客攻击。

最后…

我再说一次,会议规模不大,除了少数几个地方,其他地方都应该避免。

更新:

所以我从上一篇文章开始就考虑过这个问题,我想我会用另一个答案更新我的想法…

生成16字节或更大的ID应该足以有效地消除攻击者猜测会话ID的情况。假设这和使用ssl+安全cookies,您应该尽可能的安全。为什么?

SSL将有效地防止某人在传输过程中获取会话密钥。因此,如果有人有一个不属于他们的会话密钥,那是因为他们正在做两件事之一:a)他们在客户机上运行代码(可能在浏览器中),或b)他们在服务器上运行代码。所以,基本上,如果他们能破坏一个端点,那么你已经失去了安全游戏,而且他们很可能不会通过任何额外的工作获得什么好处。

如果您不使用SSL,那么您就没有任何安全性。简单的中间人攻击会让攻击者为客户做任何我想做的事情。在没有SSL(或某种形式的安全协商会话密钥)的情况下,任何保护HTTP使用的工作都只是安全的借口。是的,你可以让它更困难,但你不能让它安全。

因此,最后,只需信任ssl就可以完成保护传输的工作,并继续使用life:)

1. 需要吗?你不能攻击不存在的东西,而且大量的会话使用系统不需要。
2. 攻击的含义是什么?(如果有人能看到其他人喜欢的配色方案,我不在乎)未来的含义是什么?(我明天可以扩展相同的皮肤选择代码来处理更敏感的数据吗?)
3. 我是否已经受到了SSL的保护?
4. 是否可以预测密钥生成?我需要定期换钥匙吗?多久?我该怎么做?我应该如何处理顺序错误的请求(img1.png的真正请求是在img2.png的请求更改了键之后发出的)。
5. 曲奇还是别的什么?
6. 是否需要“注销”以清除服务器状态以及客户端的cookie?
7. “包”会议将在哪里举行?在Web服务器上或其他地方。我该如何处理WebFarm情况(如果我现在不需要,可以吗?)
8. 我可以将一些信息拆分为会话状态,并将其他信息建立在身份验证的基础上吗?
9. 我可以使用客户端代码向cookie处理添加质询响应,还是必须假设没有JS环境?
10. 我能探测到想猜身份证的人吗?我应该如何回应?
11. 如何避免重用密钥(也就是说,我“诚实地”分配了以前使用过的密钥)和/或避免它成为问题?

会话处理中的弱点是服务器对指定会话的识别,因为它必须是信息的一部分,所以客户机将提供给服务器。

因此,我鼓励对密钥进行一些加密,并使其失效。

您可以将密钥存储在cookie、url或任何适合您需要的地方。

How ASP.net store the identification on the client side

一次吃一个:

1. 重建.NET会话处理的安全注意事项有哪些:
   .NET的会话处理仅在大多数情况下提供非常有限的安全性,而对其他情况则没有。如果目标是阻止数据进入浏览器,那么它就是这样做的。但是,如果目标是确保只有授权用户才能利用该数据。嗯,不是这样的。把它重建成一个微不足道的东西,会让我们想到你的其他问题。

2. 加密令牌实际上提供了真正的安全性吗?
   不,没有。您发送到浏览器的任何内容都可能受到影响。如果这些数据可以被截取和重放,那就不重要了。不过,还有一些解决方案……

3. 生成长随机令牌是否与签名较小的令牌一样安全?
   考虑到两者都不提供任何级别的安全,那么它们是等效的。

如果我要重新构建ASP.NET的会话处理,那么我要添加一件事:一个随机更改的值,指示下一个被接受的“请求令牌”。这应该是尽可能不可猜测的。

此密钥将在每次响应时发送到浏览器,并通过每个请求发送回浏览器。该站点将验证该密钥是否对此请求有效,并为响应生成一个新的密钥。

这将确保即使记录了浏览器和服务器之间的数据流,也无法重播。例如:

1. 浏览器向服务器发出初始请求。服务器用会话ID abc响应并请求令牌1
2. 浏览器通过ABC和1向服务器发出第二个请求。服务器验证组合,执行请求并用令牌453响应。
3. 浏览器通过ABC和453向服务器发出第三个请求。服务器验证组合,执行请求并用令牌23响应
4. 坏人重放第2步,通过ABC和1。服务器发现无效请求,通知网站所有者并以安全冲突错误响应。

在这个场景中,坏人重放的唯一方法是发送一个带有最后一个接收到的令牌的全新请求。但是,一旦真正的浏览器发送了一个新的请求,他们就会收到一个很好的安全违规通知,并且会通知您。

从这里你可以做很多其他的事情来进一步锁定它。这只是减轻特定类型攻击的一个想法。

更新

评论中的一个问题是关于并发请求。一般来说,浏览器会对CSS、图像、javascript等工件发出多个GET请求。这些请求不应包含在安全测试中。但是,浏览器每次只能发出一个POST请求,因此每个POST请求都应该触发验证并将新值发送回浏览器。