Loading:


Jak zabezpieczyć bazy MySQL przed SQL Injection

Atak SQL Injection to jeden z najpopularniejszych ataków na bazy danych MySQL i jeden z najwiÄ™kszych problemów twórców profesjonalnych serwisów www opartych na PHP oraz innych jÄ™zykach dziaÅ‚ajÄ…cych po stronie serwera i odpowiadajÄ…cych za komunikacjÄ™ aplikacja – baza danych. Celem tego ataku jest wstrzykniÄ™cie / modyfikacja / usuniÄ™cie lub wydobycie z bazy danych poprzez klienta bazy danych (np. aplikacjÄ™ webowÄ…) odpowiednich danych lub struktur. Skrajnymi przypadkami zagrożenia może być niszczenie tabel baz danych, wybieranie z nich szczególnie sensytywnych danych (np. danych osobowych) lub niszczenie caÅ‚ych baz. Możliwe jest nawet wykonywanie niebezpiecznych komend na poziomie hosta bazy danych lub, podczas łączenia siÄ™ do bazy danych na prawach administratora baz danych, haker może również tworzyć osobnego, wÅ‚asnego użytkownika posiadajÄ…cego maksymalne uprawnienia.

 

Oto przykład prostej komendy w mysqli zdefiniowanej w języku PHP:

 

Przykład 1:

 

mysqli_query($con,"INSERT INTO Names (Imie, Nazwisko, Wiek)

VALUES ('Jan', 'Kowalski',32)");

 

Zmienna $con odpowiada w powyższym przykładzie za połączenie z bazą danych.

 

Jeżeli powyższe zapytanie zamienimy na przejmujące wartość danej zmiennej (np. przychodzącej POSTem), może wyglądać następująco:

 

Przykład 2:

 

 

mysqli_query($con,"INSERT INTO Names (Imie, Nazwisko, Wiek)

VALUES ('$imie', '$nazwisko',$wiek)");

 

Tak wykonane mysqli_query to jedna z najprostszych postaci komendy typu INSERT wykonywanej do bazy danych i przechwytujÄ…cych wartoÅ›ci zmiennej wysÅ‚anych np. z formularza napisanego w technologii HTML w żaden sposób nie zabezpieczonej przed atakiem SQL Injection.

 

Logika aplikacji powinna zapewniać odpowiednie przetworzenie funkcji z przykÅ‚adu 2. NajprostszÄ… metodÄ…, aby zapewnić elementarne bezpieczeÅ„stwo, jest używanie PHPowej funkcji mysql_real_escape_string(), dodajÄ…cej znaki unikowe w Å‚aÅ„cuchu znaków, które sÄ… używane w komendzie SQL. Funkcja ta jest rekomendowana w miejsce starszych i mniej bezpiecznych funkcji: mysql_escape_string() oraz addslashes().

 

W jaki inny sposób można zabezpieczyć siÄ™ przed atakiem SQL Injection?

 

Po pierwsze, należy pamiÄ™tać, że aplikacje, czyli klienci, którzy łączÄ… siÄ™ z bazÄ… danych, zawsze powinni być traktowani jako potencjalne zagrożenie dla ciÄ…gÅ‚oÅ›ci dziaÅ‚ania bazy. Ponieważ łączÄ… siÄ™ oni z bazÄ… danych jako pewien użytkownik, a wiÄ™c logujÄ…c siÄ™ do niej, zgodnie z zasadÄ… ograniczonego zaufania, powinny łączyć siÄ™ jako użytkownik z odpowiednimi ograniczeniami. Po stronie bazy danych warto wiÄ™c zdefiniować usera specjalnie na potrzeby klientów. Użytkownik taki powinien mieć np. uprawnienia jedynie do odczytu danych (SELECT).

 

Ponadto, w przypadku aplikacji PHP należy stosować rozszerzenia mysqli lub pdo_mysql zamiast starszego ext/mysql.

 

Innymi dobrymi praktykami podczas zabezpieczenia bazy MySQL, podobnie jak PostgreSQL, sÄ…:

 

  1. Nadanie kolumnom i procedurom mniej intuicyjnych nazw, szczególnie w przypadku umieszczania w nich kluczowych danych. Hakerzy atakujÄ… bazÄ™ danych czÄ™sto wybierajÄ… popularne nazwy tabel lub kolumn w tych tabelach (np. users lub użytkownicy). Jeżeli nazwy te bÄ™dÄ… miaÅ‚y charakter schematyczny wówczas SQL Injection może być zdecydowanie trudniejszy do przeprowadzenia.

  2. Zasada opisana w powyższym punkcie powinna odnosić siÄ™ również do nazw użytkowników. PowinniÅ›my zrezygnować z oczywistych nazw takich jak „admin”, ponieważ je również również zdecydowanie Å‚atwiej podrobić przy SQL Injection oraz przy próbie wÅ‚amania bezpoÅ›rednio przez phpmyadmina (lub pgadmina).

  3. Kluczowe dane powinny być kodowane co najmniej przy użyciu mechanizmu md5 (zalecane sÄ… jednak mechanizmy z grupy SHA-1). W przypadku kodowania należy jednak pamiÄ™tać, że zakodowanie nazwy użytkownika „admin” przy użyciu md5 da nam 32- znakowy string, który dla wprawnego hakera bÄ™dzie znany (na podstawie np. baz md5). Bezpiecznym połączeniem jest zatem łączenie nazw maÅ‚o intuicyjnych z odpowiednim ich kodowaniem. Inne rozwiÄ…zania czyniÄ… bazÄ™ danych gorzej zabezpieczonÄ….

  4. Używanie w języku działającego po stronie serwera funkcji zabezpieczających wysyłane dane takich jak mysql_real_escape_string() lub settype ().

Mottem, do którego należy siÄ™ stosować projektujÄ…c bazy danych, jest to, że powyższe zabezpieczenia powinny dotyczyć wszystkich rodzajów baz danych, a nie tylko posiadajÄ…cych kluczowe dane. Zagrożenia, które istniejÄ…c dla zupeÅ‚nie niezabezpieczonych baz, mogÄ… narażać całą usÅ‚ugÄ™ na niespodziewane przerwanie ciÄ…gÅ‚oÅ›ci dziaÅ‚ania. PamiÄ™tajmy bowiem, że mimo że aplikacja jako taka nie zostanie uszkodzona, jednak może odwoÅ‚ywać siÄ™ do zaatakowanych (skasowanych lub zmodyfikowanych) danych/struktur, wprowadzajÄ…c użytkowników w błąd, lub uniemożliwiajÄ…c poprawne wyÅ›wietlenie danych.

 

Autor Artykułu: Mateusz Jabłoński z http://www.datalab.pl/



Napisz Artyku³

Listing

niema




Dodano przez: mateuszj Ranga: Poziom 3 Punktów: 50
Komentarze użytkowników
    • Tre¶æ komentarza
      Kod do komentarza (opcjonalnie)
      PHP JavaScript MySQL Smarty SQL HTML CSS ActionScript
      Autor
      Token
      token

       

       








funkcje.net
Wszelkie prawa zastrzeżone©. | Funkcje.net 2008-2021 v.1.5 | design: diviXdesign & rainbowcolors