Stavte na víťaza

Užívateľ

Ako sa bránite proti PHP injection vo svojich skriptoch? Aké metódy sú podľa vás účinné? Taktiež, ako sa bránite proti otváraniu nechcených PHP súborov ako sú súbory s prihlásením sa na DB a heslami? Diskusia...

Viac o PHP injection tu.

K PHP injection, include() iba cez premenné, súbory zašívam do priečinka a nepridávam do adresy príponu. Čo sa týka otvárania súborov používam metódu známu z phpBB:

kód:

V hlavnom súbore:
define ('niečo', true);

V includovaných súboroch:
if (!defined('niečo')) { exit; }

Užívateľ

hej to z phpBB robim aj ja:D potom este pouzivam jednu fciu a to:

kód:

function protect($var)
{
foreach ($var as $k => $v)
{
$protected[$k] = addslashes($var[$k]);
}
return $protected;
}

co si vlastne ked mam nejake get a post premenne tak si ich takto osetrim a viem ze na mna ziadne sql injection neplatia.

potom este definujem premennu s priponov php

kód:

$phpEx = substr(strstr(__FILE__, '.'), 1);

a v tom subore includujem config kde mam udaje s databazov. a a hned po scripte fciou unset() zmazem premennu heslo a table prefix.
a nazaver ked potrebujem nieco nechat len pre adminov nejake filezz tak osetrujem hned na zaciatku tak ze vyberiem session z databazi a zistim aky ma rank. ak zly tak ho presmeruje na index.
a aby som nezabudol za kazdym sql query davam

kód:

or die(sprintf("Mysql query failed on file %s and line %d"), __FILE__, __LINE__);

Skúsený užívateľ

Zobrazovanie chybových hlášok (podľa mňa) nie je najlepší nápad. Môžeš tým potencionálnemu útočníkovi prezradiť príliš veľa informácií.

Užívateľ

chrono napísal:

Zobrazovanie chybových hlášok (podľa mňa) nie je najlepší nápad. Môžeš tým potencionálnemu útočníkovi prezradiť príliš veľa informácií.

no z toho co som dal. by si moc toho nevyrozumel. kedze si zober. nevies nazov tabulky ani databazi nic. poznas len subor. a to poznas aj na phpBB , drupal, phpfusion a mnoho dalsich, to by ma moc neiritovalo

Zablokovaný užívateľ

vl4kn0 napísal:

hej to z phpBB robim aj ja:D potom este pouzivam jednu fciu a to:

kód:

function protect($var)
{
foreach ($var as $k => $v)
{
$protected[$k] = addslashes($var[$k]);
}
return $protected;
}

co si vlastne ked mam nejake get a post premenne tak si ich takto osetrim a viem ze na mna ziadne sql injection neplatia.

...

by si sa dosť okakal, ale musím ťa sklamať.. addslashes je slabá ochrana.. niekde som o tom čítal článok, keby ho nájdem tak ti ho pošlem.. išlo o to, že addslashes pracuje istým princípom, a dá sa ho oklamať tak, aby niektoré znaky zle "chápal"

Užívateľ

ako myslim si ze na nejaky sql injection staci
ale to neznamena ze adslashes nemozem zamenit za str_replace alebo ereg_replace
kde budem odchytavat iba text a cislice. ak budem odytavat iba stringy a cilice tak uz to nemoze nikto o....t. kazdemu podla jeho chuti

ale kazdopadne. ziadna obrana nieje dokonala a vzdy sa najde nejaky spekulant ktory to dokaze "obist". napr. koho z vas napadlo ochranovat proti sql injection aj nazvy uploadovanych suborov? lebo ak niekto da vazov suboru ako select * from name_of_table where id = 0 -- ??lebo aj to je druh injections

Užívateľ

Ešte ma napadla zaujímavá ochrana, okrem základného define z phpBB, čo som už vyššie písal, tak aj ochrana cez $_SERVER:

kód:

if (!defined('NIEČO') OR (
$_SERVER['DOCUMENT_ROOT'] != '/www/***/public_html' && $_SERVER['DOCUMENT_ROOT'] != 'E:/***'))
{ exit; }

Sú tam dve rôzne "porovnávačky" s $_SERVER['DOCUMENT_ROOT'] pretože skript robím aj u seba na localhoste, ale aby to aj platilo na už skutočnom serveri...

Zablokovaný užívateľ

neriešim použijes .hdacess na to aby si útočník nemohol prezerať súbor s pripojovacími nastaveniami

2. rada použite aj obmedzenia pre robotov aby vam admin stranky neindexovali

Čestný člen

citácia:

2. rada použite aj obmedzenia pre robotov aby vam admin stranky neindexovali

prave toto by som nerobil pretoze ten subor sa da velmi lahko vygooglovat a prezret, takze vies kde sa tie admin stranky nachadzaju. naopak ked o nich nemas ziadnu zmienku google ti ich neindexuje, ved ako by aj mohol ked sa k nim nevie prihlasit.

Užívateľ

citácia:

a nazaver ked potrebujem nieco nechat len pre adminov nejake filezz tak osetrujem hned na zaciatku tak ze vyberiem session z databazi a zistim aky ma rank. ak zly tak ho presmeruje na index.

prvykrat citujem sam seba

ale k veci. nemyslim ze google a ani iny bota je az taky mocny hackersky nastroj ze to dokaze obist cize to bude neindexovatelne

Zablokovaný užívateľ

suchy napísal:

citácia:

2. rada použite aj obmedzenia pre robotov aby vam admin stranky neindexovali

prave toto by som nerobil pretoze ten subor sa da velmi lahko vygooglovat a prezret, takze vies kde sa tie admin stranky nachadzaju. naopak ked o nich nemas ziadnu zmienku google ti ich neindexuje, ved ako by aj mohol ked sa k nim nevie prihlasit.

spravne suchy beriem späť

Užívateľ

Hm, ja mam stranky robene tiez sposobom inckude, ale mam to takto:

kód:

switch ($page) {
case 1:
include_once "zoznam.php";
break;
case 2:
include_once "reklama.php";
break;
.
.
.
default:
include_once "uvod.php";
break;

Cize nemam tam priamo GET, ale po includovani URL vyzera nejako takto ... /index.php?page=2. Je aj tento sposob ohrozeny?

Na niektorych strankach, kde mam uploadnute clanky, vyzera URL takto: index.php?ID=2 /kde ID je vlastne ID clanku/

Viete mi poradit jednoduchy sposob, ako toto ochranit od SQL a kadejakych inych injection?

Vdaka, rad sa poucim...

Čestný člen

na tvoj konkretny skript je sql injection nepouzitelna. co sa tyka ochrany pred nim, mame tu trebars direktivu magic_quotes_gpc, alebo funkcie mysql_real_escape_string() pripadne addslashes(). zakladom ochrany je filtrovat uzivatelsky vstup, v pripade xss aj vystup. napriklad odfiltrovat nechcene tagy, ci atributy tagov, pripadne odfiltrovat vsetko okrem plaintextu. dalej je dobre mat osetrene chybove hlasenia, bo tie dokazu tiez dost napovedat a takto by sme mohli pokracovat. ohladom bezpecnosti webaplikacii je to na dlhsiu debatu, vysla o tom aj celkom zaujimava kniha Zranitelny kod.

Užívateľ

a co napr. php injection? ked niekto dosadi namiesto adresy index.php?page=2 nejaky svoj script napr. index.php?page=http://www.necomoje.ic.cz/hack.php ako je uvedene napr. tu http://www.chill.sk/clanky/php-injection/?

Alebo druhy pripad, ked mam uz spominane index.php?ID=2 /kde ID je vlastne ID clanku/ ? Jedna vec su vstupne data, ktore sa osetrit daju, ale druha vec je ak mi namiesto adresy dosadia kadejake svoje scripty, ktore potom includuje namiesto mojich a zobrazi sa obsah mojich scriptov /napr. pomocou show source.../

Užívateľ

ak dosadi namiesto page=2 page=http://www.necomoje.ic.cz/hack.php a ak je script cez switch tak potom hodi na uvod.php

a v tom id ak je prenasane napr: id clanku ktore ma byt otvorene tak by najjednoduchsie riesene by bolo ze preskumas to ci to je ciselna hodnota a nech tam niesu takmer ziadne znaky a dalsie a az potom to das prejst cez databazu + aj tam to dajak osetri

ale tam uz naj niekto iny hodi navod

Stavte na víťaza

Správca siete

Kvalitné potreby pre psov

Hodinky - zásielkový predaj

Štýlové hodinky za super ceny

Ochrana PHP skriptov a vy