SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. Opcje

[MStaniszczak]

Nie ma sensu nic wywalać (filtrować żadnych słów). Grunt to dobrze wstawiać slashe a tam gdzie ich nie można dodać (np. identyfikatory) stosować odpowiednio is_number, is_integer, intval etc… Nie da rady o tym zapomnieć;-)

Dobry sposobem mogą być filtry w frameworku;-) Ew. klasa z metodami sprawdzającymi dane odpowiednich typów, a wówczaj wystarczy już coś w stylui:

[PHP] pobierz, plaintext 
<?php
try {
   $id = CheckData::integer($_GET[&#8216;id’]);
   $name = CheckData::string($_POST[&#8216;name’]);
   $postcode = CheckData::postcode($_POST[&#8216;postCode’]);
} catch(DataFormatException $e) {
   echo &#092;"Zły format danych\";
}
?>
[PHP] pobierz, plaintext 

Czy jakoś tak;-) Przy takiej organizacji łatwiej nawet poprawić ew. błąd czy luke w sposobie sprawdzania danych;-)

Pozdrawiam
Marcin Staniszczak

Ten post edytował MStaniszczak 8.07.2005, 09:39:33

[Imperior]

Oświećcie mnie proszę i powiedzcie, gdzie przy zdrowych zmysłach programista może zostawić lukę, że można użyć UNION bez ani jednego apostrofa? Przecież to jest możliwe tylko przy czymś takim:

[SQL] pobierz, plaintext 
SELECT * 
FROM users WHERE id = $string
[SQL] pobierz, plaintext 

O czym wogóle rozmawiacie... tak robią tylko początkujący-nieuświadomieni.

[Vengeance]

Imperior... są nawet tacy co robią

[SQL] pobierz, plaintext 
SELECT *
FROM users $warunki
[SQL] pobierz, plaintext 

Widac, ze analizowales malo skryptów i mało skomplikowanych zapytań widziałeś.

tak robią tylko początkujący-nieuświadomieni

O ile mi wiadomo, to forum i ten wątek jest także dla takich a my staramy się ich uświadomić co może być błędem.

@logeen:
AD2. Prawdopodobnie masz racje i wykorzystanie wszędzie odpowiednich filtrów intval() itd... wystarczy, ALE

Mała opowieść:

Zostałem adminem forum szkolnego. Obecnie jedyna możliwość posiadania dość fajnego i darmowego forum to phpBB. Pozatym
wcześniej też takie tam było i użytkownicy się przyzwyczaili.
Zrobiłem update do najnowszej wersji, ale wiadomo że i tak znajdą jakieś błędy (i znaleźli). Trzeba było więc zastosować właśne zabezpieczenia. Przecież nie będę naprawiał całego phpBB i w odpowiednich miejscach dawał intval() tam gdzie oni zapomnieli!

Zrobilem tak więc filtrację danych z GET i usuwam wszystkie "UNION".
Jeśli znajdziesz mi podobne w szybkosći implementacji i pod względem bezpieczeństwa rozwiązanie to z chęcią wysłucham.

A na forum dalej można pisać UNION gdyż filtruje tylko GET (phpBB do wszelkich rzeczy używa naszczęście tablic GET/POST/COOKIE a nie jedzie na superglobalach.

[logeen]

@Vengeance: Z tą opowieścią, to się z Tobą zgodzę. Z tym, że są pewne "ale":

1. Ten temat chyba raczej miał na celu przedstawienia zasad takiego pisania skryptów, aby nie były podatne na SQL injection, a nie poprawiania gotowych skryptów. Więc w przypadku, który podałeś, takie postępowanie może być uzasadnione, ale chyba raczej nie w sytuacji, kiedy piszemy cały skrypt od nowa.

2. Jeżeli w sytuacji, którą przedstawiłeś, nie przefiltruje się odpowiednio danych, to i tak usuwanie "UNION" niekoniecznie da 100% bezpieczeństwo, bo przecież są inne sposoby wykonania SQL injection niż tylko za pomocą unii. Natomiast faktycznie w sytuacji konieczności porawiania istniejących dziurawych skryptów, lepsze takie zabezpieczenie niż żadne.

3. Dane $_POST też przecież można spreparować, po prostu tworząc odpowiedni formularz i go wysyłając do skryptu Co wiecej, można zrobić tak, żeby taki formularz wysłał nieświadomie administrator forum.

[Vengeance]

@logeen: Ale powiedzmy sobie prawde, że fora szkolne "hakują" tylko gówniarze co potrafią jedynie ściągnąć sploita z internetu. A te korzystają wyłącznie z GET i najczęściej właśnie z UNION (w przypadku phpBB). Ja nie mówie o pełnym zabezpieczeniu gotowca (bo to niemożliwe) ale o "zawężeniu kręgu niebezpieczeństwa" :]

Chyba doszliśmy do porozumienia

[johnson]

Mówcie co chcecie, ale czy jest ktoś w stanie podać konkretny zestaw zabezpieczeń, który ustrzeże nas przed atakami poprzez php (oczywiście takie, które zależą od programisty) czy może nie ma sposobu na 100%-owe zabezpieczenie skryptów?

[logeen]

@johnson:
Odpowiedź brzmi: pełna filtracja (tzn. "addslashes", "intval" itp.) wszystkich danych zewnętrznych, które podstawiamy do zapytania SQL. Oczywiście jeżeli piszesz skrypt od zera, bo jeżeli poprawiasz bezpieczeństwo jakiegoś dziurawego gotowca, to trudno Ci będzie sprawdzić wszystkie linie kodu (ale nie jest to niewykonalne, bo tak naprawdę musimy odszukać tylko miejsca wywoływania zapytań SQL i sprawdzić, czy wszystkie zmienne podstawiane do kodu SQL są przefiltrowane) - wtedy można się dodatkowo zdecydować na rozwiązanie podane przez Vengeance, choć i tak nie będzie to pełne zabezpieczenie, niemniej powinno powstrzymać większość script kiddies.

Ten post edytował logeen 8.07.2005, 13:34:56

[brachu]

jezeli mozna wtracic swoje 3 grosze.... to testowalem swoj system zlecen i o dziwo nie mozna sie do niego dostac za pomoca SQL injection, zasluga jest to domyslnych ustawien serwera oraz kilku funkcji sprawdzajacych poprawnosc - ktore wcale nie byly pisane w tym celu.... ogolnie warto jest pisac funkcje sprawdzajace poprawnosc wpisanych przez uzytkownika wartosci - nawet po to aby uniknac wpisywania glupot w wypadku gdy uzytkownikowi pomieszaja sie pola formularza

pozdrawiam

[MStaniszczak]

A tu http://www.gajdaw.pl/varia/xss.html macie coś o atakcha na strony (nie SQL Injection więc troche OT;-) )

Pozdrawiam
Marcin Staniszczak

[moron]

czyli co? mysql_escape_string, stripslashes
moglby ktos napisac jakas funkcje ktora by to robila?

[logeen]

[PHP] pobierz, plaintext 
<?php
/**
 * Wstawia znaki unikowe w zapytaniach, dzieki czemu zapobiega atakowi "SQL injection".
 * @param string $text Ciag tekstowy do zamiany
 * @param resource $handle Identyfikator polaczenia
 * @return string Ciag tekstowy po zamianie
 */
function mysql_escape($text, $handle=NULL)
{
    if (version_compare(phpversion(), '4.3.0', '>='))
    {
        if ($handle) return mysql_real_escape_string($text, $handle);
        return mysql_real_escape_string($text);
    }
	if (version_compare(phpversion(), '4.0.3', '>=')) return mysql_escape_string($text);
    return addslashes($text);
}
?>
[PHP] pobierz, plaintext 

Ten post edytował logeen 22.10.2005, 13:58:36

[qeuw]

Jak można zabazpieczyć stronę jeżeli mam where id=$_GET['id'] and password=$password, wtedy wpisując kod w $_GET['id']= '7 --'
Zaniecha mi sprawdzanie hasła. Te funckje działają tylko w ściśle określonych przypadkach. Jak można było by zabezpieczyc przed pytaniami or,select,delete, into,update, w tablicy _GET, i mieć jakąś tam pewność że skrypt będzie zabezpieczony.

[ActivePlayer]

Jak można zabazpieczyć stronę jeżeli mam where id=$_GET['id'] and password=$password, wtedy wpisując kod w $_GET['id']= '7 --'

uzyj is_numeric na $_GET['id']

[h.4]

Mam takie pytanie...

[PHP] pobierz, plaintext 
<?php
 
$_POST['komentarz'] = mysql_real_escape_string($_POST['komentarz'];
$_POST['komentarz2'] = mysql_real_escape_string($_POST['komentarz2'];
$_POST['komentarz3'] = mysql_real_escape_string($_POST['komentarz3'];
 
?>
[PHP] pobierz, plaintext 

i teraz jak zrobic zeby wszystkie dane z _POST przepuscic przez mysql_real_escape_string bez koniecznosci powtarzania tej funkcji do kazdej zmiennej... tylko zrobic to hurtem

please help

[ActivePlayer]

a jeśli zamiast _GET będzie _POST z jakimś tekstem?

to obejmiesz te dane w ' i wykonasz na nich mysql_escape_string()

[wojto]

i teraz jak zrobic zeby wszystkie dane z _POST przepuscic przez mysql_real_escape_string bez koniecznosci powtarzania tej funkcji do kazdej zmiennej... tylko zrobic to hurtem

[PHP] pobierz, plaintext 
<?php
		foreach($_POST as $a => $b) {
			$_POST[$a] = mysql_real_escape_string($b);
		}
 
?>
[PHP] pobierz, plaintext 

?

[qeuw]

Otóz zrobilem funckje która zamienia wyrażenia sql na np. z UnIoN na !union!. Sądze że to w miare skuteczna metota gdzyż zawiera popularną składnie sql + wyrażenia opisane w phpmyadminie na stronie ze statystykami. A co to tej pętli to się bardzo mi przyda

[logeen]

Otóz zrobilem funckje która zamienia wyrażenia sql na np.  z UnIoN na !union!. Sądze że to w miare skuteczna metota...

Fakt... tylko po co? KAŻDE zapytanie można skutecznie zabezpieczyć przed SQL Injection, bez usuwania z niego słów kluczowych SQLa, a jedynie poprzez odpowiednią filtrację danych, przed podstawieniem ich do zapytania. Przez "Filtrację" rozumiem wykonania np. addslashes (albo lepiej funkcji, którą podałem wcześniej) lub np. intval tam, gdzie jest to konieczne - w zależności od kontekstu. Ciekaw jestem jak rozwiążesz sprawę, kiedy "UNION" powinno się zapisać w bazie danych, np. w jakiejś treści wyświetlanej później na stronie WWW? Fakt, można zamieniać np. na "!union!", a potem przy wyświetlaniu z powrotem na "UNION", ale po co? Jak ktoś mi pokaże jak wykorzystać "UNION" do wykonania SQL Injection w prawidłowo zabezpieczonym skrypcie - np. takim, jak podawałem w tym temacie kilka postów wcześniej - to będę bardzo wdzięczny. Wg mnie jest to niemożliwe. Po co w takim razie narzucać sobie jakieś sztuczne ograniczenia, polegające na niemożności wystąpienia w rekordach bazy danych jakichś słów (np. "UNION")?

Ten post edytował logeen 29.09.2005, 20:01:40

[MalyKazio]

Prawdę mówiąc ten temat jest strasznie zaśmiecony. Niby ktoś pisał, że ma być też pomoca dla początkujących a jedyną rzeczą przydatną dla mnie, jako bardzo początkującego, było słowo addslashes. Niestety nic poza tym... Ani jak to wykorzystać ani jak to potem wyciągnąć z bazy danych... trochę szkoda bo gdy założyłem temat z prośbą o prostą odpowiedź ( http://forum.php.pl/index.php?showtopic=40200 ) to mi się trochę "oberwało" a temat przyklejony to dla początkującego uzytkownika czarna magia.

[Vengeance]

MalyKazio: Znów ci się "oberwie" odemnie osobiście, bo skoro piszesz, że w tym temacie nic nie znalazłeś prócz addslashes() to śmię twierdzić, że czytać nie potrafisz i analizować kodów też nie!

Wiadomo, ile ludzi tyleż opini, dlatego w tym wątku znaleść można prawdziwe multum informacji o tym jak się zabezpieczyć. I nikt nie napiszę Ci jednego 100% sposobu - bo taki nie istnieje. Każdy ma jakieś zalety i wady, każda osoba faworyzuje innych.

Ktoś ci napiszę "używaj addslashes" a potem odnajdą lukę w tej funkcji i cała koncepcja bierze w łęb :]

Jeśli szukasz posegregowanych informacji to odsyłam do książek i artykułów. Tutaj jest forum, i nikt nie będzie edytował każdego postu tak aby początkujący mógł odczytać to jako książkę :/ A że się 5 stron czytać dokładnie ludziom nie chce.... no sorry.