Napad na Citigroup izkoristil trivialno luknjo

Prosim?

Zato je dražje?

Mislim... pri kateri firmi ti delaš?

Matthai dej ne bebcka delat iz sebe. Dejstvo je, da ce ID vodis v seji in sejo vodis preko sejnega piskota (tako kot v preko 99% premirih se), lahko zaradi uporabe piskotov nastopijo pravne posledice. Zdaj lahko izbiras med:

-dopises med pogoje uporabe da stran za svoje delovanje uporablja piskote
-najames svetovalno druzbo, ki ti zagotovi da ne potrebujes dovoljenja uporabnika za uporabo sejnih piskotov
-se odlocis, da ignoriras problematiko in riskiras placilni nalog od inspekcije

Zame nobena od teh treh opcij ni zastonj. Seveda je najlazje v pogoje uporabe vtakniti se dolocilo o piskotih. Se vedno pa kot izdelovalec spletnih stvari moras pomisliti tudi na to malenkost in jo urediti. Dejstvo je, da tega posebej ne izkazes na racunu ampak je vracunana v paket. Zaradi tega pa to se ne pomeni, da je zastonj. In ce na hitrico pregledas pogoje velikih slovenskih strani bos nasel tudi dolocilo o piskotih. Se slo-tech ga ima.

Se opravicujem za "bebcka". Ker iz preostalih tem mislim, da si dovolj pameten, da ves o cemu sem govoril, sklepam da si le zelel, da se preostalim bralcem foruma razjasnim kako lahko zaradi vodenja spremenljivke v seji namesto v URLju se dejansko povecajo stroski izdelave strani.

ID seje moraš tako voditi, kako boš pa drugače vedel če je uporabnik prijavljen?

Reycis je 18. jun 2011 ob 01:41 izjavil:

Matthai dej ne bebcka delat iz sebe. Dejstvo je, da ce ID vodis v seji in sejo vodis preko sejnega piskota (tako kot v preko 99% premirih se), lahko zaradi uporabe piskotov nastopijo pravne posledice.

Kakšne pa? Slučajno zelo dobro poznam tovrstno zakonodajo, zato kar na dan z besedo. Govorimo seveda o session in persistent cookijih.

Reycis je 18. jun 2011 ob 01:41 izjavil:

Zame nobena od teh treh opcij ni zastonj. Seveda je najlazje v pogoje uporabe vtakniti se dolocilo o piskotih.

Da, to stane vsaj kakšnih 100 jurjev. EUR seveda...

(mislim, kakšne bučke)...

Reycis je 18. jun 2011 ob 01:41 izjavil:

In ce na hitrico pregledas pogoje velikih slovenskih strani bos nasel tudi dolocilo o piskotih. Se slo-tech ga ima.

Ne boš verjel - ta del sem jaz pisal.

Reycis je 18. jun 2011 ob 01:41 izjavil:

Se opravicujem za "bebcka". Ker iz preostalih tem mislim, da si dovolj pameten, da ves o cemu sem govoril, sklepam da si le zelel, da se preostalim bralcem foruma razjasnim kako lahko zaradi vodenja spremenljivke v seji namesto v URLju se dejansko povecajo stroski izdelave strani.

Ampak če vodiš "spremenljivko v URL-ju", to potem ni avtentikacija. Saj to veš, ne? Razen če bi na vsaki strani zahteval ponoven vpis gesla.

No, jaz sem zelo dobro preučil zakonodajo v zvezi s tem in so mi stvari jasne. Dejstvo je, da strošek klavzule je zanemarljiv. Sploh če ga skopiraš iz drugih spletnih strani. Če pa si seveda nategunsko IT podjetje, je verjetno smiselno, da naročniku zaračunaš ta strošek kot ogromen znesek, po možnosti podprt z obširno (in seveda nepotrebno) raziskavo.

Smiselno je seveda zate, ne za neukega naročnika.

Vodenje seje preko URLja seveda je opcija. Samo je treba imeti nekaj pameti in narediti tisto, kar pri session cookijih browser naredi avtomatsko. Ne recimo tako kot tisto znano dvorno slovensko IT podjetje, ki je za en precej velik državni organ v Sloveniji to izvedlo tako, da sem pred par meseci odkril kako s spremembo URLja ugrabit sejo in dostopat do kritično občutljivih podatkov tega državnega organa.

Ko sem jim zadevo predstavil (organu) so najprej eno uro lovili sapo, na koncu pa prišli do tega, da se zadevo da popraviti, jih bo pa pošastno drago stala. Popravek bo seveda delal dvorni IT ponudnik, ki je celo stvar že v osnovi zajeb**.

Na splošno ugotavljam, da v teh krajih ljudem ni jasno kaj je to avtentikacija in kako narediti varno spletno avtentikacijo.

Evo, ker sem dobre volje še en primer. Za enega naročnika sem delal varnostni pregled aplikacije. Podatki iz njihove baze se se znašli na spletu in ker so bili to podatki, ki jih je treba varovati po zakonu je bila seveda pizdarija.

JAsno - takoj so posumili na teorijo zarote. Prideva z direktorjem tja in rečem naročniku če pokaže spletno aplikacijo. Top gre na login page, vpiše u/p in se začne sprehajat po bazi.

Nakar tipa prosim, da se odjavi.

Sedem za računalnik in vpišem URL, ki je bil vpisan prej (ko je bil prijavljen). In padem seveda v bazo, ki sem jo lahko tudi spreminjal.

Rečem tipu da je problem v tem, da oni predvidevajo, da bo v bazo vsakdo skušal vstopiti zgolj skozi login page, če pa nekdo vpiše direkten URL pa oni predvidevajo, da je user ustrezno logiran (a tega ne preverjajo).

Pravi da ne, da je to zato, ker se je on prej logiral iz tega računalnika "in je nekaj ostalo v cacheju". Pa ga vprašam ali se je odjavil ali ne. Reče da ja, ampak si je browser ziher nekako zapomnil da je bil on prej logiran.

Potem ležerno potegnem ven svoj laptop in ga vprašam, če se vsi strinjamo, da iz mojega laptopa nikoli ni bil nihče logiran v njihovo bazo.

Reče ja, nakar vklopim mašino in notri vpišem direktni URL... bingo, bil sem v bazi.

Tip se je dobesedno sesedel na stol, tako da sva z direktorjem že mislila klicati rešilca. Zadevo jim je programirala neka znanan firma, revizijo so dali delat drugi znani IT firmi, pa so oboji kompletno zajebali.

No, mi smo ugotovili kje je problem v pol re, potem smo rabili še ene pol ure, da smo spisali le report in 15 minut za račun. Moj najbolj easy-money...

Citigroup suffered about US$2.7 million in losses ...
http://yro.slashdot.org/story/11/06/26/...