Ochrana webových aplikací pomocí .htaccess

Narazil jsem na tento článek, popisující univerzální .htaccess údajně chránící webové aplikace před velkou částí pokusů o napadení/hacknutí: RewriteEngine On Options +FollowSymLinks ServerSignature Off RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) RewriteCond %{HTTP_REFERER} ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* RewriteCond %{REQUEST_URI} ^/(,|;|<|>|/{2,999}).* RewriteCond %{HTTP_USER_AGENT} ^$ RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* RewriteCond %{HTTP_USER_AGENT} ^.*(libwww|curl|wget|python|nikto|scan).* RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* RewriteCond %{HTTP_COOKIE} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* RewriteCond %{QUERY_STRING} ^.*(;|'|").*(union|select|insert|declare|drop|update|md5|benchmark).* RewriteCond %{QUERY_STRING} ^.*(localhost|loopback|127.0.0.1).* RewriteCond %{QUERY_STRING} ^.*..* # prevents shell injection RewriteCond %{QUERY_STRING} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* RewriteRule ^(.*)$ index.php # better yet: send them to a fail-safe page, like error.php Co na to říkají ti z vás, kdo se ve webové bezpečnosti vyznají lépe než já? Má takový .htaccess smysl? Dokážu vyčíst, před čím ta pravidla chrání, ale už neposoudím, nakolik jsou ty typy útoků časté a závažné.

Napsal Retal;55530

Narazil jsem na tento článek, popisující univerzální .htaccess údajně chránící webové aplikace před velkou částí pokusů o napadení/hacknutí...

Co na to říkají ti z vás, kdo se ve webové bezpečnosti vyznají lépe než já? Má takový .htaccess smysl? Dokážu vyčíst, před čím ta pravidla chrání, ale už neposoudím, nakolik jsou ty typy útoků časté a závažné.

Dokážu si představit scénáře, kdy nasazením výšeuvedených pravidel rozbiješ do té doby funkční aplikaci, která je napsaná bezpečně. (Namátkou: některé firewally blokují referer, menšítko může v parametru regulérní znak, dokážu si představit, že prohlížeš bude mít v hlavičce UserAgent slovo Python nebo Java, ...). Dokážu si představit i aplikaci, která je napsaná tak špatně, že ji výšeuvedená pravidla nezachrání. (Např: Vůbec neošetřují data posílaná jako POST). Aplikaci, která je napsaná špatně a musím ji používat, bych radši zavřel do nějakého ořezaného sandboxu. Just-my-2-cents. --VK

Sem spíš začátečník, ale když si to tak prohlížim tak by tim neměl projít XSS, coz je hodně. Dnes je proti tomu velká část serverů nechráněná a přitom to může být velký problém!Takže můj skromný neprofesionální názor: rozhodně použít, ale nezapomenout i na ochrany proti dalším typům útoků (php injection)...

Mno... Jak napsal Věroš, tohle spíš způsobí, že se začnou ozývat lidi a hlásit "nepochopitelnou" nefunkčnost aplikace a "záhadné" poruchy. Pokud to máš nastavené na nějakém hostingu, kde je CRON řešen přes wget (Ignum např.), tak ti "záhadně" přestane fungovat, některé dotazy přestanou "záhadně" vracet informace a začnou blbnout, atakdále... Minimálně ochrana refererů je pochybná, stejně jako ochrana useragents (útočník si prostě vezme UA stejný jako má Explorer...) V praxi to dělá to, že cokoli "podezřelého" přehodí na index.php. No... a pokud máš aplikaci postavenou na nějakém MVC frameworku, tak ti přes index.php jde stejně každý požadavek... :) IMHO řádnou programátorskou práci s ošetřením vstupů tímhle nenahradíš :)

Má to dvě části: - První část má zabránit procházení webu nežádoucím robotům. - Cílem druhé části je zabránit různým injekcím. První část je šíleně průstřelná, ale jestli někomu vytěžuje server pár blbečků s wgetem, může to zabrat. Většina lidí u wgetu neumí obejít ani robots.txt, natož přenastavit si user agent. Ale rozhodně bych ta pravidla hodně pročesal. Jak říká Věroš, některá ta slova se v signatuře žádoucího klienta můžou objevit taky. Druhá část je úplně mimo. Má to díry i v tom, co domněle ošetřuje: Zabrání vložení ";insert into ...", ale nezabrání už vložení ";delete from ..." nebo " or 1;". Podle mě jakékoli injekce (ať už XSS nebo SQL injection, princip je stejný) je nejlépší ošetřovat až na místě. XSS až při výpisu HTML, SQL při sestavování SQL příkazů, shell při sestavování shellových příkazů, PHP při sestavování názvu souboru pro includování a tak dál. Můj neprofesionální názor: Rozhodně druhou část nepoužít, je to blbost. Ani jako nouzovka pokud zdědíte špatně zabezpečenou aplikaci. V takovém případě je jistější zapnout magic_quotes_gpc, vypnout allow_url_fopen, přes auto_prepend_file předpojit soubor, který všechen vstup zpracuje funkcí htmlspecialchars a pomalu se pustit do opravování a uklidňování uživatelů, že o tom \"podivném chování webu\" víte a usilovně na tom děláte...

To uz je lepsi zapnout mod_security v apache. Ten mi mimochodem chytal i velke mnozstvi komentaroveho spamu...Bohuzel vsechny tyhle ochrany jsou proste by design spatne. Ale nekdy se neda delat nic jineho.Vyse uvedene radky treba neresi ruzne email injection utoky, ktere jsou u spatne napsanych aplikaci velmi bezne. To umi poresit treba mod_security, u PHP uplne nejlepe Suhosin.

Tak se na to dívám a nikdy jsem neviděl flag OR (je v ) co vlastně znamená

Python v UA obsahuje URL Fetcher od Googlu, PycURL zase cosi od Seznamu. Javu posílá pouze JVM. Zbytek blacklistu se zdá být bezpečný.Když už to ověřuje cookie a referer, tak by to mohlo hlídat i REMOTE_HOST, protože ta se dá taky podvrhnout...Může být sranda, když někdo omylem něco změní a ono se to zacyklí až při návštěvě bota...