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.
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.
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.
É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.
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...
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.
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.
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.
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.
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.
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.)
A cikk megoldásként azt írja,
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.
Magyarul irány a
Miért is?
Mert a "küldjünk miné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.
Ha így nézzük, akkor igen.
Használhatsz XSLT-t.
És érdekes módon, ilyen
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.
Lehet, az a baj a webbel,
Amit nem értek
Ez nekem sem teljesen tiszta,
Köszi
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.
Ha átlag (35/2)*karakterek
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.
A kézenfekvő védekezés az
Én is ezen gondolkodtam.
jól értem?
Valamint ugyanarról a végpontról?
Mert ha jól értem, ezt azért ki lehet szűrni.
Lehet, de azért nem
Ha 5 percenként küldi, nem
Engem mondjuk eleve kiborít,
De egyébként a munkamenetet más oldalakra küldött GET-ekkel is életben lehet tartani.
2 megoldás
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.)
Könyvjelző megnyitásakor is
Referer