Puszczenie całego zapytania przez mysql_real_escape_string "zniszczy" go, przykładowo:

Przed:

[SQL] pobierz, plaintext 
SELECT * FROM tabela WHERE pole = 'moje extra p'ole'' AND inne_pole = 'inne'pole';
[SQL] pobierz, plaintext 

Po:
Po użyciu mysql_real_escape_string:

[SQL] pobierz, plaintext 
SELECT * FROM tabela WHERE pole = \'moje extra p\'ole\'\' AND inne_pole = \'inne\'pole\';
[SQL] pobierz, plaintext 

Kolega wyżej dobrze radzi, tym bardziej że aktualnie funkcje mysql_ są już deprecated

o ile dobrze pamiętam to podstawówkę zaczyna się właśnie od... intval, a mysql_real_escape_string() raczej wpływ na szeroko pojętą kompatybilność niż zabezpieczanie przez atakami.




No i ja się dołączam do pytania, nie wiem po co zabezpieczać dane które wyświetlam więc tu proszę o jakieś uzasadnienie. Zawsze wydawało mi się że najważniejsze są dane wprowadzane do bazy czy też odbierane od użytkownika. Zwalanie wszystkie na PDO raczej nie załatwia tematu i nie zabezpiecza z samego tytułu jego używania. Inni może wolą inne rozwiązania albo chcą po prostu wiedzieć.

Do bazy jak wkładasz to zabezpieczeasz przed sqlinjection.

Podczas wyświetlania zaś bronisz się np. przed XSS. Dlatego do bazy nie wkłada się danych przepuszczanych przez htmlspecialchars. Tę funkcję używa się dopiero przed wyświetlaniem

Nie znam się za bardzo na atakach (inaczej bym pewno nie pytał) ale irracjonalne jest trochę filtrowanie danych wyświetlanych. Z prostej przyczyny są tylko wyświetlane i nigdzie nie są zapisywane. Z tego co przeczytałem o XSS to też biega o zapis...

1) Proszę nie mieszaj już w tym wątku o XSS. To jest wątek o SQLInjection
2) I tak i nie. Owszem, trzeba filtrować np. komentarz by ktoś nie zrobił ataku xss, ale to nie polega na htmlspiecialchars do wkladania do bazy. A htmlspecialchars przed wyswietleniem używa się profilaktycznie, jakbyś źle dofiltrował dane od usera. Ale koniec już na ten temat w tym wątku

Da się jakoś w postgresql wydobyć wszystkie nazwy kolumn w danej tabeli? O ile w MySQL mamy podatność sql injection, to nie jest to żaden problem, o tyle w postgresql tabele jeszcze można przejrzeć, ale już z nazwami kolumn lipa. Żadnego information_schema ni widu, ni słychu ;/

http://stackoverflow.com/questions/109325/...-describe-table

Co do MySQL...

Sterownik mysql już w roku 2009 był uważany za "powrót do przeszłości". Jeśli chodzi o silnik MySQL, to SQL Injection jest raczej problemem dla żółtodziobów, którzy uczą się PHP oraz MySQL z samouczków napisanych w czasach, kiedy na Ziemi ludzie żyli z dinozaurami (okazuje się, że znaleziono kilkukrotnie ludzkie szczątki obok szczątek dinozaurów).

Wiadomo, że programista z powołania szybko dojdzie do tego, że mysql to już staroć (wystarczy pierwsza lepsza aktualna książka), ale młokosi będą się męczyć z tutorialami i problemami, które już dawno zostały rozwiązane. A z tego powodu, że młokosami i klepaczami kodu nikt się nie martwi, to będą dalej trwać w Ciemnogrodzie i nikt ich za szybko o niczym nie uświadomi - choć z drugiej strony to dobrze, bo wcześniej przejdą selekcję przydatności do zawodu. *wink*

W końcu jeśli ktoś w tym fachu nie potrafi samemu zadbać o to, aby wiedzieć co jest up-to-date, wtedy będzie z niego dupa a nie programista.

@Dejmien_85, gadasz o młokosach, a sam z siebie jednego zrobiłeś.

Tak czy inaczej pozdrawiam.

@pyro, nie wnikam w Twoje prywatne wierzenia. Skoro zaprzeczasz temu, że pewne problemy rozszerzenia mysql zostały rozwiązane przez jego następców (mysqli, PDO) i dodatkowo nazywasz mnie młokosem za takie stwierdzenie, wtedy ofiarować mogę Tobie jedynie krzyrzyk na drogę.

Problem SQL Injection jest mocno zredukowany, gdy używa się mysqli/PDO, ejmen.

Powiem Ci jedynie tak: Istnieje mnóstwo podatnych na SQL Injection skryptów, mimo że używają wyłącznie mysqli / PDO. Z tydzień temu znalazłem nawet w [ciach, może jednak lepiej nie mówić], najnowszej wersji, gdzie nie ma ani jednego użycia sterownika mysql i na pierwszy rzut oka tego nie widać. Nawet przy ORMach też się można włamywać, bo czasem trzeba użyć Native Query przy bardzo skomplikowanych zapytaniach.



Nawet nie użyłem tego słowa, sam zacząłeś .

To nie jest remedium na całe zło, liczy się myśląca głowa przede wszystkim. Zauważ też, że ryzyko zredukowane nie oznacza, że go nie ma.

pedro84 dokładnie, ale jak widać niektórym się wydaje, że jak użyją PDO/mysqli to już o nic się nie muszą wgl martwić.
Dejmien_85 To wszytko zależy od tego jak to oprogramujemy, owszem PDO może ten proces ułatwia, ale już nie raz ludzie przychodzili tu na forum i dawali do oceny strony gdzie na starcie było SQL Injection mimo iż wcale nie używali mysql_*

Panowie, spokojnie, nikt tutaj nie chce nikomu krzywdy zrobić. ; )

Problem SQL Injection oczywiście istnieje i zawsze będzie istniał, jednak przy użyciu sterowników mysqli czy PDO podchodzi się do niego inaczej - aplikację jest po prostu łatwiej i szybciej zabezpieczyć.

Oczywiście nie ma problemu, aby bazę danych dobrze zabezpieczyć przy korzystaniu z DB z użyciem rozszerzenia mysql, jednak pojawia się pytanie: "Czemu mam jeździć starym autem, skoro w garażu stoi nowe?".

Nie będę także zaprzeczał starego powiedzenia: "o gustach się nie dyskutuje". Jedni wolą nowe auta, inni stare. W sumie ich działanie jest podobne - auto ma dojechać do punktu B z punktu A. Wszystkie rozszerzenia jadą, tylko troszkę inaczej.

Wybierajmy swoje typy, cieszy się jazdą - w końcu o to chodzi. Ale weźmy także pod uwagę to, że w świecie IT wszystko idzie do przodu i to co dzisiaj jest na topie za kilka lat zostanie czymś zastąpione. Nieustanny rozwój czasem jest męczący - jednak w przypadku naszej branży niestety jest konieczny.

Uczmy się, wyciągajmy wnioski, żyjmy w zgodzie - peace and love. Na zakończenie jeszcze zapraszam wszystkich na koncert słitaśnej muzyki, niech nas pogodzi!

http://www.youtube.com/embed/0gEVaniPOmU?rel=0

Przysięgam, że dużo nie piłem.

Tu nie chodzi o gusta, bo sterownik mysql to jest przeżytek bez wątpienia.

Chodzi o to, że z punktu widzenia SQL Injection np. PDO jest taką samą gwarancją bezpieczeństwa jak jogurt naturalny jest gwarancją zwycięzkich walk wojowniczki Xeny.

Pyro, Ty nam tutaj Xeny nie mieszaj do SQL Injection.

Wszystko zostało już powiedziane:
1) Stopień zabezpieczenia zależy od programisty - dokładnie jego wiedzy i stopnia lenistwa (nie od sterownika).
2) PDO/mysqli niweluje pewne ataki (jednak ich nie eliminuje w 100%).

Użycie PDO/mysqli powoduje, że pewne rzeczy mamy z głowy (ex-problemy mysql) i nie musimy się nimi przejmować (i to napisałem gdzieś tam wyżej w pierwszym poście).

Także proponuję zakończyć ten temat przy zimnym browarku (póki jeszcze ciepło jest). No chyba, że się zbroisz, wtedy...

@Dejmien, dla Pyro chodzi zapewne o to, ze ktos moze uzywac PDO ale zapytania pisac normalnie, bez bindowania wartosci. Wowczas te PDO na nic sie zdaje. A uwierz, tu na forum była cała masa osob, ktore tak wlasnie robily. Niektore nawet sprzedawaly swoje skrypty jako super hiper a w kodzie kwiatki takie kwiatki:

$pdo->query("select ..... from...... where pole='{$_POST['zmiennazforma']}' ");

Wiec podsumujmy: tak, PDO rozwiazuje zdecydowanie wiekszosc problemow ale pod warunkiem, ze wiemy jak z niego korzystac. Bo samo jego zastosowanie a robienie rzeczy jak kod powyzej, da nam gu......zik

Niweluje? Dobre żarty. Wystarczy jeden klepacz, który nie użyje parametryzowanego zapytania i cała Twoja teoria leży. PDO jest wygodniejsze, nowocześniejsze i powinno się go używać już na samym początku, ale pisanie, że samo użycie PDO rozwiązuje problem wstrzyknięć jest sporą bzdurą.

PS. Poczytaj: http://stackoverflow.com/questions/134099/...t-sql-injection

Ech, posiadam chyba zbyt wielką wiarę w ludzi.

Gdy wsiadam do auta, to zawsze zapinam pasy - niektórzy jednak widzą w nich tylko kawałek wiszącego materiału, albo w ogóle ich nie zauważają. Rozsądny programista wie do czego służy PDO i tego się trzymam.

Ale rację macie, czasem trzeba wytknąć rzeczy oczywiste - dla niektórych ludzi nie są one tak oczywiste. Z tego też powodu moje wcześniejsze wypowiedzi należy zmodyfikować - PDO/mysqli niwelują... jednak póki są odpowiednio wykorzystane.

Poza tym, chyba wiem w czym problem - w dziale książek ktoś kiedyś napisał, że nie warto czytać książek, ponieważ wszystko można znaleźć w internecie - i tu się zaczynają problemy.

1. Aby się zabezpieczyć na 100% przed usunięciem tabeli najlpeszym rozwiązaniem jest dodanie nowego użytkownika z ograniczonymi uprawnieniami globalnymi.
2. Zaminast dokładać linijek kodu PHP aby przefiltować GET można użyć htaccess, wtajemniczeni wiedzą, że oprócz przyjaznych linków ( np. zamiast ?user=12 można zrobić user-12 ) istnieje możliwość przefiltrowania tekstu np. tylko liczby, tylko duże litery, itp.

O żesz Ty hakerze... To jakaś tajemna wiedza tylko i wyłącznie dla wtajemniczonych, czy podzielisz się nią z innymi?