好的，与其看漏洞，不如看可能的攻击路径。我会在这里添加一个表格作为 TL/DR。
Attacker | Vulnerable?
Eavesdropper | Yes
MITM | Yes
Local Attack | Yes
Server Attack | Yes
是的，这确实是一个问题。
远程攻击者可以观察流量，但无法修改流量
考虑一下在咖啡店中的被动攻击者。他们可以看到所有的TCP级别流量。
SO的请求和响应默认情况下不加密。您可以通过HTTPS浏览，但默认情况下只有HTTP。
因此，攻击者可以看到任何请求，并检查/窃取数据。
我们来看看GlobalLogin令牌是否会在请求中被发送...
事实上，它是会发送的。在登录页面上，通过iframe发送了一个请求到以下URL：
https://stackauth.com/auth/global/read?request=//snip//
那个 URL 返回一个脚本：
var data = {
"ReadSession":"https://stackauth.com/auth/global/read-session",
"Request":"//snip//",
"Nonce":"//snip//",
"Referrer":"//snip//",
"StorageName":"GlobalLogin"
};
var toMsg = window.parent;
var obj = localStorage.getItem(data.StorageName);
if(obj != null) {
var req = new XMLHttpRequest();
req.open(
'POST',
data.ReadSession+
'request='+encodeURIComponent(data.Request)+
'&nonce='+encodeURIComponent(data.Nonce)+
'&seriesAndToken='+encodeURIComponent(obj),
false
);
req.send(null);
if(req.status == 200){
toMsg.postMessage(req.responseText, data.Referrer);
}else{
toMsg.postMessage('No Session', data.Referrer);
}
}else{
toMsg.postMessage('No Local Storage', data.Referrer);
}
请注意，GlobalLogin是通过HTTPS发送到服务器的。因此，远程攻击者无法获取GlobalLogin令牌，即使他们能够读取流量。
因此，GlobalLogin部分是安全的，不会被窃听者窃听。
但是，请注意，由于会话cookie是通过HTTP发送的，因此仍然很容易受到嗅探的攻击。
远程攻击者可以修改流量（MITM）
如果您可以修改流量，则可以做一些有趣的事情。
初始页面通过HTTPS创建一个包含上述stackauth.com URL的iframe。如果您可以修改初始页面（也可以通过XSS实现），则可以将请求降级为HTTP。
StackAuth.com将不会受到影响。当它向stackauth.com发出请求时，您需要拦截该请求，并将其ReadSession URL也更改为HTTP。
但是，您只需要观察对ReadSession URL的调用，就可以窃取GlobalLogin令牌。
但是，流量已经是HTTP了，因此如果您不需要通过这种方式来窃取cookie，那么这没有任何意义。那为什么要费心呢？
本地攻击者
如果有人可以访问计算机以读取本地存储文件，则他们可以做比仅窃取您的登录令牌更严重的事情。
有一类攻击称为“浏览器中间人”，其中浏览器中的妥协使攻击者可以随心所欲地操作。
除了尝试保持浏览器安全之外，没有真正有效的保护方法（您无法从自己的端口执行任何操作）。
因此，如果攻击者可以获取对计算机的本地访问权限，则游戏结束了。
基于服务器的攻击者
如果攻击者可以访问StackOverflow的服务器，则无论如何游戏都结束了...
结论
只要允许HTTP（因为MITM始终可以将连接降级为HTTP），就没有什么可保护的，因为会话密钥始终可以通过窃听来窃取。
唯一保护此信息的方法是使用HSTS并强制使用HTTPS。
值得注意的是，您可以通过在stackauth.com上强制使用HSTS，使GlobalLogin受到保护，而仍然可以通过HTTP访问主站点。这将无法防止攻击的影响（会话劫持）。但是它会保护一个向量。
但是，通过HSTS全面使用HTTPS只是预防这些问题的最佳且唯一方法。其他任何措施都是给枪伤涂上创可贴。
注意：在发布此文章之前，我已经与SO进行了交谈。
