Większość zaawansowanych witryn przesyła zapytania, formularze korzystając z POST i GET. Często jednak webmaster robiąc stronę nie myśli, że użytkownik może sobie łatwo zmienić to, co widać w jego pasku adresu.
Co można zrobić z wykorzystaniem braku odpowiedniej walidacji zapytań GET?
Pominę SQL injection. Skupmy się na innych rzeczach.
Gdy zawartość w pasku URL wygląda tak:
http://strona.pl?user_id=5827&action=remove
aż czasem kusi, żeby narobić problemów innym użytkownikom. Przejdźmy do wyjaśnień:
Najlepiej będzie to objaśnić przykładem. Chcemy usunąć nasze konto z serwisu więc przechodzimy do panelu użytkownika. Mamy ładny formularz, który ładnie wypełniamy. W tym wypadku, wybieramy tylko „Usuń konto”. Wciskamy przycisk „Zatwierdź” i formularz jest przesyłany przez GET, czyli przez pasek URL. user_id jest unikalnym numerem naszego użytkownika, który znajduje się w bazie danych. Akcja to usunięcie, więc logicznie action=remove oznacza akcję do wykonania, która jest żądaniem usunięcia konta.
Proszę nie myśleć, że gdy coś takiego jest w pasku URL, to znaczy, że od razu można usunąć innego użytkownika niż samego siebie. Często sprawdzana jest sesja i inne podobne rzeczy, które uniemożliwiają taki „atak”.
No ale, czemu by nie spróbować? A potem webmasterzy szukają w logach, czemu użytkownik został usunięty 😉
Stąd ten apel:
– używaj częściej POST niż GET, bo używa się go tak samo, a dla zwykłego użytkownika trudniej to zmienić
– weryfikuj użytkownika hasłem, patrząc na ciasteczka w przeglądarce
Dzięki temu Twoje życie i życie użytkownika będą łatwiejsze – prosto a skutecznie 🙂
Może na koniec pare linków pokazujących, co da się zrobić gdy webmaster odpowiednio nie zabezpieczy skryptu (oczywiście dalej chodzi tu o zapytania):
Wrzucił posta na ścianę Marka Zuckerberga, bo zespół bezpieczeństwa Facebooka nie zrozumiał na czym polega dziura…
Jak można było przejąć dowolne konto na Facebooku przy pomocy SMS-a?
Nawet takiemu kolosowi jak Facebook’owi zdarzają się wpadki 😉