dziwne, że przy małostkowości i czepialstwu "ekspertów" na wykopie jeszcze nikt dodającemu nie wypomniał, że mysql.com to oficjalna strona systemu zarządzania bazą danych MySQL, a nie bazy danych :)
@jamzed: Ja jeszcze rozumiem jakiś mały projekt, stronkę wizytówkę, ale przecież w czymś takim powinna powastać wypasiona klasa walidacji konstruowana przy każdym wywołaniu bazy, dla bezpieczeństwa nawet dla zapytań wewnętrznych, aż tyle czasu pracy serwera to nie pochłania a gwarantuje bezpieczeństwo.
jeszcze się dowiemy że ich serwer PHP, jako jedyne zaabezpieczenie miał włączone "magic quotes":)
@jamzed: Wiesz może, o jakie zapytanie chodzi(nie specjalnie chce mi się szukać)? Podobno serwer SUN też był podatny, aż zaczynam się obawiać o moje projekty:)
Było by fajnie, jabys odpisał np. OR DROP TABLE content; SELECT '1' na co wykop na głównej: table content doesn't exist :)
@Mephistofeles: Przy bardzo dużych repozytoriach danych, jakim raczej jest mysql.com powinno się poza sprawdzeniem czy potencjalne dane są szkodliwe, w jakiś sposób zapisać anomalie, skalsyfikować je, zablokować nadawce...? Prosote filtrowanie treści to zdecydowanie za mało, jeśli o tym nie wiesz to mam nadzieję, że nie administrujesz dużą bazą danych.
@plan9: Można oczywiście logować każde podejrzane zapytanie, ale lepiej od razu nie blokować użytkownika. Niektórzy po prostu sprawdzają z ciekawości, po co skrypt miałby ich banować i bóg wie co jeszcze? Samochody za pociągnięcie klamki nie wzywają automatycznie policji.
@Mephistofeles: To spróbuj wybić szybę: po pierwsze jest to trudne, po drugie włączy się alarm, po trzecie zostanie to zapisane w pamięci komputera (mam na myśli nowsze auta) . Nikt nie mówi nic o banowaniu, ale o zaprzestaniu przetwarzania potencjalnie podatnych zapytań.
"Niektórzy po prostu sprawdzają z ciekawości" - czy uda im się zrzucić bazę, no zajebiście.
Jeśli jakiś user wysyła kolejkę " 'OR DROP 'jakastabela' "" to praktycznie bez względu na jego intencje nie chcesz go mieć na swojej stronie.
Jeśli w kolejce występuje " ' + and, or + słowa interpretowane przez sql i nic więcej to można przyjąć, że to nie jest przypadek i zadziałać za w czasu.
Wyobraź sobie taki scenariusz: masz zabezpieczone przez powiedzmy mysqlrealescapestring wszystkie _$POSTy i _$GETy
bezpośrednio od usera (już pomijając przypadek włączonych "magic quotes").
Jako że mamy 21 wiek, nie lubimy zbyt często ładować 1,5MB grafik więc strona działa po AJAX z $.post(...), wysyłałeś do php sporo danych, oczywiście najprościej przez JSON kompletnie olewając nawet mysqlrealescapestring. Co się może stać tutaj raczej tłumaczyć nie muszę.
Przyjmijmy jednak, że masz znajomego, koksa php i doradził Ci dopisać mysqlrealescape_string przed podaniem tego do kolejki. Tu też nie jest tak kolorowo, wiesz jak JSON traktuje dane?
No ale zastosowanie klasy która potrafiła by odróżnić zapytania własne od usera, zrobić jakiś raport, przyblokować jego kolejki, uratować twoje leniwe dupsko przed odbudową całego serwisu... po co?
Może lepiej zajmij się okradaniem aut a nie programuj.
@plan9: Wszystko fajnie, ale nie możesz przewidzieć wszystkich sytuacji, a jeśli user będzie chciał mieć nick z wykluczonym przez walidację słowem? Zablokujesz? Pytanie tylko po co się przejmować atakami typu SQL Injection, skoro można przerzucić odpowiedzialność na silnik bazy, czyli właściwie je wyeliminować, stosując zapytania preparowane i podpinanie parametrów.
Nie bardzo rozumiem Twój przykład z AJAXem, czyżby chodziło Ci o niestosowanie walidacji przy żądaniach asynchronicznych?
W moim przypadku obojętne co wpisze użytkownik to zostanie dodane do bazy i mało mnie obchodzi czy to będzie nick "drop table" czy "jasiek411". Jak ktoś chce sprawdzić to niech sprawdza, na tym polu dużo nie zdziała.
A co do sprawdzania, sam czasem z nudów testuję odporność różnych stron, ale tylko idiota na poziomie intelektualnym przeciętnego gimbusa mógłby od razu próbować usuwać tabele. Żadnego z tego pożytku ;).
@Mephistofeles: W takim razie twórcy TYPO3, sphinx'a i wielu innych projektów kompletnie niepotrzebnie się trudzili.
Myślisz, że mysql.com nie miał zabezpieczeń? Ktoś się w polu login zapytał o pola bazy i je dostał?
Nie kolego, oni właśnie polegali na wbudowanych zabezpieczeniach (chociaż oczywiście nie tylko), koniec końców sami je projektowali.
@plan9:
> Myślisz, że mysql.com nie miał zabezpieczeń? Ktoś się w polu login zapytał o pola bazy i je dostał?
Myślę, że konto z wysokimi uprawnieniami nie powinno mieć maski % i hasła złożonego z czterech cyfr. A to była jedna z osi ataku.
Mephistofeles ma rację. Obecnie nie ma możliwości wykonania udanego wkłucia SQL, jeśli zmienna jest przetwarzana przez tzw prepared statements.
@plan9: Myślę, że polegali właśnie na takich wymyślnych zabezpieczeniach, które w końcu poległy. Czym więcej kodu tym większe prawdopodobieństwo wystąpienia błędów.
@mad_dud: Gdy pierwszy raz się spotkałem z biblioteką PDO i prepared statements to korzystam z tego wynalazku do tej pory ;) Przez jakiś czas miałem zwątpienie w to, czy aby wszystko to jest bezpieczne, ale w końcu całkowicie się przekonałem :) Ale i tak zawsze na wszelki wypadek rzutuję dane liczbowe do inta... Ważne jest także to, żeby pamiętać, że dane wewnętrzne pochodzące np. z bazy danych przy wykorzystywaniu w kolejnym zapytaniu również należy filtrować (używając właśnie prepared statements)...
@mad_dud Co do tego jak przebiegał atak mógłbym polemizować, sun.com poległ przez właśnie tą lukę, hasło nie miało znaczenia.
Mephistofeles nie ma racji; stwierdzenie, w dużym uogólnieniu , że lepsze zabezpieczenia są gorsze bo są lepsze jest sofizmatem.
@Mephistofeles: a Ty swoje. Z tego wynika, że najbezpieczniejszy system to taki którego niema. Na taki komfort niestety nie możemy sobie pozwolić, więc buduje się systemy zapobiegające występowaniu błędów; widzisz sztuka polega na tym, żeby nie przewidywać błędy, lecz by zabezpieczyć się przed nieprzewidywalnym. Zanim będę kontynuował z Tobą rozmowę, pozwól, że zapytam jaki jest największy projekt jaki tworzyłeś/współtworzyłeś - chodzi mi tutaj o liczbę użytkowników?
Bo o ile faktycznie nie widzę sensu wdrażania zaawansowane systemu IPS do prostego forum dla kilku tyś. zarejestrowanych to przy bardzo złożonych systemach, jest to niemal konieczne. Dlaczego?:
@mad_dud Nic nie jest niemożliwe:) Ale w przypadku PreparedStatement (które jest zdaje się obiektem, odnośnie początku mojej rozmowy z Mephistofeles'em) faktycznie bardzo trudne. Jednak budowanie wszystkiego w oparciu o ps nie zawsze jest możliwe/wygodne/korzystne. Naprawdę zakładam, że mogę się mylić ale nie wierzę, że myli się 90% programistów tworzących solidne frameworki.
Wydaje mi się, że dalsza rozmowa nie ma sensu, zaraz będziecie mi udowadniać wyższość programowani strukturalnego nad obiektowym, bez względu na okoliczności.
@plan9: Ja p$!%!#!e uniosłem się, k!%$a weź za przykład: platforma B2B ~420k aktywnych klientów; właśnie tutaj zajebistą różnicę mi robi czy ktoś sobie wpisze 'nick "drop table" czy "jasiek411" '. Bo jeśli, przez p$!%!#!ony przypadek, (zakładam, że nie mam innych zabezpieczeń) powiedzmy jakiś debil dodający ankietę zapomni przefiltrować _$posta i szlag trafi pół bazy a drugie pół wycieknie inny ktoś poleci dobre kilka baniek w efekcie czego ja zostanę rozj%#$ny przez jego pana prawnika.
Nie powiedziałem, że wiem jak to zrobić, wiem że prędzej czy jeszcze prędzej będzie to możliwe.
Worth noting: MySQL.com wasn't hacked with purloined or guessed passwords. TinKode and Ne0h broke in with a blind SQL injection, targeting the interface, not the database. TinKode also claims to have pwned MySQL.fr, MySQL.it, jp.MySQL.com, and MySQL.de.
@mad_dud: Właśnie widzę, link jest martwy. Było na rumuńskim forum Slacker.ro, też dead. Jak uda mi się coś wydobyć dam znać.
Zobacz mirror googli http://tinkode27.baywords.com/
@plan9: http://www.hackerregiment.com/mysql-com-vulnerable-to-blind-sql-injection.html
tu masz pierwszą publikację informacji, ale tam nie ma ani słowa na temat konkretnego scenariusza włamania. Nie zrozum mnie źle - ja nie chcę Ci dopiec, ale szukam jak najwięcej informacji na temat tego konkretnego przypadku.
@simperium: Ani też żadnej sensownej strony nie zrobisz ;) Równie dobrze możesz powiedzieć że ceny benzyny Cie nie obchodzą bo chodzisz tylko pieszo :P
@simperium: To nie znaczy, że nie można Ci się włamać, twój serwer http może mieć jakieś luki. Jedyna 100 % pewność to napisanie swojego własnego serwera http.
@crystalDesign: po pierwsze przeczytaj ze zrozumieniem post simperium a po drugie bzdury pleciesz, że jedynym 100% bezpiecznym rozwiązaniem jest napisanie własnego serwera http. Nawet jakby jakiś imba master napisał swój serwer to i tak ktoś by złamał jego zabezpieczenia.
@a5x4: Tylko w pewnym momencie zabezpieczenia stają się na tyle silne, że bardziej od ich złamania opłaca się fizyczne wejście do firmy i podpięcie się do komputera.
@a5x4: To widze, że nic o tych sprawach nie masz pojęcia. Jeżeli jedyny otwarty port na serverze to 80, a server napisał jakiś amator, który wie jak pisać bezpieczne programy w C++ niepodatne na ataki to włamanie do takiego czegoś jest niemożliwe.
To co napisałeś jest po prostu żałosne, niby jakim cudem ktoś by złamał jego zabezpieczenia ? Jakie zabezpieczenia ? Czym te zabezpieczenia niby są? Wiesz w ogóle o czym ty mówisz ? Chyba, że masz na myśli aplikacje bez żadnych luk. Z tego co widzę to nie masz pojęcią jak wygląda włamywanie się na serwery, to co napisałeś w swoim komentarzu to pewnie z wiedzy na podstawie filmów, które obejrzałeś w telewizji.
Swoją drogą, napisanie swojego własnego prostego serwera http do obsługi html bez żadnych luk podatnych na atak trwa od kilkunastu minut do max 2 godziny.
A Pan hacker pracuje dla Oracle, który po przejęciu MySQLa stara się zwyczajnie go udupić na kaźdy możliwy sposób w celu "ujednolicenia" rynku. Cała nadzieja w PostgreSQL.
@mr-lutze: Kolego jak się nie orientujesz w temacie to się nie wypowiadaj. Tutaj chdziło oczywiście o "shacking" (sqlhacking). Forma zshackowane była by dziwna, więc kolega Jamzed zastosował jak najbardziej uzasadnioną formę. Bpmljvfpvr avr genxghwpvr grtb cbjnmavr r13
@KawaMakjato: Zadałem sobie podobne pytanie kilka (no dobra, parenaście) lat wstecz. Widzisz w kryptografi, chodzi o to by znalezienie odpowiedzi nie było takie oczywiste, choć ta metoda genealogicznie sięga ponoć czasów samgo Juliusza Cezara i do bezpiecznych z cała pewnością się nie zalicza. Niemniej to paranaście lat temu ktoś odrobinkę mi podpowiedział, tylko dla tego zrobię to teraz:
to zdanie jest zaszyforwane w bardzo prosty sposób, skrót nazwy, i zarazem klucza szyftu zawiera się w zdaniu.
Komentarze (61)
Reklamy Google
pokaż pozostałe komentarze (50)
-
-
-
Allegro.plAPPLE MACBOOK PRO 15.4" i7 2,66 GHz 4GB 320GB Cena: 4599.00 zł
bk726b GŁOŚNIKI PRZENOŚNE RADIO FM microSD USB MP3 Cena: 56.99 zł
nowy Windows Vista Home Premium BOX Pl 32b +fVAT Cena: 439.00 zł