ugrás a tartalomhoz

Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages

Joó Ádám · 2013. Aug. 2. (P), 04.44
Új sebezhetőség a TLS protokollon
 
1

A cikk megoldásként azt írja,

Hidvégi Gábor · 2013. Aug. 2. (P), 08.16
A cikk megoldásként azt írja, hogy kapcsoljuk ki a tömörítést, ha https-t használunk, valamint azt is, hogy ez persze érzékenyen érinti mind a kliens-, mind pedig a szerveroldalt.

Jóval kevésbé függenénk a tömörítéstől, ha megszabadulnánk a HTML-től, és helyette az adatokat jóval kompaktabb formában, például XML-ben küldenénk. A HTML statikus, ráadásul nagy része a kódnak csak a dizájn miatt szükséges.
2

Magyarul irány a

H.Z. · 2013. Aug. 2. (P), 08.26
Magyarul irány a vastagkliensek kora ismét? ;)
3

Miért is?

Hidvégi Gábor · 2013. Aug. 2. (P), 08.33
Miért is? Ahhoz, hogy áttérjünk egy XML alapú webre, szoftverileg semmit sem kéne megváltoztatnunk.
4

Mert a "küldjünk minél

H.Z. · 2013. Aug. 2. (P), 08.38
Mert a "küldjünk minél kevesebb infót a szerverről, lehetőleg szorítkozzunk csak és kizárólag az adattartalomra" már erről szól.
Van egy adatbázis szervered, esetleg egy alkalmazás szerver és a kliens csak az adatokat kapja, a feldolgozás nagy részét ő végzi ahogy neki tetszik.
Ez nem sokban tér el attól, ami a web előtt volt.
5

Ha így nézzük, akkor igen.

Hidvégi Gábor · 2013. Aug. 2. (P), 08.49
Ha így nézzük, akkor igen. Majd a kliens eldönti, mit kezd az adatokkal, a HTML segítségével való megjelenítés legyen csak egy opció a humán olvasóknak.
13

Használhatsz XSLT-t.

szjanihu · 2013. Aug. 4. (V), 17.23
Használhatsz XSLT-t.
14

És érdekes módon, ilyen

saxus · 2013. Aug. 7. (Sze), 03.30
És érdekes módon, ilyen kezdeményezés volt is az IE-ben: http://weblabor.hu/cikkek/ieadatkapcsolas

Csak aztán mi kellett a népnek? HTML5 meg csilivili CSS3 meg egyéb szemetek. Pedig mennyivel jobb lenne, ha a tartalmat (XML adatforrások pl. bindinggal) a megjelenítéstől (HTML+CSS+JS) külön lehetne választani.

De neeeem, a népeknek csicsa és parasztvakítás kellett (meg egy tök új jelölőnyelv, ami se az XML-lel se az SGML-lel nem kompatibilis már, csak saját magával), érdemi dolgokban meg továbbra is 0 előrelépés.
15

Lehet, az a baj a webbel,

Hidvégi Gábor · 2013. Aug. 7. (Sze), 06.08
Lehet, az a baj a webbel, hogy túl alacsony a belépési küszöb, emiatt az egyszerűbb dolgok felé orientálódunk. Technológiailag egyértelműen visszafele fejlődünk, és közben milyen gyorsan elrepülnek az évtizedek...
6

Amit nem értek

vbence · 2013. Aug. 2. (P), 16.42
Miből áll össze egy ilyen "próbálkozás" plaintextje, amit a szervernek küldenek? (Tömörítés és kódolás előtt).
7

Ez nekem sem teljesen tiszta,

Joó Ádám · 2013. Aug. 2. (P), 17.55
Ez nekem sem teljesen tiszta, úgy tűnik, hogy a kiszolgálónak a küldött próbát vissza kell írnia a válaszba. Tehát például a munkamenet-azonosítóra vonatkozó próbálkozást egy szándékosan rontott űrlap adatai közt küldöd, hogy az űrlapban visszakapd. Ha az üres mezővel küldött kérésre kapott válaszhoz képest nőtt a próbára kapott válasz mérete a tömörítés mellett, az azt jelenti, hogy rossz úton jársz, ha nem (mert a fejlécben és az űrlapmezőben is szerepel a karakterlánc), akkor megtaláltál egy újabb bájtot.
8

Köszi

vbence · 2013. Aug. 3. (Szo), 11.48
Így a helyére került pár dolog.

Ezesetben viszont létezik egyszerű a védekezés. Egy iylen keresés egyértelműen a bruteforce jeleit mutatja a szerver felől nézve. Egy netbank szintű szolgáltatást nem tudok elképzelni jól megválasztott limitek nélkül bármilyen user akcióra.
9

Ha átlag (35/2)*karakterek

tgr · 2013. Aug. 3. (Szo), 12.53
Ha átlag (35/2)*karakterek száma próbálkozásban törni tudsz egy kulcsot, az olyan kevés, hogy nehéz a limitek megválasztásával védekezni ellene. Egy 16 karakteres külcsot egy nap alatt meg lehet törni úgy is, ha csak öt percenként küldesz egy új requestet. Plusz általában csak a módosítások limitáltak, a támadást meg meg lehet csinálni pl. úgy is, hogy sima GET requesteket küldesz, és a query stringet manipulálod.

A kézenfekvő védekezés az lenne, hogy az SSL endpoint hozzátesz egy véletlenszerű hosszúságú "zaj" fejlécet a válaszhoz.
10

A kézenfekvő védekezés az

Joó Ádám · 2013. Aug. 3. (Szo), 17.31
A kézenfekvő védekezés az lenne, hogy az SSL endpoint hozzátesz egy véletlenszerű hosszúságú "zaj" fejlécet a válaszhoz.


Én is ezen gondolkodtam.
11

jól értem?

zzrek · 2013. Aug. 3. (Szo), 22.29
Jól értem, hogy 5 percenként küldött új request, amiben rontott adat van ?
Valamint ugyanarról a végpontról?
Mert ha jól értem, ezt azért ki lehet szűrni.
12

Lehet, de azért nem

Joó Ádám · 2013. Aug. 3. (Szo), 22.34
Lehet, de azért nem egyértelmű a kivitelezés, ha nem akarod tönkretenni a felhasználói élményt. Arról nem is beszélve, hogy az űrlap csak egy lehetséges támadási pont, bármilyen szolgáltatás, ami visszaküldi mondjuk a query stringet (például kereső), ki van neki téve.
19

Ha 5 percenként küldi, nem

inf · 2013. Aug. 24. (Szo), 14.30
Ha 5 percenként küldi, nem jár le addigra a munkamenet?
20

Engem mondjuk eleve kiborít,

Joó Ádám · 2013. Aug. 28. (Sze), 19.11
Engem mondjuk eleve kiborít, ha a böngésző bezárása előtt kiléptetnek, na de öt perc? Egész biztos, hogy amint meglátom, átmegyek a versenytárshoz.

De egyébként a munkamenetet más oldalakra küldött GET-ekkel is életben lehet tartani.
16

2 megoldás

vbence · 2013. Aug. 7. (Sze), 13.56
Felhasználóknak:
Ha a próbálkozásokat a támadó saját kódja (saját weblapjáról) intézi, egyszerű védekezeés lehet a user oldalán ha kikapcsoljuk a 3rd party cookiekat, így a próbálkozásokból - amit én hidden iframe-nek értek - máris hiányzik az eredeti munkamenet azonosító (és bármi más adat maiért a felhasználó gépéről érdemes ezeket a próbálkozásokat küldeni).

Szervereknek:
Külső Referer tiltás: a kérést egyszerűen dobjuk el, ha nem ellenőrzött site-ról (mint Referer) érkezik. - (Szigorúbb esetben elgondolkodhatunk az üres referer tiltásán. Erről nem ismerek friss számokat.)
17

Könyvjelző megnyitásakor is

Hidvégi Gábor · 2013. Aug. 7. (Sze), 14.01
Könyvjelző megnyitásakor is üres a referer.
18

Referer

vbence · 2013. Aug. 7. (Sze), 14.08
Ezzel semmi probléma, a könyvjelző nem egy formot fog elpostolni.