Utok na vlastnu stranku

rooobertek nie ja praveze ju chcem spravit co najbezpecnejsiu v ramci mojich moznosti este tam nacpem stripslashes a mysql_real_escape_string a to mi asi staci nie ?
// este by som podotkol ze moj stranku asi moc vela ludi nebude hackovt z dovodu ze ju koli mojmu SEO ani poriadne nenajdu

Hlavne sa na to nespoliehaj, že "veď načo by to niekto skúšal", to je výraz absolútneho amatérizmu. Na Slovensku asi 3/4 php-čkarov to tak bere.
Nie je to celkom tak, že by ti stačilo mysql_real_escape_stringa pod. To ťa SČASTI ochráni proti sql injection, ale je ešte veľa veľa vecí, ktorými ti môže niekto spraviť vrásky na čele. Napríklad buffer overflow by nenapadlo hocikoho hľadať v PHP. html_entities v starsich verziach PHP, na urcitych operacnych systemoch, dokaze spravit riadnu sarapatu, pad celeho systemu ak tam das niektore grecke znaky.
Treba stále čítať, stále sa objavujú nové útoky, prečítaj si aj staré veci, aktualizuj všetko, čo používaš vrátane free balíčkov ako cms, chat...
Môžeš spraviť všetko totál brutál bezpečné, necháš jednu malú medzeru a celý systém môže padnúť. Aj bankám sa stávajú takéto veci.

(sorry za preskakovanie medzi textom s diakritikou a bez)

este snad jedna poznamka: osetruj aj data, ktore tahas z db - na toto drviva vacsina ludi zabuda...

Ahoj stenley,
o tom som ešte nepočul. Nakoľko si myslím, že nebezpečenstvo vzniká pri čítaní zlých parametrov (nebezpečných). Nakoľko ich musíš mať v databáze uložené. Teda pokiaľ máš v databáze uložené všetko bezpečne, nemalo by sa stať, že by si spracovával nebezpečný kód. Nakoľko by si mal mať dobre zabezpečené knižnice a includy nemalo by sa stať, že sa ti do DB dostane niekto iný.

Teda mohli by sme povedať, že keď si to prefiltruješ pri vkladaní, malo by to byť prefiltrované pri čítaní. Teda kde je nebezpečenstvo?

ja velmi do bezpecnosti neumim, preto sa pytam: ja bezne pouzivam include_once da sa includovat aj bezpecnejsie? ak ano, ako?

a ako je include_once napadnutelny?

DIK.

stenley, jj, to som zabudol spomenúť, whitelisting je momentálne najbezpečnejšia metóda.Robí sa väčšinou pomocou regexp - v php sú na to funkcie skupín preg a ereg.
Okrem toho, ak očakávaš, že vstup má byť číslo, použi settype($input,"integer") alebo intval, na desatinné čísla tiež settype alebo floatval...

Na veci v databáze sa nemôžete spoľahnúť, že nie sú zmenené útočníkom. Do databázy sa ti vždy môže niekto nabúrať. Neveril by si, aké heslá si dávajú niektorí admini na databázy. A nemenia ich aj niekoľko rokov.

max-m, pokiaľ includuješ takto: include_once("abc/settings.php"), je to v pohode, ale include_once($_GET['abc']) je už iná káva

Tak teda ja na strankach nepouzivam nic "cudzieho" vsetko iba moje kody a este k tym vraskam na cele a pade celeho systemu moji 3 uzivatelia by sa urcite znova regli takze tak
ale ano samozrejme treba citat o new utokoch a brant sa proti nim

>Tominator: ty sice zabezpecis vsetky vstupy prichadzajuce od uzivatela, ale to je len polka prace, ktoru musis urobit... a preco? niekto ti napadne databazu a vlozi tam skodlivy kod... nakolko neosetrujes data ziskane z db, kod sa pri nacitani stranky vykona... takze netreba sa spoliehat na to, ze v db su ulozene len spravne udaje...

a teda ako to mam teoreticky kontrolovat tie udaje z DB akou tou funkciou bo ja som taku nenasiel rooobertek

to by som aj ja rad vedel.
ja este k tomu includovaniu: staci mi nieco taketo?

subor include_file.php:


subor napr. index.php:


alebo sa to da lepsie - bezpecnejsie?

rozhodne sa snažte nepovoliž útoččníkovi čítanie vaších kódov. Mnoho programatorov používa config.php na uchovávanie informácií o prístupe na databázu. Pomocou .htaccess by preto mali mať povoleneé iba čítanie zo servera (teda nie z iného servera, rieši to tak aj phpBB).

>stenley: to mi je jasné ale nakoľko, máš config naozaj neprečítateľný a heslo je dlhé je prakticky nemožné dostať sa do databázy. Napr. na 18 miestne heslo by si potreboval neskutočnú výpočtovú techniku a pár rokov ...

tak ako mi niekto napadne DB tak isto mi moze napadnut aj FTP ucet, takze mam kontrolovat aj mnou napisany kod, alebo co ?

to zas nemusis... ale skor ti mozu napadnut db ako ftp... db mas pristupnu z viacerych stran... najma zo stranky...
tiez som si raz myslel, ze mam vsetky vstupy osetrene a z nicoho nic som mal v kazdom poli typu text a varchar v celej db skodlivy kod... odvtedy si davam vacsi pozor... hovori sa tomu zdrava paranoia tusim este mam niekde ulozenu tu proceduru, ktora to vsetko spiskala...

ale ked naprosto doverujes datam v db, tak to neries... spomenul som to len ako dalsiu moznost ochrany...

Tominator akym sposobom mam dat iba citanie zo servera? bo aj ja mam riesene prihlasenie pomocou .htaccess

stenley, a vysvetlíš nám, aký význam má ošetrovať vstupy z napadnutej DB ? pokiaľ ti do nej dakto získa prístup, tak je stránka v <> tak či tak jedine možno prípad, kedy by si mal stránku vo svojom pc a nejakým zvráteným spôsobom by sa im podarilo do db uložiť kód, ktorý by potom cez klienta pustili a dostali sa ti do pc, ale ....
neviem no, pripomína mi to dosť výroky roooberteka, ten keď mal windows, tak ho preinštaloval vždy, keď sa mu zdalo že by mohol byť potencionálne nakazený vírom

vyznam je taky, ze ak ti ju uz raz napadnu, tak nebudes dalej sirit virusy medzi navstevnikov tvojej stranky... co je dost podstatny "detail"...

ja som sa nieco pytal ak ste si tu spravili debatny kruzok tak si spravte novu temu dobre?!

//neviem o tom, ze by si tuto temu zalozil ty... vsetko, co tu bolo povedane, je k teme, tak sa tu laskavo nerozkrikuj... (stenley)

tiez sa mi to zda pritiahnute za usi...
to je ako keby, ze na dome zamkinam dvere, aby neprisiel zlodej, ale pred spanim sa vzdy pozrem do skrine, ci tam nahodou neni zlodej

ked ti zalezi len na bezpecnosti "tvojich" dat, ale na navstevnikov uz "kasles", tak sa nemame o com bavit... vidno, ze este neberies uplne vazne bezpecnost webovych aplikacii...

bs, dam ti trosku iny priklad:
skuseni horolezci - vedia sa pohybovat po skalach ako nik a predsa pouzivaju istenie, lebo co ak... ale to mas jedno, povedal som, co som chcel povedat, mozno sa nad tym nikto nepozastavi, a mozno to bude pre niekoho dovod na zamyslenie... ale v kazdom pripade, clovek sa uci na vlastnych ale aj cudzich chybach... a o tom to vsetko je...

ale potom hacking je blbost ved jako sa ti naburam na stranku ked je softwerovo a nedajboze este aj hardwerovo osetrena no tak to potom nemas sancu jak to je

admin spravi php sript kde ti nepovoli pristup k nicomu ako zasles poziadavku?ak sa vobec nejaka da zaslat.
to by si musel byt iny reverzak aby si to nasiel nie?co si myslis.iny reciprocaci chces povedat ze mitnick bol reciprocak jak svina?pochybujem
nic sa neda ked je funkcia nie na pristup tak mozes maximalne uhadnut heslo to je vsetko a ked nepoznas ramec paketa a vvsetko oklo toho ako je zanulajednotkovany tak to mozes zabalit nemas sancu

aa naco mi je odchyteny paket ked neviem jeho ramec

//pouzivaj edit (stenley)

tak zas musím sa stenleyho zastať, nakoľko má malú pravdu. Pre prípad, že niekto ti už 7 rok lúska tvoje heslo to DB a náhodou sa mu to podarí, a dostane sa dnu a urobití "šarapatu", je výhodné ošetriť si vstupy pred tým ako zmeníš heslo a spustíš zálohu. Prakticky to však až taký veľkýá zmysel nemá, lebo predsa nikto nebude čakať x rokov len nato aby si užil tie 2 hod slávy než si to všimneš a spustíš zálohu

Základ bezpečnosti je - všetko je nebezpečné okrem toho, čo som skontroloval podľa striktných pravidiel. Neverte ani vlastným dátam. Dokonca aj veci, ktoré máte v sessionoch treba kontrolovať. A zabezpečiť session proti ukradnutiu.
K tým databázam, naozaj nemôžte veriť tomu, že všetky údaje sú tam ok. Aj keď máte heslo dlhé 100 znakov.
Ešte jedna vec: stretol som sa s prípadom, že webová stránka nedobrovolne slúžila ako spambot. Bolo tam staré neaktualizované miniBB. Traffic im to spravilo tuším 20GB za mesiac.

euthanan, gratulujem, pridal si sa k 3/4 php-čkarov, o ktorých som hovoril na predchádzajúcej strane. Že nechápeš princípom, to neznamená, že sa ti nikto nenabúra do aplikácie a nebudeš servírovať svojím návštevníkom malware. A opakujem ti, zmeň rétoriku.


// Tominator, ale je možné, že sa k heslu dostane nejakým iným spôsobom. Napríklad bývalý zamestnanec, ktorého si vyhodil za neschopnosť. Alebo na hostingu ti vypadne PHP a odrazu všetky zdrojáky si môže ktokoľvek pozrieť a v nich budeš mať $password = "nbusr123"; Už som taký prípad zažil (aj keď to nebolo zrovna nbusr123). Kolegyňa chodila na jednu stránku (sociálna sieť) a zrazu pozerá, že prečo chce ten IE niečo sťahovať. Tak som išiel pozrieť a tam zdrojáky ako na dlani.



//tiez som uz zazil, ze na jednom nemenovanom slovenskom webhostingu "vypadlo" phpcko... bol to zaujimavy pohlad, ked sa zobrazil php kod namiesto ocakavanej grafickej casti stranky... (stenley)

no, asi mas pravdu, ale neviem preco mi to pripada blbe, osetrovat data vybrate z DB... a ako ich osetrujes vlastne?? vsetky co vyberes z DB prebehnes funkciou ?

Blackshadow aj mna to zaujima ako to osetrujete teda kontrolujete vlastne

pripada ti to blbe preto, lebo doteraz si to nerobil a nie si na to zvyknuty...

ako osetrovat data z db? dobra otazka, ale v podstate to zalezi od povahy dat, ktore mas ulozene v tabulkach... ked tam mas len cisty text, tak to osetrujes inak, ako ked tam mas html zdrojak... myslim vsak, ze vo vacsine pripadov staci pouzit (vlastne) funkcie pribuzne funkciam vyuzivanych pri osetrovani klasickych vstupov od uzivatela...

cize napr funkciu safety ale fakt ma toto este nenapadlo asi to zacnem pouzivat... aj ked si myslim, ze ked je uz utocnik v DB, tak to je uz dost pruuuuuser

no a keby si o ňom ešte vedel tak by bola aspoň sranda

ee, safety urcite nie, aspon nie v sucasnej podobe... lebo ked budes mat v db html entity, tak opatovnym pouzitim safety ti napr. & prevedie na &amp; (&lt; => &amp;lt;) Preto som aj pisal, ze treba pouzit modifikovane funkcie...

njn, to je fakt... takze dalsia funkcia...

najjednoduchsie je pravdepodobne (v pripade textu) previest vsetky prekonvertovane znaky (entity a pod) spat na obycajne znaky (pomocou html_entity_decode, htmlspecialchars_decode) a nasledne aplikovat napr. uz spominanu funkciu safety... cize nic zlozite...