2013-04-30 19 views
8

Provo a riprodurre alcuni file mp3 tramite il tag audio html5. Per il desktop questo funziona alla grande (con Chrome), ma quando si tratta di browser mobili (anche Chrome (per Android)), sembrano esserci alcune difficoltà:I browser mobili inviano i cookie httpOnly tramite l'etichetta audio HTML5?

Ho protetto il flusso con una password e quindi lo streaming il server deve trovare uno speciale cookie di autenticazione (spring security remember-me). Ma in qualche modo il browser mobile non invia questo cookie quando accede al flusso mp3 tramite il tag audio. Quando inserisco l'URL dello stream direttamente nella barra degli indirizzi, tutto funziona perfettamente.

Mentre cercavo il cookie smarrito, ho scoperto che il browser mobile invia ancora alcuni cookie (ad esempio il JSESSIONID) ma non tutti. Ulteriori indagini (rapido PoC con PHP) hanno rivelato che il browser mobile sembra rifiutarsi di inviare cookie tramite il tag audio che ha il set HttpOnly Flag. Quindi la mia domanda è:

Si tratta di un comportamento specifico, perché ci sono differenze tra le versioni mobile e desktop (di Chrome) e c'è un modo per controllare il comportamento dal lato client?

risposta

10

Osservando più a fondo i pacchetti HTTP che ho scoperto, il browser Android non richiede il flusso mp3 stesso, ma lo delegizza a stagefright (un client multimediale Android). Una rapida ricerca ha rivelato che, per le vecchie versioni di Android (prima 4.0) stagefright non può gestire i cookie:

I miei test hanno confermato questo. Il vecchio stagefright (Android 2.3.x) non invia alcun cookie, lo stage da un europeo S3 (Android 4.1.2, stagefright 1.2) invia solo i cookie che NON hanno il flag httpOnly.

Quindi penso che ognuno deve decidere se stesso quale soluzione vuole usare:

  • consentire HTTPOnly: Android non ha accesso a tutti, ma il suo sicuro
  • disabilitare HTTPOnly: meno sicuro contro XSS, ma lavora per Android> 4,0
  • disabilita cookie di autenticazione a tutti: non sicuro, ma funziona per tutti

Nota: Il problema con semplicemente disabilitando HTTPOnly è che fate il vostro wh applicazione oleosa vulnerabile ai dirottatori di cookie. Un'altra possibile soluzione sarebbe quella di avere uno speciale cookie rememberme per lo stream (senza httpOnly) e un altro cookie rememberme con httpOnly abilitato.

+0

Questo problema è stato segnalato per Android: https://code.google.com/p/android/issues/detail?id=17553 sebbene sia stato contrassegnato come "spam" chiuso. Potrei riaprire il problema perché non capisco la risoluzione "spam". –

+0

Altri problemi da guardare: https://code.google.com/p/android/issues/detail?id=66050, https://code.google.com/p/chromium/issues/detail?id=163796 –

+0

Probabilmente lo stesso problema con l'incorporamento/streaming di video usando PHP e l'autenticazione cookie/sessione, vedere http://stackoverflow.com/q/32181185/1066234 –

0

Ho avuto lo stesso problema e disabilitare i flag HttpOnly o Secure sui cookie non ha risolto il problema su Android 4.2 e 4.4 browser Chrome.

Finalmente ho capito la causa. Avevo un cookie con il suo valore contenente caratteri speciali due punti (:) e pipe (|), ecc. Dopo aver disabilitato quel cookie con caratteri speciali, i video funzionano bene su Android 4.2 e 4.4.

Spero che questo aiuti qualcuno.

Problemi correlati