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

[propage]

to wyjątkowa sytuacja, nie mam zamiaru robić forum dla programistów.

---------

Mam dodakotwe pytanie.
Jesli w skrypcie inkluduje sobie plik na z nazwy GETA.
Aby zabezpieczyć się przed tym, żeby ktos nie piwsał nap ?p=../../config.php

robię taki warunek "if(eregi ('\.', $_GET['p'])) die();

czy są jakieś metody, które obejdą mój warunek?


Ten post edytował propage 30.01.2011, 16:14:42

[pyro]

to wyjątkowa sytuacja, nie mam zamiaru robić forum dla programistów.

---------

Mam dodakotwe pytanie.
Jesli w skrypcie inkluduje sobie plik na z nazwy GETA.
Aby zabezpieczyć się przed tym, żeby ktos nie piwsał nap ?p=../../config.php

robię taki warunek "if(eregi ('\.', $_GET['p'])) die();

czy są jakieś metody, które obejdą mój warunek?

yyy tak. I to co najmniej kilka metod.

[Crozin]

to wyjątkowa sytuacja, nie mam zamiaru robić forum dla programistów.

To nie ma znaczenia.

W ogóle zabierasz się za to od złej strony. Próbujesz nie dopuścić do wprowadzenia "dziwnych" danych (co jest bardzo trudne) zamiast upewnić się, że dane zostaną odpowiednio obsłużone (co jest bardzo proste).
Dane trafiają do XML-a czy formatu pochodnego jak HTML? htmlentities czy któraś z podobnych funkcji - problem z głowy.
Dane trafiają do URL-a? (raw)urlencode - problem z głowy.
Dane trafiają do JSON-a? json_encode - problem z głowy.
itd.

Mam dodakotwe pytanie.
Jesli w skrypcie inkluduje sobie plik na z nazwy GETA.
Aby zabezpieczyć się przed tym, żeby ktos nie piwsał nap ?p=../../config.php

robię taki warunek "if(eregi ('\.', $_GET['p'])) die();

czy są jakieś metody, które obejdą mój warunek?

1. Nie używaj ereg.
2. Po prostu określ jakie wartości może przyjąć. Ile masz tych plików? 5, 10, 15?

[propage]

To nie ma znaczenia.

W ogóle zabierasz się za to od złej strony. Próbujesz nie dopuścić do wprowadzenia "dziwnych" danych (co jest bardzo trudne) zamiast upewnić się, że dane zostaną odpowiednio obsłużone (co jest bardzo proste).
Dane trafiają do XML-a czy formatu pochodnego jak HTML? htmlentities czy któraś z podobnych funkcji - problem z głowy.
Dane trafiają do URL-a? (raw)urlencode - problem z głowy.
Dane trafiają do JSON-a? json_encode - problem z głowy.
itd.

1. Nie używaj ereg.
2. Po prostu określ jakie wartości może przyjąć. Ile masz tych plików? 5, 10, 15?

Mam wiele plików, to musi być bardziej elastyczne. Nie chce wypisywać w skrypcie nazw wszystkich możliwych plików.
Skoro są takie metody to chciałbym je poznać, aby się zabezpieczyć przed nimi.

[pyro]

W tym przypadku wystarczy (zakładając, że wszystkie pliki do includowania posiadasz w jednym, oddzielnym katalogu [np. `includes/`]):

[PHP] pobierz, plaintext 
$inc = basename($_GET['inc']);
if(!include_once('includes/'.$inc))
{
echo 'Podales nieistniejacy plik';
}
[PHP] pobierz, plaintext 

[propage]

pyro, przed czym ma zabezpieczyć ten kod?


jesli inc bedzie mieć zawierać "../../index.php"

to

if(!include_once('includes/'.$inc))

da nam to

if(!include_once('includes/../../index.php'))

plik taki istnieje.

[nospor]

@propage aleś ty cwany... wyciąłeś kawałek z kodu pyro i masz do niego jakieś żale :/

Z kodu pyro wywaliłeś:
$inc = basename($_GET['inc']);
a ten właśnie kawałek kodu stanowił podstawę zabezpieczenia

[propage]

nie zauważyłem tej funkcji, to jest wystarczające zabezpieczanie?

[nospor]

nie zauważyłem tej funkcji,

Kod miał 4 linijki :/

[japolak]

chciałbym sie dowiedzieć jakie jest/są w "miarę" skuteczne zabezpieczenie/a przed tym atakiem

szukalem na tym forum... i co któryś post przekierowujecie do tego.. .

poczytałem kilka stron tego tematu.. i jednym słowem tu jest wielka sieczka:

kazdy sie "przekrzykuje" tak jak tirowcy stojący w korku przekrzykują osobówki mijające ich bokiem..


skoro temat jest tematem tak ważnym może "moderacja" by podsumowała go i napisała w pierwszym poście na co tak naprawdę trzeba zwrócić uwagę..

Ten post edytował japolak 28.07.2011, 19:31:11

[kilas88]

chciałbym sie dowiedzieć jakie jest/są w "miarę" skuteczne zabezpieczenie/a przed tym atakiem

szukalem na tym forum... i co któryś post przekierowujecie do tego.. .

poczytałem kilka stron tego tematu.. i jednym słowem tu jest wielka sieczka:

kazdy sie "przekrzykuje" tak jak tirowcy stojący w korku przekrzykują osobówki mijające ich bokiem..

rozwiązując dany problem mamy mnóstwo rozwiązań i w zależności od problemu stosujemy odpowiednie ku temu rozwiązanie - jeden napisze swój algorytm, ktoś inny usiądzie nad tym samym problemem i wypluje zupełnie inny kod. zmierzam więc do tego, że nie ma "złotego" rozwiązania, inaczej dawno temu ktoś napisałby program, który zastąpiłby programistów i pisał programy za nich

[pyro]

chciałbym sie dowiedzieć jakie jest/są w "miarę" skuteczne zabezpieczenie/a przed tym atakiem

szukalem na tym forum... i co któryś post przekierowujecie do tego.. .

poczytałem kilka stron tego tematu.. i jednym słowem tu jest wielka sieczka:

kazdy sie "przekrzykuje" tak jak tirowcy stojący w korku przekrzykują osobówki mijające ich bokiem..


skoro temat jest tematem tak ważnym może "moderacja" by podsumowała go i napisała w pierwszym poście na co tak naprawdę trzeba zwrócić uwagę..

Zobacz na phpmagazyn.pl

[gargamel]

Nie znalazłem w temacie, więc pozwolę sobie dodać przykładowe użycie PDO.
Prosty skrypt, więc myślę że pozwoli zrozumieć o co w tym chodzi, osobie która zaczyna z nim zabawę:

[PHP] pobierz, plaintext 
$conn = new PDO("mysql:host=$host;dbname=$db", $user, $pass);
 
$sql = "SELECT user_id, user_name, user_email FROM users WHERE login = :login AND password = :password ;";
 
$q = $conn -> prepare( $sql );
 
$q -> execute(
              array(
                    ':login' => $_POST['login'],
                    ':password' => $_POST['password']
                    )
              );
 
  if( $q -> rowCount() > 0 ){
 
    while( $r = $q -> fetch() ){
    echo 'Witaj ' . $r['user_name'] .'. Twoje id to: ' . $r['user_id'] . ', Twój email to: '. $r['user_email'];
    }
 
  }
  else{
  echo 'Nie znaleziono użytkownika!';
  }
[PHP] pobierz, plaintext 

[Inscure]

Byłby ktoś tak miły, żeby streścić cały ten temat do jednego posta wybierając najlepsze i najskuteczniejsze metody, przy okazji usuwając posty wprowadzające w błąd?

Z góry dzięki

[Noidea]

@Inscure
W celu zabezpieczenia się przed atakami SQL Injection używa się prepared statements. Wszystkie powyższe posty które mówią co innego wprowadzają w błąd.


Bardziej streścić się chyba nie da

[skowron-line]

A pro po tematu znalazłem dziś na dzone.com
http://php.dzone.com/news/hardening-php-sql-injection

[thek]

@Noidea: nie spłycaj tak, bo nie masz do końca racji. Zabezpieczanie przed sql injection jest zazwyczaj kilkupoziomowe i powiedzenie "używaj prepared statements a bedzie cacy" jest po prostu ignorancją. Ono zabezpiecza, ale nie wszędzie jest możliwe do zastosowania to raz, a dwa, że prawidłowe zabezpieczenia działają jeszcze zanim cokolwiek do bazy zaczniesz wrzucać i obejmują filtrowanie danych oraz ich walidację.

[Noidea]

PDO jest dostępne w PHP gdzieś od wersji 5.1. MySQLi chyba jeszcze dłużej. Sterowniki do mniej popularnych baz również mają obsługę prepared statements. Myślę, że już najwyższy czas, żeby społeczność zakończyła wsparcie dla staroci pokroju 4.x. Ewentualnie można napisać

Aby zabezpieczyć się przed SQL Injection używaj prepared statements
opis...
opis...
opis...

gdzieś na dole, małymi literami:
Jeśli na twoim hostingu nie ma obsługi prepared statements dla twojej bazy danych to
a) zmień hosting
LUB
poczytaj innych sposobach zabezpieczania [link]

Takie coś przynajmniej nie będzie mącić w głowie początkującym, którzy wielopoziomowe zabezpieczenie przed SQL Injection rozumieją tak:

[PHP] pobierz, plaintext 
$var = mysql_real_escape_string( htmlspecialchars( addslashes( $var ) ) );
[PHP] pobierz, plaintext 

a dwa, że prawidłowe zabezpieczenia działają jeszcze zanim cokolwiek do bazy zaczniesz wrzucać i obejmują filtrowanie danych oraz ich walidację.

Przed SQL Injection zabezpieczają prepared statements.
Filtrowanie i walidacja zabezpiecza przed tym, żeby użytkownik nie ustawił sobie wieku -12345 lat, nazwiska zawierającego cyfry, czy adresu email bez małpy. To, że niektóre rygorystyczne filtry (np. login mogący składać się wyłącznie z liter i cyfr) zabezpiecza przed SQL Injection to tylko efekt uboczny. Dlatego uważam, że sposoby poprawnej walidacji danych powinny być przedstawione w podczepionym temacie o walidacji danych.

[thek]

Noidea... A ja napiszę, że zamiast prepared statements można użyć procedur składowanych i też będę miał rację. To na co chciałem zwrócić uwagę to fakt, że wspomniane przez Ciebie rozwiązanie nie jest jedyne i niepodważalne to raz, a dwa, że nie jest problemem napisać nowy serwis od zera i zastosować każdy myk jaki się zna. Programista wielokrotnie musi grzebać w czyimś kodzie, który "pierwszej świeżości" być nie musi i konieczność jego bezpiecznego utrzymania także jest ważna, mimo wprowadzania swoich poprawek. Możesz przemycać własne sztuczki, ale możesz dostać serwis, gdzie jesteś zmuszony zapomnieć o mechanizmach ochrony Ci znanych bo próba pisania w php5 = przepisanie całego core i masy elementów zależnych, czyli w zasadzie napisania serwisu od zera. Pół biedy gdy serwis wspiera kilka wersji i sobie po stronie serwera ustawisz które pliki idą jako php4, a jakie przez php5, ale i tak będzie to bagno z wydzielonymi funkcjonalnościami i gdzieś w końcu umoczysz zapewne bezpieczeństwo przez przypadek choćby. Wtedy tylko konkretna walidacja Cię może jakoś poratować, ale nie zabezpieczy i tak, bo część przydatnych funkcji jest dopiero od php5 i masz potencjalnie przydatne funkcje odcięte od arsenału. Witamy w prawdziwym świecie, a nie jego wycinku. I nie zapomnij o kompatybilności kodu wstecz. Naprawdę fajnie się pisze "rób tak i tak, olej resztę rozwiązań", tyle że jest to najczęściej prosta droga do tego by pokpić sprawę i puścić na produkcję bubel. Pamiętaj, że Twój komp to nie jedyna konfiguracja dla serwerów, a ja już wystarczająco wiele widziałem ustawień w php.ini, które powodowały, że zgrzytałem zębami. Nie wspominam nawet o aplikacjach firm trzecich, które zakładają sobie hostingodawcy i które mają w zamyśle chronić serwery, a wyjątkowo często sprawiają masę problemów. Sam niedawno kląłem na czym świat stoi, gdy się okazało, że hostingodawca filtruje dane $_POST i $_GET przez co 90% akcji administratorskich kończyło się errorem 403. A potem szukaj wiatru w polu bo kod poprawny się sypie, choć na developerskim śmigał jak marzenie. Powiesz klientowi, że ma sobie serwer zmienić lub doinstalować jakiś pakiet czy skompilować z obsługą określonego bo Twój konfig to ma i użyłeś przy pisaniu serwisu? Nie sądzę.

A to co mówiłem o wieloetapowości ochrony to jest ważna rzecz. Po co zezwalać na zapis do bazy głupot, skoro można i powinno się je odsiać już wcześniej. Należy nie tylko kontrolować co wchodzi ale i wychodzi z bazy. Większość osób zwraca tylko na to pierwsze uwagę, ignorując choćby pobieżne sprawdzenie danych otrzymanych

[Noidea]

Sparametryzowane wywołanie procedur składowanych zabezpiecza przed SQL Injection. Ale jeśli będziemy to wywołanie sklejali ze stringów, to może nam to nic nie dać. O ile w przypadku MySQL ciężko będzie to wykorzystać, bo mysql_query nie zezwala na więcej niż jedną instrukcję, to dla innych baz już takiego ograniczenia nie ma:

[PHP] pobierz, plaintext 
<?php
// SQL Server
 
$_GET["user_id"] = "1234; DROP TABLE users";
 
$query = "EXEC getUserById " . $_GET["user_id"];
echo $query; // EXEC getUserById 1234;  DROP TABLE users
 
$result = sqlsrv_query( $conn, $query ); // Instrukcje wykonają się poprawnie. Obie.
?>
[PHP] pobierz, plaintext 

Chodzi mi o to, że najwyższy już czas przedstawiać użytkownikom nowoczesne rozwiązania problemów. Funkcje mysql_* siedzą w pehapie już od przeszło dziesięciu lat. Doczekały się następców, nieobarczonych charakterystycznymi dla nich problemami (ręczne zabezpieczanie przed sql injection, błędy zamiast wyjątków, itd.). Ale pomimo to są w 90% przypadków przedstawiane jako podstawowe rozwiązanie problemu wykorzystania baz danych w php.
Co ciekawe gdy ludzie zadają na stackoverflow pytania odnośnie C#, nie dostają odpowiedzi z stylu "hmm... nie podałeś wersji .NET pod którą piszesz, więc na wszelki wypadek podam ci rozwiązanie dla .NET 1.1 z 2001 roku". Nie, zamiast tego piszą "W .NET 4.0 możesz bardzo łatwo zrobić to przy użyciu XXX oraz YYY (...)". Dzięki temu wiesz jak rozwiązać problem, lub szukasz odpowiedników XXX i YYY dla starszej wersji .NET.
Więc zgadzam się ze wszystkim o czym mówisz, oprócz:

Programista wielokrotnie musi grzebać w czyimś kodzie, który "pierwszej świeżości" być nie musi

Otóż świeży kod, datowany na 2011 rok, również jest pisany przy użyciu mysql_* i zabezpieczany ręcznie przy użyciu mysql_real_escape_string, co nie zawsze się młodym programistom udaje, przykład:

[PHP] pobierz, plaintext 
mysql_query( "SELECT * FROM users WHERE id = " . mysql_real_escape_string( $_GET["id"] ) );
// albo
mssql_query( "SELECT * FROM users WHERE username = '" . addslashes( $_GET["name"] ) . "'" );
[PHP] pobierz, plaintext 

Dlatego ja nadal obstaję przy swoim i uważam, że aby pisać kod zabezpieczony przed SQL Injection, należy korzystać z prepared statements. A gdy już na prawdę nie ma innej możliwości, to wtedy czytamy o addslashes, magic_quotes, mysql_real_escape_string, rzutowaniu na typy liczbowe, itd. Może dzięki temu kilku początkujących zacznie pisać swoje pierwsze zapytania od razu w PDO.