ugrás a tartalomhoz

XSS védelmet hova?

Max Logan · 2009. Feb. 13. (P), 10.54
Azon gondolkodtam, hogy az XSS védelmet hova kellene beépíteni? Jelenleg a kontrollerben van megvalósítva (kimenő adaton szűrés, mielőtt a nézetnek átadásra kerül), de mivel ez a megjelenítéssel kapcsolatos dolog, talán jobb lenne a nézetben megoldani.

Vélemény?
‹ Uninitialized string offset: adatbázis válltozásainak naplózása ›
 ■
1

XSS védelem >= output escape

vbence · 2009. Feb. 13. (P), 12.29
Te most konkrétan az output escapingre gondolsz. Ennek helye a view rétegben van (ha az MVC paradigmát akarjuk forszírozni). Az ok az, hogy nem csak egyféle outputja lehet egy bizonyos adatnak. A klasszikus kimenet HTML, de ha elkezdesz AJAX bizgentyűket készteni, mindjárt képbejön a JSON vagy az XML, ahol más karaktereket és más módon kell escape-elni, mint a HTMLben.

Amit nem igazán értek, hogy lehet a kontrollerben (ez a fajta) a védelem? Ha általában az XSS védelemről beszélünk,annak nagyon fontos komponensei vannak a kontrollerben, de az escape-elés milyen módon krül ide? Htmlspecialhars-al írod a DB-be a stringeket?

Fejtsd ki bővebben...
2

Metódus

Max Logan · 2009. Feb. 13. (P), 13.07
A dolog úgy néz ki, hogy a form-ot POST-olja a user. Ekkor szerver oldalon lefut egy validátor, ami regex minták alapján elég jól behatárolja, hogy milyen adatok mehetnek egyáltalán tovább tárolás céljára.

Ha már nem jelez hibát a validátor, akkor mentésre kerülnek az adatok, pl. adatbázisba.

Amikor kírásra kerül sor, akkor mondjuk egy blog post, vagy komment BBCode-os szűrésen megy keresztül (ez a view egy helper-je), ami automatikusan kiszűri a HTML elemeket.

A BBCode parser-en át nem kerülö adatokat, pedig a kontrollerben egy erre szakosodott clean metódus csonkítja adott hosszra (ha kell), majd egy htmlspecialchar-t futtat rajta.

A clean függvény által adott escape-elt string kerül átadásra a view-nak.

(Természetesen a COOKIE-ból olvasott adaton is átmegy a clean.)
3

Ha jól látom..

vbence · 2009. Feb. 13. (P), 13.14
A Clean nálad egy statikus metódus, magyarán egy függvény. Így csak filozófikus kérdés, hogy a View vagy a Controller részének tekinted. Ebben a helyzetben a view részeként állja meg legjobban a helyét.
4

észrevétel

Hodicska Gergely · 2009. Feb. 15. (V), 01.15
Amikor kírásra kerül sor, akkor mondjuk egy blog post, vagy komment BBCode-os szűrésen megy keresztül (ez a view egy helper-je), ami automatikusan kiszűri a HTML elemeket.
Ez a mondatod nem tiszta nekem teljesen. BBCode-os szűrést mondasz, de HTML-t szűr. Gondolom alapvetően utóbbira gondolsz. Szerintem ezt pont fordítva kéne, illetve félig biztosan. A BBCode cseréje HTML-re az lehet döntés kérdése, hogy kiíráskor akarja-e az ember megcsinálni, de az elvileg nem megnegedett HTML-t biztosan mentéskor lenne érdemes szűrni.

Eredeti kérdésre: magának az escapelésnek szerintem is abszolút a view-ban van a helye, pont azért, mert escapelni mindig adott környezetnek megfelelően kell. Nálunk pl. a symfony-ban is jelen levő módszer van, a TemplateView nevű osztály (HTML jön ki belőle) a controllertől kapott változókat automatikusan escapelve teszi elérhetővé a template-ben. El lehet érni a "raw" verziót is, de ezt már külön így kell kérni, ergó tudatos döntés a programozótól, de véletlenül nem maradhat egy kiírt változó nem escapelve. Ez egy jó kis CoC.
5

Re: észrevétel

Max Logan · 2009. Feb. 15. (V), 02.22
Kicsit hülyén fogalmaztam. Szóval van egy BBCodeParser osztály. Ebből van származtatva a HTML BBCode helper és ebben a helperben van megoldva, hogy szedje ki a HTML tag-eket (de ez egy paraméter alapján dől el, azaz nem automatikus működés a HTML szűrés).

Ez azért van így, mert ha csak BBCode-dal engedem meg a formázást, akkor ugye minden HTML elemet ki kell gyilkolni. Viszont ha keverni akarom (tudom nem szép, de van létjogosultsága; alap esetben HTML kódok és BBCode speciális esetekre – pl. YouTube videó embed), akkor már nem kell kiszűrni a HTML-t.

Amikor felvetődött az, hogy a form helperben automatikusan meg lehetne oldani az esacpe-elést, valamint a maxLength-nek megfelelő csonkítást (biztos, ami biztos), akkor már sejtettem én is, hogy a view-ban lenne ennek a helye, csak megerősítésre volt szükségem.

Ami viszont az automatikus escape-et illeti megfontolandó. Felkerült a todo listára :-)
6

ne csonkítsunk

Hodicska Gergely · 2009. Feb. 15. (V), 13.03
valamint a maxLength-nek megfelelő csonkítást (biztos, ami biztos)
Én mindig azt mondom, hogy ne nyúljunk hozzá a user által bevitt adathoz. Ellenőrizzük, és ha nem felel meg, akkor dobjuk vissza neki, írja át ő úgy, ahogy jónak látja. Többször futottam már bele abba, hogy egy ilyen jószándékú javítás okozott hibát vagy side effectet.
7

MaxLength

Max Logan · 2009. Feb. 15. (V), 13.56
A csonkítás az input mező maxlength értékének megfelelően történik. A maxlength pl. név esetében akkora, mint az adatbázisban tárolt hossz.

Azaz a maxlength-nél hosszabb stringet normál körülmények között nem is tud POST-olni (persze Firebug és egyebek most nem téma). Ha pl. névnek mégis hosszabb string jön (hackelés) és még van hiba a form adataiban, akkor az input-ba való visszaírásnál lesz az input maxlength értékének megfelelően csonkítva a névnek megadott string. A DB-be írásnál meg úgyis csak a megadott maximális hossz lesz eltárolva (varchar mezőbe).
8

hackelés

Hodicska Gergely · 2009. Feb. 16. (H), 00.58
Ha úgyis hack vagy pedig elvileg elő nem fordulható eset, akkor miért mented le?
9

Még egy feltétel

Max Logan · 2009. Feb. 16. (H), 01.29
Hm, valóban. Azt is vizsgálni kellene a validálásnál, hogy hosszabb-e a POST-olt string, mint az input maxLength értéke. Ha igen, akkor hibát dobni, mert valamilyen módon megváltoztatták a form-ot, vagy nem is böngészőből küldték be az adatokat.

Így biztosan nem jut el a mentésig a folyamat. Viszont a hibajelzésnél, adatok form-ba való visszaírásánál így is van értelme csonkítani, mert látni fogja a próbálkozó, hogy nem fogja tudni beküldeni a hosszabb stringet.
10

Én nem mennék ilyen messzire

vbence · 2009. Feb. 16. (H), 12.22
Ha van security logod, ott mindneképpen megér egy sort, de amúgy ugyanaz a facilitás használható rá, mint amit a hibás (hiányos) kitöltésre használsz. Megmondhatod neki, hogy a "berít szöveg túl hosszú".. Ki tudja lehet, hogy a látogató böngészője nem vagy hibásan támogatja a maxlength attribútumot. (Bár nem túl nagy a valóznűsége).