移动浏览器是否通过HTML5音频标签发送httpOnly cookie？

Question

我尝试通过html5音频标签播放一些mp3文件.对于桌面而言,这非常适合(使用Chrome),但是当涉及到移动浏览器(也是Chrome(适用于Android))时,似乎存在一些困难:

我用一些密码保护了流,因此流媒体服务器需要找到一个特殊的身份验证cookie(spring security remember-me).但不知何故,移动浏览器在通过音频标签访问mp3流时不会发送此cookie.当我直接输入流URL到地址栏时,一切正常.

当我搜索我发现的丢失的cookie时,移动浏览器仍然发送一些cookie(例如JSESSIONID),但不是全部.进一步调查(使用PHP的快速PoC)显示移动浏览器似乎拒绝通过具有HttpOnly Flag设置的audio-tag发送cookie.所以我的问题是:

这是一个指定的行为,为什么移动和桌面版本(Chrome)之间存在差异,是否有一种方法可以控制客户端的行为？

Answer 1

通过深入研究我发现的HTTP包,Android浏览器不会请求mp3流本身,而是将其委托给stagefright(一些Android多媒体客户端).快速搜索显示,对于旧的Android版本(4.0之前),stagefright无法处理cookie:

• 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

我自己的测试证实了这一点 旧的stagefright(Android 2.3.x)根本不发送任何cookie,来自欧洲S3(android 4.1.2,stagefright 1.2)的stagefright只发送没有httpOnly标志的cookie.

所以我认为每个人都必须自己决定使用哪种解决方案:

• 启用httpOnly:android完全没有访问权限,但它的安全性
• 禁用httpOnly:对XSS的安全性较低,但适用于Android> 4.0
• 完全禁用cookie身份验证:不安全但适用于所有人

注意:简单地禁用httpOnly的问题在于,您使整个应用程序容易受到cookie劫持者的攻击.另一种可能的解决方案是为流提供一个特殊的记忆cookie(没有httpOnly)和另一个启用了httpOnly的记忆cookie.