|
Ja koliko kapiram, taj mod ima jedini zadatak da krpi rupe u drugim aplikacijama. To jest, ako aplikacija nema rupa, nema potrebe za tako nečim što na ovaj ili na onaj način može da uskrati neku funkcionalnost (ovo sad vidimo i na primeru)...
|
Egzaktli :)
Bilo je svega prosle nedelje, nekoliko exploatisanja contact formulara za slanje SPAM-a na par "ru*****vih" sajtova. Bolje spreciti nego leciti :) Sada samo jos malo fine tuning pa da ne pravi probleme sa ovakvim stvarima. |
Citat:
|
Pa da, ali se to sve konfigurise, postoji .conf u koje iskljucujes i ukljucujes sta se filtrira. Ja se razumem u te serverske stvari onoliko koliko mi je potrebno u odredjenom trenutku, i iskreno do skoro nisam imao pojma o mod_security dok ga nismo stavili na zahtev administratora. Kada naidjem na nesto, onda saznam sto vise tome i tako gradim svoje znaje o administraciji servera. Sada mislim da mod_security uopste nije glupa stvar narocito za shared hosting gde ne mozes da znas ko sta stavlja na sajt. Jedino sto treba je operzna konfiguracija - znaci nikako po defaultu jer neke sasvim obicne i bezazlene stvari nece raditi.
Zato cu najverovatnij skolniti ovo: # Make sure that URL encoding is valid SecFilterCheckURLEncoding On ali to onda opet otvara vrata nekim drugim stvarima, evo mozda Ivan, nas "security expert" moze o encoding exploitima. Postoji recimo i ovo: # Only allow bytes from this range #SecFilterForceByteRange 1 255 SecFilterForceByteRange 1 500 |
Nisam bas nesto preterano testirao ovaj mod_security tj skorije sam skinuo source i poceo da ga proucavam ali sto se tice te stavke:
# Make sure that URL encoding is valid SecFilterCheckURLEncoding On ... mislim da se moze slobodno skloniti ukoliko bluesman programira ;) Tj, svi znamo da se URL-ovi sastoje od alfanumerickih simbola (A-Z, a-z, 0-9 ), rezervisanih simbola (; / ? : @ & = + $ , < > # % " ) i specijalnih znakova (- _ . ! ~ * ' ( ) {} | \^ [ ] ` ). Problem dolazi kada npr: Pozivamo neku naredbu iz nase scripte na nivou sistema, a pre toga nismo encodovali input, mozemo jednostavnim | da ubacimo naredbu po zelji. Ili obrnuto imamo funkciju koja includuje fajlove ali nam je zabranjena . tj server je automatski odklanja onda mozemo encodovanjem da je provucemo i includujemo neki fajl koji ne bi smeli. Ovo su primeri iz glave ... Mislim da se ne treba bojati ove vrste napada sada jer su ispravljene greske u web serverima koje su uveliko omogucavale ovaj tip napada jedino moze doci do previda programera koji ce da omoguci ovako nesto ali svako sa i malo iskustva nece to dozvoliti sebi ... |
a mod_security je tu bas zbog tih koji nemaju ni malo iskustva, a prave web aplikacije (kako god to zvucalo, ima i toga..)
|
ukoliko se koristi ascii ili UTF8 za bazu onda (AFAIK) nema opasnosti od SQL injectiona sa chudnim enkodovanjima... mysql_real_escape_string() radi posao fino... nek me Ivan ispravi ako zna nesto vise od mene o ovome, mada ovo sam prilicno pazljivo proucio...
a mogao bi da se naprosto uradi javascript encode() nad podacima koje ajax salje, pa bi to resilo problem, right? |
Nema veze koji encoding koristis za bazu, vazno je da pre upisa uradis neki filtering podatka sto i radis sa mysql_real_escape_string(). Tj ovo uopste nema veze sa bazom to je druga prica (SQL injection).
Vec se govori o filtriranju parametara koji se dobijaju a usput su i encodovani ... Neki web serveri filtriraju neke zabranjene znakove ali te iste ne filtriraju kada su encodovani isto i vazi i za aplikacije ... o ovome sam ja pricao (encoding & exploiting). |
Citat:
uzgred za neke encodinge baza postoji mogucnost da se zezne i mysql_real_escape_string, mada je ovo prilicna egzotika: http://ilia.ws/archives/103-mysql_re...tatements.html |
Sam mod_security i ne treba da sluzi kao quick fix za bagovit kod (posebno ne da sprecava sql injection napade), vec pre svega kao zastita od nekih drugih napada koji nisu specificni samo za jedan jezik, vec za sam HTTP standard i Apache okruzenje.
|
| Vreme je GMT +2. Trenutno vreme je 10:34. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.