在这里询问，是因为我找不到我想要的东西。我查看了几个OWASP页面，使用诸如“登录代理网络钓鱼”，“登录csrf攻击”之类的术语进行搜索，但没有找到有用的信息来保护这种情况。
假设您有一个受信任的站点（T），一个恶意站点（M），以及在受信任的站点（U）拥有帐户的用户。
M向用户发送了一封恶意电子邮件，假装为T。用户单击链接并重定向到M。现在，M充当您受信任的站点的代理，并刮擦了登录页面-表单， CSRF令牌（如果有）在那里。但是，该表单的操作已被操纵为从POST到M而不是T-允许恶意行为者在转发登录请求并提供用户T的响应（重定向）之前捕获凭据。
这是我要防止的攻击的序列图：
USER MALCIOUS TRUSTED
| | |
| access site > | |
+----------------------->| scrape login form > |
| +----------------------->|
| | < give form |
| < give modified form |<-----------------------+
|<-----------------------+ |
| login > | |
+----------------------->| capture credentials |
| | and forward login > |
| +----------------------->|
| | |
| | < login success |
| | < 301 to /home |
| |<-----------------------|
| < redirect to | |
| < trusted.com/home | |
|<-----------------------+ |
| | |
| (phished!) |
| |
| |
| access site normally > |
+------------------------------------------------>|
| |
这实际上是可以预防的吗？我有种直觉，CSRF在这里无济于事，因为令牌很容易被刮擦并传递回T并通过。让我知道我是否错了。
我还认为使用ajax张贴登录信息将无法正常工作，因为攻击者可以代理包括资产在内的所有内容，并在向受害者提供服务之前对其进行修改-并使浏览器将ajax表单发布到恶意网站（绕过XSS） ）。然后，M可以使用curl伪造XHR呼叫，以将请求转发给T。
我相信专家们已经考虑并解决了这一问题，但是英语不是我的母语，这给我寻找合适资源的困难。
为了防止这种情况，我需要知道哪些关键词？
答案 0 :(得分：1)
假设我向您发送了一个指向https://grnail.com的链接（我尝试用m伪造rn的gmail，在某些字体中看起来很像）。您要登录并放置自己的凭据吗？您将检查域名，如果它确实是您期望的东西。
不幸的是，此时大多数安全性都取决于用户及其阅读能力。另一方面，有时阅读根本没有帮助。有例如几年前非常流行的unicode攻击：
好吧，您可以在不同的浏览器中尝试一下：https://www.аррӏе.com/
如何防止这种攻击。你不能好吧，差不多。如果您的站点使用身份验证，并且用户使用U2F进行身份验证，那么即使他们的凭据很不错，攻击者也将无法接管该帐户。