G3: Found defect in handling user agent on iOS devices - TECHNICAL DESC INSIDE
|
leonki
Joined: 2010-12-18
Posts: 32 |
Posted: Tue, 2014-04-01 17:37
|
|
I've been spending a significant amount of time with tcpdump, wireshark, and digging through the G3 source and I finally believe why (At this point) secure videos have no hope of being served with G3. 1) Requests to HTTP pages are served with the following user agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_1 like Mac OS X) AppleWebKit/5 37.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D167 Safari/9537.53 2) Requests for media (e.g. mp4 files) are served with the following user agent: AppleCoreMedia/1.0.0.11D167 (iPhone; U; CPU OS 7_1 like Mac OS X; en_us) As you can see, the session security in G3 will detect that user_agent is different, and a new session will be generated. The user ID for the new session will be set to "guest" and file_proxy will fail in access::can("view", $item) with test_fail_code 4! |
|
Posts: 27300
So a ipad (iphone) have 2 different user agents depending on the content requested (html versus media)?
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 32
Exactly!!
This is true for both Chrome for iOS as well as native Safari.
Posts: 27300
Well that makes no sense.
Isn't a user agent a user agent? It should not be depended on the content requested. Apple!
Not sure how to get round that other than rewriting the proxy file and jumping though a bunch of hoops for idevices. Or making is less secure.
How does G2 handle it? Dayo? suprsidr?
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 32
Here's the thing, the user agent together with expiry date is used to validate that the session cookie has not been duplicated. This level of security is traditionally not done with other software/PHP scripts - the likelihood of you guessing my session ID cookie is equivalent to you guessing facebook's private SSL key. It will take you billions of years.
I'm not sure why G3 goes to that extend. Even the default for Kohana is expiry date only.
There's other Kohana defaults that are overwritten by G3 (assuming for paranoid security reasons). For example, session data is not stored in the FS (default /tmp/sess_*), but rather in a sessions table in MySQL. All the data in that table is encrypted on write use SHA!! (too bad the salt used for the SHA encryption is the default Kohana one rather than a custom G3 one - security hole?)
The ultimate solution has to happen in Kohana, or G3 overwrite. Rather than store the entire user agent, smarts has to be deployed to figure out the if they are equivalent (e.g. iPhone keyword).
Even with my code hacks in place, video streaming from iOS still doesn't work unless I implement byte_range correctly (easier said than done, as latest version of Chrome on desktops also sends the byte range header, even though it doesn't use it!!)
Posts: 120
While I agree that makes no sense, it could make some sense. Maybe the IOS browsers handle off media content to some other helper library or something (that does the lifting and processing of media). Still, what a pain in the backside.
Personally I like the fact that G3 is exceeding the norm in regards to validation.
Posts: 32
I've spent an aweful amount of time debugging the communication between the iPhone and gallery. There's a lot of funky stuff apple does to minimize data usage. At this point I give us. The problem is between Kohana and gallery file_proxy with session cookies being ignored due to user agent.
My quick hack was to modify the htaccess file. I added a rule that detects requests for .mp4 files and just let's them through rather than redirect to the proxy. Html5 video plays perfectly as Apache supports byte range already.