allow_url_fopen() je zakazany z jednoducheho duvodu, neskutecne mnozstvi lidi pouziva primo GET parametry pro include obsahove casti a neobtezuji se ani primitivni kontrolou zda-li je soubor lokalni. Nez to zacali admini zakazovat, tak to byl snad nejcastejsi vektor utoku na PHP aplikaci, hned po hadani FTP hesla a tesne pred ruznymi druhy SQL injection.
To ze to ma provest u sebe pouze nastavenim serveru utocnika. Ale ten muze provadeni php zakazat a soubor se posle tak jak je, nebo muze dynamicky generovat php kod ktery se vlozi. Nebo vlozi „jen“ javascript. Moznosti je spousty.
Programator ktery pusti vlozeni souboru bez kontroly je bud nactilety jelito bez zkusenosti nebo debil (mysleno je jako sproste slovo ale jako diagnoza)
Nejsem programátor v PHP, tak se omlouvám za laické dotazy.
Pokud napíšu include (http://include.com); tak je snad ta doména include.com v mé správě a útočníkovi je to prd platné (bavíme se o plném zabezpečení, nepředpokládejme změnu dat na síti). Pak ale útočník má jedinou možnost a to přepsat ten zdrojový kód na include (http://utok.com), ale proč by dělal zrovna toto, když už má napadený kód pod vlastní kontrolou? A napadat server include.com s tím, že tím zničí stránky „jinde“ mi také nepřijde moc smysluplné.
Programator ktery pusti vlozeni souboru bez kontroly je bud nactilety jelito bez zkusenosti nebo debil (mysleno je jako sproste slovo ale jako diagnoza)
S tím souhlasím, rád bych se však o aspektech tohoto útoku dozvěděl víc.
No vida, takže jde o problém socialistický :).
Korektní odezva je podle mě nechat každého ať se spálí, když přijde o data takovýmhle způsobem, přišel by o ně se zákazem url_fopen jen o malou chvíli později. Když útočník vytíží server, od toho tu je omezení CPU času pro účet (a mail klientovi po překročení kvóty). A když se útočník dostane na web jednoho klienta, tak je jednoznačně chyba hostingu když to ohrozí i ostatní.
includnes z serveru utocnika ciste plain-text soubor, obsahujici PHP kod. „Chytry“ server napadene strany provede plain-text soubor, protoze obsahuje PHP kod. Tradaaa, kod bezi na strane napadene, cimz muze delat cokoliv…
Kdysi davno toto slo i pres sikovny include uploadovaneho obrazku, pricemz kod byl uvnitr jako popiska (jsem sklerotik, takova ta popiska jmena/rozmerua/cehokoliv jineho). Obrazek musel byt bran jako zdroj text infa, a ne jako obrazek…
k tomuto sa pripaajam, robim vo firme kt. hosting poskytuje v podstate ako „bonus“ k pripojeniu.. a riesit kazdy den diela „radoby programatorov“ web stranok (syn/synovec/pribuzny/kamaraat a ini odbornici) vdaka povolenemu allow_url_fopen nezelam nikomu (includovanie zavirenych/malware odkazov na dennom poriadku..)
V tom případě je na místě abyste se zamysleli nad tím, jestli chcete provozovat na svoje náklady tuhle službu a ztrácet s ní čas i image.
Buďto jí dělejte pořádně, nebo vůbec, postoj kdy klientům slibuju „vychytaný hosting zdarma k připojení“, a klienti pak najdou „ojebaný socialistický hosting bez podpory“ mi přijde přinejmenším jako klamavá reklama. Ale v čechách tenhle přístup jede – i díky vám.
ja ne, ale firma si mysli ze je to nezbytny bussiness, bez ktereho se neumi obejit (mam stejne zkusenosti jako SK kolega).
ja bych to vypnul/outsourcoval nekomu kdo to umi, bohuzel management je jineho nazoru a s tim nikdo z nas nic neudela.
p.Kafka – mozna by to chtelo mene utoku, a vice praxe (tim myslim zkusit si nejdrive u nejakeho takovehoto providera pracovat – to vam da nahled i z druhe strany).
s tim ze webdyzajnera a programatora dela taky kazdy kdo ma otvor tam kde konci zada :-((((
Dobrý den, děkuji za vysvětlení – špatné služby z rozhodnutí managementu budou asi hodně častým důvodem toho, co řeší tento článek. Tady ale nevidím jiné řešení, než „provinilé“ hostingy veřejně pranýřovat, s tím, že s postupným nárustem informovanosti si změny vynutí ti jediní kdo mají moc nad managementem – zákazníci.
Věřím, že kdybych byl adminem, byl by můj pohled jiný, já jsem ale na druhé straně barikády, a situace, kdy strávím týden pologramotné komunikace s několika hostingy, abych zjistil že stěží na jednom ze tří budu moci klientovi spustit Drupal bez omezení funkčnosti či ohrožení bezpečnosti, mě štve asi stejně jako vás moje „útoky“.
Držím vám palce abyste váš názor prosadil, jak vypnutí tak outsourcing do schopných rukou imho povede k menšímu naštvání uživatelů…
+1, hřebík na hlavičku!
PHP patláci který někde pokradou opensource kód a pak čekaj že za dvěstě korun měsíčně se z nich pos… přetrhnu a budu 24/7 na telefonu kvůli jejich studentskejm kšeftíkům.
Buzz off, script kiddies!
Ve svém byznysu už mám zájem jenom o firemní zákazníky, uhrovitá pakáž mi už sebrala dost času a nervů a platí nula nic.
Kanec a frája, mariňák, bedna a tvrdej chlapák před lidmi a za zavřenými dveřmi se bude producírovat v taftové róbě, usrkávat baileys a švihat sluhu bičíkem, to známe. Kdyby mi u vás nešel drupal tak bych chvíli zůstal jen aby ste se posral a pak přešel na hosting. Ale ne "hosting" ale hosting, něco, kde je podpora 24/7 jenom střícnej krok, protože všechno funguje.
…áááá Tonda je jeden z těch „chytrejch“ rádobyadministrátorů co je vostrej jak břitva a s těma sračkama uživatelema (co ho mimochodem živěj) je natotata hotovej......nicméně se řídí heslem zamáznout,zamáznout a zamáznout. Když dojde na nějakou diskuzi pak jeho odpověď je „NE nejde to , jinak nezaručím bezpečnost“ (ha ha ha…jako by někdy za nějakou ručil).
No jen více takovejch šulínů........ časem se sami vyautujou…
Skoda ze jste jen teoretik. Vas pristup je typicky cesky. Budu vsechno kritizovat a sam to neumim lip. Ukazte se. Ukazte jak se to ma delat.
Zazil jste nekdy jak neprijemne to je to debilni allow_url_fopen nebo allow_url_include povolit na rekneme 100vkach domen? Reknu vam, to je fakt sila. Najednou zjistite ze pulka joomla webu je shozena. Protoze nejaky debil neco neosetril. A neni to jenom joomla. To je jeden web vedle druheho. A kdyz uz to napsal dobre atak je chyba v php.
Jinak samozrejme je jina pravda nez se tu uvadi. Dat to allow_url_fopem jako volitelne a zapni si to na vlastni riziko.
PHP samo o sobe je jazyk ktery bude vzdy s bezpecnosti na stiru. Uz tim jak funguje a jak se v nem programuje. Nic lepsiho na masovy vyvoj webu ted bohuzel neni.
1) Asi vas prekvapi ze vetsina malware napadeni webhostingu nepochazi pres prasacky napsane scripty, ale pres prozrazene hoslo k FTP napr. z TotalCommander 7.0× (ktery hostingy tak radi uvadeji jako priklad FTP klienta), ktery uklada plaintext hesla. Pro boty je infikovani stranek stale jeste celkem slozite a procentualni uspesnost (produktivita) nizka. Utoky hackeru jsou take malo produktivni a zabiraji jen nejake to promile z celkoveho objemu napadnutych webu.
2) mame tu direktivu allow_url_include ktera brani includovani vzdalenych souboru (coz rozumne napsana aplikace nevyzaduje).
3) Prosil bych nejake fakticke dolozeni o penalizaci IP v Google kvuli malware.
Davide, ja absolutne nechapu, proc ty a autor clanku to nazyvate socialisticke omezeni. Naopak, je to kapitalisticke omezeni. Vzdy mas moznost utect k jinemu hostingu.
Myslim, ze omezeni allow_url_fopen a zaroven povoleni curl na serveru je naprosto bezne. Podle me autor clanku nema pravdu v tom, ze je to uplne to same. Pro vytvoreni nejake chyby typu include($url) v cURL toho musim udelat mnohem vice a proto je velmi nepravdepodobne, ze bych neco takoveho vytvoril.
Navic, ani allow_url_include neni resenim bezpecnosti. Staci pouzit neco jako php://input a jsme zase na tom samem. Jedinym resenim proti include vulnerabilities je Suhosin.
Dale si myslim, ze hosting, ktery to nema takto resene (vypnute include + suhosin) je naopak spatny. Zkuste mit na serveru 200 domen a mluvit o tom, ze je kazdeho zodpovednost starat se o bezpecnost. To nejde. Teoreticky ano, prakticky ne.
Posledni troskou je zminka o exec() na serveru jako moznem reseni zakazu include. Prosim? Hosting s povolenym exec()? Dle meho ruce pryc! Pokud neco takoveho chci, mel bych mit VPS. Jiste, existuji zahranicni reseni, ruzne giganty typu hostmonster. Ale mluvime tam o stovkach tisic domen, ne o stovkach (jednotek) jako v CR. Vyvijet takove reseni je mimo rozpocet 99 % hostingu v CR.
Se vsim vsudy, ja osobne bych naopak doporucil vyhledat hosting s allow_url_fopen Off (cURL je proste dnes standard), suhosin, exec() disabled (a mnoho dalsich funkci, cca 20ti). Nejlepe pak i s FastCGI. Mam relativni jistotu me bezpecnosti. V opacnem pripade si zahravam se svymi daty. Pokud potrebuju vic, mel bych mit VPS.
A nebo take z druhe strany „Ano, ochranime Vas pred Vasi blbosti at chcete nebo ne, protoze diky Vasi blbosti to pak budeme muset spravovat. Ze zamalawatovaneho FTP budete vinit nas a tezko se z toho budeme vymlouvat, jelikoz nevim proc, ale v Cesku je nejak zazity nazor, ze zakaznik ma vzdycky pravdu.“
Teda nevim, nevim, ale zustavam nekde uprastred, protoze jsem jak admin, tak clovek co lidem poskytuje souvisejici technickou podporu. Dilema, vidte?
Nechte nést důsledky zákazníka – vytěžuje server? Ukažte FUP, pošlete varování o odpojení/přechodu na vyšší tarif, buď si díru opraví, nebo si připlatí. Ohrožuje bezpečnost svých dat? Jeho chyba, vy mu můžete maximálně nabídnout placenou konzultaci. Ohrožuje útočník vaše ostatní zákazníky? Vaše chyba, nemáte co být adminem.
Pak je tu otázka jestli je dobrou strategií stát o každého zákazníka, i o amatéra který nadělá víc nákladů, než přínosů, a přitom vám zkazí náladu na dva dny dopředu.
Hostingů se strategií nízká kvalita za nízkou cenu je u nás přehršle, možná by pár zákazníků ocenilo i kvalitní hosting podle zahraničních vzorů, kde nic není problémem, a bylo by ochotných si za to připlatit – a bonusem pro vás by bylo to, že byste nemusel ztrácet nervy v opravování skriptů script kiddies.
Ale to už zde padlo: http://www.root.cz/…zory/329082/