移动浏览器是否通过HTML5音频标签发送httpOnly cookie? [英] Do Mobile Browsers send httpOnly cookies via the HTML5 Audio-Tag?
问题描述
我尝试通过html5音频标签播放一些mp3文件.对于台式机来说，这很好(适用于Chrome)，但是对于移动浏览器(也适用于Chrome(适用于Android))，似乎存在一些困难:
I try to play some mp3 files via the html5 audio-tag. For the desktop this works great (with Chrome), but when it comes to the mobile browsers (also Chrome (for Android)), there seem to be some difficulties:
我用一些密码保护了流，因此流服务器需要找到一个特殊的身份验证cookie(春季安全性，请记住我).但是以某种方式，移动浏览器通过音频标签访问mp3-stream时不会发送此cookie.当我直接在地址栏中输入流URL时，一切正常.
I protected the stream with some password an therefore the streaming server needs to find a special authentification cookie (spring security remember-me). But somehow the mobile browser doesn't send this cookie when it accesses the mp3-stream via the audio tag. When I enter the stream URL directly to the address bar everything works just fine.
当我搜索发现的丢失的cookie时，移动浏览器仍会发送一些cookie(例如JSESSIONID)，但不是全部.进一步的调查(使用PHP的快速PoC)显示，移动浏览器似乎拒绝通过设置了HttpOnly标志的音频标签发送cookie.所以我的问题是:
While I searched for the lost cookie I found out, that the mobile browser still sends some cookies (e.g. the JSESSIONID) but not all. Further investigations (quick PoC with PHP) revealed that the mobile browsern seems to refuse to send cookies via the audio-tag which have the HttpOnly Flag set. So my question is:
这是一种指定的行为吗，为什么移动版和桌面版(Chrome的)之间会有区别，并且有一种方法可以从客户端控制行为?
推荐答案
通过更深入地研究我发现的HTTP包，Android浏览器并不要求mp3-stream本身，而是将其委托给stagefright(有些android多媒体客户端).快速搜索显示，对于旧的Android版本(4.0之前的版本)，stagefright无法处理Cookie:
By looking more deeply into the HTTP packages I found out, that the Android browser doesn't request the mp3-stream itself, but delegates this to stagefright (some android multimedia client). A quick search revealed, that for the old Android versions (before 4.0) stagefright cannot handle cookies:
- https://code.google.com/p/android/issues/detail?id = 17553 <-(状态:垃圾邮件)WTF ...
- https://code.google.com/p/android/issues/detail?id = 17281
- https://code.google.com/p/android/issues/detail?id = 10567
- https://code.google.com/p/android/issues/detail?id = 19958
- https://code.google.com/p/android/issues/detail?id=17553 <-- (Status: spam) WTF...
- https://code.google.com/p/android/issues/detail?id=17281
- https://code.google.com/p/android/issues/detail?id=10567
- https://code.google.com/p/android/issues/detail?id=19958
我自己的测试证实了这一点.旧的stagefright(Android 2.3.x)完全不发送任何cookie，来自欧洲S3(android 4.1.2，stagefright 1.2)的stagefright仅发送不带有httpOnly标志的cookie.
My own tests confirmed this. The old stagefright (Android 2.3.x) doesn't send any cookies at all, the stagefright from a european S3 (android 4.1.2, stagefright 1.2) sends only the the cookies which do NOT have the httpOnly flag.
所以我认为每个人都必须自己决定要使用哪种解决方案:
So I think that everybody has to decide himself which solution he wants to use:
- 启用httpOnly:除了安全之外，android根本无法访问
- 禁用httpOnly:针对XSS的安全性较低，但适用于Android> 4.0
- 完全禁用cookie身份验证:不安全，但适用于所有人
注意:仅仅禁用httpOnly的问题是使整个应用程序容易受到cookie劫持者的攻击.另一种可能的解决方案是为流添加一个特殊的记住我" cookie(不使用httpOnly)和另一个启用了httpOnly的记住我" cookie.
Note: The problem with simply disabling httpOnly is that you make your whole application vulnerable to cookie hijackers. Another possible solution would be to have a special rememberme cookie for the stream (without httpOnly) and another rememberme cookie with httpOnly enabled.
这篇关于移动浏览器是否通过HTML5音频标签发送httpOnly cookie?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
