Nejste přihlášeni
Stránky 1
V poněkud horké diskusi na forum.zive.cz kolem chybových hlášek mi jeden uživatel sdělil, že se mu podařilo nahlédnout do adresáře.
Potřeboval bych tedy poradit, jak tomu napříště předejít, zabránit. Nevím totiž, jestli je chyba v mém .htaccess souboru, nebo (a to doufám ne) u endory.
Bude to chtít změnit obsah tohoto souboru. Netuším však, co do toho souboru přidat - co změnit. Tedy pokud je to vůbec možné.
Offline
Do ktorého adresára? A akým spôsobom doň nahliadol? Môže byť veľa druhov, napr máte jednu premennú v htaccess zapnutú ktorá zobrazí obsah adresára, alebo používate CMS ktorý obsahuje bezpečnostnú dieru cez ktorú sa užívateľ dostal do vašeho adresára. Môžete teda to nahliadnutie bližšie špecifikovať?
Offline
Asi moc neřešíte SQL injection co? Přes URL adresu se to da pěkně shodit. Hlavně ty nazvy php souboru jsou fakt cool.
to znamená, že nemáte ošetrené parametre v URL adrese a dokázal sa cez tento parameter dostať tam, kde to Vy nechcete.
Inak z takých ľudí si nelámte hlavu, sú to ľudia, ktorým narástlo EGO z ich práce. No, ale na začiatky, kedy začínali to už spomínať radšej nechcú a majú pre seba len 2 prirovnania - viete toho menej -> ste pre nich blb, viete toho viac -> radšej nenapíšu a pôjdu tam, kde sa môžu predviesť .
Upravil Lkopo (2014-01-20 18:06:12)
Portfólio
E-mail: eduard(at)karpiel.sk
Offline
Do ktorého adresára? A akým spôsobom doň nahliadol? Môže byť veľa druhov, napr máte jednu premennú v htaccess zapnutú ktorá zobrazí obsah adresára, alebo používate CMS ktorý obsahuje bezpečnostnú dieru cez ktorú sa užívateľ dostal do vašeho adresára. Môžete teda to nahliadnutie bližšie špecifikovať?
Podle jmenovaných souborl nahlédnul do adresářů Extra a Ovladace.
Což je docela zvláštní, protože v. htaccess v výchozím adresáři mám
<Files ./Extra>
Order Allow,Deny
Deny from All
</Files>
Chtěl jsem, aby mi soukromou zprávou napsal, jak se k těm souborům dostal.
Ale doteď to neudělal.
to znamená, že nemáte ošetrené parametre v URL adrese a dokázal sa cez tento parameter dostať tam, kde to Vy nechcete.
Inak z takých ľudí si nelámte hlavu, sú to ľudia, ktorým narástlo EGO z ich práce. No, ale na začiatky, kedy začínali to už spomínať radšej nechcú a majú pre seba len 2 prirovnania - viete toho menej -> ste pre nich blb, viete toho viac -> radšej nenapíšu a pôjdu tam, kde sa môžu predviesť .
Pro práci s databází používám DIBI - a kromě nehody z roku 2012, která způsobila, že jsem musel databázi znovu vytvořit a nahrát obsah, ta prezentace zatím všem útokům odolala. A že asi nejvážnější útok byl asi ten, který se odehrál před nějakou dobou - kdy někdo zkusil v adrese zřetězit parametry.
Offline
Také je možné, že si stáhnul z Uložto.cz kopii Kasandry, kterou jsem tam hodil před nějakým časem. Protože se v jednom téma rozhořela diskuse o používání češtiny (a jiných jazyků než angličtiny) při programování.
Offline
To je vysoko možné.
Inak, zrejme hovoril o SQL injection v týchto súborov, čo ste uploadovali. Napr. tu ->
$RusenySoubor = $_POST['RusenySoubor'];
$Dotaz = "DELETE FROM Sprava_SeznamNahranychSouboru WHERE NazevSouboru = '$RusenySoubor'";
Alebo tu:
$ZnackaSekce = $_POST['ZnackaSekce'];
$Prikazy = array( "DELETE FROM Sekce_DobaZobrazeni WHERE Znacka='$ZnackaSekce'",
"DELETE FROM Sekce_Obsah WHERE Znacka='$ZnackaSekce'",
"DELETE FROM Sekce_ZakladniInfo WHERE Znacka='$ZnackaSekce'",
"DELETE FROM Sekce_MoznostiZmen WHERE Znacka='$ZnackaSekce'");
Upravil Lkopo (2014-01-21 14:00:52)
Portfólio
E-mail: eduard(at)karpiel.sk
Offline
Jenže k skriptu k mazání souborů by nemělo být možné se dostat. Navíc obsah POSTu mazaného souboru je z formulářového pole.
Ale mohl bych udělat opatření, že bude ověřeno, že obsah POSTu je povolený - například tím, že nejprve vytáhnu z DB seznam povolených hodnot a POST porovnám s hodnotami z DB. To je myslím ochrana, která by se měla blbě prolamovat. Jenže nejde použít u ukládání obsahu stránek.
Jenže nejprve musím upravit kódovací engine Kasandry - a Kasandru upravit na tento nový engine. Takže ještě chvíli chráněná nebude.
Offline
To že by se ke skriptu nemělo být možné dostat je úplně irelevantní - ono se nejedná jen o toto místo, takto postižen je celý kód.
To že by POST mělo být políčko z formuláře je také názor naprosto mimo. POST jsou prostě data od uživatele, nemusí se vůbec jednat o data z nějakého formuláře, uživatel vám tam může (stejně jako v GET) poslat úplně cokoli. Proto datům přicházejícím od uživatele na server NIKDY A V ŽÁDNÉM PŘÍPADĚ NEDŮVĚŘUJEME.
V daných případech by mělo postačit dané hodnoty před použitím v dotazu escapovat. To je prostě základ. Co to je escapování, jako ho správně provést a další informace viz Google. Jeden z tisíců článků na dané téma lze najít např. na blogu Jakuba Vrány - http://php.vrana.cz/obrana-proti-sql-injection.php.
Offline
Na integer stačí
(int) $_GET['page']
a na zvyšok
mysqli_real_escape_string();
Inak tá stránka už je dosť zastaralá, mysql_ je deprecated a plánuje sa zrušiť celkovo, preto odporúčam MySQLi alebo PDO. Tiež dôvod, prečo nepoužívať addslashes od mysqli_real_escape_string je vysvetlený pekne tu: http://stackoverflow.com/questions/3473 … addslashes
/e Tiež je v tom odkaze nižšie v komentároch odkaz na prezentáciu, kde sa tvrdí, že escapovanie nestačí. Dobré na vzhliadnutie.
Upravil Lkopo (2014-01-21 18:18:37)
Portfólio
E-mail: eduard(at)karpiel.sk
Offline
DIBI samo provádí escapování.
Offline
jistě, ale i dibi se musí použít správně, ve chvíli kdy do něj nacpete dotaz, jako je ten výše, tak vám nepomůže.
Lkopo: jistě, že je zastaralý, vždyť je z roku 2005 a samozřejmě je třeba přečíst si komentáře a používat hlavu.
Upravil jp007 (2014-01-21 19:55:34)
Offline
Stránky 1