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]

Opcja

magic_quotes_gpc=On 

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

ty ten wacky jestes od xss w php cos ta m cos tam ?

[ble34]

a ty wcale niemusiałes mu mowic kto wysłal tego esa z bramki
mogłes powiedziec ze urzywasz windy i własnie sie popsuła z roobił ciu sie format chyba bycie niewsadzili do wiezienia za popsuty komputer

a liga liga usuneła dziure zabraniajac dostępu do modułu zwykłym śmiertelnikom i usuwajac moje konto z ich strony na tym sie to chyba zakonczy ,lol>

[TQM]

a ty wcale niemusiałes mu mowic kto wysłal tego esa z bramki
mogłes powiedziec ze urzywasz windy i własnie sie popsuła z roobił ciu sie format chyba bycie niewsadzili do wiezienia za popsuty komputer

Rzecz w tym ze musialem... tak mowi prawo. Na dodatek tworzac kilka bramek NAT ktore sa jedynymi systemami podpietymi do osobnego lacza 100mbit/sek (swiatlowodzik) i obsluguja 2500 uzytkownikow to juz bylem traktowany jako ISP.

Gdybym powiedzial ze uzywam windy i wlasnie ja sformatowalem, to wzialbym na sieibie personalnie odpowiedzialnosc za te 550 osob podlaczone tylko w tym jednym budynku i mogliby mnie ciagac pozniej po sadach w calym kraju, tym bardziej ze sieci mialem we Wroclawiu a pismo z prokuratury w Gdansku.

Poza tym bylo to oficjalne wezwanie do ujawnienia danych wystawione przez prokurature ktore dotarlo do nas przez naszego ISP. Przekazalem sprawe naszym prawnikom, ktorzy powiadomili policje, ze przekaza dane jak dostana wszystko pismem poleconym a nie FAXem. Pismo przyszlo 2 dni pozniej i dane zostaly wyslane... Sprawa zamknieta, policja miala dane ale chyba nawet ich pozniej nie wykorzystala w zaden sposob...

Chodzilo o SMSa zgrozbami wyslanego z bramki Internetowej. Nie ma anonimowosci w sieci... to jest taki sam mit, jak to ze hacker == przetepca.

[ble34]

olać to %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

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