同一个应用的不同子域能否防止 XSS 等恶意攻击? [英] Can different subdomains of the same app prevent malicious attack like XSS?

查看:49
本文介绍了同一个应用的不同子域能否防止 XSS 等恶意攻击?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在我的 Rails 应用程序中,我有 2 个子域,

In my Rails app i have 2 subdomains,

一:members.myapp.com,这是所有成员共享的区域(他们可以在其中登录和管理他们的帐户)

one : members.myapp.com which is the area shared between all members (where they can login and manage their accounts)

二:每个成员在这样的子域上都有自己的网站:member1.myapp.commember2.myapp.commember3.myapp.com 等...

Two : each member has its own website on a subdomain like this : member1.myapp.com, member2.myapp.com, member3.myapp.com etc...

想象一下,user1.myapp.com在他的网站上运行了一段恶意的js代码,members.myapp.com会受到XSS或者其他攻击的影响吗?

Let's imagine that user1.myapp.com run a malicious js code in his site, can members.myapp.com be affected through XSS or other attacks?

推荐答案

他们将能够设置可以被 members.myapp.com 读取的 cookie - 所以如果他们是任何 cookie 处理漏洞在 members.myapp.com 上,他们可能会利用这些.cookie 中毒的一个例子可能是 会话固定.

They would be able to set cookies that can be read by members.myapp.com - so if they are any coookie handling vulnerabilities on members.myapp.com then they could possibly exploit these. An example of cookie poisoning could be session fixation.

除非两个域都选择加入,否则 XSS 是不可能的.也就是说,它们都必须包含以下代码.

XSS would not be possible unless both domains opted in. i.e. they would both have to contain the following code.

document.domain = 'myapp.com';

除非 members.myapp.com 这样做,Origin 不会在子域之间共享.

Unless members.myapp.com is doing this, the Origin will not be shared between subdomains.

如前所述,一种类型是 Session Fixation.

As mentioned, one type is Session Fixation.

现在,假设攻击者访问 members.myapp.com 并获得一个随机会话 cookie:set-cookie: session_id=123456.

Now, say the attacker visits members.myapp.com and is given a random session cookie: set-cookie: session_id=123456.

然后攻击者向管理员发送一封电子邮件,说他的域 user1.myapp.com 存在问题.

The attacker then sends an email to an administrator saying there is a problem on his domain user1.myapp.com.

攻击者在 user1.myapp.com 上托管了一些 JavaScript 代码:

The attacker has some JavaScript code hosted on user1.myapp.com:

document.cookie = "session_id=123456;domain=myapp.com";

受害者(myapp.com 的管理员)转到攻击者的页面并接收 cookie.

The victim (an administrator of myapp.com) goes to the attacker's page and receives the cookie.

管理员稍后会转到 members.myapp.com 并登录到他们的管理员级别帐户.然而,由于攻击者在一个 cookie 中向攻击者提供了他们的会话 ID (123456),members.myapp.com 可以读取该 cookie(因为它在 123456>myapp.com 级别)攻击者现在以管理员身份登录.即攻击者已设法让管理员共享他的会话,因此当管理员登录时,共享其会话的攻击者也已登录.

The admin later goes to members.myapp.com and the logs into their administrator level account. However, as the attacker has give the attacker their session ID (123456) in a cookie that can be read by members.myapp.com (as it was set at myapp.com level) the attacker is now logged in as the administrator. i.e. the attacker has managed to make the administrator share his session so when the administrator logs in, the attacker sharing his session is also logged in.

这只是 cookie 处理漏洞的一个示例.在这种情况下,系统应该在登录后发布一个新的会话cookie,以防止会话固定攻击.

This is just one example of a cookie handling vulnerability. In this case the system should issue a new session cookie after login to prevent the session fixation attack.

这篇关于同一个应用的不同子域能否防止 XSS 等恶意攻击?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆