| Ilija Studen |
31. 07. 2006. 09:44 |
Ne prolaze asinhroni zahtevi?
Da li je to kod mene lokalno ili ne prolaze asinhrone forme (quick reply i inline edit)? Jednostavno se zakuca i ni makac...
|
| noviKorisnik |
31. 07. 2006. 10:13 |
Pa nešto ti ne valja ... a bogami ni meni ... evo ima već nekoliko dana.
|
| zextra |
31. 07. 2006. 10:33 |
Sta ne stima?
[edit]ovo je editovano kroz quick edit, a postovano kroz quick reply[/edit]
|
| Ilija Studen |
31. 07. 2006. 11:06 |
Firefox 1.5.0.5 :)
Edit: Quick reply je prošao bez problema, ali edit ni da bekne. Samo se smrzne...
|
| Dragan Babić |
31. 07. 2006. 11:13 |
men ni quick reply ne radi, a ni mungosu kako zakljucujem
|
| Dragan Babić |
31. 07. 2006. 11:14 |
u stvari evo sad je prosao, ali sinoc nije hteo
|
| noviKorisnik |
31. 07. 2006. 11:49 |
Test ... ... ... eto opravljeno izgleda :-)
|
| Ilija Studen |
31. 07. 2006. 12:35 |
Siguran da je popravljeno?
Siguran!
Gle opravljeno :D
|
| bluesman |
31. 07. 2006. 13:13 |
Ja mislim da je frka od kada smo stavili mod_security posto smo imali skoro par "pokusaja" a neki sajtovi pustaju zahteve tipa ...?dir=../../etc/... pa smo onemogucili to. Ja mislim da je to razlog zasto ne radi quick reply, moracu da pogledam source a bas me mrzi.
BTW, oni koji hostuju kod mene bi trebali da provere svoje sajtove, ako se pojavi greska 406 to je mod_security sprecio request.
|
| bluesman |
31. 07. 2006. 13:13 |
Vidi sad radi QR ?!?
|
| zextra |
31. 07. 2006. 14:28 |
gremlini...
|
| ivanhoe |
01. 08. 2006. 11:12 |
evo sad i mene zeza Quick Edit poruke. Evo kako tacno izgleda zahtev (iz FireBug-a), da lakse debagujete:
Kôd:
POST http://www.devprotalk.com/editpost.php
Poslato:
do=updatepost&ajax=1&postid=15735&wysiwyg=0&message=%5BQUOTE%3Djablan%5DJa%20ne%20znam%2C%20ali%20sam%20primetio%20da%20se%20ovakve%20%22twilight%20zone%22%20stvari%20uvek%20tebi%20dešavaju...%20%3B%29%5B/QUOTE%5D%0A%0Aznao%20sam%20da%20nije%20trebalo%20da%20psujem%20onog%20vracha%20u%20Keniji...%3AD%0A%0AVerzija%20je%204.1.9-max%2C%20to%20je%20kod%20mene%20u%20lokalu%20na%20WinXP%2C%20ali%20do%20sad%20je%20lepo%20radila%2C%20prvi%20put%20jutros%20vidim%20ovako%20nesto...%20nije%20mnogo%20bitno%20jer%20na%20linux%20serveru%20sve%20sljaka%2C%20nego%20me%20zanimalo%20kako%20uopste%20moze%20da%20se%20desi%20ovako%20nesto...%0A%0AEDIT%3A%20Izgleda%20da%20se%20ipak%20ovo%20desava%20samo%20iz%20konzolnog%20mysql%20klijenta%2C%20bice%20da%20sam%20nabo%20nekakav%20dos%20bug..&postcount=4&s=
Response:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>406 Not Acceptable</title>
</head><body>
<h1>Not Acceptable</h1>
<p>An appropriate representation of the requested resource /editpost.php could not be found on this server.</p>
<hr>
<address>Apache Server at www.devprotalk.com Port 80</address>
</body></html>
|
| dinke |
01. 08. 2006. 11:50 |
Meni ne radi quick reply, a i sinoc me je nekoliko puta zezao onaj "ajax based" edit. Sve lepo editujem, al kad kliknem da edit dugme, jednostavno se nista ne desava. Srecom, mogao sam da odem u advanced mode, inace bi izgubio sve izmene.
|
| jablan |
01. 08. 2006. 12:10 |
Trebalo bi da se pogleda log tog mod_security-ja, da se vidi koje pravilo pravi problem sa AJAX zahtevima i da se isto pravilo promeni ili izbaci.
|
| bluesman |
01. 08. 2006. 14:07 |
Pogledao sam jos juce audit.log i ima problem sa nekim "illegal character", samo nisam uspeo da provalim kojim posto me mrzelo da unescape-ujem stringove :( Zato neki put radi, neki put ne radi. Mozda ga cak zeza encoding pa se ne snalazi, probacu nesto.
Izmena (bluesman): evo meni je sada radio i quick reply, a sada probam i edit |
Ma ista situacija i meni se desava ... moramo da vidimo ako ima negde taj problem dokumentovan ...ako ne tu je vBulletin support :)
|
| bluesman |
01. 08. 2006. 14:14 |
Nema to veze sa vB, znam sta je, samo da provalim koji ga to karakteri zbunjuju pa da sredim.
|
| bluesman |
01. 08. 2006. 14:16 |
Nema to veze sa vB, znam šta je....
(ovo sam namerno ponovio ali sa našim slovima, dakle problem nismo imali nixa i ja jer nismo koristili šćđ... zato je i prošao zahtev.... čim sam ubacio jedno"š", opet problem. Sada sam 100%o siguran da mod security pravi problem jer detektuje karaktere koji nisu po encoding-u strane)
|
| Dragan Babić |
01. 08. 2006. 14:23 |
HA! kako si mu samo doskocio! :)
|
| bluesman |
01. 08. 2006. 14:33 |
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? :)
|
| jablan |
01. 08. 2006. 14:38 |
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 |
01. 08. 2006. 15:05 |
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 |
01. 08. 2006. 15:31 |
Citat:
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 |
01. 08. 2006. 15:42 |
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 ...
|
| zextra |
01. 08. 2006. 21:46 |
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 |
01. 08. 2006. 22:13 |
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).
|
| ivanhoe |
02. 08. 2006. 18:19 |
Citat:
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 |
02. 08. 2006. 19:15 |
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 05:32. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
