Nastoletni
Programiści

Logo Nastoletnich Programistów

Zabezpieczanie baz danych

Ochrona przed nieuprawnionym dostępem do bazy danych

Baza danych jest jednym z najcenniejszych zbiorów danych o jaki powinni dbać deweloperzy. Może ona zawierać dane osobowe (imię, nazwisko, adres), dane płatnicze (nr karty, kod ccv2) lub  dane powiązane z logowaniem (hashe haseł, salty).

Pierwszym błędem jaki może popełnić programista to naiwność. Czasami poszukując rozwiązań problemów możemy natrafić na posty typu: „podaj dane dostępowe to pomogę”. Nigdy nie ufajmy takim ludziom. Dane dostępowe do baz danych powinniśmy podawać tylko zaufanym developerom pracującym z nami, ale też nie podajmy danych dostępowym każdemu deweloperowi. Dwie lub trzy osoby wystarczą (powinny to być osoby zajmujące się administracją bazy danych lub backendem, każdy użytkownik powinien mieć indywidualny login. Używanie root do wszystkiego jest ogromną dziurą bezpieczeństwa).

Dodatkowym zabezpieczeniem jest ograniczenie dostępu do bazy danych do hosta lokalnego. W takim przypadku osoba atakująca bazę danych musi pozyskać jeszcze dane do ssh lub vpn (Nie muszę chyba wspominać, że wszystkie hasła powinny być inne).

Ochrona poprzez ograniczanie uprawnień

Załóżmy, że mamy jakąś tam aplikację webową i chcemy ją połączyć z baza danych (np. MySQL). Zabezpieczanie naszej aplikacji powinniśmy zacząć od utworzenia konta (na serwerze baz danych) dedykowanego dla naszej aplikacji. Kolejnym podstawowym zabezpieczeniem będzie wykonanie poprzez utworzone lub inne konto instalacji wszystkich tabel a następnie ograniczenie uprawnień konta, którego używa nasza aplikacja webowa, do INSERT SELECT UPDATE DELETE. Takie działanie pozwoli naszej aplikacji tylko na: dodawanie, pobieranie, aktualizacje oraz usuwanie danych z bazy danych. Takie ograniczenie uprawnień pozwoli na zabezpieczenie w przypadku uzyskania dostępu do bazy danych (atakujący nie pozmienia nam struktur danych itp). Warto zauważyć, że w powyższym przypadku atakujący będzie zdolny do usunięcia danych, możemy temu zapobiec odbierając kontu uprawnienie DELETE. W takim przypadku do tabeli będzie trzeba dodać kolumnę is_deleted, działanie jest następujące: jeśli chcemy coś usunąć, poprzez komendę UPDATE ustawiamy kolumnę is_deleted na true, a po pewnym czasie z innego konta (np poprzez  SSH) usuwamy wpisy WHERE `is_deleted`=1.

Ochrona poprzez filtrowanie „user input”

Można powiedzieć, że każdy potral/strona internetowa będzie miała element interakcji z użytkownikiem, użytkownik będzie wprowadzał jakieś dane (user input). Nie można zakładać, że wszyscy użytkownicy będą mieli dobre intencję, zawsze znajdzie się ktoś kto będzie chciał uzyskać nieuprawniony dostęp, jedną z metod ataku jest „SQL Injection”. Jak sama nazwa mówi polega on na dodaniu własnych poleceń do zapytania:

SQL injection (z ang.) – metoda ataku komputerowego wykorzystująca lukę w zabezpieczeniach aplikacji polegającą na nieodpowiednim filtrowaniu lub niedostatecznym typowaniu danych użytkownika, które to dane są później wykorzystywane przy wykonaniu zapytań (SQL) do bazy danych. Podatne są na nią wszystkie systemy przyjmujące dane od użytkownika i dynamicznie generujące zapytania do bazy danych.

Aby zapobiec takiemu typowi ataków należy przefiltrować dane podane przez użytkownika. Najlepszą metodą filtracji jest stosowanie prepared statements, polegają one na wysłaniu do bazy danych samego zapytania z ? w miejsce zmiennych, a następnie wysłania danych. W ten sposób baza danych wie, że tylko pierwsze zapytanie jest składnią SQL, a nastepnie podane są dane. Poniżej podaję przykład zastosowania prepared statements w PHP i z użyciem bazy MySQL:

Słowo końcowe

Mam nadzieję, że te 3 sposoby zabezpieczenia pomogą wam w tworzeniu bezpiecznych stron/serwisów internetowych. Ważne jest jednak, aby wszystkie zabezpieczenia poddawać testom penetracyjnym (jeśli w przyszłości pojawi się poradnik mojego lub czyjegoś autorstwa to podlinkuję). Internet jest bardzo złożonym środowiskiem i należy zwracać uwagę na to komu ufamy.

TESTUJ WSZYSTKO!!!

Literatura dodatkowa

OWASP SQL Injection Prevention Cheat Sheet


Ten artykuł używa materiałów z Artykułu na Wikipedii „SQL_injection”, który jest wydany pod licencją Creative Commons Attribution-Share-Alike License 3.0.
Autor artykułu oświadcza, że publikuje artykuł pod licencją Creative Commons Attribution-Share-Alike License 3.0 (CC BY-SA 3.0).
Wyłączenie odpowiedzialności: Autor oświadcza, że nie bierze żadnej odpowiedzialności za nieprawidłowe/błędne działanie kodu i metod zamieszczonych w artykule

Jakub Serwatka

Programista od dziecka, aktualnie uczeń 3 gimnazjum. Głównie skupiam się na technologiach webowych, lecz znam się coś tam na aplikacjach desktopowych. Chętny do pomocy :)

Zobacz wszystkie posty tego autora →

Komentarze

  • Meridion

    Nie sądzę by ograniczenie uprawnień na DELETE coś pomogło, jedyne co to spowoduje to utrudnienie sobie życia. Chcąc usunąć dane zamiast delete można je po prostu nadpisać poleceniem UPDATE.

    • JakubSerwatka

      Wiem, w poście rozważam bardzo „ściśnięte” rozwiązania. Jeśli pracujesz nad jakimś projektem, najlepiej jeśli rozwiązania bezpieczeństwa opracujesz sam

      • Czyli, jeśli dobrze rozumiem, sam przyznajesz, że wpis nie ma sensu bo i tak w razie czego trzeba samemu ogarnąć temat?

        • JakubSerwatka

          mój wpis miał na celu pokazanie „zarysu” oraz naprowadzenie na podstawowe techniki zabezpieczania, reszta technik bedzie rozwijana w gescie developera, jesli chce to moze tworzyc jakies filtry etc

          • Super zarys, po przeczytaniu są 2 opcje:
            1. Nic nie robić z bazami danych i już zapomnieć o czym to w ogóle było (ja tak zrobiłem);
            2. Pójść przeczytać o tym gdzie indziej, gdzie podstawy i tak najprawdopodobniej też będą zawarte.
            Ok.