Zaštita od hakovanja

[Misko]

Nisam neki vičan PHP koder (učim se polako) i imam jedan problem... imam skript (stranu) u kome se delovi učitavaju u zavisnosti od HTTP_GET_VARS-a, tj od parametara koje prosledim kroz link... u kodu to izgleda ovako

<?
$page=$HTTP_GET_VARS["p"];
?>

a onda gde mi je to potrebno štampam:

<? include $page.".php";?>

e sad u čemu je problem... dešava mi se da mi hakuju sajt :1092: :1027: i koriste ga za phishing. Ukapiram ja u čemu je problem ali neznam da ga rešim... pa je moje pitanje:

kako da proverim da li se fajl koji učitavam nalazi na mom serveru i ako se nalazi, onda da dopustim da se smesti u varijablu tj. odštampa gde je potrebno?

[dinke]

Sto bi rekao Harry Fuecks, ovaj tvoj nacin je "path to serious hair loss" :1064:

Elem, ako vec zelis da ukljucujes php strane u zavisnosti od request stinga, onda trebas da uradis sledece:

1) listu dozvoljenih vrednosti za tu 'page' variablu cuvas u nekom array-u tipa:


$allowed_pages = array('foo','foo1','foo2');
if(in_array($_GET['page'], $allowed_pages))
{
//nastavljas sa inludom
}
else
{
//neko pokusava da te hakuje!
}

2) nemoj page variablu da zoves page, mozes da joj das neko manje smisleno ime koje potencijalnom hakeru nece odmah reci za sta se koristi.
3) Mozes koristiti jednostavan metod "kriptovanja" (ovo nije naravno pravo kriptovanje) sadrzaja query stringa sa base64_encode/base64_decode f-jama.

I naravno, nikada ne veruj onome sto ti stize sa druge strane (usera). Za vise informacija, mozda da potrazis "Php Architect Guide to Security", mislim da se tako zove knjiga.

[Blood]

Uh, kod koji sam postavio ne valja nista :)

Ako ti treba knjiga koju je Dinke spomenuo, javi mi se na pp i poslacu ti je...

[Ilija Studen]

Pretpostavimo da je struktura ovakva:

/pages/
/pages/homepage.php
/pages/about.php
index.php

index.php kroz koji idu svi zahtevi mogao bi da ide ovako:

$page = isset($_GET['page']) ? $_GET['page'] : 'homepage';
$page_path = dirname(__FILE__) . '/pages/' . $page . '.php';
if(is_file($page_path)) {
include $page_path;
} else {
die("A to bi ti!!! E nem're!");
}

[bluesman]

Uh bre, Misko, pa to je jedna od prvih "NO-NO" stvari koje treba da naučiš. Ima dosta članaka na temu security i PHP, trebalo bi da potrošiš par dana da pročitaš to pa onda da prepraviš svoj kod.

Možda izgleda kao veliki napor, ali veruj mi da ćeš se rešiti glavobolja kao što je ova. Pročitaš jednom i "vozi miško" :)

[misk0]

Ilijin nacin ima i dobrih i losih stvari:
- na taj nacin, lako inkludujes nove stranice bez ikakvog 'instaliranja'
- isto tako haker moze tako da ukljuci stranice koje ti ne zelis da javno prikazes.

Jedan nacin bi bio da napravis (kako se zvase.... ) niz :
["p1"] = "page1.php";
["p2"] = "otherpage2.php";
........

Tako kad zelis da uradis include, prvo provjeris da li se element nalazi u nizu, ako jeste, inkludujes tacno stranicu koja je u nizu (a ti si napunio taj niz).

[Ilija Studen]

Način funkcionisanja ove skriptice je prilično jednostavan:

* sve što je u /pages može biti prikazano automatski, nema "instaliranja"...
* sve van /pages je nevidljivo skripti (tj. haker ne može da ga koristi)
* pošto se koriti apsolutni path nema protokola tako da nema učitavanja resursa spolja
* forsirana je .php ekstenzija tako da sama stranica mora da bude izvršiva

Ako nešto ne želi da bude dostupno kroz index.php neka ga ne stavalja u /pages. Jako jednostavno...

Ovo je jedno od onih "sipaš i ne misliš" rešenja. Strašno je jednostavno, a opet ga je teško oboriti.

[Aleksandar.Ilic]

Ajde jedno pitanje, ako neko zna odgovor. Da se nadovezem na ovu temu.

Imao sam bas ovakav nacin upada pre neki dan na mom serveru.
tip je bukalno imao kod ovog tipa:

if (isset($_GET['page])) {
require($_GET['page]);
}

i sta se desilo....

dosao pametni haker i poslao kao parametar za page neki svoj url, i onda mu se u okviru ovog sajta otvorila neka web konzola. I on je bukvalno kroz konzolu mogao da uploaduje fajlve na moj server, i da pokrece programe na mom serveru. E sad. Kako moze da radi upload?? Aj to cu i da shvatim, ali kako bre moze na taj nacin da pokrene neki program koji se izvrsava na mom serveru :1027:
any hint?

[Pedja]

Onog momenta kada dodje u situaciju da izvrsi svoj PHP kod, moze da uradi sve sto je PHP-u doyvoleno a to manje/vise znaci sve.

imas u stvari jednostavan trik protiv toga, samo uvedi nekiprefiks za ime datoteke koju inkludujes tako daces da zeznes bilo kakav podmetnut sadrzaj. to je naravno samo brza precica, ali moze da odradi posao ko ti je nezgodno da odrzavas listu dozvoljenih skriptova.

Jos je bolja opciaj da oznaka strane budeneki id a da se na osnovi ID-a u stvari odnekud procitakoji se tacno skript ucitava. Tadane moras da radis neku veliku proveru, prosto ako ID nije definisan, prijavis gresku. Na taj nacin ustvari najbolje izolujes hakera od include i require.

[misk0]

Aleks: Nisam siguran, ali mislim da je moguce da ucita PHPShell i da na osnovu toga izvrsava fakticki bilo koju komandu. Ako nije to u pitanju, vidjao sam custom-made skripte koje dozvoljavaju takve akcije (cak sam imao tako nesto na disku).
Takodje nisam siguran (ideja) mislim da se u php.ini moze zabraniti include URL-a unutar parametara ili tako neka fora, ne znam na pamet.

[dinke]

Ovo je jedno od onih "sipaš i ne misliš" rešenja. Strašno je jednostavno, a opet ga je teško oboriti.
A sta ako user posalje nesto tipa page = ../../../foo ? ladno ce taj fajl traziti ispod page dira o kome pricas. Sve u svemu, vrlo insecure.

[Br@nkoR]

>= PHP 5.1.0

//php.ini

allow_url_include = Off


edit:

a postoji i allow_url_fopen

[Aleksandar.Ilic]

hm, ja licno znam za taj allow_url_include. I nije meni problem da zastitim svoj kod protiv ovakvih napada. Stavise, nijedna moja skripta nije ranjiva na ovakav tip napada. Nego mene zanima kako da napravim skriptu koja moze se tako includuje preko url-a i da radi na server na kome je includovana :)

[Pedja]

Pa napravis kao i svaku drugu skriptu, samo moras da joj promenis ekstenziju da tvoj server posalje php kod a da ga ne izvrsi. Ovaj drugi include-uje sors i izvrsi ga.

[Aleksandar.Ilic]

lele, a ja sam mislio to neki teski hack :D Sramota :) Thnx

[zark0vac]

Hehe..
Sto se tice zastite od rfi-a, sledece stvari su korisne da se podese kako
navedem sem ukoliko je neophodno za funkcionisanje skripte da se ne menja.

Za pocetak ako ti skripta moze bez, obavezno iskljuci potencijalno opasne funkcije:


disable_functions=system,exec,passthru,shell_exec


Ovime si onemogucio pokretanje php shell skripti (r57, c99..) i samim tim
ozbiljniju stetu na serveru, ali ako nisi u mogucnosti to da uradis, ali i ako
jesi, u svakom slucaju procitaj ceo post i preporucljivo je da poslusas. :)

Zatim nacin za zabranu pozivanja fajla van odredjenog direktorijuma se moze
odraditi sa array-om kao sto je navedeno na 1 strani, ali ako ne zelite tako,
mozda vam ovaj kod moze pomoci:


<?php
$folder = 'moduli/';
$ekst = '.php';
$modul = str_replace(".","",$_GET["modul"])

if ( file_exists($folder.$modul.$ekst) ) {
$fajl = $folder.$modul.$ekst;
include($fajl);
} else {
echo "404 Not found";
}

?>



Postoji mogucnost da se uploaduje preko ovog koda i fajlovi koji
nisu sa .php ekstenzijom ali se nalaze u direktorijumu moduli/.
Primer:


http://www.serv.com/include.php?modul=nesto.txt?
# cime postaje: modul/nesto.txt?.php i zanemarena je .php ekstenzija,
# primer broj 2:
http://www.serv.com/include.php?modul=nesto.txt%00
# isto samo sto se ovime sav nastavak posle nesto.txt zanemaruje zbog
# null chara.


Za prosledjivanje vrednosti koristi $_POST umesto _request-a,
a $_get koristi samo tamo gde je namenjen, forsiraj post metod.
Zatim iskljuci register_globals i allow_url_fopen, i gledaj kod skripti :)
Preporucujem ti da pregledas security deo php manuala, dosta
ces nauciti o ovim napadima. Takodje se pozabavi sql injectionom,
daleko manje opasnim xss-om i komplikovanijimm csrf-om (ako je
manji projekat, csrf mozes zaobici, za sad :) ).

Ako imas dedicated onda ili unajmi nekog security experta da ti
podesi sistem kako i kada bi doslo do includeovanja php shell skripte
i dizanje nc-a da napadac ne moze da roota server, ali i redovno
skidaj patcheve za sve daemone/servise koje se vrte na tvoj boxu...

Nadam se da sam pomogao...

[oliver]

A sta ako user posalje nesto tipa page = ../../../foo ? ladno ce taj fajl traziti ispod page dira o kome pricas. Sve u svemu, vrlo insecure.

quickfix :)

$page = isset($_GET['page']) && strpos("../",$_GET['page']) === false ? $_GET['page'] : 'homepage';

[bluesman]

ili instaliras mod_security :) Ono sto sve zive nervira, ali radi pos'o :)

[ivanhoe]

ma bre Ilija sta fali tome da imas niz u kome pisu sve stranice koje je moguce inkludovati...ccc, sto ste bre toliko lenji...ova omladina, sve bi automatski :D

em je znatno sigurnije, em kad otvoris kod posle x meseci znas odmah koje strane se ukljucuju za koji ulazni parametar, bez da trazis po direktorijumima i tumacis mogucnosti...

[dinke]

jel to pokusavas da mi kazes da i ja trebam da stavim "old school" u svoj potpis ;) ?

[Aleksandar.Ilic]

Pa to je i najsigurniji nacin. Ja uvek hardkodiram inkludovanja. Manje boli glava, kod nije sporiji i naravno, definitivno je daleko pregledniji.
Samo sto eto, neki zele da pisu sto manji kod :), jer ih mrzi da kucaju (ponekad) par desetina puta include (require)

[Ilija Studen]

A sta ako user posalje nesto tipa page = ../../../foo ? ladno ce taj fajl traziti ispod page dira o kome pricas. Sve u svemu, vrlo insecure.

100% si u pravu. Rupčaga!

if(!preg_match("/^([a-zA-Z0-9_]*)$/", $page)) {
die('Invalid file name');
} // if

Ili još jednostavnije:

if(strpos($page, '.') !== false) {
die('Invalid page name');
} // if

ma bre Ilija sta fali tome da imas niz u kome pisu sve stranice koje je moguce inkludovati...ccc, sto ste bre toliko lenji...ova omladina, sve bi automatski :D

em je znatno sigurnije, em kad otvoris kod posle x meseci znas odmah koje strane se ukljucuju za koji ulazni parametar, bez da trazis po direktorijumima i tumacis mogucnosti...

Ručno moraš da edituješ fajl ako nešto dadaš što je ponekad smor. Oba će raditi posao bez ikakvih problema, tako da je sve manje više stvar ukusa... Ipak više volim kada skripta radi veći deo prljavog posla za mene.

Btw, ja bih od ovoga napravio klasu :) Prima dva parametra - odakle da pokupi ime stranice i gde su smeštene stranice. Dokle god je interfejs klase čitak bole me uvo šta je ispod haube. Tipa:

$dispatcher = new Dispatcher(dirname(__FILE__) . '/pages');
$dispatcher->dispatch(@$_GET['page']);

:p

[ivanhoe]

pa, uvek moze da se napravi zaseban ini fajl sa spiskom fajlova za include.. tako izbegavas editovanje koda...

[Ivan]

Hm, vidim da je ovde iznete dosta pametnih stvari ali ajde da probam da sumiram ...

Prvo i najvaznije pravilo koje svi treba da zapamtimo je: Filtrirati ulaz i escajpapovati izlaz.

Sto znaci da ulazni podaci mogu biti samo oni koje nasa aplikacija moze i sme da koristi. U konkretnom slucaju, najpamentnije resenje sa gledista sigurnosti je koriscenje switch-a. Tj za svaki zahtev postoji deo koda koji barate njime. Sve ostale metode se mogu lakse ili teze exploitovati, dodavanjem specijalnih karaktera ili losom konfiguracijom servera. Dalje npr, ako su nam potrebni samo brojevi u nasam scriptu koje dobijamo preko GET-a onda ogranicite te varijable na brojeve. Ne ostavljajte mesta za nehendlovane situacije.
Sto se tice izlaza, uvek treba prikazivati samo ono sto smemo da prikazemo a to znaci da sav kod koji moze da se izvrsi u browseru usera a ne treba biti izvrsen treba sanitizovati.

Za pocetak je dovoljno poslusati ovaj savet gore jer cete se tim nacinom kodovanja osloboditi vecine XSS, CSLF, SQL injectiona, Directory Traversal, include propusta ...
Neko je vec rekao da treba forsirati POST sto je delimicno tacno jer ce tako skinuti scriptkiddie sa vrata ali to ipak nije pravo resenje.

$page = isset($_GET['page']) ? $_GET['page'] : 'homepage';
Ovakav nacin pisanja koda (Ternary Operator) nije pozeljan zbog preglednosti koda.

Neko je pomenuo mod_security, a takodje i neka podesvanja u samom php-u ... Sve ovo resava neke sigurnosne probleme ali poenta je napisati siguran kod bez pomocnih sredstava jer u svakom trenutku moze doci do promene konfiguracije servera.

Za vise informacija, mozda da potrazis "Php Architect Guide to Security", mislim da se tako zove knjiga.

Za pocetak:
http://phpsecurity.org/
http://phpsec.org/projects/guide/sr/

E kad ovo predjete onda krece pravo zezanje :p Ajax, CSRF, i sl ...

[dee]

Uh, kod koji sam postavio ne valja nista :)

Ako ti treba knjiga koju je Dinke spomenuo, javi mi se na pp i poslacu ti je...

trebalo bi meni...imas li jos koji primjerak? :)

[Ilija Studen]

pa, uvek moze da se napravi zaseban ini fajl sa spiskom fajlova za include.. tako izbegavas editovanje koda...

Ali dodaješ editovanje ini fajla. Šta si time dobio? Ništa... Još jedan fajl viška i dodatnu kompleksnost jer moraš da ga učitaš, parsiraš, izvučeš vrednost. Rad sa nizom unutar index.php je bolje rešenje od toga.

Pazi ovo, samo malo discipline i zdravog razuma: u /pages direktorijum samo stavljaš one stranice koje želiš da budu dostupne kroz index.php, nikakve druge gluposti. To je prvo i poslednje pravilo. Skripta radi ostatak.

Ovakav nacin pisanja koda (Ternary Operator) nije pozeljan zbog preglednosti koda.

Sorry, već sam par puta od jutros krenuo da odgovorim pa zatvorio reply prozor. Ipak ne mogu da se suzdržim. Moram:

:1075:

TO je izuzetno praktična stvar dokle god ga koristiš sa osnovnom dozom zdravog razuma, a trudim se da verujem da je prosečan PHP developer ima ;)

Bah, i evo mene opet u ovakvim diskusijama i sa istim tonom. A obećao sam da neću više :D

[ivanhoe]

Ali dodaješ editovanje ini fajla. Šta si time dobio? Ništa... Još jedan fajl viška i dodatnu kompleksnost jer moraš da ga učitaš, parsiraš, izvučeš vrednost. Rad sa nizom unutar index.php je bolje rešenje od toga.

ilija, nisi slusao na casovimal :)

$ini_array = parse_ini_file("sample.ini");


ini fajl je laksi za odrzavanje nego niz, a i malkice je brze nego include php fajla (jedino ne znam da li je podrzano kesiranje rezultata od strane akceleratora ? )

[Misko]

Uhhh... ovo se zove serija konstruktivnih odgovora... hvala puno svima... rešio sam problem :1042:

[Ilija Studen]

ilija, nisi slusao na casovimal :)

Ništa novo ni iznenađujuće ;) Ja sam na časovima programiranja čitao "Očevi i oci" i još par naslova (za Očevi i oci znam sigurno jer mi je profesorica oduzela knjigu i rekla da će se žaliti razrednoj; nije mi išlo u glavu što bi se bilo ko žalio na tako dobru knjigu? :D ).

ini fajl je laksi za odrzavanje nego niz, a i malkice je brze nego include php fajla (jedino ne znam da li je podrzano kesiranje rezultata od strane akceleratora ? )

Ček, ček. Hoćeš da kažeš da je:

$ini_array = parse_ini_file("sample.ini");

Brže od:

$allowed_pages = array('home', 'about', 'contact');

Ovo drugo sam imao na umu kada sam rekao "rešenje sa nizom" (Dinke je prvo to ponudio). Niz je unutar index.php jer nema poente da bude spolja.

Zip...

[oliver]

trebalo bi meni...imas li jos koji primjerak? :)

ajd i meni, cini mi se da nemam to u "arhivi".

...ili okacite na Host011 tracker (http://torrent.host011.com/) :)

[zark0vac]

Ja sam svakako za koriscenje nizova i samo nizova sem kada je izricito receno da se ne radi sa nizovima :-))

Najlaksa 100% sigurna varijanta.

[Ivan]

@Ilija:
TO je izuzetno praktična stvar dokle god ga koristiš sa osnovnom dozom zdravog razuma, a trudim se da verujem da je prosečan PHP developer ima

Da, prosecan pa i napredniji PHP developer je veoma razuman covek koji ipak pravi greske. Ova preporuka koju sam naveo je preporuka vodecih security experata koju sam ja samo preneo (i da slazem se sa njom).
Ako te zanima zasto je to tako, onda malo vise procitaj ili razmisli o tome ...

Btw, spusti se na zemlju jer ni tvoj kod nije bas tako siguran ... :1074:

[ivanhoe]

Ček, ček. Hoćeš da kažeš da je:

$ini_array = parse_ini_file("sample.ini");

Brže od:

$allowed_pages = array('home', 'about', 'contact');


ne naravno :), samo sam nudio varijantu da mozes da napravis svoju klasu, i da omogucis da se ne menja php kod pri svakom dodavanju fajla (menjas samo ini koji je jednostavne strukture, znaci minimalne sanse za gresku)...i sve je divno i uredno, a jos i sigurno... and they lived happily ever after :1042:

[Blood]

ajd i meni, cini mi se da nemam to u "arhivi".

...ili okacite na Host011 tracker (http://torrent.host011.com/) :)

heh, za ovo nisam ni znao - kacim o'ma sada... :P


POzdrav!

EDIT By Dinke:
Bez warez linkova na forumu! Kome treba moze da koristi pp za razmenu.

[zira]

Btw, spusti se na zemlju jer ni tvoj kod nije bas tako siguran ... :1074:

Cemu ovakvo "spustanje", Ivane? :1050:

[Ivan]

OMG, ne ponovo ...

Odgovorio sam tako zbog Ilijinog stava.
Zar nije bilo bolje da pita zasto je tako to sto sam napisao ? Ne, on je odmah rekao da pricam gluposti ...

[Ilija Studen]

Ako te zanima zasto je to tako, onda malo vise procitaj ili razmisli o tome ...

Baš me zanima to o potencijalnim opasnostima. Može neki link ili objašnjenje?

Btw, spusti se na zemlju jer ni tvoj kod nije bas tako siguran ... :1074:

Kakve to veze ima sa čitljivošću TO-a? Osim u detinjastom kontekstu a-la "Moj tata jači od tvog tate!" ili "Ceca je bolja riba od Brene!"? Molio bih da me poštediš toga... Hvala.

Što se sigurnosnih propusta u activeCollabu tiče ljudi su ih prijavljivali, ja sam ih ispravljao i tako dan za danom, pred kockastim ekranom. Sudbina većine web aplikacija koje počnu da se distribuiraju je da pre ili kasnije nalete na sigurnosne probleme. Ja new kid on the block, a takvo tržište (sistemi su heterogeni, ne možeš da pružiš auto update itd)... Pogreši čovek. Ono što je bitno je vreme u kome možeš da reaguješ i doturiš pokrpljen kod korisnicima.

Btw, govorio si o ČITLJIVOSTI koda ;)

[Ivan]

@Ilija
Zbog tvog oholog stava ostavicu te da mislis o temi ...

[Ilija Studen]

Sorry, ali sve što vidim je verbalni terorizam (http://www.pionirovglasnik.com/index.php?category=31&content=279) (a must read tekst btw).

Btw, za ovu priču automatsko razrešavanje lokacije fajla koji sadržaj stranice vs. definisanje niza ili ini fajla naiskrenije sam ubđen da je prvo bolje rešenje. Dodaje na kompleksnosti aplikacije, ali smanjuje kompleksnost korišćenja jer ukida jedan korak pri definisanju novog sadržaja (to je inače jedan od principa razvoja koji smatram da je OK). Sorry ako je zvučalo oholo (pošto mi to uopšte nije bila namera). Sve je bilo samo posmatranje par konkurentnih rešenja - njihove prednosti i mane.

[zark0vac]

Svaka cast za link Ilija.
Najbolje mi je: Primetio sam da su oni koji se ne slažu sa mojom sledećom tezom uglavnom neobrazovani. [sledi teza] aka Najbolje je koristiti nizove/ini fajl/ automatsko razresivanje stranica, ko se ne slaze neka procita malo vise literature... :-))

[dee]

Samo vas gledam i razmišljam da li da vam predočim svoje poglede i tehnike vezane uz temu, ali uzimajući u obzir vaše iskustvo, obrazovanje i inteligenciju, prilično sam siguran da vi to ne bi mogli razumjeti :D

-------

alzo...

kad smo vec kod hakovanja... da ne otvaram novi topic. kako rjesavate login sistem? mislim cisto nacelno kao ideju? ono sta sam ja do sad koristio je otprilike:

- korisnik unosi usr/pass (filter podataka)
- kreira se session sa custom IDjem
- taj ID se sprema u cookie
- pri ponovnom dolasku, provjerava se
a) ima li covjek cookie? (ako nema -> login.php)
b) ako ima, pokreni session ciji ID je zapisan u cookie
c) ako ima i cookie i postoji taj sessID -> dozvoli pristup, else -> login.php

i cookie lifetime stavim na 15 minuta.

po literaturi o sigurnosti nailazio sam i na prijedloge da se pri svakom requestu provjerava User-Agent jer je malo vjerojatno da ga covjek mijenja pri aktivnosti na stranici, a ako ga je vec promijenio, nece zamjerit ponovni login. tako da mi se to cini ko dobra usputna provjera (nisam koristio).

sta se jos koristi i kako?

[Ilija Studen]

^ Cookie lifetime ti je prekratak. U tom slučaju slobodno možeš da koristiš i sesije jer im je trajanje duže od navedenog lifetime (ali nije trajno).

Cookie bi trebalo da koristiš kada ti sesije ne rade posao (traju prektratko, recimo kod webmaila gde korisnici cepaju jedan email dosta dugo) ili gde jednostavno hoćeš da obezbediš remember me funkcionalnost (remember me for 14 days ili remember me forever).

Jedan od meni poznatih problema sa čuvanje SID-a u cookieju je što isti podaci mogu lako da budu pročitani ako ti skripta ima neke druge propuste, XSS pre svega (recimo, JS ima mogućnost da pročita vrednosti cookie-a i ako ti neko ubaci maliciozan JS taj kod može da pošalje vrednosti unutar cookie-a napadaču). Tu bi fazon sa proverom user agenta odradio posao ako ga malo "posoliš" (dodaš mu neki prefix ili sufix znan samo skripti koji ne može da se pročita iz JS-a).

Ima tu peripetija... Recimo, problem je što će korisnik biti izlogovan ako recimo upgraduje browser.

Pogledaj linkove ovde (http://www.google.com/search?q=session+fixation&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a). Pokriveno je dosta situacija povezanih sa logovanjem korisnika i sesijama koje su potencijalne rupe, a nisu odmah očigledne. Dovitljivi su hakerani, teško im je stati na rep :D

[dee]

Cookie bi trebalo da koristiš kada ti sesije ne rade posao (traju prektratko, recimo kod webmaila gde korisnici cepaju jedan email dosta dugo) ili gde jednostavno hoćeš da obezbediš remember me funkcionalnost (remember me for 14 days ili remember me forever).


ovo bi filtriranje ulaznih podataka trebalo rijesiti, zar ne? recimo prosto htmlspecialchars() i htmlentities()?

[Ilija Studen]

ovo bi filtriranje ulaznih podataka trebalo rijesiti, zar ne? recimo prosto htmlspecialchars() i htmlentities()?

Možeš odmah pri inputu da escapeuješ, a možeš i prilikom prikazivanja. Preferiram ovo drugo jer volim da imam originalne podatke u bazi.

Primer, ja na activeCollab želim da dozovolim da ljudi postoju JavaScript kod (recimo, dva developera diskutuju o nekoj JS funkciji u messages sekciji). Ono što ne smem da dozvolim je da to bude renderovano kao JS i intepretirano već kao klasičan output. Zato escapeuješ content...

clean() funkcija (http://code.activecollab.com/trac/browser/trunk/environment/functions/general.php#L64) mi do sada nije pravila problema. Za razliku od čiste htmlspecialchars() ona se ne gubi sa kodiranim UTF-om. Preuzeto iz punBB-a (doduše, tamo se drugačije zove) :)

[Pedja]

Samo jedna kratka poaska na temu INI-ja: ne volim d aih korsitim u PHP zato sto je to neuobicajen tip dokument za web serer i po pravilu znaci da moram da podesavam server da ne prikazuje INI korisniku. Ja sve drzim kao PHP (cak i sablone) jer sam tako siguran da sadrzaj koji predstavlja kod nece biti prikazan korisnisku.

Osnovni princip koga se drzim kada pisem skript, to je da on ne trazi neka specijalna podesavanja servera. Razlog je ocigledan: nikad ne znam na kom serveru ce taj skript da se vrti i da li ce taj server moci da se prilagodjava.

Zbog toga i konfiguraciju drzim u PHP i to upravo kao niz. Niz ima i jos jednu lepu prednost: ima hijerarhijsku strukturu za razliku od INI-a koji ima samo dve dimenzije.

Sto se tice logina, nikada mi nije bas sasvim bilo jasno zasto login sistemi nude koridniku opciju da ga automatski uloguju. Meni se to cini kao poprilican rizik, a kao opcija mi se cini nepotrebno, jer svaki veb citac ima opciju da to sam uradi, i to jos da podatke cuva u kriptovanom obliku, ne u kolacicu, na mestu koje je hakerima mnogo nedostupnije.

[Ilija Studen]

Sto se tice logina, nikada mi nije bas sasvim bilo jasno zasto login sistemi nude koridniku opciju da ga automatski uloguju. Meni se to cini kao poprilican rizik, a kao opcija mi se cini nepotrebno, jer svaki veb citac ima opciju da to sam uradi, i to jos da podatke cuva u kriptovanom obliku, ne u kolacicu, na mestu koje je hakerima mnogo nedostupnije.

Browseri imaju mogućnost da popune polja login forme, ne i da automatski uloguju korisnika (ili grešim???). Ovo je jako bitna opcija za stvari koje korisnici jako mnogo koriste (forumi) i gde mnogo pišu. Bar malo olakšaš ljudima život, cene to ;)

Recimo, imaš situaciju gde čovek 2h piše specifikaciju ili neki timeline - nakon submita skripta skonta da je sesija istekla i da ovaj treba da se uloguje. U tim slituacija će imati ili frustriranog korisnika koji će da ti okrene familiju po spisku jer mu je propalo dva sata posla (nisi mu sačuvao podatke) ili moraš da obezbediš mehanizam za resubmitovanje forme (podaci se pamte zajedno sa login podacima i nakon uspešnog logovanja ponovo submituju). Doduše, ovu drugu funkcionalnost je dobro imati za korisnike koji nisu čekirali Remember me pri loginu tako da će opet izgubiti rad nakon par sati idleovanja...

Najjednostavnije rešenje je održavanje sesije tako što je pamtiš u cookie-ju na više od session lifetimea. Klasičan remember me pamti na par dana, meseci ili beskonacno, ali možeš da koristiš recimo čuvanje na 5 sati čisto da bi se ogradio od slučajeva kao što je gore (retko će se desiti da neko submituje formu 5 sati nakon poslednje aktivnosti na sistemu).

Duga priča :( :1075:

[Pedja]

Citac zapamti user i pass tako da korisniku ostaje samo da klikne na login. To je cak i prakticno jer mnogi forum i kada se izlogujes resetuju pokazivace na procitane poruke pa ako samo na brzaka zelis da udjes na forum da nesto pogledas a on te autologuje onda moras da pregledas sve neprocitane poruke jer ti je to jedina sansa da ih vidis kao neprocitane.

Meni se to redovno desava sa ES-om, jer mi je kod njega ukljucen autologin i svaki put kada trazeci nesto na Google otvorim ES link, ugrizem se za kaziprst, jer onda moram da proverim poruke (posto sam moderator, moram da o tome vodim racuna)

Ako nisi autologovan uvek imas mogucnost da izbegnes login i samo bacis pogled na forum.

Takodje je veliki problem ako pises poruku pa oduzis i forum te izloguje sto ce autologin da odradi stvar a ti to neces ni primetiti, i opet imas isti problem - izgubljeni su pokazivaci na neprocitane poruke ali ovaj put ti to i ne znas jer nisi ni primetio da si bio izlogovan.

[MorenoArdohain]

^ Mislim da je onda greska do lose napisanog softvera, jer bi pokazivaci na neprocitane poruke trebale da se oslanjaju ne na vreme logina, vec na flag za svaku poruku, za tog usera, tj tebe (procitano/neprocitano).

[ivanhoe]

Recimo, imaš situaciju gde čovek 2h piše specifikaciju ili neki timeline - nakon submita skripta skonta da je sesija istekla i da ovaj treba da se uloguje.

ovaj problem se elegantno resava ajaxom...samo osvezis sesiju svakih 15-20 minuta tako sto cimnes neku skriptu na serveru.. ne mora naravno XMLHttpRequest da se koristi, moze obicna slika kojoj se setuje novi src sa setTimeout...



takodje za login je odlicna ideja da se generise novi session id kod svakog pristupa, pri cemu se pazi da jedan korisnik ne moze da ima 2 sesije otvorene istovremeno... napadac mora da uzme friski SID i da ga iskoristi pre korisnika da bi mogao da pristupi sajtu, ali onda korisnik dobije login formu i nakon sto se uloguje, napadac je opet izlogovan..

sto se provere user-agenta tice, meni se to cini kao nepotreban trud...onaj ko moze da mazne SID, moze i da pogleda koji je user-agent u pitanju, a ionako ljudi masovno koriste IE pa nije tesko cak i pogoditi.. daleko korisnije bi bilo kad bi mogla da se proverava IP adresa, jer tu nema prevare...ali to je diskutabilno zbog ljudi/firmi koje koriste farme proxija, pa im se ip menja..

[bluesman]

Browseri imaju mogućnost da popune polja login forme, ne i da automatski uloguju korisnika (ili grešim???). Ovo je jako bitna opcija za stvari koje korisnici jako mnogo koriste (forumi) i gde mnogo pišu. Bar malo olakšaš ljudima život, cene to ;)

Recimo, imaš situaciju gde čovek 2h piše specifikaciju ili neki timeline - nakon submita skripta skonta da je sesija istekla i da ovaj treba da se uloguje. U tim slituacija će imati ili frustriranog korisnika koji će da ti okrene familiju po spisku jer mu je propalo dva sata posla (nisi mu sačuvao podatke) ili moraš da obezbediš mehanizam za resubmitovanje forme (podaci se pamte zajedno sa login podacima i nakon uspešnog logovanja ponovo submituju). Doduše, ovu drugu funkcionalnost je dobro imati za korisnike koji nisu čekirali Remember me pri loginu tako da će opet izgubiti rad nakon par sati idleovanja...

Najjednostavnije rešenje je održavanje sesije tako što je pamtiš u cookie-ju na više od session lifetimea. Klasičan remember me pamti na par dana, meseci ili beskonacno, ali možeš da koristiš recimo čuvanje na 5 sati čisto da bi se ogradio od slučajeva kao što je gore (retko će se desiti da neko submituje formu 5 sati nakon poslednje aktivnosti na sistemu).

Duga priča :( :1075:

Ne znam zašto ovoliki offtopic, ali aj'... Ja sam to rešio tako što ako mu je istekla sesija (možda neko drži jednu stranu otvorenu ceo dan... pa nastavi "kasnije") onda mu izbacim opet sve što je napisao uz komentar tipa: istekla vam je sesija, morate ponovo da se ulogujte, ovo je tekst koji ste napisali, kopirajte ga da ne bi morali da pišete ponovo. To pali čak su mi neki ljudi sa sajta pisali da im je to "spasilo život" jer bi se roknuli da su morali ponovo da pišu sve.

Kada sam proverio kako je došlo do toga, kaže da je počeo da piše odgovor pa je seo da večera, odgledao film i nastavio 3 sata kasnije, dovršio (ogromnu) poruku i kliknuo "send". Zašto bi on i morao da zna da mu sesija traje 1 sat ili 15 minuta....

Drugo rešenje koje sam koristio, ali se nije pokazalo kao sjajno iako na prvo pogled tako izgleda, je da ubaciš neki brojač na stranu i recimo posle 15 minuta ispiše nešto tipa: vaša sesija će isteći za 5 minuta, refreshujte stranu ili ćete morati ponovo da se ulogujete. Naravno, problem je bio što kada čovek nije ispred računara, kao recimo onaj gore što je odgledao film, ne može ni da vidi takvu poruku pa da reaguje.

Eto,... šta sam ono hteo da kažem? :)

[Ilija Studen]

ovaj problem se elegantno resava ajaxom...samo osvezis sesiju svakih 15-20 minuta tako sto cimnes neku skriptu na serveru.. ne mora naravno XMLHttpRequest da se koristi, moze obicna slika kojoj se setuje novi src sa setTimeout...

Zaboravih na ovu foru. Čak ne mora ni Ajax, dovoljan je iframe sa meta refresh koji otvara blanko stranicu koja samo osveži sesiju i umre. Time nema JS zavisnosti.

takodje za login je odlicna ideja da se generise novi session id kod svakog pristupa, pri cemu se pazi da jedan korisnik ne moze da ima 2 sesije otvorene istovremeno... napadac mora da uzme friski SID i da ga iskoristi pre korisnika da bi mogao da pristupi sajtu, ali onda korisnik dobije login formu i nakon sto se uloguje, napadac je opet izlogovan..

Ovo je dobra ideja. S ovim bih se mogao malo poigrati...

sto se provere user-agenta tice, meni se to cini kao nepotreban trud...onaj ko moze da mazne SID, moze i da pogleda koji je user-agent u pitanju, a ionako ljudi masovno koriste IE pa nije tesko cak i pogoditi.. daleko korisnije bi bilo kad bi mogla da se proverava IP adresa, jer tu nema prevare...ali to je diskutabilno zbog ljudi/firmi koje koriste farme proxija, pa im se ip menja..

Zato rekoh "posoljeni" user agent. Npr, prilikom instalacije skripta napravi neki random string od X karaktera i to koristi kao prefiks za user agent, a u cookie čuva dadatni parametar koji je hash od tog random stringa + vrednost UA. Pošto skripta zna i jedno i drugo lako je da rekonstruiše hash i proveri da li se poklapa sa ovim u cookie-ju... Napadaču nedostaje random string, a ako hoće da bruteuje hash samo nek izvolu :)

Meni je zanimljiva vaijanta kod Raiffeisen ebankinga je što ti iskoči popup minut pre nego što ti sesija istekne i pita da li da je osveži (ova druga varijanta što je Blues predložio). Uglavnom beskorisno pošto to uradi uvek kada nisam za kompom :)

[Kenny]

Sta bi bio SQL Injection? Takoder prijatelj mi je rekao da ne koristim:

or die(mysql_error());
jer ce potencijalni hacker namjerno upisati nesto pogresno, pa ce mu izbacit liniju koda gdje se nalazi taj query i sl, ne znam ja sad to objasniti, da li je to ok? I oko sql injectiona gdje treba paziti?

[ivanhoe]

^^ hehe, ako nastavis da postavljas ovakva pitanja bice "Who killed Kenny" :D

potrazi brate malo po netu, ne budi lenj... ima gomila textova o SQL Injectionu, i o tome da ne treba printati detaljne greske korisnicima...

[salebab]

Prvo, trebas da napises kod koji ne dozvoljava korisniku da izazove neki error na bilo koji nacin. To je onda klasican bug. Postoji gomila teksta o filtiranju podataka koji dolaze spolja, pa pretrazuj.
A drugo, korisnika ne treba da zanimaju greske. Dovoljno je samo da im ostavis neku ovakvu poruku: "**** happens, try latter", ili nesto humanije, a da mysql_error upises u neki .txt fajl za koji ces samo ti znati gde se nalazi :)

Pozdrav!

[Kenny]

^^ hehe, ako nastavis da postavljas ovakva pitanja bice "Who killed Kenny" :D

..


:D

hvala svima :1043: