亲爱的habrozhitel！ 尊敬的专家！ 我为您评估了一个新的网站用户身份识别概念，希望在您的帮助下成为开放的Internet标准，使这个Internet世界变得更好一点。 这是无密码身份验证协议的草稿版本，设计为免费文章。 亲爱的读者，如果它的想法得到您的正面评价，我将继续在reddit.com和rfc-editor.org上发布。 我希望我能够引起领先浏览器开发人员的兴趣。 因此，我希望您提出建设性的批评。

注意：大量文字。


问题是。 是否可以明确标识站点访问者而不泄露他们的个人数据并在不同站点之间进行跟踪？ 解决这样的问题，是否有可能完全放弃登录名/密码所使用的最原始的授权形式，而使用cookie / localStorage？

一方面，站点需要识别客户，以便例如“恢复”其设置，产品篮，广告，文章等。 另一方面，访问者希望尽可能保持匿名，而不泄露其个人数据，并阻止第三方站点对其进行跟踪。 后者可以通过在彼此之间交换所收集的数据来做到这一点。

听起来像是要确保狼吃饱了，羊是安全的任务。 这是真的吗？

在某种程度上，我认为我-是的。

目录

1无密码认证概念
1.1键和令牌，而不是登录名和密码
1.2代币结构
1.3 HTTP协议标头
1.4客户如何识别站点？
1.4.2如何知道站点是否支持此协议？
1.5客户如何授权网站？
1.6如何实施可靠的客户识别？
1.7通过用户的眼睛对网站的授权
1.8站点密钥如何更改？
1.9如何实施跨域授权？
1.10如何实现跨域认证？
1.11帐户移动性

2协议的技术说明
2.0域密钥生成算法
2.1计算源令牌的算法
2.2传输期间的令牌保护算法
2.3浏览器和服务器之间的盐交换程序
2.4上下文字段的形成规则
2.5定义发件人和收件人字段的规则
2.6上下文定义表的详细信息
2.7协议场景
2.8在服务器上处理令牌
2.9跨域认证

3安全建议
3.1保护关键信息免遭未经授权的访问
3.2关于密码作为域密钥
3.3丢失/破坏密钥并将密钥最小化的风险

4攻击授权方案
4.1用户跟踪
4.2 XSS攻击
4.3 CSRF攻击
4.4使用SSO进行跟踪
4.5 SSO的主要危害
4.6转让期间的代币泄露
4.7入侵网站并破坏令牌

结论

1无密码认证概念

1.1键和令牌，而不是登录名和密码

对于每个域（包括子域），客户端浏览器都会随机生成一个唯一的256位密钥 $$ 。 此密钥从不发送。 在用户会话中保持不变。 每个新会话都会创建一个新密钥。
基于密钥 $$ 浏览器使用特殊算法生成256位^*令牌 $$ 识别具有特定域的用户。 识别令牌 $$ 用户（以下简称为令牌）代替了会话cookie（例如PHPSESSIONID和JSESSIONID）。
关键 $$ 可以由用户“ 固定 ”。 修复密钥将使用户可以在不同的浏览器会话中无限期地保留在站点上的授权，并返回以前存在的授权。 这类似于“记住我”功能 。
取消提交后，浏览器将“忘记”该密钥，并再次开始为每个新会话（从当前会话开始）为该域生成一个随机密钥， 类似于用户从站点的“退出” 。 输出是即时的，不需要重新加载页面。
用户可以为域创建一个永久密钥 。 永久密钥以及固定密钥将允许用户返回先前的授权。 实际上，该密钥替代了登录密码连接。
用户有机会控制域的浏览器何时使用常数键，以及何时-随机。 这类似于登录/注销功能 。 下面的屏幕快照中介绍了该概念。
生成永久域密钥的方法提供了不同设备之间用户帐户的移动性。 该协议定义以下内容：

• 根据用户主密钥生成域密钥
• 基于生物随机数传感器分别形成域密钥
• 从另一个设备的密钥文件导入现有密钥

1.2代币结构

令牌是256位结构，表示为十六进制字符串：

令牌的标识部分（最高128位）类似于登录名。 通过此位序列，服务器可以唯一地标识用户。
令牌的身份验证部分（低128位）类似于密码。 此位序列有助于服务器验证令牌。
令牌验证规则如下所述 。

1.3 HTTP协议标头

客户端使用的标头：

CSI-Token ：<Token>用于将令牌发送到服务器
CSI-Token ：< 令牌 1>; Changed-To <令牌2>用于更改当前令牌：

• 在授权使用永久密钥时，
• 注册永久密钥时，
• 更改永久密钥时。

CSI-Token ：<Token> 永久由用户修复当前的随机密钥时使用。
CSI-Token ：<Token> 注销用于过早结束当前会话。

服务器使用的标头：
CSI支持：yes告诉客户端服务器支持CSI授权协议。
CSI-Token-Action：CSI-Token-Action：成功用于通知浏览器有关新用户令牌（Change-To密钥）的接受。
CSI-Token-Action：CSI-Token-Action：中止会取消更改令牌的过程（回滚到前一个令牌）。
CSI-Token-Action：CSI-Token-Action：注册告诉浏览器新用户令牌仍在注册过程中。
CSI-Token-Action：无效的服务器端令牌验证错误。

终于
交换用于保护令牌的“盐”（身份验证部分）时，浏览器和服务器都会发送CSI-盐 。 有关更多详细信息， 请参见下文 。

1.4客户如何识别站点？

网站可以使用令牌来标识网站访问者。 同时，令牌生成方案及其256位容量可为每对用户域保证唯一的令牌 。 另一个域将看到另一个用户令牌。 即使在目标站点的上下文中执行（通过IFRAME，IMG，LINK，SCRIPT）。 此外，一种特殊的令牌生成算法可保护用户免受XSS和SRF攻击，并使其无法在用户不知情的情况下进行跟踪。 但是与此同时， SSO技术仍然可以通过其许可和跨域标识来实现。
令牌与每个对任何域资源（页面，文档，图像，脚本，样式，字体，文件，ajax请求等）的请求一起在CSI-Token HTTP标头中传输 ：

在每个 HTTP（S）请求 ：页面，图片，ajax请求中都会重新计算令牌。
为了优化计算，允许浏览器对令牌进行缓存，但是仅在会话持续时间内并且仅在满足请求的条件保持不变的情况下才允许对令牌进行缓存。
如上所述，令牌可以替代会话cookie（例如PHPSESSIONID和JSESSIONID）。 唯一的区别是，如果该站点先前为访问者生成了一个标识符，以在其不同请求之间跟踪特定用户（毕竟，来自不同用户的数千个请求同时到达该站点），则客户端现在将执行此功能。
这样的识别足以让您在网上商店进行购买，在适当的网站上做广告，在论坛上，在社交网络上，在Wikipedia或Habré上写字。
是的，用户对该站点保持匿名。 但是它可能是该站点的匿名“熟悉”站点。 服务器可以将此类用户的令牌及其数据（带有购买，偏好，业力、,头，喜欢和其他奖励的个人帐户）连同其数据一起保存在其一边。 但仅在完成任何业务流程的条件下进行：购买，提交公告等。 条件由站点本身确定。
如您所见，对于不需要在向您采取任何行动之前进行注册的网站，该协议尽可能地简单。 但是那些需要它的人会遇到一些困难。 但是下面有更多关于它的内容。

1.4.2如何知道站点是否支持此协议？

该站点应在其响应的“响应标头”部分中通过“ CSI-Support：是” http标头：

看到这样的标题，浏览器将毫不干扰地通知用户他可以将自己保存在网站上。例如，地址栏中的钥匙符号：

例如，点击一个键，将为www.youtube.com域创建一个键：

新密钥的形成不会导致其自动使用。

永久密钥仅在用户激活后才开始使用。

1.5客户如何授权网站？

重要的是要了解令牌还不能使用户在特定站点上获得授权-只能被识别。但是，正如已经说过的那样，现在您只是一个可以识别的“匿名者”。
如果该站点需要将您的令牌与您个人相关联，那么请避免在该站点上注册。但是在提议的协议中，这变得容易一些。

对于开发人员而言，重要的是要理解：大多数站点不需要问卷。避免强迫访客注册。在大多数典型情况下，您可以执行业务流程而无需收集PD访问者。

“有或没有”填写繁琐的注册表是不愉快的。但是，使用新协议，不再需要提供另一个登录名和密码。仅“确认并保存我”按钮：

当然，您必须首先为该站点创建一个永久密钥。但这只是几次鼠标单击的问题。
而且，可以肯定的是，将要求您确认电话或邮寄地址。但这已经取决于站点。
授权成功后，服务器将通过特殊的HTTP标头CSI-Token-Action将通知浏览器它已接受新密钥。第二章有更多细节。

1.6如何实施可靠的客户识别？

在更严重的情况下（提供者，托管人，银行的个人帐户），应该并且可以进行两步验证，并且可以通过其他方式通过电子邮件的预先注册和身份确认来完成令牌拥有的证明：通过电子邮件，SMS甚至是通过固定用户令牌的书面方式。（是的，是的。证书记录在纸上，为什么不是令牌）。

1.7通过用户的眼睛对网站的授权

浏览器通过地址栏中的锁定图标通知用户该站点支持CSI授权。如果您在网站上执行某些操作，则可以要求网站记住您。从这一刻起，服务器将即使在不同的会话之间也可以识别用户：


用户可以不固定密钥，而可以为站点创建永久密钥并在此处注册。动画插图：


并且，当用户拥有该站点的永久密钥并且该密钥在此处注册时，登录过程将大大简化：


当用户基于主密钥为站点创建密钥时，将体现出协议的最大功能。在这种情况下，可以轻松解决在其他设备上的站点上进行标识的问题。以下动画对此进行了演示。假设您之前曾在设备/浏览器之间分配过一次主密钥：


对于具有两要素授权的网站，“识别”可能如下所示：


退出更加容易。在浏览器中单击“注销”，仅此而已：

浏览器使用HEAD方法将请求发送到站点（在任何页面上），并在其中发送CSI-Token <>标头；注销。

服务器看到这样的标头，将注销。如果它是固定密钥，则该站点将删除有关该用户的所有信息（绝不会出现更多此类密钥）。如果它是永久密钥，则中断会话。
该网站的任何进一步活动都会使用户变成该网站未知的匿名用户：重新加载页面，尝试发出ajax请求，下载文件等。-浏览器将发送已经基于随机密钥生成的令牌。

您可以在密钥管理器中管理密钥：更改永久密钥，将永久密钥导出到文件，从另一设备从文件导入。关闭标签页或浏览器后，设置“自动退出”。设置固定键的持续时间。

1.8站点密钥如何更改？

从技术上讲，替换站点的永久密钥与将随机密钥更改为永久密钥相同。在第二章中对此进行了更详细的描述。
在更改站点的永久密钥的情况下，浏览器会通知站点令牌中的相应更改，并在随后的每个请求中发送带有Changed-To密钥的CSI-Token标头：

该站点必须正确处理此类请求。并且，如果给定的用户令牌存储在其数据库中，则必须进行适当的替换。同时，网站应就其一侧令牌的成功更改对浏览器做出响应。他在Response Headers头中使用参数CSI-Token-Action：success，指示所应用的令牌来执行此操作。
该站点有权拒绝使用CSI-Token-Action：aborted参数 更改令牌的尝试（例如，如果其数据库中没有此类令牌或根本不保存它们）。
在浏览器收到CSI-Token-Action标头之前，它将向每个站点的CSI-Token请求添加Changed-To键。
这类似于用户的“密码更改”。

1.9如何实施跨域授权？

使用SSO技术的经典跨域授权对用户而言具有许多优势。 您无需记住来自多个站点的一堆密码。 无需注册和填写沉闷的表格。 某些授权服务器询问授予请求SSO的站点的权限。
但是也有缺点。 您取决于SSO提供程序。 如果SSO服务器不起作用，您将无法到达目标站点。 如果您丢失密码或您的帐户被盗-您将一次失去所有站点的访问权限。
对于Web开发人员而言，事情要复杂一些。 从一开始，您需要在授权服务器上注册您的站点，获取密钥，学习如何使用协议（ SAML ， OAuth等）和相应的库，确保密钥不过期，并且授权服务器不会由于您的原因而阻止您的站点，并且等 您无需保留用户帐户，注册表格，登录等信息，这是收费的。 事实增加了维护成本（以修复突发故障的形式）。 同样，如果该服务器突然无法访问该站点，则可惜。
这种授权方案使SSO更加安全，并且对所有参与者的授权也更加容易。 关于安全性，将在下面的“ SSO的密钥妥协”部分中讨论。

看一下支持Google SSO的站点S。 假设您有一个Google帐户。 要登录，请单击“使用Google登录”链接，这将打开Goog​​le授权标签。 浏览器会告诉您您具有Google密钥。 Google会告诉您S.请求什么权利。
如果您同意，请在密钥管理器中单击“登录”。 页面将重新加载。 Google将已经收到其有效令牌，可以识别并授权您。 并通过服务器间请求，它将根据请求的字段将您的帐户信息通知站点S。
重新加载的页面将包含一个“下一步”按钮，可将您返回到目标站点。


站点S可能决定是否将有关您的数据保存在其数据库中。 此问题超出了建议的授权方案的范围。 但是，此外，在考虑丢失SSO密钥的风险的情况下，建议该站点将SSO的用户令牌和标识符保留在其一边，并建议用户为S创建永久密钥。

漏洞：获得授权后，站点S1，S2，S3 ...（您通过Google登录的站点）将能够识别您（通过Google分配给您的标识符），从而跟踪您的活动。

保护选项：如果您通过同一提供商的SSO注册，则不能同时在站点上工作。 如果可能，在完成授权（域的“自动退出”）后立即从授权服务器注销。

1.10如何实现跨域认证？

当然，所有这些都是好的。 尽管工作是在一个浏览器上进行的，但是一切都很好。 但是，当一个人拥有两部手机，一部工作计算机和几台浏览器，一部家用计算机和另一台笔记本电脑时，现代现实又如何呢？ 以及为妻子/孩子准备的通用平板电脑。
我们必须以某种方式解决在浏览器，设备之间转移域密钥的问题。 并且还解决了它们正确同步的问题。
解决该问题的机制之一是基于公共主密钥来计算各种域密钥，而没有从已知域密钥反向恢复主密钥的可能性。
在一个设备上使用主密钥M为域D创建了个人密钥K之后，用户可以使用相同的主密钥M和单个算法在域D上以及在其他任何一个域上创建相同的密钥K。 更准确地说，这不是由用户而是由他的浏览器完成。 使用这种方法，用户就可以在他使用的所有浏览器之间分配他的主密钥，并且他可以立即“转移他的所有密钥”域。 同时以这种方式进行备份。
最大程度的用户便利。 但是 ，如果万能钥匙失窃， 也将带来最大风险 。 因此，后者必须得到相应的保护。 “ 3安全建议”一章中介绍了丢失或破坏主密钥的风险以及将此类风险降至最低的方法。
仅使用一个主密钥来生成所有域的所有密钥并不总是一种方便的选择。 首先，如果域密钥突然遭到破坏并需要更改，该怎么办？ 其次，如果您需要与他人共享域密钥怎么办？ 例如，在家庭成员之间。 还是公司的公共邮件访问帐户。 然后如何“领取”您的密钥（因为实际上它已被盗用）？
因此，浏览器必须支持使用生物随机数传感器生成单个域密钥。 但是，我们再次回到移动性和同步性问题，在浏览器中导出和导入密钥以及创建备份副本的功能。

通过可转让的物理设备转移

智能卡和USB令牌非常适合作为密钥信息的安全存储（因为它们是为此创建的）。 两因素身份验证通过直接访问设备来保护密钥免遭未经授权的访问。
的确，智能卡需要特殊的读取器（更不用说驱动程序了），这限制了它们只能用于配备有此类读取器的工作站。
使用USB令牌要容易一些。 只需要驱动程序。 但是您不能在手机中粘贴这样的令牌。 而且，尽管对于移动电话，有以SD卡形式生成的令牌，但这并不是说此解决方案增加了移动性。 尝试从手机中提取一张卡，但将其插入另一张中。 这不是不可能的。 问题是它不方便。
如果令牌破裂？ 然后，您所有的钥匙都将进入大克苏鲁。
因此，这种使用多个重复设备的方案很有吸引力。 但是，如果您有多个智能卡，则仍然需要解决密钥同步问题。
而且，坦率地说，此类设备不受键盘记录程序的保护。 现在，如果将通过卡/令牌本身输入密码。 然后另一件事。 但是我从没见过这样的天性。

优点：可以使用随机的256位密钥； 通过使用两因素身份验证实现高安全性； 防止直接篡改的最高级别的保护。
缺点：设备依赖性； 需要财务费用； 行动不便； 需要保留卡并因此在它们之间同步数据； 键盘记录程序仍然存在漏洞。

通过在线服务同步

现在尽可能地推销“云技术”。 看来它们与区块链一起已成为“香蕉技术”的替代品。 自然地，希望使用某种因特网平台来交换关键信息。 一种智能卡“在线”。
什么啊 您在这样的站点上使用我们的计划匿名登录； 将用密码加密的密钥发送到该处； 您使用相同的密钥/密码从另一台设备转到相同的站点； 您从那里得到钥匙； 您可以按编辑日期同步更改。 与密码管理器类似，仅此功能在线。
就是说，没有人能保证在线服务不会被黑或不会合并您的（即使是加密的）“必要时”密钥。 谁将免费实施这种服务。 就是这样
当然，虽然密码可以防止密钥被直接使用。 但是您的密码可以抵抗暴力“离线”吗？ 那是另一个问题。

优点：高凭据移动性； 设备和浏览器的独立性； 您只需要一个密码（尽管他们没有留下密码，但最好还是这样）。
缺点：安全性不如将密钥存储在可移动媒体上。 实际上，密钥的安全性取决于选择密码的强度。

当然，您可以使用主密钥来加密其他密钥。 用于计算其他域密钥的密钥。 作为一种选择。

2协议的技术说明

2.0域密钥生成算法

该协议仅定义了两种生成域密钥的方法。

• 基于随机数生成器（最好是生物学的）
• 基于256位主密钥

在后一种情况下，域密钥的计算公式为：

$$

在哪里 $$ -256位主密钥，域-为其创建密钥的域名。
在下文中， HMAC是基于SHA-2哈希函数的256位实现的哈希密码算法 。

妥协或自愿披露域密钥不会损害原始主密钥。

主密钥提供了用于移动用户凭证的机制。

如果破坏了基于“主”创建的密钥，或者破坏了根据此类密钥计算出的令牌（由于黑客入侵了站点），则必须更改密钥。 您可以将其更改为随机的256位密钥，或者从相同的“向导”生成它，并添加以下版本：

$$

在下文中，符号 $$ 将用于字符串连接操作（字节数组）。

2.1计算源令牌的算法

用户的身份验证令牌是与任何域资源的每个请求一起计算的。 要计算请求令牌，将获取以下数据：

• 发送方 -请求发起方的域名（可以是带有iframe的页面或其他人的域中执行抓取的脚本），
• 收件人 - 收件人的域名（发送请求的位置），
• 上下文 -请求执行上下文，
• 保护 -如果Context为空，则为32个字节（256位）的随机序列； 否则为空

在发起请求的域的密钥K上，此数据被连接并用256位SHA-2 进行哈希处理：

$$

当Context不为空时，将获得一个有效的令牌。 为了在目标站点上正确识别，必须满足条件“发件人=收件人=上下文”。

上下文字段与保护一起用于防止XSS和CSRF攻击以及防止用户跟踪。
下面将给出有关确定发件人/收件人/上下文的规则的更详细说明。

2.2传输期间的令牌保护算法

原始客户端令牌很少被传输。 仅在创建会话时传输未注册的令牌时。
如果令牌是基于随机（非固定）密钥创建的， 则视为未注册 。 发送“更改为”或“永久”密钥后，服务器未接受该密钥。 有关更多详细信息，请参见“在服务器上处理令牌” 。
浏览器和服务器共同生成一对随机数，即所谓的 盐（Salt），令牌的低128位被散列。 两者都根据协议交换这些号码。 有关详细信息，请参见“盐交换过程浏览器-服务器” 。
因此，站点服务器看到以下令牌：

$$

在哪里 $$ -高128位， $$ -原始令牌的低128位， $$ -字符串串联。 在这种情况下，初始令牌 $$ 服务器应该已经知道。

理想情况下，每次浏览器请求服务器时，CSI-Salt都应该更改。 但是，就计算资源而言，这可能是一项昂贵的要求。 此外，它可以“杀死”向服务器发送并行请求的功能。
因此，为了优化计算，允许在不同请求中将CSI-Salt值保持不变， 但不得超过一个会话 。 这可以是时间限制（每5分钟更改一次CSI-Salt），或者是对请求强度的反应（每100个请求更改CSI-Salt），也可以是在一系列请求之后（在暂停时，客户端-服务器之间）或混合版本。 在这里，决定权留给浏览器开发人员。
长时间保持CSI-Salt不变会削弱对已传输令牌的保护，从而使攻击者可以在合法用户完成注销并代表受害者执行未经授权的请求时拦截令牌。

2.3浏览器和服务器之间的盐交换程序

2.3.1基于随机或未注册的^[1]服务器密钥的令牌。

2.3.2基于服务器^[1]注册的密钥的令牌。

---

^{[1]如果令牌是：根据随机密钥创建的，则视为未注册。 发送带有CSI-Token-Action：成功响应的Change-To或Permanent密钥后，服务器不接受该密钥。
[2]更改CSI-Salt的时间由浏览器本身确定。 在一系列请求之后，超时之后，一定数量的请求之后，可能会发生这种情况。 – CSI-Salt .
[3] 16- 128- . , : _salt || S _salt . – , . , , .}

2.4 Context

我们将我们的域名称为我们正在加载其页面的域名（显示在浏览器的地址栏中）。其余域将称为external。即使这些是给定的子域。如果

资源是从外部域下载的，则我们将其称为外部资源。如果资源是从我们的域下载的，我们将其称为内部资源。该资源可以是脚本，图像，ajax请求和任​​何其他文件。

如果脚本是从外部域下载的，则被视为外部脚本。放置在创建的<script>标记中的脚本（由外部脚本创建）也将被视为外部脚本。如果修改后的<script>标记中的脚本被外部脚本修改过，或者当其内容更改时在调用链中存在外部脚本，则该脚本将声明为外部脚本。即使此<script>最初同时在页面上，还是由内部脚本创建的。

我们呼吁LINK标签，SCRIPT，IMG，IFAME和其他需要在浏览器加载的资源，只要通过DOM解析器收到- 资源标签。

我们将其命名为FORM，A，META等标签，它们可以在某些条件下（提交，点击，超时）- 启动标签。如果

该标签最初是在服务器首次发布时出现在页面上的，则我们将其称为静态标签。如果标记是在运行脚本的过程中创建的，则我们将其称为动态标记。

FORM标记被声明为动态的，即使不仅标记本身已更改，而且与该表单关联的所有INPUT字段的值都已更改。

我们称之为动态标记自己，如果脚本创建属于我们的领域，如在催生这个标签是不属于外部脚本函数指令调用链。否则，我们认为这种动态标签不合适。

页面加载是通过启动标签触发的。发起标签可以由用户直接激活，也可以由脚本激活，可以通过执行click命令（对于链接）并提交（对于表单），也可以由脚本生成相应的onclick / onsubmit事件。

另外，启动标签可以由浏览器激活。此类标签的示例是META，其参数为http-equiv =“ refresh” content =“ 0”。

^{表P.不同页面打开条件下的上下文值}


如果资源标签被脚本（例如IMG的SRC属性）更改，然后资源被浏览器自动加载，则我们认为内容/资源是由解析器触发的，加载方法是标签，但是此标签的状态变为``动态''。

^{表R.在不同条件下加载内容/资源的上下文值}

---

^{[1]正在启动标签
[2]资源标签
[3]对于自己的页面继承，在打开外部域的页面时为空
[4]在将服务器重定向到其页面时进行继承，在将服务器重定向到其他域或从外部源打开页面时为空（请参阅。澄清）}


分析特定情况时，将使用P1..PF，R1..RC形式的标记来引用表中的相应单元格。

请注意第一个表中突出显示的“ 引荐来源网址和域 ”。仅当您自己在直接地址或通过其他站点的链接打开站点，然后自行重新加载页面时，才可以在站点上获得授权。

2.5定义发件人和收件人字段的规则

发送者是请求所来自的页面/脚本/样式的域。该页面要求样式，图片，脚本。脚本通过ajax请求内容。样式可以加载其他样式。这些是请求的发起者。

收件人是请求真正到达的域。

为了不遗余力，让我们考虑具体的例子。

让有一个site.net网站。在该网站的主页上是：

• 样式site.net/css/common.css
• common.css样式导入fonts.google.com/fonts/Roboto.css样式
• Roboto.css样式导入字体fonts.google.com/fonts/Roboto.ttf
• 导致img.site.net/picture1.jpg的图片
• 从adriver.ru/frame加载的框架
• adm.site.net/admin.js中的脚本

让框架（与adriver.ru）连接：

• 来自adriver.ru/style.css的样式
• 图片来自img.adriver.ru/img/01.png
• 来自adriver.ru/libs.js的脚本
• api.adriver.ru/v1/ad.js中的脚本

使用DOM解析器加载资源时的发件人/收件人值

现在，让我们看一下在执行Ajax请求期间使用脚本加载内容时的发件人/收件人的值。

使用脚本加载内容时的发件人/收件人值

2.6上下文定义表的详细信息

让我们更详细地考虑我们拥有哪些打开页面的选项（浏览器中的选项卡），以及将获得哪些Context值。

P1-前一页上的用户单击链接或单击表单上的提交按钮。链接/表单的标准事件浏览器处理程序将用户重定向到此页面。正常情况。域或不同域的页面之间的安全过渡。

从另一个google.com域切换到site.net时，上下文将等于先前的域（google.com）。并且新site.net域上的用户将被未经授权（即使打开了授权用户的该站点的相邻选项卡）。

用户通过链接重复访问同一站点（在没有脚本帮助的情况下），将再次导致情况P1，但上下文将已经等于域site.net，因为按照规则Context = Referrer。

旨在防止CSRF攻击。

P5-前一页的用户单击了从前一页的域下载的脚本创建/修改的链接；或上一页的用户单击由脚本创建/修改的表单的提交按钮（更改FORM标记，包括其INPUT字段）。链接/表单的标准事件浏览器处理程序将用户重定向到此页面。

P9与P5相同，只是脚本是外部的，或者调用链中有外部脚本的功能（防止第三方脚本编辑站点脚本的脚本功能）。

PD-用户在直接地址打开页面。安全开启。

用户必须通过在地址栏中输入URL来打开页面。或通过浏览器书签打开网站。

从另一个程序的桌面快捷方式打开链接，在操作系统向浏览器发送命令以打开链接的任何其他情况下，都应将其视为PG情况（打开链接由浏览器启动）。即使用户按F5重新加载页面，也应将其视为PG情况。仅当用户进入地址栏并按Enter时，浏览器才会将其视为PD。

这样做是为了保护CSRF免受其他程序的攻击。

跟随另一个程序的链接，用户将获得带有无效令牌和空上下文的受攻击站点，即使用户按下F5（刷新页面），上下文也将被保存。在用户打开指向该网站页面的任何链接（情况P1）之前，您无法登录。

因此，如果来自另一个程序的攻击者决定向授权用户提供指向执行命令的site.net站点页面的链接，则他将无法轻松地做到这一点。有必要迫使用户单击此页面上的另一个链接，然后强制用户在此进行身份验证，然后才进行身份验证。然后，该用户很可能位于site.net的另一个页面上。

P2-在上一页中原本放置在页面上的链接或表单上一页中，上一页的本机脚本生成了单击/提交事件。调用链中没有属于外部脚本的函数。浏览器将用户重定向到此页面。

如果新页面属于同一域，则上下文将从上一页继承。如果新页面属于外部域，则上下文将为空白。

P6与P2相同，只是链接/表单是由其自己的脚本创建/修改的。

PA与P2相同，只是链接/表单是由外部脚本创建/修改的。

PE-前一页上的脚本使用window.location.href或window.open（...）命令引发了该页面的打开。

如果site.net页面脚本将用户重定向到同一域的页面，则“上下文”字段将从继承的页面继承。在这种情况下，上下文= site.net。

如果ya.ru页面已打开，并且脚本将我们转移到maps.ya.ru，则新页面的上下文将为空。在用户的后续操作中，上下文几乎总是保持为空，这会使用户在站点上的授权复杂化。

该协议意味着打开一个站点到另一个站点是不安全的操作。这样可以保护用户免受这些站点的未经授权的跟踪和CSRF攻击。

P3-与P2相似，只有外部脚本触发了click / submit事件。上下文变为空（发送随机字节序列），这可以保护第三方站点免受跟踪该站点（横幅网络）。

P7-与P6类似，仅链接/表单是由外部脚本创建/修改的。

PB-与PA类似，只有链接/表单是由外部脚本创建/修改的。

PF-与PE类似，只有挑衅性脚本是外部的。

P4-由于处理<META>标签，浏览器重新加载了页面。标签最初在页面上。合法重定向。上下文将从原始页面保留。与PE一样。

P8-由于处理<META>标签，浏览器重新加载了页面。但是标记是由其自己的脚本创建/修改的。这是有效的，但上下文将从原始页面保留。与PE一样。这样就不可能吸引用户的合法令牌。

PC-与P8类似，仅是外部脚本。打开的站点将收到一个随机数字作为上下文。

PG-浏览器打开来自操作系统的命令链接。可能是，您单击了另一个程序的链接，在桌面上打开了一个快捷方式。这可能是来自另一个程序的命令，而您并不知道。在这种情况下，源不受信任，并且在任何用户操作期间，“上下文”字段将保持为空。

这样做是为了保护CSRF免受其他程序的攻击。

如果浏览器本身打开了先前保存的选项卡，则页面的上下文设置为等于关闭浏览器时此页面的值。

此外，此类别还包括所有由于处理Header HTTP标头而将服务器将浏览器重定向到另一页（其域或其他人的域）的情况。如果重定向转到您自己的页面，则将继承Context值。如果重定向转到其他人，它将被重置。

这样做是为了防止Web服务器受到跟踪攻击。

顺便说一句，这种规则可能会导致跨域授权的当前实现出现问题。如果在授权后，SSO服务器将用户重定向回目标站点，则该目标站点将在该站点匿名。

为了防止用户“丢失”目标站点上的原始授权，有必要在服务器请求之间传输身份验证信息。该算法可以如下：

1. 用户创建并激活目标站点的永久密钥；
2. 单击适当的链接从目标站点转到SSO服务器本身；
3. 从SSO服务器激活现有的永久密钥；
4. SSO服务器收到“更改至”密钥后，将服务器间请求发送到目标站点。
5. 用户单击授权页面上的“继续”按钮，将其返回到目标站点；
6. 为了满足规则P1，目标站点为用户提供了再次单击链接按钮的链接，并指向该链接按钮（例如，指向授权参与者的起始页）。
7. 用户单击链接按钮，页面将重新加载，并且该用户已在目标站点上获得授权。

该算法的描述实际上看起来比其实现更为复杂。UI实现可能如下所示：

重新进入目标站点不再需要用户的SSO授权。激活永久密钥就足够了。

现在，让我们仔细研究一下在页面上加载内容的选项，以及根据请求将获得哪些Context值。

R1-资源由浏览器作为解析页面的结果加载（浏览器符合资源标签）。从包含资源标签的“上下文”页面获取生成资源请求时的“上下文”值。

例如，如果site.net具有adriver.ru框架，其中加载了img.disk.com中的图像，则在生成对img.disk.com的HTTP请求时，浏览器会将为页面计算的值用作上下文。 site.net。

R4与R1相同。只有资源标记是由其自己的脚本创建/修改的，因此浏览器DOM Parser可以工作。例如，在site.net/index.html页面上，我们自己的site.net/require.js脚本插入了另一个自定义脚本（<script src = ...>标记）site.net/min.js，这迫使浏览器生成文件下载请求。 main.js。该请求中的“上下文”字段将设置为为site.net页面计算的值。

R7与R1相同。但是由于资源标签是由外部脚本创建/修改的，因此当请求资源时，浏览器将基于空的上下文和随机的256位序列生成令牌。结果，嵌入受攻击的site.net域页面上的攻击者evil.com/drop.js的外部脚本试图代表受害者完成对目标site.net的请求将失败，因为服务器将收到带有随机令牌的请求，并且将无法识别请求的发送者。

RA-解析器下载内容是对其他内容进行分析的结果。例如，为site.net/index.html页面下载的site.net/css/common.css样式表会导入fonts.google.com/fonts/Roboto.css样式表，这会强制浏览器请求fonts.google .com代表Referrer = site.net/css/common.css。在这种情况下，上下文值将等于Referrer。接下来，Roboto.css样式文件导入Roboto.ttf字体，这将强制浏览器代表Referrer = fonts.google.com/fonts/Roboto.css来请求fonts.google.com/fonts/Roboto.ttf。在这种情况下，“上下文”值将等于“引荐来源网址”，但这是不同的。

假设，假设Roboto.css文件（外部资源）没有导入字体/样式，而是尝试通过以下指令进行CSRF攻击：

@import "https://site.net/api/payment?victim_params" 

希望代表授权用户满足site.net上的要求。 但是攻击者面临的问题是site.net希望从用户那里收到令牌：

$$

然后，与CSRF请求一样，浏览器将创建一个令牌：

$$

并且对该站点的请求将代表一个没有执行这些操作访问权限的匿名站点。

RB-内容是通过网站自己的脚本上传的。 在这种情况下，上下文用于计算请求令牌，该令牌等于包含脚本的页面。 对于site.net上下文页面中的site.net/1.js脚本，它将等于页面本身的上下文。

请注意，页面本身的上下文并不总是等于页面的域名，而是取决于最初打开页面的方式。

假设攻击者evil.com的网站打开了受攻击网站site.net的页面，其中site.net/util.js脚本使用通过页面URL传递的参数执行请求。 攻击者希望通过在URL上滑动“他的参数”，来迫使自己的site.net/util.js脚本执行ajax请求，以代表受害者执行重要的操作。

假设用户本人通过直接链接访问了evil.com。 那么evil.com的上下文将是evil.com。 然后evil.com使用脚本打开site.net/api/payment?victim_params ，希望发起攻击，但是site.net的上下文字段将为空（PE / PF情况）。 执行ajax请求的site.net/utils.js脚本将强制浏览器从site.net页面获取Context。 它对我们来说是空的。 但是，site.net将收到带有此令牌的ajax请求：

$$

而对于授权用户，则期望：

$$

site.net将看到未知的令牌，并且将无法识别用户。 保护工作。

顺便说一句，由于这种方案，通过弹出窗口进行跨域授权将是不现实的。

要在协议下实施SSO，必须为授权服务器页面打开一个新选项卡。 同时，用户必须打开这样的选项卡。 最好的选择是从目标站点打开用户适当的链接。

RC-内容加载有外部网站脚本。 在这种情况下，上下文用于计算请求令牌，该令牌等于“请求引荐来源”字段。

尽管RA ， RB和RC可以抵御CSRF攻击，但它们仍然导致生成常量令牌。 这样，您就可以实现跨域身份验证和跨域用户身份验证 （当您需要确定对该用户发出的对不同服务器的多个请求时）。 可以采取哪些措施为他提供一组相关领域的平等权限。

如果该站点页面是从另一个站点自动打开的 ，则即使您自己重新加载该站点，也将无法登录。 因为Source将继承自空值。 浏览器应向用户发出有关此事实的信号（来源=随机）：

这样做是为了防止强制打开其他弹出窗口的站点（自身或其外部脚本），并且在打开的站点上，它们将重新引导或在通往同一站点的整个屏幕上创建假的“关闭”按钮。 即 这样可以防止尝试跟踪您，从而希望获得有效的令牌。

如果站点尝试使用外部脚本模仿您的操作 ，或者试图通过外部脚本直接或间接创建启动标签并将其拖给您，都会导致源为空，并且在计算令牌哈希时会添加随机字节。

在DOM的受攻击页面中创建或修改<script>标记的技巧无济于事。 Source字段将保留为空白。

但是在相同条件下，内部脚本将导致查询Source等于其先前值的查询。 如果原始页面具有Source = Domain，那么一切都会好起来的。 用户将继续获得此类请求的授权。

但是，从第三方资源（CDN）下载脚本后，在某些情况下可能会出现问题。 是的，因为 不保证CDN代码的完整性。 如果不想丢失用户授权，请将脚本保留在您的站点上，然后从您的域中下载它们。 这类似于禁止在https页面上使用http链接。

我们描述了开发人员可能会遇到的情况。 作为用户操作的结果，您的脚本将授权用户重定向到站点的页面之一（例如，通过表单完成），要求该用户保持授权。 例如，您的脚本使用从CDN加载的jQuery脚本调用$（form）.submit（）。 在这种情况下，浏览器会看到在触发表单提交事件的调用堆栈中，有一个来自外部脚本的函数。 为了防止XSS / CSRF攻击，浏览器将Source字段设置为空，并向令牌的生成添加随机字节（案例P9 ）。 结果，新页面上的用户突然变得未经授权，无法完成操作。 这会使习惯于使用CDN的开发人员感到困惑。

2.7协议场景

这是用户使用网站的主要可能情况，影响所有可能的情况及其实施阶段（匿名登录，“记住我”，“忘记我”，切换到使用永久密钥，授权和退出，注册和两因素身份验证，导出/密钥导入，密钥替换等）

基于.htaccess文件的令牌访问配置示例。

 <Directory "/var/www/html"> AuthType CSI AuthName "Restricted Content" AuthTokensFile /etc/apache2/.csi_keys Require valid-user </Directory> 

 猫/etc/apache2/.csi_keys 

 # # Client Self Identification tokens file # # CSI-Domain-Key UserName Role 84bc3da1b3e33a18e8d5e1bdd7a18d7a166d77ac1b46a1ec38aa35ab7e628ab5 MelnikovIN admin 6d7fce9fee471194aa8b5b6e47267f0348a24b70a0b376535542b996af517398 BoshirovAM user 

2.7.1使用已知密钥计算站点可能的用户令牌的算法

如果我们知道域密钥K，则可以轻松计算出将随其请求一起出现的用户的可能“有效”令牌T。为此，必须满足条件：请求的发起者，请求的接收者以及执行上下文必须匹配并等于域。换句话说，如果我们拥有vsphere.local域名，则：

 Sender = Recipient = Context = vsphere.local 

从这里开始，原始（原始）令牌的计算公式为：

$$

传输后，原始令牌将得到进一步保护。令牌的低128位将与在CSI-Salt ^*请求标头中传递的盐一起哈希。因此，该站点将看到以下令牌：

$$

其中，Hi是高128位，Lo是原始令牌的低128位。
通常，对于公司网络上的封闭式管理控制台，Web控制台不会加载外部脚本，框架等。因此，在大多数情况下将满足此条件。

---

^{*有关成盐的方法，请参阅“浏览器和服务器之间的盐交换过程”一节。}

2.8在服务器上处理令牌

将令牌发送到服务器（无密钥）

Permanent

浏览器锁定客户端密钥。用户希望站点记住一个以上会话的客户。是否将用户令牌存储在其数据库中由服务器决定。我们将CSI-Token-Action：成功或CSI-Token-Action：中止返回给客户端。

使用注销密钥发送令牌

指示当前令牌将不再被浏览器使用。当用户单击浏览器中的“退出”，或关闭选项卡并且配置了选项（关闭选项卡时自动退出），或者拒绝使用固定键（“在此站点上忘记我”）时发送。

顺便说一句，不应该自动登录。出于安全原因。

使用更改至密钥发送令牌

我们将旧令牌称为T，将新令牌称为T'。

重要说明：作为新令牌T'，令牌的实际值被发送（对于未注册的令牌，是第一次），而旧令牌是散列的（低128位）。

---

^{* , .}

2.9 -

如前所述，站点可以与其他合作伙伴站点或其子域进行交互，以向用户提供某些功能。最常见的示例是，当在site.ru网站上某些资源是从img.site.ru子域加载的，一部分是download.site.ru的一部分，另一部分是其他资源的一部分。

在这种情况下，site.ru网站需要能够告知其合作伙伴域确切向谁发出了请求。实际上，如果您在site.ru上获得了授权，则不会自动使您在其他站点（包括该站点的子域）上得到授权。他们还会看到您的其他令牌。

让我们看看令牌是如何计算的，以及如何为我们提供帮助。
让用户使用永久密钥登录到site.ru并在其中拥有令牌：

$$

从site.ru网站页面到site.ru域的所有请求都是由以下原因引起的：

• 页面资源标签（静态或本机动态）
• 自己的脚本

将具有令牌T ₁（请参阅规则R1，R4和RB）。这些是对site.ru的合法请求。

现在，让客户端从site.ru页面下载受限制的文件，但是该链接指向download.site.ru。在这种情况下，子域将收到以下令牌（规则R1，R4）：

$$

如果在site.ru网站页面上执行了ajax请求（RB，RC规则），则将获得完全相同的download.site.ru令牌。

另一个域域将收到令牌：

$$

但是，请注意，如果满足请求的条件没有改变，则对于给定的域A，B，C，浏览器将始终生成一个常量令牌。因此，我们可以进行跨域识别。像这样

从site.ru，我们对子域进行ajax请求。我们传递由site.ru颁发给用户的标识符ID！= T _1。子域得到这个相同的用户ID令牌牛逼_X。每个子域都会使用用户ID生成一堆令牌。子域将已经通过服务器到服务器的请求共享有关用户ID及其权限的信息。

一堆完成一次。随后，子域将以其自己的令牌为导向，如 它们对于site.ru永久密钥也将是永久的。

3安全建议

3.1保护关键信息免遭未经授权的访问

提议的授权协议可保护用户免受键盘记录程序窃取您的密码的侵害，因为提议的方案根本不使用密码。

但是，应该更详细地考虑保护密钥免受破坏的方法。

可以通过以下方式破坏密钥：

• 通过恶意软件复制关键信息（远程访问）
• 通过关键信息“离线”直接访问文件（直接访问）
• 在设备之间分发时

假设密钥信息存储在智能卡上（我们在“帐户移动性”部分中考虑了此选项），则保护密钥信息的任务将转移到芯片上。没错，按键记录程序存在一个漏洞，可以拦截输入的PIN码。好吧，使用上不便。

除智能卡外，对称加密还可用于防止直接访问密钥信息。但是问题是：加密采用什么密钥？

如果此密钥是根据用户的密码生成的，则首先，我们容易选择“脱机”密码，其次，实际上，他们留下的内容是：“再次输入了一些密码”。

更加正确的选择是以特殊方式缝制^*浏览器程序集（或其专用库之一）中的此类密钥。每次浏览器更新都会更改密钥及其在已编译文件中的位置。这种方法不会提供100％的保护，但是会使解密任务严重复杂化。首先，攻击者将需要找出程序集的确切版本，然后找到它，将其拆解并找出密钥的组装方式。

同样，域密钥本身应直接存储在单独的文件中，而不是与其使用配置一起存储（即仅密钥，仅此而已）。然后，将不可能通过密钥选择（从已知程序集中）对它们进行解密，因为不可能从随机字节序列中区分正确解密的密钥。然后，尝试在不知道浏览器程序集确切版本的情况下拿起主键，而直接反汇编其代码将变得根本不可能。

您可以使用组合选项：使用浏览器的密钥加密+使用OS帐户的用户密码加密（如果OS API允许）。而且，密钥总是动态生成的。然后，离线暴力将变得更加昂贵。

另外，在操作系统中更改用户密码后，密钥也将更改。而且，如果您不对旧密钥进行预解密，则可以防止计算机管理员更改密码以访问您的帐户并代表您执行操作时的情况。类型的情况：辞职。

您将首先制作密钥的备份副本（将密钥导出到文件中）。当然，除非您在将密钥分配给其他设备之前已经这样做。

---

^{*例如，一个32字节的密钥随机分布在可执行文件的64K部分中。而且只有源代码知道如何从这些字节中收集珍贵的密钥。}

3.2关于密码作为域密钥

在协议的初始版本之一中，可以根据用户的密码生成域密钥。该算法非常棘手，它排除了针对同一密码的不同域的重复密钥。

这被定位为通行帐户的便捷方式。输入一个密码，不用担心。但是后来发现：

1. , «» , , . , -, .
   
   (), 8- , , .: ~!@#$%^&. : 26 + 26 + 10 + 8 = 70 . 8- 70 ⁸ .
   
   , , 10 ¹² . 70 ⁸ / 10 ¹² = ~576 . 即 ~10 . 5 . 10- 15 . 10 , 1-2 .
   
   , .
2. , .
3. , . 即 ( SHA-2).
4. , , , . .

3.3 /

如果我丢失了万能钥匙怎么办？

如果您更改密码或重新安装操作系统，则可能发生这种情况。有什么风险？

好吧，您将无法访问以前的站点。失去在线商店的购物记录，在线网站上的广告，论坛上的业力。没关系

但是，谁阻止使用新令牌进行重新注册过程并通过同一公告中指示的电话号码进行确认？原来，该站点需要对令牌进行某种形式的重新注册（类似于“密码恢复”）吗？保证没有“各种”形式的地方在哪里？

实际上，一个站点不仅需要识别访问者，而且还必须知道其真实身份，因此必须制作注册表。实际上，该表格可以用于重新注册。您指定的数据与以前完全相同（电子邮件，移动电话）。确认您具有这些数据（字母，SMS）。系统看到这样的帐户已经存在，数据是您的100％，但是令牌不同-它重写了令牌。

但是，仍然最好不要丢失主密钥。

如何防止损失？创建备份副本，使用密码保护它并将其存储在一次性介质上。而且，实际上，就像比特币的密钥一样。原则上，您可以将主密钥转换为印刷形式并将其保存在一张纸上。为此。然后通过手动输入还原。但这是针对像我这样的“偏执狂”的人。

但是，如果万能钥匙被我偷走了怎么办？
这已经很严重了。尽管此处描述的用于存储主密钥（未包含在协议中）的建议可以防止它们遭到直接篡改，但键盘记录程序和木马程序仍然可以避免损害主密钥的风险。不幸的是，不存在完善的保护措施。可以通过javascript引擎漏洞直接从浏览器内存中劫持密钥。举个例子。还是您丢失了手机...

那么，窃取主密钥有什么风险？

接收有关您的信息甚至代表您采取行动所必需。获得攻击者以您的身份并以读取模式登录以获取敏感信息的能力。安静安静。或一次下载来自同学的所有私人视频。对你来说很不愉快海豹爱好者很高兴。

在这里，您需要快速在重要站点上使用新密钥重新注册。而且，如果发生了可怕的事情，那么以正确的方式在服务提供商的数据库中注册新令牌是唯一的正确选择。您可以想到许多注册方法：从正式信件中的纸张固定，到通过网站的技术支持服务进行的应用程序，以可接受的方式确认您的身份。但这仅适用于严重的网站，例如网上银行。

最小化风险的方法。在域中使用单个密钥（但这会减少帐户的移动性）。通过独立通道进行两因素身份验证。该站点显示了上次连接的IP地址和设备，因此您至少会发现一个妥协。

4攻击授权方案

4.1用户跟踪

您信任的站点可以无耻地将有关您的信息与其他站点合并。在Internet上，有收集器站点，这些站点聚集了此类信息并将其出售给所有人。Yandex指标，Google Analytics（分析）-一个罕见的网站没有它们。

为了使两个不同的站点可以确定它们正在使用同一客户端，使用了两种技术：

1. ( , ).
2. ( ) .

方案2中有一个小缺点：不是标识用户，而是浏览器。但通常是浏览器==客户端。

似乎该令牌最适合在方案2中使用。毕竟，如果用户允许将自己“记住”到两个站点（作为一对），那么我们的永久令牌可以充当这样的“指纹”，不仅是浏览器，而且是用户本人。这里站点的问题在于它们将收到不同的令牌。

但是站点可以尝试也应用方案1。然后将得出以下结论。

站点1将从浏览器接收代码H ₁，并且在站点1的上下文中执行的站点2 将接收代码H ₂。现在看来站点可以形成一对（H ₁，H₂），甚至将其传递到某个聚合器站点。
假设有另一个站点3与站点2配对，试图跟踪您。站点3将从浏览器接收H ₃令牌，在站点3的上下文中执行的站点2 将接收H _2'令牌！= H ₂（请参阅令牌的形成方式）。结果，不可能合并获得的数据，他们没有重叠的部分。

但这并不意味着站点将无法使用指纹浏览器进行监视。它仅说明令牌生成方案本身是非常可靠的，并且可以防止跟踪。

保护选项：注销您已经使用完的网站。关闭选项卡时，浏览器可以自动执行此操作。

4.2 XSS攻击

XSS是一种攻击，涉及将恶意代码引入受害者网站的页面。例如，通过会员脚本或流行框架的被黑CDN。

恶意代码可以使用站点上的用户授权来获得对该站点的授权访问或窃取用户身份验证数据。可以通过Web服务器中的漏洞（琐碎的黑客攻击），会员网络（不可靠的来源），用户计算机上的漏洞（木马抓取）将恶意代码插入页面。

对于我们的授权方案，防止此类攻击的主要保护措施是在计算令牌时生成Source字段的特殊规则。

脆弱性：对于存储的XSS（当脚本被黑客入侵服务器直接插入受攻击的站点并从中加载脚本时），保护将不起作用。因为浏览器将无法将此类脚本标识为“外部”。当攻击者代理客户端-服务器流量时，也会发生相同的问题。

4.3 CSRF攻击

受害人访问了由攻击者创建的网站evil.com。代表她的请求（GET / POST / HEAD / PUT / DELETE）被执行到已经授权用户的站点（例如，支付系统服务器）。该请求本身执行某种恶意操作（例如，将资金转入攻击者的帐户）。根据开发人员的监督，该站点不会检查Referer字段，也不会向用户请求其他验证信息。结果，攻击成功。

拟议的站点授权方案可以抑制大多数CSRF攻击情形，这取决于令牌生成算法。任何跨站点请求都将导致受攻击的站点从用户那里收到无效的令牌。结果，在这种情况下，受攻击站点的用户将为匿名匿名。即使尝试从攻击站点向受攻击站点执行无害GET请求（上传图片），也会导致后者收到无效令牌。

这将大大简化站点开发人员的工作。

4.4使用SSO进行跟踪

用户信任并为其拥有密钥的两个站点S ₁和S ₂决定将类似于SSO的技术应用于用户跟踪。但是因为您无法将一个网站嵌入另一个网站（其中一个会收到无效的令牌），也无法使用脚本打开合作伙伴的网站（出于相同的原因），然后网站S ₁决定使用棘手的技术。

在其中一页上，他放置了一个半透明标签A，覆盖了整个窗口。链接通向站点S ₂，并且用户标识符（来自S ₁）和令牌H ₁在地址_中传输。用户看不到链接。通过单击站点S _1的任何区域，它将启动站点S ₂上新标签的打开。

目前，S ₂将不会收到有效令牌。使用标签自动重新加载也不会帮助他

 <meta http-equiv="refresh" content="0"> 

或脚本。

但是S ₂可以伪造的“关闭”按钮的形式在其整个页面上使用A标签：

此链接将首先重新加载该站点，然后将其关闭。在重新启动时，浏览器会将已经有效的H ₂令牌发送到S ₂站点（因为已遵循2.4 P1规则：用户已亲自打开了两个链接）。结果，S ₂将接收有关其用户在站点S ₁上的动作的信息，将令牌H ₁与它的H ₂相关联，并将服务器间请求发送给H ₂到S ₁。将来，站点S ₁和S ₂将能够通过服务器交换来交换有关用户的任何信息，例如 现在他们可以彼此独立地唯一标识它

。

移动用户特别容易受到这种攻击，因为 试图关闭不必要的页面可能会意外地点击占据整个移动屏幕的虚假链接。

保护方法：关闭选项卡时自动中断会话。然后，站点S ₂在用户本人登录之前无法接收到有效令牌。的确，当用户本人打开选项卡并登录到S ₁和S ₂时，这将无法避免这种情况。然后站点才进行了这样的攻击。

4.5 SSO的主要危害

让支持SSO的身份验证服务器上的用户帐户受到损害。我们将通过认证方案评估可能的风险。

每个站点的令牌都是根据域密钥单独计算的。

破坏一个域密钥不会自动破坏所有其他密钥。

您以前使用SSO登录的大多数站点可能会将令牌和您的个人资料从SSO服务器保存在其数据库中。在我们的方案中，站点将仅从数据库中提取令牌并识别您。即在此类站点上不再需要SSO服务器-它在注册阶段执行了其功能。

换句话说，您不会立即自动丢失所有访问权限。攻击者将与其他人在同一站点上被识别。

重新进行跨域身份验证的尝试也不会对攻击者有所帮助：站点应阻止尝试使用旧的SSO ID用户和新的站点令牌创建新帐户。或者，应阻止尝试为SSO进程中的现有ID重写用户令牌。这样的事实应该引起现场的合理怀疑。
用户令牌只能以一种方式合法地更改（请参阅“协议操作方案”）。

风险如果该站点未将您的令牌和配置文件保存在其数据库中，而是完全依赖于SSO机制，则攻击者只需执行跨域身份验证即可使用您的名称登录。

在妥协的情况下将风险降至最低。奇怪的是，但这是令牌和用户个人资料站点在其侧面保留的。攻击者尝试进行跨域身份验证可能会导致旧ID用户与其新令牌之间发生冲突。当用户以协议中指定的方式以外的任何其他方式更改令牌时，这种情况本身应被可疑甚至拒绝。

最大风险：代表您在其他站点（您尚未去过的站点）进行授权。访问您的个人资料数据。代表您实施违法行为。为了使合法所有者无法返回任何东西，攻击者可以通过合法方式在授权服务器上更改其令牌。但是，这种风险与使用传统授权方案时的风险一致。

保护方式。拒绝使用SSO（特别是因为提出的方案被认为是摆脱集中式身份验证方案的一种方式）。使用多个SSO（不要将所有鸡蛋都放在一个篮子中！）。

如果SSO支持通过其他属性（邮件，电话）进行身份验证的两因素身份验证，则可能会重新获得对授权服务器帐户的控制权。

4.6转让期间的代币泄露

显然，所提出的在传输期间对令牌进行哈希处理的机制并不能100％保证其受到保护。例如，攻击者可以在转移不安全的令牌时（在永久密钥的初次注册时）拦截受害者的流量。然后使用它。

因此，鼓励使用SSL。但不要将HTTPS视为灵丹妙药。该协议以及HTTP也被公开。仅难一点。

的确，开放令牌的这种罕见转移以及对每个域使用单独的令牌，降低了利用此漏洞的风险。尽管如此。

另一个危险是在用户的当前会话中拦截和重用令牌。就像我之前说的，理想情况下，应在每个客户请求时用新的盐对令牌进行散列。但是，这将消除在服务器上并行处理请求的可能性，并使不可能从客户端发送并行请求。计算和检查哈希值通常是一项昂贵的操作，会降低性能。

此外，标头中传递的令牌永远不能从Javascript获得。与带有HttpOnly标志的Cookie相似。即使在通过脚本接收ajax请求时也是如此。

操作方法：拦截用户的请求，提取令牌的当前值，使用相同的令牌（代表同一用户）发送另一个操作。的确，基于会话cookie的经典系统也容易受到此类攻击。

保护方法：通过其他通信渠道（例如，通过短信或邮件）确认重大操作；通过其他通信渠道对令牌进行预注册（例如纸质证书）。

4.7入侵网站并破坏令牌

黑客网站不断发生。即使是大型且受到良好保护的站点也会损坏。黑客攻击的方式有很多：从琐碎的注入到内部人员“流失”。因此，很可能会在任何站点上泄露令牌。

但是，提议的协议相同，这使网站黑客事件对您的痛苦最小。

令牌的泄露不会导致域密钥的泄露，而域密钥的计算是基于令牌的。同样，此事件不会导致其他令牌的损害。如果是这样，则无法访问其他站点。

当使用主密钥对大多数站点进行密钥时，这尤其令人愉悦：不可能通过反向工程来还原它。

但是同时，出于明显的原因，不可能使用令牌被泄露的域密钥。必须更改密钥。

可以使用一个随机数或一个主密钥（加上一个版本号）来为发生官​​方泄漏的域创建密钥：

$$

结论

我向我展示了这篇文章的几个朋友问我基本上相同的问题：“这里的主要内容是什么？”


哦，没有主芯片！ las但是有许多细节使该协议比传统的登录/密码方案更有利可图。

1.您可能在许多站点上注意到了这个烦人的弹出窗口。

“我们的网站保存cookie！戴上头盔并保持警惕，因为大哥在看着你！单击“是”，因为您仍然别无选择。

这是一堆其他同样具有侵入性且非常必要的弹出窗口。而这一切都要归功于欧洲GDPR（类似于我们的PD法律）。

所以在这里。在我们的方案中，出于识别目的，不再需要Cookie！从单词“完全”开始。用户决定是否允许站点识别它，以及何时以及持续多长时间。减去一个烦人的弹出窗口，为协议业力+1。

2.开发人员不再需要执行授权和密码恢复表格。无需实施复杂的SSO算法并掌握复杂的库：OAuth，SAML，Kerberos等，无需完成注册网站，更改授权密钥，监视其安全性的过程；如果SSO出了问题，请紧急了解：“出了什么问题以及原因。” 此外，授权服务器可能会出于未知原因阻止您的站点。去弄清楚。昨天一切正常，但是今天……这里足以从标题中读取令牌并检查数据库中是否存在令牌。简单=可靠。



3.用户不需要输入并记住一堆密码。使用第三方站点的服务，或者由谁以及如何编写程序尚不清楚。您不必担心第三方，键盘记录程序和特洛伊木马程序会访问计算机。制作主密钥的备份副本，用密码保护它并将其存储在USB闪存驱动器上就足够了。就像一个比特币钱包。什么不是功能？

4.如果该站点被黑客入侵，则无需承担任何风险。好了，再次生成密钥。虽然密码泄露给网站的破解者会造成很多麻烦。

5.创建该协议时要考虑到已知网络攻击的经验。它的体系结构已经包括针对XSS，CSRF的基本保护。再次，网站管理员会发现开发站点更加容易。和他们的用户-更冷静。

6.与特定服务提供商无关的协议及其异想天开。该协议使您自由。

7.最后，拟议的协议声明了未来的开放标准。并且，如果参与者采用了该标准，则该标准将承担根据规范实施功能的义务，并且不要使集体农场脱离其自己的授权决定，而再次发明登录，注册，密码恢复，注销的形式。并且不要搞乱密码哈希或SQL注入。

最重要的是，像任何开放标准一样，它可以并且应该得到验证独立专家。即使协议的原始版本的作者被“搞砸了”，在线社区也可以及时识别此修复程序。好吧，或者把我的协议寄给废话。for对我来说，对其他所有人都是“维尼携带”。

-我想我应该在这里停
E.怀尔斯

---

聚苯乙烯
您可以使自己熟悉离线格式全文文章的选项。在Habr上排版材料时，我会打错字。如果您有严重的评论，最好检查原始文件并将文章评论（审阅）保留在此文件中。将您的更改发送给我sergey201991 [] gmail。我不是章鱼，但我会尽力回答。我将在本文中添加多个匹配/有趣的评论。连同答案。不排除单独的评论文章的变体。

是的，我知道该协议可能存在问题：

1. 如果您手边没有钥匙，但无法使用别人的设备在您的帐户下登录，则非常需要；密码在这里更方便
2. ; , SSO
3. «», - : - ( )
4. -

关于第1页-我正在认真考虑回到基于密码生成域密钥的想法，通过使生成密钥的过程复杂化来防止暴力破解：例如，将散列回合的数量增加到1000。该网站困扰着我。

关于第2页-这是按时间处理的。您需要习惯于新界面。起初并不清楚，然后简单。给80年代的一个人提供现代智能手机，他也不会想如何管理它。

如果您读完了，非常感谢！