Android-on böngészővel fájl letöltése POST request-tel

Fejlesztés

Adott egy web interface, ahol a user fájlt tud letölteni linkekről. A fájl letöltést POST kéréssel csinálom, mert azonosítom a user-t (be van jelentkezve). Sima GET nem jó, mert biztonságilag nem elfogadható.

Minden asztali böngészővel jól működik, Android-on meg csak Operával. Azért csak ezzel, mert Opera beépített letöltés kezelővel jön, az összes többi meg nem.

A probléma a következő: a letöltendő fájl linkjét a böngésző átadja a letöltés kezelőnek, aki GET-tel tölti le. Így a fájl tartalma a html kimenet lesz a kiküldött fájl tartalom helyett. Nagyon gáz, net szerte anyáznak miatt sok bejegyzéssel. Pl.:

https://code.google.com/p/android/issues/detail?id=1780
https://code.google.com/p/android/issues/detail?id=1780#c40

google://android browser download with post request

Más is belefutott már ebbe? Lenne valamilyen megoldás mégis POST request-tel?

(iOS-en állítólag ez nem áll fenn, de még tesztelnem kell bővebben. iPhone 4 alatt nem történik semmi a linkre tapizva, de lehet csak nem értek hozzá. Ott feldob valamit ha jön fájl? Vagy csendben letölti egy mappába?)

Előre is kösz!

  • 6836 megtekintés

( djpety v | 2014. 04. 06., v – 22:26 )

Ha más nem, generálsz egy átmeneti letöltési URL-t amire átirányítod, és az feltehetőleg menni fog.

Bejelentkezés még POST-al menne, ekkor generálnál egy linket egy hash-el, amire a átirányítanád a usert.
A hashelt linken meg valami egyszerűbb php lökné a fájl tartalmát a megfelelő header-el.
A letöltés megkezdésekor a hash link érvénytelenné válna.
Ebben én nem látok biztonsági kockázatot.

------------------
My Open-Source Android "Projects"

Ha nem használsz https-t, akkor a POST sem megoldás arra, hogy ne nyúlják le a linket útközben (mondjuk a DNS nem is fog vele találkozni :)
Ha valami biztonságosabbat akarsz, akkor tarts az Androidon egy kulcsot, azzal csinálj egy disgestet a linkből, fűzd hozzá a GET-hez nyugodtan, és a szerver meg ellenőrízze.

Bocs, nem figyeltem, hogy browser, csak arra, hogy fejlesztés topic...
Ha viszont browser, akkor a cookie miért nem jó?
Vagy alternatív eset, ha nagyon nem akarsz cookie-t: POST-tal az auth, visszajön válaszban egy HTML redirect, ami lekérésére mondjuk adsz egy 10 mp-es időablakot a szerveren, plusz még ellenőrizheted az IP-címet is.

Nem jók ezek a trükközések ablakot hagyva támadási felületnek. Ha odáig jut egy dolog, hogy "xy tanút kérem meghallgatásra", és felteszik az egyenes kérdést, hogy tudatosan hagyott a technológia tervezésekor támadható felületet? Akkor mindegy mi az eredeti ok, ha nem tudsz nem-mel válaszolni, megszívtad. Ilyet nem szabad beletervezni.

Azért kösz az ötleteket, még keresem a jó megoldást. Operával megy, de azért így még nem kerek.

Tudok nemmel válaszolni.
Ugyanis ennyi erővel azt is lehet mondani, hogy végső soron ráhibázhat valaki simán a szerveremhez szüksége 2kbites kulcsra és kb. 200 bites jelszavamra. Egy 4-500 karakteres URL ezzel kb. egyenértékű. (Ráadásul 10 mp-nél és egy próbálkozásnál ennek mennyi az esélye?)
(Egy ismert URL és POST-tal elküldött név/jelszó a fentihez képest egy tágra nyitott gyárkapu.)

A ráhibázásnak van esélye, csak nagyon kicsi és tömegesen nem kihasználható.

A 10 mp-nél és 1 próbálkozásnál meg nem az esély a probléma, hanem hogy visszatérően minden egyes letöltéshez megadod ezt az esélyt. Főleg úgy, hogy ha a kérés kimegy a klienstől (itt ugye az url végig megy a neten) és nem sikerül eljutni a szerverig, máris ott a lehetőség bárkinek a letöltésre bármiféle nehézség nélkül. Ezt súlyosbítja a tény, hogy minden egyes művelethez adsz egy ilyen esélyt a támadónak, mely akár több száz vagy ezer lehetőség per nap. Szerintem nagyon rossz megközelítés.

Https-en POST kéréssel végzett kommunikáció miért lenne nyitott?

A lenyeg az, hogy tartosan titkos informaciot nem szabad benne kuldeni, mert azt a kliens oldalon a bongeszo kiirja, a szerver oldalon pedig bekerulhet a logba. A koztes eszkozok szamara tovabbra is titkos. Tehat ha egy ideiglenes kulcsot generalsz es azt rakod a GET-be akkor az elfogadhato. Termeszetesen biztonsagi dokumentacioba erdemes feltuntetni, hogy ilyen fajta logolast nem szabad bekapcsolni a szerveren.

Világos, de ez nekem akkor nem lesz jó, mert olyan URL-eket generálok, melyeknek akárhány alkalommal kell működniük. Ez a szolgáltatás tulajdonsága miatti igény sajnos.

(Több azonos csoportban lévő felhasználó feltolhat fájlokat a fájl szerverre, melyhez vissza kapnak egy URL-t és ez tárolódik le az adatbázisukban. Ezért kell többször felhasználhatónak lenni, ráadásul megosztottnak a csoporton belül, de úgy, hogy simán kikopizva a link-et más user ne tudjon hozzáférni a fájlhoz.)

Marad a minden egyes alkalommal való auth post-on keresztül akkor. Kérdés létezik-e jó harmadik lehetőség?

Szóval, nem fejtettem ki részletesen, de:

1. Belép a felhasználó, van joga a fájlhoz
2. Van egy link, ami a fájlt azonosítja (egy rövid url, amit még a programod ellenőriz). Ezt fogod a csoportban terjeszteni mint link.
3. A linkre lépéskor a rendszer generál egy egyszeri URL-t, amelyet IP címhez kötsz, és egyszeri alkalommal teszed elérhetővé (ha pedig nem használják fel a linket, elévül X időn belül). Erre irányítod át a klienst.
3+1. Tehetsz még bele HTTP Auth-ot, amit szintén az átirányításnál adsz át, és egyedileg generálódik egy letöltés erejéig.

Hol van itt a biztonsági rés HTTPS felett? Csak szerver oldalon és kliens oldalon lehet kompromittálni ezt (figyelmen kívül hagyva most a MITM támadásokat).

Ebből a szempontból a POST semmivel sem jobb mint a GET.