Ne prolaze asinhroni zahtevi?

[jablan]

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)...

[bluesman]

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.

[Ilija Studen]

Originalno napisao bluesman

Da, za one koji hostuju na ovom serveru, čisto da napomenem da neće prolaziti zahtevi tipa : nekastrana.php?nesto=../../nesto drugo ... dakle uopste nece dozvoliti zahtev koji ima bilo koji / u sebi.

Treba da se provere scriptovi, narocito oni koji koriste neke CMS-ove koji imaju ovako glupave sisteme.

Doduse postojale su i neke nebuloze koje smo sklonili, nije hteo da propusti bilo sta sto ima "ls", pa recimo ne moze da se uploaduje Excel file jer ima ekstenziju .xls Treba biti jako oprezan sa ovim mod_security, pa ako imate "gremline" na sajtu, na bilo kom serveru, upitajte svog hosta da li imaju mod_security

Zar ovo vec nisam napisao?

Kad god neko pomene mod_security meni padne na pamet ovo. Pa ti razbijaj glavu oko greške koju prvi put u životu vidiš.

[bluesman]

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

[Ivan]

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 ...

[zextra]

a mod_security je tu bas zbog tih koji nemaju ni malo iskustva, a prave web aplikacije (kako god to zvucalo, ima i toga..)

[ivanhoe]

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?

[Ivan]

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).

[ivanhoe]

Originalno napisao Ivan

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).

nisam ja odgovarao na tvoj post, nego sam hteo da kazem da ne vidim potrebu da mod_secure blokira ne ascii znake, jer ako je baza setovaana na ascii ili ut8 onda addslashes ili mysql_real_escape_string rade posao, znaci nema posebne opasnosti od koje se tu treba braniti... bar sto se baza tice...

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

[zextra]

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.