GoldenLine
Zaloguj się
Michał Stachura

Michał Stachura Dedykowane serwisy i
strony www -
http://santri.eu

Temat: Zabezpieczenie przed SQL Injection

Witam,

Jakie zabezpieczenie przed SQL Injection stosujecie?

Czy PDO::prepare wg Was wystarczy?Michał Stachura edytował(a) ten post dnia 05.11.09 o godzinie 22:10
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

procedury po stronie sql-a i wspomniane prepare
lub ORM -> doctrine / propel wedle uznania
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

wszystko zalezy od tego z jakiego narzedzia korzystasz :-)

duzo informacji na temat bezpieczenstwa webaplikacji znajdziesz tutaj:

http://www.owasp.org/
Link do wypowiedziLink
Michał Stachura

Michał Stachura Dedykowane serwisy i
strony www -
http://santri.eu

Temat: Zabezpieczenie przed SQL Injection

Zastanawiam się czy oprócz PDO::prepare stosować jeszcze addslasze i inne tego typu funkcje.
W zasadzie nie udało mi się znaleźć informacji czy jest sens?
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

Michał Stachura:
Zastanawiam się czy oprócz PDO::prepare stosować jeszcze addslasze i inne tego typu funkcje.
W zasadzie nie udało mi się znaleźć informacji czy jest sens?

1. forsować typ jakiego się spodziewasz (uint - przepuszczasz tylko cyfry, imię czy nazwisko - wywalasz nie-litery, itd)

2. wywalać z łańcuchów separatorki i cudzysłowia - tam gdzie to możliwe.

3. (w ekstremalnych przypadkach) wywalasz błąd jeśli znajdziesz w zmiennej słowo kluczowe SQL. (nikt nie będzie miał na imię "DELETE" lub "DROP").

SQL injection to produkt uboczny tego, że PHP akceptuje dowolne wartości w zmiennych i zwykle działa na SQL-ach dynamicznych.
Link do wypowiedziLink
Piotr Borek

Piotr Borek CTO w Let's Deliver
Sp. z o.o.

Temat: Zabezpieczenie przed SQL Injection

Michał Stachura:
Zastanawiam się czy oprócz PDO::prepare stosować jeszcze addslasze i inne tego typu funkcje.
W zasadzie nie udało mi się znaleźć informacji czy jest sens?

Jeśli używasz PDO, to używaj tylko wbudowanych w bibliotekę narzędzi do zapewnienia bezpieczeństwa SQL. Chodzi o to, że użycie kilku metod do zabezpieczenia powoduje, że każda traktuje wynik poprzedniej metody jako dane, które mają być zapisane.

Dodatkowo, jest jeszcze kwestia magic_quotes i innych dziwnych rozwiązań w konfiguracji php, które miały zwolnić programistę od myślenia, ale ostatecznie tylko utrudniają życie :)

Obecnie mam adres, który w nazwie ulicy ma apostrof i w wielu sklepach internetowych zapisuje się on z dużą ilością backslashy, właśnie dlatego, że ktoś źle zrozumiał ideę bezpieczeństwa, a poza tym - nie przetestował swego rozwiązania dla przypadków szczególnych.
Link do wypowiedziLink
Stanisław P.

Stanisław P. Software designer

Temat: Zabezpieczenie przed SQL Injection

Piotr Likus:
2. wywalać z łańcuchów separatorki i cudzysłowia - tam gdzie to możliwe.
NIEEEEEEeeeeee!
3. (w ekstremalnych przypadkach) wywalasz błąd jeśli znajdziesz w zmiennej słowo kluczowe SQL. (nikt nie będzie miał na imię "DELETE" lub "DROP").
NIEEEeeeeeee! :)

Proszę - nigdy tego nie róbcie na stronach. Później ktoś np. chce napisać komentarz zawierający SQL'a i ma problem :/ #2 i #3 przed niczym nikogo nie obronią. Dlaczego?
Jeśli wiesz, że o jakąś zmienną trzeba zadbać, to po prostu przepuszczasz ją przez funkcję escape'ującą. Jeśli zastosujesz #2, albo #3, to znaczy, że już wiesz, że ta zmienna idzie do sql'a - więc czemu nie zrobić tego poprawnie od razu? Jeśli zrobisz błąd i rzeczywiście zapomnisz przecież zapomnisz zastosować wszystkich metod... Nie wyobrażam sobie żeby ktoś przefiltrował dane szukając kawałków sql'a a potem nie escape'ował całego stringa.
Link do wypowiedziLink
Michał Jarosz

Michał Jarosz Frontend Developer &
Team Leader

Temat: Zabezpieczenie przed SQL Injection

Jak tak się boisz DROPa to po prostu zabierz uprawnienia użytkownikowi, przez którego łączy się aplikacja. Rzadko która potrzebuje coś więcej niż INSERT,SELECT,UPDATE,DELETE i EXECUTE
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

Michał Jarosz:
Jak tak się boisz DROPa to po prostu zabierz uprawnienia użytkownikowi, przez którego łączy się aplikacja. Rzadko która potrzebuje coś więcej niż INSERT,SELECT,UPDATE,DELETE i EXECUTE

NIE, tak nie da rady.
Dlatego że nie ma "bezpiecznego zbioru komend".

SELECT - "SELECT INTO", "select nieswoje-dane"
"DELETE", "UPDATE", "INSERT" - każdy tego potrzebuje, nawet "gość"

Ktoś takie uprawnienia stosuje na WWW, w praktyce? Ja stosuje to co wspomniałeś - blokadę DROP-a itd - ale to chyba stanowczo za mało?Piotr L. edytował(a) ten post dnia 25.10.11 o godzinie 21:04
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

Piotr Likus:
Michał Jarosz:
Jak tak się boisz DROPa to po prostu zabierz uprawnienia użytkownikowi, przez którego łączy się aplikacja. Rzadko która potrzebuje coś więcej niż INSERT,SELECT,UPDATE,DELETE i EXECUTE

NIE, tak nie da rady.
Dlatego że nie ma "bezpiecznego zbioru komend".

EXECUTE / CALL - w zależności od wersji silnika - pełna kontrola
Link do wypowiedziLink
Michał Stachura

Michał Stachura Dedykowane serwisy i
strony www -
http://santri.eu

Temat: Zabezpieczenie przed SQL Injection

Widzę, że dość trudno określić co dokładnie należy robić ze zmienną przed powiedzmy dodaniem jej do bazy. I chyba nie wynika to z różnego poziomu wiedzy uczestników dyskusji ale raczej z ich własnego doświadczenia.

Może na przykładzie będzie będzie łatwiej zrozumieć. Przypuśćmy, że mamy standardowy zwykły formularz przesyłający jedną informację wprowadzaną przez użytkownika w polu <textarea> czyli bez żadnych ograniczeń można wpisać co się chce.
Co należałoby zrobić z ta zmienną przed dodaniem jej do bazy.

Bazując na mojej obecnej wiedzy zrobiłbym to tak:
$query = $db->prepare('INSERT INTO baza_danych VALUES(':zmienna')');

$zmienna = addslashes($_POST['zmienna']);

$data['zmienna'] = $zmienna;

$query->execute($data);

I to tyle. Zastanawiam się czy w przypadku użycia PDO::prepare używanie addslashes nie jest zbytnim dmuchaniem na zimne?

P.S. Nie zwracajcie uwagi jeśli są błędy w składni, pisałem z głowy a nie o to tu chodzi :)Michał Stachura edytował(a) ten post dnia 14.11.09 o godzinie 20:20
Link do wypowiedziLink
Wojciech Małota

Wojciech Małota Programista

Temat: Zabezpieczenie przed SQL Injection

Tak będzie bardziej "jazzy":

$query = $db->prepare('INSERT INTO baza_danych VALUES(:zmienna)');

$query->bindParam(':zmienna', $zmienna, PDO::PARAM_STR);

$query->execute();


W zupełności wystarczające i bezpieczne.Wojciech Małota edytował(a) ten post dnia 14.11.09 o godzinie 20:26
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

Michał Stachura:
I to tyle. Zastanawiam się czy w przypadku użycia PDO::prepare używanie addslashes nie jest zbytnim dmuchaniem na zimne?

Na twoje pytanie odpowiedź znajduje się na wspomnianym OWASP:

http://www.owasp.org/index.php/PHP_Top_5


addslashes() should be deprecated - it does not protect against SQL injections
Link do wypowiedziLink
Michał Stachura

Michał Stachura Dedykowane serwisy i
strony www -
http://santri.eu

Temat: Zabezpieczenie przed SQL Injection

Piotr Likus:
Michał Stachura:
I to tyle. Zastanawiam się czy w przypadku użycia PDO::prepare używanie addslashes nie jest zbytnim dmuchaniem na zimne?

Na twoje pytanie odpowiedź znajduje się na wspomnianym OWASP:

http://www.owasp.org/index.php/PHP_Top_5


addslashes() should be deprecated - it does not protect against SQL injections
Żona mi cały czas powtarza: "czytaj wszystko dokładnie...".
Dzięki Piotrek.
Link do wypowiedziLink
Michał Jarosz

Michał Jarosz Frontend Developer &
Team Leader

Temat: Zabezpieczenie przed SQL Injection

Piotr Likus:

Ja stosuje to co wspomniałeś - blokadę DROP-a itd - ale to chyba stanowczo za mało?

Oczywiście, że za mało - niemniej w 100% zabezpiecza przed DROP, ALTER itd, a nic nie kosztuje ;) . Podstawa to zapytania przygotowane i poprawne escapowanie (jak to będzie po polsku?) danych wstawianych do kwerend. Usuwanie komend SQL uważam za przesadę.

Najbardziej hardcore wersja, to oczywiście to co sugeruje Przemek Rachwał, czyli przeniesienie wszystkich kwerend do procedu składowanych i przydzielenie użytkownikowi uprawnień tylko do ich wywoływania.Michał Jarosz edytował(a) ten post dnia 14.11.09 o godzinie 23:32
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

Michał Jarosz:
Najbardziej hardcore wersja, to oczywiście to co sugeruje Przemek Rachwał, czyli przeniesienie wszystkich kwerend do procedu składowanych i przydzielenie użytkownikowi uprawnień tylko do ich wywoływania.

To rzeczywiście byłoby najbezpieczniejsze, tylko jest to dodatkowa , całkiem spora praca podyktowana tylko bezpieczeństwem. Zmniejsza też elastyczność kontaktu strona-baza.
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

z tą elastycznością to nie jest tak
zapodaję powiedzmy dwa parametry na wejście, procedura mieli sobie coś tam i wypluwa wynik
w międzyczasie zmienia się struktura bazy danych, Ja chwilę myślę i zmieniam zawartość procedury w taki sposób że nadal podaję dwa parametry a wykonuje się zupełnie coś innego, a wynik jest dokładnie taki sam - zero modyfikacji aplikacji - wiec to zależy od wielu czynników

w podejściu klasycznym zeka nas żmudne poprawianie SQL-i wklejanych do poziomu PHP co nie jest ani fajne ani szybkie bo i tak trzeba sobie te zapytania w czymś wyklikać

ale jak wiadomo o gustach się nie dyskutuje
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

jesli chodzi o MySQL, to stosuje prawie zawsze mysql_real_escape_string(). prosto i skutecznie.

look @ this: http://www.php.net/manual/en/function.mysql-real-escap...Kuba Świegot edytował(a) ten post dnia 16.11.09 o godzinie 00:30
Link do wypowiedziLink

konto usunięte

Temat: Zabezpieczenie przed SQL Injection

Trzeba wziąć pod uwagę, że mysql_real_escape_string() miało błędy:

http://www.linux.com/archive/articles/54798

@Przemek: to samo możesz osiągnąć na poziomie PHP-a.
Wtedy zamiast "mysql_select" robisz w kodzie "getCustomerOrders()".
Link do wypowiedziLink
Michał Jarosz

Michał Jarosz Frontend Developer &
Team Leader

Temat: Zabezpieczenie przed SQL Injection

Piotr Likus:
>
@Przemek: to samo możesz osiągnąć na poziomie PHP-a.
Wtedy zamiast "mysql_select" robisz w kodzie "getCustomerOrders()".

No nie jest to do końca to samo. W przypadku procedur składowanych, zapytania przechowywane są w postaci skompilowanej i nijak nie wstawisz do nich własnego SQL.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Zabezpieczenie formularza p...




Wyślij zaproszenie do
Anuluj