停止flash访问http资源
我的 HTTP 服务器上有一些音频流资源，比如说
http://example.com:7000/foo。 mp3
我确实设计了一个flash播放器来播放它。
我注意到有些人使用第三方 Flash 播放器播放该音频。
他们的播放器将尝试重新加载该资源，直到该资源可用为止。这给我的 HTTP 服务器带来了很大的压力。为了阻止他们攻击我的服务器，我想只允许从我的 Flash 播放器进行访问。奇怪的是，我认为在这种情况下，flash 播放器应该在加载我的音频资源之前先检查 crossdomain.xml，但他们没有。他们只是加载声音并播放。 corssdomain.xml 甚至不存在。我尝试添加一个，但效果不佳
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com"/>
</cross-domain-policy>
那么 Flash 播放器有什么问题吗？为什么不检查crossdomain.xml就可以访问资源？
在某些情况下，flash 播放器是否不必检查 crossdomain.xml？如果是，我如何阻止第三方玩家（来自不同域）访问我的资源？
谢谢。
I have some audio streaming resources on my HTTP server, let's say
http://example.com:7000/foo.mp3
I did design a flash player for playing it.
And I noticed that some guys use third-party flash player to play that audio.
Their player will try to reload that resource until it's available. This makes a lots of stress to my HTTP server. To stop them from hamming my server, I want to allow access only from my flash player. Strangely, I think in this case, flash player should check the crossdomain.xml first before load my audio resource, but they didn't. They just load the sound and play. The corssdomain.xml is not even there. I try to add one, it doesn't work as well
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com"/>
</cross-domain-policy>
So what's wrong with the flash player? Why it can access the resource without check crossdomain.xml?
Is that in some cases, flash player doesn't have to check crossdomain.xml? If it is, how can I stop my resource be accessed by third-party players (from different domain)?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果你真的想解决这个问题，我会研究对你的资源进行一些真正的保护。 IE、
http://example.com:7000/foo.mp3不应直接访问。您可以将其放在强制使用一次性密钥之类的服务器后面，这样就需要以http://example.com:7000/foo.mp3?key=1234的形式请求它，其中1234是加密安全随机密钥。加载 Flash 应用程序的 Web 服务器将生成此密钥，将其作为变量传递到 Flash 应用程序中，然后在为您的媒体内容提供服务的服务器（可能是同一台服务器）上授权此密钥。特别是如果资源服务器和 HTML 服务器相同，则也可以使用 HTTP cookie 轻松完成。现在，这不会阻止某人加载您的 HTML 来获取授权密钥。但是，如果您将密钥正确地嵌入到 HTML 中，它至少会起到很大的威慑作用。 （如果您需要对此 HTML 页面进行身份验证和授权，那么您几乎已经涵盖了所有内容。）
使用
crossdomain.xml或任何其他类似的方法可以将资源的安全性置于控制之下。客户端而不是服务器 - 这绝不是一个好主意。If you really want to fix this, I'd investigate putting some real protection around your resources. I.E.,
http://example.com:7000/foo.mp3should not be directly accessible. You could put it behind a server that forces something like one-time keys, such that it would need to be requested ashttp://example.com:7000/foo.mp3?key=1234, where1234is a cryptographically secure random key. Your web server that loads your flash application would generate this key, pass it along as a variable into the flash application, then authorize this key on the server that is serving your media content (possibly the same server). Especially if the resource server and the HTML server are the same, this could also easily be done with HTTP cookies.Now, this won't prevent someone from loading your HTML to obtain an authorized key. However, if you properly embed the key within the HTML, it will at least be a significant deterrent. (If you would require authentication and authorization for this HTML page, you'd pretty much have everything covered.)
Using
crossdomain.xmlor any other similar approach is placing the security of your resources in control of the client instead of the server - which is never a good idea.从
Sound类发出的请求实际上忽略了跨域策略。这是一个长期存在的错误，Adobe 多年来都没有修复。当您只需要向服务器发送数据但不期望任何响应时，通常会使用此“功能”。也就是说，播放器将阻止您从不提供策略文件的服务器获取响应，但无论如何都会发送请求。现在，如果您试图保护自己免受 ddos 攻击 - 这是一个完全不同的问题，攻击者很可能会使用 Flash 播放器以外的其他东西来发起此类攻击。 Flash 播放器网络 API 对于此类活动有些缺乏/限制...
如果您需要身份验证来提供文件，那么基于 HTML/cookie 的解决方案可能并不理想/并不总是有效，因为您有时可能希望提供服务文件不使用 html / 如果黑客创建合法会话 / cookie 怎么办？您可以使用两部分加密（例如 RSA）来生成密钥对，一个用于授权用户，另一个用于服务器。要求在数据请求和凭据中提供用户密钥。如果用户未注册该服务，则用户的密钥部分与服务器的密钥部分相结合将不会生成用户的凭据（或使用密钥加密的任何数据） - 这将表明欺诈企图。然后由您来阻止请求者等。这种方法是一种坚如磐石的方法，再精明的黑客也无法绕过。如果黑客未经授权，那么她在本世纪将无法获取数据:)
如果您不需要身份验证，那么基于cookie/会话的方法可能是合适的（这意味着数据访问仍然容易受到攻击） ，但更难到达）。
哦，我刚刚意识到问题是请求太多了。那么，如果您已经发现他们不会获得任何真实数据，例如为他们提供一个 1 太字节大的文件，那么您为什么不“满足”这些请求呢？ :) 或者可以向他们发送一些 Justin Beeber 的唱片/其他不太可能符合他们音乐品味的唱片？ :)
Requests made from
Soundclass effectively ignore crossdomain policies. That's an old living bug, Adobe didn't fix in ages. This "feature" is often times used when you need to only send data to server, but you don't expect any response. That is, the player will prevent you from getting the response from a server that doesn't provide policy file, but will send the request anyway.Now, if you you are trying to protect yourself against a ddos attack - that is a completely different issue, the attacker will most likely use something other than flash player to launch such an attack. Flash player networking API are somewhat lacking / restricting for this kind of activity...
If you require authentication for serving the files, then probably HTML / cookie based solution is not ideal / will not always work, as you may want sometimes to serve the file w/o using html / what if a hacker creates a legitimate session / cookie? You could use two-components encryption (RSA for instance) to generate the key pairs, one for the authorized user and the other for the server. Require the user's key to be supplied with the request for the data as well as credentials. If the user is not registered with the service, the user's part of the key combined with the server's part of the key will not generate user's credentials (or whatever data you encrypted using the keys) - which will signal a fraud attempt. Then it is up to you to block the requester etc. This way is a rock-solid, no more-savvy-hacker-can-bypass kind of approach. If the hacker is not authorized, then she will not get the data in this century :)
If you don't require authentication, then, probably, cookie / session based approach would be appropriate (which means that the data access will be still vulnerable, yet more difficult to get to).
Oh, I just realized that rather too many requests is the issue. Then, well, why wouldn't you "satisfy" the requests, if you can already find out they aren't going to get any real data, with say, serving them a file one Terrabyte big? :) Or maybe send them some records of Justin Beeber / whatever else is unlikely to match their musical taste? :)