zastrzyki sql

[ble34]

Tak więc ostatnio dużą popularnością ciezą sie wszelkiego rodzaju ataki typu injection a może tylko tak mi się wydaje bo stosunkowo od niedawna interesuja mnie zabespieczenia no ale nieważne mam takie pytanko dotyczące opcji magic_quotes_gpc=On czy da sie ja obejśc i po mimo jej właczenia przeprowadzic atak typu injection podobno nie eliminuje ona wszystkich rodzaji zastrzyków własciwie niewiem dlaczego mowi sie ze ataki tego typu sa duzym zagrożeniem może mam zamałą wiedze jeszce ale z tego co zauważyłem jedna głupia opcja uodparnia serwer na wstrzykiwanie kodu
więc oco kama bo jeśli w systemie portalowym wspólpracującym z bazą sql
wpisuje w formularzu np wyszukiwania coś takiegio * ' " ; # -- , and 1=0 a otzrymuje taki wynik * \\\' \\\ to chyba znaczy ze filtrowane sa wszystkie znaki specjalne a skoro tak to serwer oprze sie ataka xss sql itp oczywiscie gdzies spotkalem sie z opinia ze mozna je zastąpic odpowiednikami szesnastkowymi ale osobiście niespotkałem sttrony www która by się na to nabrała wiec jeszcze raz powtórze o co mi chodzi bo sie rozpisałem troche

1 czy da sie oszukać opcje magic_quotes_gpc=On i wogole filtracje danych po stronie serwera

2 bo jesli wystarczy w pliku konfiguracyjnym zmienic opcje z off na on i to zartrzymuje złosliwe dane to oco chodzi to raczei injection to atak typu hakuj z google niz poważna bron przeciwko serwerowi www

za wszelkie gafy i nieścisłosci przepraszam jestem świerzak w tych sprawach
jeli juz to wynika to tylko z mojego niedoinformowania

[wacky]

Opcja

magic_quotes_gpc=On 

Nie zabezpiecza przed SQL injection. Wystarczy troszke pogooglac i znajdziesz odpowiedz.

[ble34]

zamotałem ten post troche sam chyba niewiem oco mi chodziło dokońca
więc mówisz ze niezabespiecza no luz poszukam ale mimo wszystko chodzio o omijanie filtracji danych bo manipulacja danymi wejściowymi to tak naprawde jedyny sposób chyba na zddobycie serera wykożysta sie jakie s luki w apaczach itp ale generalnie jezeli serwer www dobze filtruje dane niedopuszczajac zadnych znaków specjalnych chyba jest niedozdobycia przynajmniei teoretycznie ja przynajmniei niemam pojęcia jak sie na niego dostac chociaż z drugiei strony jezeli jakis sytem portalowy wspólpracuje z mysql to prawie napewno w jakms mjescu jest błąd do którego mozna dołaczyc zapytanie sql albo javke trzeba je tylko znaleśc zreszta niewiem ale trzeba byc optymistą no nie?

[ble34]

mam dla was prezencik na buqtrq niewiem czy to znana luka czy nie bo ja ja znalazłem 30 minut temu występuje w
PHP-Nuke theme by dudi
a dokładnie w tym module:
modules.php?name=coppermine&file=albmgr&cat=10019

w formularzu wpisujemy

<script type="text/javascript">ale(document.cookie);</script>

i mam ciacha

jednak warto byc optymistą

--3x3R0o+--

[ble34]

zapomniałem wczesniei trzeba załozyc konto na stronie
i prosze to najlepiej najpierw zweryfikowac

[TQM]

No to zaczynamy lekcje... ;-)

1. Serwer WWW nie robi filtrowania danych wejsciowych w zaden sposob - odpowiada za to programista i jego aplikacja
2. PHP nie jest serwerem WWW, jest jedynie dodatkiem, ktory na dodatek domyslnie jest bardzo kiepsko skonfigurowany i pozwala na rozne dziwne zagrania
3. To co przedstawiles w ostatnim poscie to jest atak XSS i to juz na 200% nie ma nic wspolnego z serwerem - tu jedynie aplikacja moze sie sama bronic

To wracajac do Twoich pytan - magic_quotes_gpc ON jedynie poprzedza wszystkie znaki, ktore moglyby byc parsowane przez jezyk PHP znakiem '\', ktory zapobiega ich interpretacji... tak wiec mozna tak wstawic do tekstu w cudzyslowiu nastepny cudzyslow, jesli wewnetrzne wystapienia zapiszesz jako \" - wtedy znak " niebedzie traktowany jako koniec stringa ale tak jak kazdy inny znak... magic_quotes_gpc nie zaradzi na kazdy atak, ale sporo pomoze...

Ataki klasy 'INJECTION' mozna podzielic w sumie na rozne grupy... SQL Injection to wrzut danych do bazy SQL - znajac jezyk SQL, jesli programista nie sprawdza tego co podaje uzytkownik w polach wejsciowych to wstawienie odpowiedniego ciagu umozliwia na przyklad ominiecie autoryzacji doszczetnie i wejscie jako uzytkownik z prawami admina - wszystko zalezy od tego jak bardzo programista spierdzielil robote... Jako weryfikacje danych wejsciowych na pewno nie mozna uzywac Javascript - moze to i ladnie wyglada jesli ktos to lubi ale w ogole nie dziala... Druga klasa to Command Injection i jest znacznie grozniejsza... Mozna czytac pliki ktorych nie powinno sie widziec, wykonywac polecenia systemowe lub nawet kawalki kodu wpisanego w formularzu hehe - to dopiero jest jazda!

Kilka dobrych rad ktore zawsze przydaja sie programistom aplikacji webowych...
1. Nigdy nie ufaj w to co klient podaje w formularzu
2. Nigdy nie ufaj walidacji po stronie klienta
3. Nie ufaj nawet danym wychodzacym, zwracanym przez wlasna aplikacje - pomyl o filtrze wyjsciowym ktory sprawdza czy przypadkiem aplikacja nie wyswietli klientowi czegos czego nie powinna... bo moze o czyms zapomniales ale atakujacy nie?
4. Juz sama informacja o wystapieniu bledu jest dla atakujacego na cene zlota - bledy loguj ale nie pokazuj jesli nie musisz.
5. Jesli juz musisz zglaszac bledy, usun domyslne strony bledow a jesli w aplikacji wystepuje blad zwroc komunikat w stylu "Blad przetwarzania danych" i zaloguj dokladnie co sie stalo, powiadom admina - nigdy nie pokazuj bledu "Blad w linii 2135: nie moge odczyta /var/vhost/domena1/etc/passwd".
6. Sprawdzaj dlugosci pol i danych wejsciowych
7. Dekoduj encje HTML tak dlugo jak dluga sa znaki wskazujace na ich istnienie... &amp; to & a nie 5 znakow... Jeden przebieg dekodowania za malo moze dopiero uaktywnic atak...

... lista jest baaardzo dluga. Ataki typu Injection to tylko jedna z kategorii atakow...

W sumie zrodla wiedzy na ten temat sa dosc liczne - google na pierwszym miejscu, a jak masz czas i pieniadze to mozesz zaplacic np $1500 za 3 dni szkolenia w SANS Institute w zakresie Writing Secure Web Applications (niestety nie ma tych szkolen w Polsce). Maja to na prawde calkiem fajnie opracowane, doskonala zabawa bo przeprowadzasz faktyczne wlamania do specjalnie opracowanego na ten cel systemu webowego... Co prawda szkolenie nieco za bardzo skupia sie na Javie (o innych jezykach zapomnieli widac) ale ma swoja wartosc... Z ciekawosci powiem Wam tylko ze Java ma zadziwiajaco duzo podatnosci na takie rzeczy i wynika to nie ze slabosci jezyka ale ze slabosci umyslu programisty, ktory musi w Javie pamietac o bardzo wielu detalach.

Z innej beczki moge powiedziec z cala odpowiedzialnoscia, ze wszystkie aplikacje napisane w Javie (no moze poza doslownie jedna) na ktorych mam watpliwa przyjemnosc pracowac slimacza sie masakrycznie (a serwery maja potezne), co kawalek sie sypia a czas usuwania awarii i poprawiania bledow idzie w dluuugie dni jesli nie tygodnie... a ze odpowiadaja za to inne firmy to juz kaplica maksymalna. Systemy o podobnej funkcjonalnosci napisane w PHP czy Perl'u (tak tak - ten jezyk nadal zyje i ma sie wysmienicie), dzialaja, nie sypia sie, nie spowalniaja bez powodu a usuniecie bledu to kwestia kilku godzin max.

Wracajac do tematu... zbieranie wiedzy - google ma to samo... ale aby zebrac ta sama wiedze z google potrzebujesz wielu miesiecy i sporo samozaparcia aby to opracowac sobie ladnie.

Zycze milego czytania, szukania i zabawy. Pamietajcie jednak ze zabawa wysmienita ale czesto jest balansowaniem na granicy przestepstwa... Nie zachecam do lamania prawa - zdobywajcie wiedze aby umiec sie zabezpieczc przed atakami i tworzyc lepsze oprogramowanie dla siebie i dla innych.

[ble34]

spoko napisane ale wsumie nic nowego sie od ciebie niedowiedziaałem pozat tym ze magic_quotes_gpc ON niechroni przed wstrzykiwaniem badziewia z czym sie nie zgodze przynajmniei niedokonca bo wwielu przypadkach chroni
moze nie całkowicie silnik portalowy cz jak to sie nazywa wiesz chodzi o jportal ps newsy itp ale wiele skryptow np w przypadku PHP-Nuke sie broniło dzięki tei opcji oczywiscie znalazł sie taki co sie nieobronił heh
ale jestem zdania ze dzieki tei opcji mozna zabespieczyc sstrone w dosc duzym stopniu ...dalei z apomniałem co miałem napisac zawaliłem dwie noce
i padam na pyszczek dobranocka

[ble34]

przynajmniei przed atakami cross site scriping a to juz dużo chociaż osobiście podpierniczają mi one lamerjadą i chamuja mój rozwój
to trzeba sobie powiedziec ze moga byc krytyczne w skutkach

dobra ide spac naprawde już <lol>

[TQM]

Ehhhhh chlopie... ales namieszal i na dodatek nie masz racji...

[...] pozat tym ze magic_quotes_gpc ON niechroni przed wstrzykiwaniem badziewia z czym sie nie zgodze przynajmniei niedokonca bo wwielu przypadkach chroni moze nie całkowicie silnik portalowy cz jak to sie nazywa

Odnosnie tego kawalka - 'wstrzykiwanie badziewia' oznacza ?!?
Jako badziewie w tym miejscu rozumiem polecenie ktore wykona PHP, XSS, SQL Injection... No wiec nie masz racji bo nie chroni w ogole :-) poza tym nie ma czegos takiego jak 'chroni moze nie calkowicie' - nie mozna byc troche w ciazy... albo sie jest albo nie... albo cos jest bezpieczne albo nie

magic_quotes_gpc to jest tylko podmiana znakow w zmiennych importowanych z formularzy i cookie's, aby te nie zawieraly znakow ktore PHP mogloby przypadkowo zinterpretowac w kontekscie wykonywanych polecen jako znakow kontrolnych.

Cobys nie mylil pojec i nie mial watpliwosci na przyszlosc o jakie znaki tu chodzi:

magic_quotes_gpc boolean

Sets the magic_quotes state for GPC (Get/Post/Cookie) operations. When magic_quotes are on, all ' (single-quote), " (double quote), \ (backslash) and NUL's are escaped with a backslash automatically.

Filtrowanie XSS to juz musi programista w aplikacji wstawic. Zabezpieczenie przed SQL Injection to tez rola programisty - wystarczy dobrze skonstruowac zapytanie. magic_quotes_gpc potrafi utrudnic zycie 80% script-kiddies, do czasu az naucza sie jak omijac pewne struktury i zapisywac stringi w innej postaci... magic_quotes_gpc to jedynie pomoc dla malo wprawionych programistow moim zdaniem, aczkolwiek sam tez tego uzywam bo jest to zawsze jakis dodatek, ktory moze przypadkiem zatrzymac cos, o czym ja moglem w natloku zajec zapomniec - w koncu kazdy popelnia bledy. Skoro magic_quotes_gpc jest dostepne to lepiej je miec niz nie miec. Poza tym przyklad zabezpieczenia PostNuke'a jest dosc slaby - ta platforma do bezpiecznych raczej nie nalezy moze dlatego ze magic_quotes_gpc wyglada na glowna jesli nie jedyna linie obrony w tym systemie.

Poskladanie nastepnej czesci Twojego maila zajelo nieco czasu bo cholernie chaotycznie to napisales... ale chyba sie udalo... sklilem dwa posty i oto co wyszlo:

[...] ale jestem zdania ze dzieki tei opcji mozna zabespieczyc sstrone w dosc duzym stopniu [tu fragment o zarywaniu nocy pomijamy] przynajmniei przed atakami cross site scriping a to juz dużo chociaż osobiście podpierniczają mi one lamerjadą i chamuja mój rozwój to trzeba sobie powiedziec ze moga byc krytyczne w skutkach

Po pierwsze jak juz wyzej udowodnilem, magic_quotes_gpc nie zabezpiecza niczego przed atakami Injection - tutaj nie masz absolutnie racji, po drugie nie bardzo rozumiem jak ataki XSS moga przeszkadzac komukolwiek w rozwijaniu sie i finalnie po trzecie zgadzam sie z Toba w kwestii ze ataki z grupy Injection moga byc bardzo dotkliwe w skutkach - dowodow nie trzeba daleki szukac...

[ble34]

magic_quotes_gpc to jest tylko podmiana znakow w zmiennych importowanych z formularzy i cookie's, aby te nie zawieraly znakow ktore PHP mogloby przypadkowo zinterpretowac w kontekscie wykonywanych polecen jako znakow kontrolnych.


no własnie oto chopdzi

czy niejest tak ze przy wyłaczonym magic_quotes_gpc iterpretator przez to ze nie podmieniono znakow w zmiennych wykona kazdy skrypt który wprowadzimy do formulaza ?

wiem ze niemozna być troche w ciazy