Dotaz: Jak ošetřit provházení webu na který nevedou odkazy

[Já]

Ahoj. Poradil by někdo řešení, jak se děla to, že když user leze kam nemá, třeba prochází strukturu webu na kterou nevedou odkazy a zadá www.blabla.bla/bla/blabla.php? Jak udělám jednoduše nějakou akci, abych nemusel do každého souboru psát celou ochranu? Díky

---

---

Odpovědi

[Kit]

V souborech PHP jsou přece jen třídy. Ty ochranu nepotřebují, protože se při přístupu jenom přeloží a nic víc.

[Já]

Ty jo, to jsou ale rady...

[=^..^= AmigaPower®]

Tak to ale je. Mít ve veřejně dostupných adresářích pomocné PHP soubory, které něco vykonají, je fatální pitomost. Takže (1) mají obsahovat pouze definice/třídy (2) mají být v jiném adresáři, který vůbec není namapován na URL, nebo alespoň v adresáři, který lze celý znepřístupnit pomocí .htaccess. Nikdo ti nebrání dělat to složitě, ale chtěls vědět, jak se to dělá jednoduše...

[Já]

který vůbec není namapován na URL

Co tím je přesně myšleno?

[potato]

Webserver zpřístupňuje pouze některé adresáře v souborovém systému, což je snad jasné. Přiřazení mezi adresáři a URL je definováno pomocí direktiv DocumentRoot, Alias, ... Viz dokumentaci Apache:

http://httpd.apache.org/docs/2.4/urlmapping.html

Adresáře s pomocnými soubory, které nemají být samy o sobě veřejně přístupné, nemají důvod, aby se jim vůbec nějaké věřejné URL přiřazovalo. Stačí, aby je mohl číst (zapisovat do nich, ...) uživatel, pod kterým web server běží, ale mohou být mimo DocumentRoot (resp. další adresáře namapované na URL).

[Já]

Tak že když mám

DocumentRoot /var/www/prace1/www

tak dám do /var/www/prace1/www index.php a style.css a všechno ostatní dám o úroveň néž? Čili do adresář /var/www/prace1 ?

Chápu tvou myšlenku dobře? Díky

[potato]

Tak nějak, nicméně podle toho, co přesně je to všechno ostatní. Pokud nějaké soubory web server servíruje přímo (obrázky, jánevímco), tak samozřejmě potřebují URL.

[pavlix]

Mít ve veřejně dostupných adresářích pomocné PHP soubory, které něco vykonají, je fatální pitomost.

Tak čistě mezi námi, pokud se jedná o web a ne o haldu CGI skriptů, tak je pitomost mít v cestě vůbec nějaké PHP soubory. Do toho, zda je web napsaný v PHP nebo Abrakadabra uživatelům nic není a to, že to vidí na první pohled je pro ně zcela nadbytečná informace.

Že se PHP historicky používalo jako halda CGI skriptů a že se v tom začaly psát větší webové aplikace a ještě se obojí zkombinovalo je jen shoda blbých náhod.

[potato]

To je požadavek na udržitelnost, a jako každý požadavek něco stojí. Přitom u jednorázových polostatických webů je to nesmyslný požadavek. Nebudou se vyvíjet, natož přepisovat do jiné technologie. Kdyby náhodou ano, tak se budou dělat znovu, jinak a zachování URL nikoho nebude zajímat.

[pavlix]

Čteš mezi řádky něco, co tam nebylo.

[potato]

Možná. Prostě jestli URL mají koncovku .html, .php nebo .abrakadabra, je v řadě případů jedno. Jakákoli strktura URL (včetně hezkých, neutrálních) něco vypovídá o použitých prostředcích. Otázka pouze je, kdy to vadí.

[pavlix]

Uznávám, že jsem v tomhle trochu perfekcionista. Ale na druhou stranu to, jestli web na venek působí jako web nebo halda .php souborů o provozovateli a tvůrcích něco málo vypovídá.

[Šangala]

Pominuli správné rady výše, zůstávají mi dva artefakty.

1. Každý ne přímo dostupný soubor má na začátku (akce je exit() ):
   if((!isset($glb_import))||($glb_import != 78951245)) exit();
   , pokud není register_globals on, tak je to poslední stupeň ochrany.
2. Každý nedostupný adresář obsahuje index.html a index.php.

Jsou to jen dodatečné prvky, základem je ošetřit nastavením webserveru nebo|a pomocí například .htaccess kam se může.

[Kit]

Bod 1. se mi jeví jako zbytečný a nic neřešící. Jen přidává k aplikaci kód, který nevykonává nic užitečného a pouze zatěžuje programátora.

Bod 2. se obvykle také nemusí řešit, pokud je správně nastaven .htaccess v kořeni webu.

[Šangala]

V první řadě je si nastavit správně server (konfigurace && / || .htaccess && / || mod_rewrite).
Uvedené věci jsou historické artefakty (dnes snad už žádný webhosting bez podpory .htaccess není).

Bod 1. Nedovolí nic vykonat klientem (a nedovolí include-ovat), pokud neznáš vstupní kód. Zatížení programátora je to jen v tom, že si to musíš hodit do šablony (to je zadarmo) a někde na začátku před použitím definovat variablu s pin-em (to je jen několik případů, nebo dokonce jen jeden. Je to hromadně měnitelné i odstranitelné, tak bych to tak černě neviděl.

Bod 2. Nic to nestojí a někam to přeneseš a náhodou není povolen .htaccess, tak to klade aspoň překážku adresář vylistovat při obvyklém nastavení web serveru.

PS: Některé distribuce mají default konfiguraci bez možnosti overwrite a .htaccess se neuplatňuje, a když pro to můžu něco, byť obskurně udělat, proč ne…

[Kit]

Bod 1. Zatížení programátora jsem měl na mysli spíš po estetické stránce. Proč bych se měl při každém otevření skriptu editorem koukat na takovou hrůzu?

Pokud vím, .htaccess má jen Apache. Na lokálu používám jako server samotné PHP, u kterého .htaccess nefunguje - také u něj nehledám zabezpečení. Nginx má také jinou konfiguraci, o IIS nemluvě. Samozřejmě je vždy nutné si tyto informace zjistit předem.

Všechny skripty na webserveru (kromě index.php) mám udělány jako samostatné třídy. Žádný jiný kód v nich nemám. Jediným vstupním bodem do aplikace je index.php - zabezpečení webu tedy není roztříštěno po celé aplikaci.

Zajistit indexem má podle mne smysl adresář s obrázky, texty a multimédii, ale obvykle stačí zakázat (nepovolit) výpis adresáře. Databázi je dobré u Apache zajistit '.ht' na začátku jejího názvu - nedá se pak stáhnout.

[Šangala]

Proč bych se měl při každém otevření skriptu editorem koukat na takovou hrůzu?

Však se nedívej, nebo si ji přepiš hezčeji, nebo… ;)

Samozřejmě je vždy nutné si tyto informace zjistit předem.

Ne každý to udělá s různých důvodů, a je na tvůrci, jestli přidá nějaké další prvky.

Všechny skripty na webserveru (kromě index.php) mám udělány jako samostatné třídy. Žádný jiný kód v nich nemám.

Ty ne, ale dotaz zněl jinak.

Jediným vstupním bodem do aplikace je index.php - zabezpečení webu tedy není roztříštěno po celé aplikaci.

Vidíš, takže obstrukce se zapíše jen jednou. …já jich mám obvykle několik málo ks víc než jeden.

Databázi je dobré u Apache zajistit '.ht' na začátku jejího názvu - nedá se pak stáhnout.

Ha, to je ale velmi podobný princip obstrukce (čisté je: explicitně nedovolit daný soubor či adresář).

[Kit]

Databázi je dobré u Apache zajistit '.ht' na začátku jejího názvu - nedá se pak stáhnout.

Ha, to je ale velmi podobný princip obstrukce (čisté je: explicitně nedovolit daný soubor či adresář).

Ha, nachytal jsi mě. V tomhle případě někdy používám kšandy a/nebo pásek. Některé databáze (read-only) dávám do kořene a jejich název začíná '.ht'. Databáze R/W dávám do samostatného adresáře kvůli detailnímu nastavení práv. Přístup do tohoto adresáře pak v .htaccess samozřejmě nepovolím.

Vždycky se snažím tyto mechanismy dělat co nejjednodušší, abych si v nich neudělal díru do systému. Jednodušší systém se udržuje mnohem lépe.

Někdy ještě dělávám do dalšího adresáře honeypot, povolím ho v .htaccess a zakážu do něj přístup přes robots.txt. To se pak člověk dozví věcí

[Šangala]

On ten robots.txt zrovna zákaz ve smyslu zabezpečení zrovna není

[pavlix]

Vzhledem k tomu, že Kit psal toho přesný opak ;)...

[Šangala]

Inu bylo toho víc něž věty jednoduché… ;)

[Kit]

robots.txt používám na sledování neposlušných robotů, kteří lezou i tam, kam nemají.

[pavlix]

+1

Databázi je dobré u Apache zajistit '.ht' na začátku jejího názvu - nedá se pak stáhnout.

Tak ideální je ji dostat mimo dosah, že, protože .ht je hack specifický pro Apache.

[Kit]

Samozřejmě, ale třeba u freehostingu to obvykle jinak nejde.

[pavlix]

Tahle statistická úvaha [co obvykle u freehostingu platí] je lichá snad na všechny strany.

1) Placené hostingy a freehostingy se v tomto statisticky nijak neliší.

2) Pokud si hosting nevybírám, je mi nějaká statistika k prdu.

3) Pokud si hosting vybírám, tak mě nezajímá statistický podíl této vlastnosti na trhu, ale její absolutní dostupnost (v kombinaci s dalšími).

4) Celý trik s .ht je zajímavý pouze pro hostování nad Apachem bez .htaccess, popřípadě jiným webserverem, který .ht pro jistotu blokuje.

Je otázka, zda pak není vhodnější dostupnost onoho souboru testovat při instalaci (a konfiguraci) než spoléhat na nějaký statisticky relativně neúspěšný hack a nechat administrátora, ať v případě non-Apache/non-htaccess instalace soubor zajistí jinak.

[Kit]

Absolutní dostupnost u freehostingu mě vůbec nezajímá. Na toho admina se v takových případech klidně spolehnu.

[pavlix]

Nevím jestli jsem tu větu napsal příliš nesrozumitelně nebo je mi naopak nesrozumitelná tvá odpověď. Měl jsem namysli to, že pokud si hosting můžu vybrat, tak mě nezajímá, zda 90% hostingů na trhu má nebo nemá vlastnost X, ať už je to kterákoli. Tak jako tak ostatní body jsou pořád platné.