Testowanie, czy witryna jest podatna na Sql Injection

Question

Czytałem o wtrysku sql i rozumiem, jak to działa, jeśli istnieje formularz, w którym użytkownik może wprowadzić swoją nazwę użytkownika i zalogować się. Nie rozumiem, jak strony bez strony logowania mogą być podatne na wtrysk sql.

http://thecybersaviours.com/how-to-find-out-if-a-website-is-vulnerable-to-sql-injection

mówi po prostu dołączyć a 'lub ''=', aby go przetestować. Nie rozumiem, w jaki sposób pomaga to ustalić, czy błąd istnieje. Gdzie w ogóle powstaje zapytanie.

Answer 1

SQL injection to próba wydania poleceń SQL do bazy danych poprzez interfejs strony internetowej, w celu uzyskania innych informacji. Mianowicie, te informacje są przechowywane informacje o bazie danych, takie jak nazwy użytkownika i hasła.

Pierwsza zasada zabezpieczania dowolnego skryptu lub strony dołączanej do instancji bazy danych to Nie ufaj wprowadzanym przez użytkownika.

Twój przykład próbuje zakończyć nieprawidłowo podany ciąg w instrukcji SQL. Aby to zrozumieć, najpierw musisz understand SQL statements. W przykładzie dodawania ' do paramater, twój 'zastrzyk' ma nadzieję na kolejny rodzaj rachunku:

SELECT nazwę użytkownika, hasło od użytkowników WHERE username = '$ username'

By dołączenie ' do tego oświadczenia, można następnie dodać dodatkowe paramaters SQL lub zapytania .: ' OR username --

SELECT nazwę użytkownika, hasło FROM użytkowników WHERE username = '' lub nazwa - „$ nazwa

To jest wstrzyknięciem (jeden typ; Przetwarzanie zapytania). Dane wejściowe użytkownika stają się wstrzykiwane oświadczenie do wstępnie napisanej instrukcji SQL.

Generalnie istnieją trzy rodzaje metod SQL injection:

• Zapytanie przekształcenia lub przekierowania (powyżej)
wiadomość
• Błąd oparte (Nie ma takiego użytkownika/hasło)
• Blind Zastrzyki

Przeczytaj na SQL Injection, How to test for vulnerabilities, understanding and overcoming SQL injection i to pytanie (i podobne) na StackOverflow about avoiding injections.

Edit:

miarę testowania witryny dla SQL injection, rozumiem, że dostaje dużo bardziej skomplikowane niż po prostu „dołączyć symbol”. Jeśli Twoja strona jest krytyczna, a Ty (lub Twoja firma) możesz sobie na to pozwolić, zatrudnij profesjonalnego testera pióra. Jeśli to nie zadziała, this great exaxmple/proof może pokazać niektóre popularne techniki, których można użyć do wykonania testu wtrysku.Istnieje również SQLMap, który może zautomatyzować niektóre testy dla scenariuszy SQL Injection i przejęcia bazy danych.

Answer 2

Wszelkie dane wejściowe od klienta są sposobami narażenia na atak. W tym wszystkie formularze i ciąg zapytania. Obejmuje to wszystkie czasowniki HTTP.

Istnieją rozwiązania 3rd Party że może indeksować aplikacji i wykryć, kiedy zastrzyk może się zdarzyć.

Answer 3

Badanie musi być wykonane na stronie że zapytania do bazy danych tak tak zazwyczaj jest to strona logowania, ponieważ jest to strona, która może zrobić najwięcej szkód, ale może być niezabezpieczone strona również.

Ogólnie rzecz biorąc, za pomocą bezpiecznego logowania można uzyskać zapytania do bazy danych, ale jeśli po prostu masz listę przedmiotów lub coś, co nie obchodzi, czy świat widzi hakera, może dodać trochę iniekcji sql do końca kwerendy.

Klucz z SQL Injection jest osoba wykonująca zastrzyk musiałby wiedzieć, że zapytań do bazy danych, więc jeśli nie jesteś zapytań do bazy danych SQL inject wtedy nie można zrobić. Jeśli twój formularz jest wysyłany do bazy danych, to tak, może to SQL Inject to. Dobrą praktyką jest stosowanie procedur składowanych w celu wybrania/wstawienia/aktualizacji/usunięcia lub upewnienia się, że wszystkie instrukcje, które będą trafiać do bazy danych, zostały przygotowane lub usunięte.

Answer 4

Strona logowania nie jest jedyną częścią witryny opartej na bazie danych, która współdziała z bazą danych.

Wszelkie dane wprowadzone przez użytkownika można edytować, który jest używany do konstruowania zapytania do bazy danych jest potencjalnym punktem wyjścia do ataku SQL injection. Atakujący może nie koniecznie zalogować się do witryny jako administrator w wyniku tego ataku, ale może wykonywać inne czynności. Mogą zmieniać dane, zmieniać ustawienia serwera itp. W zależności od charakteru interakcji aplikacji z bazą danych.

Dołączanie ' do danych wejściowych jest zwykle bardzo dobrym testem, aby sprawdzić, czy generuje błąd lub w inny sposób powoduje nieoczekiwane zachowanie na stronie. Wskazuje to, że dane wejściowe użytkownika są używane do budowania nieprzetworzonego zapytania, a programista nie oczekiwał pojedynczego cudzysłowu, który zmienia strukturę zapytania.

Należy pamiętać, że jedna strona może być zabezpieczony przed SQL injection, podczas gdy drugi nie. Na przykład strona logowania może być utwardzona przed takimi atakami. Ale inna strona w innym miejscu witryny może być szeroko otwarta. Na przykład, jeśli ktoś chciał się zalogować jako administrator, można użyć iniekcji SQL na tej drugiej stronie, aby zmienić hasło administratora. Następnie wróć do strony logowania, która nie wymaga SQL-a i zaloguj się jako administrator.

Answer 5

Najprostszym sposobem zabezpieczenia się jest użycie procedur przechowywanych zamiast wbudowanych instrukcji SQL.

Następnie użyj „najmniejszych uprawnień” uprawnienia i umożliwić dostęp do procedur przechowywanych, a nie bezpośrednio do tabel tylko.

Answer 6

Injekcję SQL można wykonać na każdym wejściu, na które użytkownik może wpłynąć, a który nie jest odpowiednio ucieczony przed użyciem w zapytaniu.

Przykładem może być zmienna get tak:

http//www.example.com/user.php?userid=5 

Teraz, gdy towarzyszący kodu PHP wygląda mniej więcej tak:

$query = "SELECT username, password FROM users WHERE userid=" . $_GET['userid']; 
// ... 

można łatwo używać SQL injection tutaj zbyt:

http//www.example.com/user.php?userid=5 AND 1=2 UNION SELECT password,username FROM users WHERE usertype='admin' 

(oczywiście miejsca będą musiały być zastąpione przez %20, ale jest to bardziej czytelne. Ponadto jest to tylko przykład przynoszący nieco więcej założeń, ale pomysł powinien być jasny.)