会话重放 vs 会话固定 vs 会话劫持 [英] Session Replay vs Session Fixation vs Session Hijacking

问题描述

谁能给出会话固定、会话重放和会话劫持攻击之间的明确区别?我看过很多文章，但会话劫持和会话重放攻击之间的问题仍然不清楚.

Can anyone give a clear difference between session fixation, session replay and session hijacking attacks? I have read many articles, but the matter is still unclear between session hijacking and session replay attacks.

推荐答案

固定和劫持最终都有相同的目标 - 获得对会话的访问权.他们只是在如何实现这一点上有所不同.

Both fixation and hijacking have ultimately the same goal - gaining access to a session. They only differ in how you achieve that.

会话劫持只是窃取现有的、有效的会话 cookie 的行为.最常见的是通过嗅探网络流量(MITM 攻击)，但也可以通过任何其他可能泄露会话 ID 的方式.

Session hijacking is simply the act of stealing an existing, valid session cookie. Most commonly through sniffing network traffic (a MITM attack), but also through any other ways that a session ID may be leaked.

会话固定与此类似，但相反 - 一个预定义的会话 cookie 植入到受害者的浏览器中.因此，在受害者登录网站后，他们将使用攻击者已经知道的相同会话 cookie，因此攻击者拥有的 cookie 现在已通过身份验证并可以被利用.
当然，这需要攻击者临时访问受害者的浏览器本身，但原理很简单 - 如果数据在您的控制之下，则无需窃取数据.

Session fixation is similar, but inverted - a pre-defined session cookie is planted into the victim's browser. So after the victim logs into a website, they will use the same session cookie that the attacker already knows, and thus the attacker-owned cookie is now authenticated and can be exploited.
Of course that requires an attacker to have temporary access to the victim's browser itself, but the principle is very simple - there's no need to steal the data if it is under your control in the first place.

重播有点不同，可能意味着两件事......

Replay is a bit different and can mean two things ...

如果攻击者已经可以访问会话 cookie(通过固定或劫持)，那么这只是为了他们想要的任何目的重用 cookie 的行为.
否则，它可以指欺骗受害者重新提交先前有效的请求(使用相同的会话 cookie).例如，用户可能会被诱骗购买多种数量的商品，而他们只想要一个单位.

If the attacker already has access to a session cookie (via fixation or hijacking), then it's just the act of reusing the cookie for whatever they want.
Otherwise, it can refer to tricking the victim into re-submitting a previously valid request (with the same session cookie). For example, a user could be tricked into buying multiple quantities of a good that they only wanted a single unit of.

注意:为了简化说明，我到处都使用了会话 cookie"，当然还有其他传输会话 ID 的方法.

如何保护自己免受这些攻击:

How to protect yourself against these attacks:

• 使用 TLS (HTTPS) 来防止 MITM 攻击以及最常见的劫持方式.还要在 cookie 上设置 Secure 标志，以防止它们通过纯文本连接提交(即浏览器只会在使用 https:// 方案时发送).
• 在 cookie 上设置 HTTPOnly 标志，以便例如JavaScript 无权访问 cookie.如果 JS 不能访问 cookie，那也意味着它不能泄漏它们(不能被劫持)，但是还有很多其他方法可以利用客户端代码.
• 针对用户执行的每个权限更改操作(登录、注销、以管理员身份登录 - 如果有额外的表单)以及定期、短时间间隔重新生成会话 ID.这是针对所有 3 种攻击的缓解机制.
• 让您的应用程序拒绝与服务器端记录不匹配的会话 cookie，以防止固定.

• Use TLS (HTTPS) to prevent MITM attacks and thus the most common ways of hijacking. Also set the Secure flag on cookies, to prevent them being submitted over a plain-text connecition (i.e. browsers will only send when using the https:// scheme).
• Set the HTTPOnly flag on cookies, so that e.g. JavaScript doesn't have access to the cookie. If JS can't access cookies, that also means it can't leak them (can't be hijacked), but there's lots of other ways to exploit client-side code.
• Regenerate session IDs on every privilege-changing action a user performs (login, logout, login as admin - if there's an extra form for that), as well as on regular, short time intervals. This serves as a mitigation mechanism against all of the 3 attacks.
• Have your application reject session cookies that don't match a server-side record, to prevent fixation.

这篇关于会话重放 vs 会话固定 vs 会话劫持的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！