Słuchajcie, jakich funkcji używacie do zabezpieczenia danych z formularzy? I w jakiej kolejności? Dla np. danych, które powinny być liczbami stosuję coś w tym stylu:

[PHP] pobierz, plaintext 
$int = intval(strip_tags(mysql_real_escape_string($_POST['int'])));
[PHP] pobierz, plaintext 

Interesuje mnie kolejność wykonywania tych funkcji. Są jakieś reguły, czy jest to bez różnicy czy najpierw strip_tags, potem mysql_real_escape_string itd. ?

To co masz jest taką głupotą, że nie jestem w stanie zrozumieć nawet IDEI twojego podejścia...

[PHP] pobierz, plaintext 
$int = $_POST['int']
[PHP] pobierz, plaintext 

Oczywiście po uprzednim sprawdzeniu czy taka wartość w poście istnieje

To może pokaż, doktorze House, jak sam zabezpieczasz swoje skrypty przed SQL injection i ingerencją w html poprzez formularze. A jak nie jesteś w stanie ogarnąć tej idei to daruj sobie sarkazm bo oczekuje tutaj rady a nie słownych przepychanek.

Nie szkoda Wam wieczoru na spięcia?

Jeśli oczekiwana wartość jest liczbą całkowitą, walnij rzutowanie:

[PHP] pobierz, plaintext 
$sprawdzona = (int)$_POST[liczba];
[PHP] pobierz, plaintext 

i masz problem SQL injection z głowy.

Ok, intval lub rzutowanie dla liczb to rozumiem. Ale co jeśli to ma być string? Czego radzisz użyć oprócz/zamiast powyższych? Bo skoro używanie strip_tags czy mysql_real_escape_string jest czarną magią dla opiekuna to już nie wiem.

Tak ciężko?
Temat: Bezpieczenstwo skryptow PHP
Temat: SQL Injection Insertion

mysql_real_escape_string() wystarczy Ci w zupełności.

Wiem Panowie, jestem zaznajomiony (w miarę) z tematem. Bardziej mi chodziło o to czy robi to jakąś różnicę w zależności od tego którą funkcję zastosujemy przed którą. Czyli dla przykładu czy zaleca się stosowanie jakiejś ustalonej kolejności, np. najpierw real_escape a potem inne, czyszczące z tagów czy na odwrót, czy jak?

Świetnie pytanie!
Osobiście bardzo wiele czasu spędziłem nad uporządkowaniem walidacji w taki sposób aby było

1. przede wszystkim bezpiecznie
2. czytelnie
3. wydajnie

walka między punkem 2 i 3 o priorytet trwa do dziś

Wstępna walidacja wygląda u mnie następująco

nie pusty string:

[PHP] pobierz, plaintext 
if ( ! isset($_POST['string']) OR ! is_string($_POST['string']) OR 0 === strlen($string = trim($_POST['string']))) {
  return false;
}
[PHP] pobierz, plaintext 

na tym kończy się moja walidacja..
tagów html nie stripuje przed dodaniem do bazy, nie widze potrzeby..
a sql_escape_string robi dla mnie bibliteka obsługująca baze danych (active records)

Jak dla mnie wyrażenia regularne spełniają wszelkie wymogi jeśli chodzi o drobne stringi oraz liczby... Dobrze obmyślana struktura wyrażeń regularnych jest po prostu nie do ominięcia. Z wyjątkami gdzie stosowane są nawiasy bądź inne znaki specjalne a wtedy już wystarczy mysql_real_escape_string() .

Jeśli chodzi o wydajność? Nie odczułem by jakikolwiek skrypt nawet przy wypełnianiu formularza o wartości 14-18 rekordów przy każdorazowym sprawdzaniu wyrażeń regularnych ucierpiał. różnica jakichś 0,0005s lub różnica jednego zera więcej...
A to co napisałeś poniżej

[PHP] pobierz, plaintext 
      $int = intval(strip_tags(mysql_real_escape_string($_POST['int'])));
[PHP] pobierz, plaintext 

To konkretna bzdura wyssana z palca gdzie brak wiedzy o zabezpieczeniach przerósł aspiracje

Wyrażenia regularne cechuje mniejsza czytelnośc oraz mniejsza wydajność..
więc u mnie przegrywają na całej linii
Oczywiście pojedyńcze wyrażenie będzie prawie na pewno szybsze od wywołania szeregu funkcji walidujących.
Osobiście wyrażenia regularne stosuje dopiero przy wnikliwej walidacji danych takich jak np. poprawność adresu email czy numeru konta bankowego.
Nigdy nie do walidacji np. inta.....

Za każdym razem jak słysze "oh, to przyśpieszy Twój skrypt tylko o 0,0002 sek" chce mi się płakać...
Takie argumentowanie jest bez sensu!
Prawidłowa odpowiedź brzmi: Jedno rozwiązanie jest 2x 4x 8x szybsze od innego.
I tyle, nie żadne 0,000005 sek, bo to totalnie nic nie mówi o wydajności.

Mniejsza czytelność? heh nauka wyrażeń to jakieś 1-5h maks z pełnymi ich możliwościami... Jeżeli chodzi o czytelność... Jak już znasz składnie i możliwości to takie wyrażenia więcej mówią niż 5 funkcji zabezpieczających i do tego usuwających wszelkie niepowołane znaki na bezpieczne. Po drugie dzięki wyrażeniom regularnym (oraz javascript i ajax) możesz otrzymać bardzo interaktywne formularze po stronie klienta... A moje oznaczenie odnośnie wydajności to tylko wzmianka iż nie ma ono żadnego znaczenia przy nie stosowaniu i stosowaniu wyrażeń... No ale lenistwo to lenistwo... Każdy orze jak może i umie

Pozostanę przy swoim jeśli chodzi o czytelność.
Czytając kod zawierający dużą ilość wyrażeń regularnych musisz poświęcić więcej czasu na zrozumienie całośc, dla mnie koszmar!
Stosując proste funkcje takie jak isset() is_int() is_numeric() is_bool() is_scalar(), ten problem nie występuje, rzucasz okiem i już wiesz co robi skrypt..

Dodatkowo nie wygłupisz się pisząć nieoptymalne wyrażenie powodujące przykładowo wiele tysięcy wycofań przy dopasowaniu co ubije wydajność, o podobne błędy jest łatwo...

Nauka wyrażeń regularnych z pewnością zajmie duużo więcej czasu niż kilka godzin.
Wysuwając podobne stwierdzenia ośmieszasz się i dajesz świadectwo swojej głębokiej niewiedzy.
U mnie na półeczce stoi sobie kilka książek na ten temat.
W kilka godzin możesz conajwyżej opanować podstawy...

Istnieje też potencjalne ryzyko bezpieczeństwa, konkretnie chodzi mi o modyfikator /e.
I jeszcze raz ta czytelność, elegancja kodu na punkcie której jestem absolutnym maniakiem dla mnie kod poprzecinany wyrażeniami jest po prostu paskudnie brzydki..

Podsumowijąc, wyrażenia regularne to potężne i często niezastąpione narzędzie.
Jednak nie znam racjonalnego powodu aby stosować je przy podstawowej walidacji.

I tak jak pisałem... Zajęło mi to maks 5h... Jakoś nie wyobrażam sobie by siedzieć przy nich dłużej. Wyrażenia regularne mają dość istotny cel... Ale co do reszty Twojej wypowiedzi to sugeruje że nawet nie spojrzałeś w specyfikację wyrażeń. Widzisz ty stosujesz 5 funkcji których dobieranie może być uciążliwe a dzięki wyrażeniom mam możliwość napisania jednej uniwersalnej funkcji która wykona mi za jednym razem 1-20 sprawdzeń... fakt może zajmie z linijkę lub dwie ale efekt jest nieziemski i mogę sobie odpuścić prócz mysql_real_escape_string()( dla pełnej pewności) inne funkcje. Tak zwany modyfikator /e jest najgłupszą i najprostszą sprawą do ominięcia ale to już zapraszam do lektury o wyrażeniach bo wcześniej czy później będziesz musiał ten "koszmar" przejść . A co do podstawowej walidacji będziesz używał tych wszystkich funkcji ? Wystarczy wymieniona przeze mnie tutaj Na tym skończyłbym temat bo o elegancji kodu i samej estetyki pisania nie będę pisał... Piszę jak piszę i mam (z tego co widzę u innych) bardzo wygórowane wymogi odnośnie estetyki pisania. Samo wyrażenie można tak napisać że człowiek staje się dumny iż stworzył coś swojego, profesjonalnego tylko na swoje potrzeby. Ale to moje zdanie. Dobranoc

Ps. Takie rozmowy są dobre bo chociaż można poczytać różne opinie, a jak pisałem każdy ustala sobie standard i rodzaj programowania. Nie można narzucać komuś swoich ideałów bo do tego zawodu łatwo się zrazić

Cóż, powstrzymam się od komentarza..

Może tylko..

"You're talkin' a lot, but you're not sayin' anything."

:-]

A propos kolejności: ktoś ostatnio na tym forum mnie upomniał, żeby mysql_real_escape_string() rzucać zawsze na lewą stronę jako coś, po czym już nie będzie się grzebać innymi funkcjami, bo z tego mogą być problemy - przy czym tak jak mówię - "gdzieś tu zasłyszałem" i nie wiem czemu i po co

Wyrażenia regularne to powinny być tylko do walidacji bardziej zaawansowanej. Do prostych takie funkcje jak ctype_* is_* czy rzutowanie lub konwersje, intval w zupełności wystarczą. Strzelać armatą do muchy chcesz? Jak już wspomniano, wyrażenia to duży narzut wydajnościowy i ma sens tylko przy już bardziej złożonych operacjach zamiany czy rozpoznawania wzorca.

Mysql_real_escape_string powinna być tuż przed posłaniem do bazy, bo przygotowuje zmienną już do przechowania zabezpieczając ją zgodnie z ustawieniami bazy danych. Jeśli potem zaczniesz coś grzebać, to możesz znaki ucieczki choćby niechcący wywalić i zmienna staje się potencjalnie niebezpieczna.

Co do wyrażeń to w kilka godzin nauczysz się jedynie podstaw teoretycznych, ale gdy przyjdzie co do czego to polegniesz. Sam często się nad jakimś głowię jak ugryźć i nieraz bez posłużenia ciągiem kilku wyrażeń regularnych nie da rady. Ale to już najczęściej mocno nietypowe parsery pod konkretne działania.

Resztę już omówiłem Jedyne co mnie szokuje to że wyrażeni regularne sprawiają Ci taki problem... Fakt przez piewszą godzinę z książką o nich nie mogłem dobrze poskładać ale zrobiłem koło 30 takich wyrażeń to po chwili składałem już sobie linki które jak byś nie chciał musiały mieć takie wartości jak chciałem i żadnych dodatkowych info. Podstawy? Jakoś piszę po tych 5h spędzonych tylko na to dość zaawansowane wyrażenia jak pisałem wyżej i nie mam zamiaru więcej tego poruszać. Gila mnie to że tak powiem iż w to nie wierzysz... Co do funkcji mysql to jest racja nic po niej nie powinno być... w końcu sama nazwa funkcji znaczy że jest to escape_string ... czyli wychodzący (wyjściowy) ciąg znaków...

W takim razie musisz mieć z bardzo prostymi pod względem wzorca ciągami do czynienia. Ja choćbym się wysilał dostaję tak losowe ciągi do obróbki, że żaden wzorzec pojedynczy ich nie obejmie, nieważne z jakimi flagami, nieważne jak "cudowny". Składanie linków to po prostu śmiech na sali i zadanie na chwilę. Tyle ile trwa wymyślenie wzorca do linku, tyle moje parsery pracują by wszystkie dane przemielić.A i tak zanim dojda do etapu wyrażeń muszą być jeszcze wstępnie przetworzone, bo bez tego już byłby Armageddon. Teraz też mam właśnie zabawę z regexami. Router konwertujący stare url na nowe jako 301. Ile mi to zajmie? 5-10 minut włącznie z napisaniem kodu w czystym php? Znajomość regexpów to może i jest po 5 godzinach ale dobra ich znajomość to już o wiele dłuższy czas. Ja też mogę się chwalić bo regexpy zakumałem w mniej niż godzinę w ogromnym stopniu i co? A i tak są rzeczy, których ugryzienie nimi jest po prostu ciężkie i nawet najzmyślniejsze wyrażenie nie da rady, ponieważ uciekają one schematom popularnym i spotykanym powszechnie w necie.

Podam Ci prosty przykład takiego, którego pojedynczym nie ugryziesz. Określenie na podstawie jednego stringa czy użytkownik podał Ci w polu input typu text jako miejscowość faktycznie ją czy jakieś kombinacje typu: "Rurki koło Wąchocka" i to obrobić tak, by w bazie mieć to opisane jako Miejscowość: Rurki, Miejscowość sąsiednia: Wąchock i oczywiście całość ma być fleksyjnie poprawna. Załatw to jednym wyrażeniem "ekspercie od regexpów w 5h" Tutaj bez conajmniej kilkunastu preg_replaców nawet nie ma co podchodzić do tematu, bo każdy będzie się zajmował zupełnie innymi składowymi zadania. Są tematy, których nie przeskoczysz, nawet będąc mistrzem regexpów.

Dlatego wypowiadanie się z taką pewnością, że coś jest świetne i dziwne, że sprawia mi problem jest właśnie abstrakcją z Twojej strony. Skąd bowiem wiesz z jakimi problemami musiały u mnie regexpy się zmagać? Przykład powyżej choć prosty wystarczająco jasno pokazuje o co mi chodzi. Składanie linków a analiza tekstu z jego dzieleniem i poprawianiem pod kątem fleksyjnym to dwie zupełnie inne bajki. Tutaj musisz znać świetnie gramatykę języka dodatkowo by wiedzieć jak napisać i kiedy odpalić dane wyrażenie. Nadal chcesz się spierać, czy w końcu może przyznasz, że wyskoczyłeś trochę jak Filip z konopii? Regexpy są fajne, ale trzeba też wiedzieć kiedy je stosować i czy ma to sens, a pełna znajomość to więcej niż kilka godzin z dokumentacją.

Mam pytanko, jeśli ktoś używa Postgresql to czym można zastąpić funkcje mysql_real_escape_string?

@rasten: Jest 2011: PDO

Co do tych wyrażeń... się już tak nie podniecajcie. Wyrażenia pozwalają wyłącznie na sprawdzenie czy dany tekst pasuje do jakiegoś wzorca, co jest z reguły jedynie jednym z kilku kryteriów przy walidacji danych.

Dodać jeszcze do ctype_ można filter_var - unikniemy stosowania wyrażeń regularnych w niektórych przypadkach.

@fifi209: tylko jeśli ktoś ma php5 na serwerze Jeśli musisz się grzebać także w php4 to filter_var odpada niestety bo tam go jeszcze nie było. Niestety wiem z doświadczenia, bo często, gęsto, filter_var używam (tutaj zapomniałem go dopisać z roztargnienia), ale przychodzi mi też walczyć ze starymi konfigami i tam już muszę protezy robić. Zamiast filter_var($email, FILTER_VALIDATE_EMAIL) muszę się podpierać preg_match na całą szerokość ekranu

@Crozin: a czym tu się podniecać? Kolega uważa regexpy za szwajcarski scyzoryk i znawcę wszystkich jego końcówek, a próbuje wkręcić nim śrubkę ( bo ma taką końcówkę w scyzoryku) zamiast po prostu sięgnąć po śrubokręt. Ale uparł się, że skoro ma narzędzie do wszystkiego to go na siłę będzie używał, zamiast sięgnąć do prostszych, pewniejszych, wygodniejszych i zwyczajnie szybciej działających.

@Crozin, dzięki chyba się przerzucę na PDO, bo jesteś którąś z kolei osobą, która mi to poleca.
Natomiast obecnie używam ADODB i nie mogę znaleźć informacji czy też tak jak PDO domyślnie waliduje zapytania. Może ktoś się orientuje?

Jeżeli na serwerze nie ma php > 5.3 to polecam zmienić serwer lub wersję php. W 4 to co było nawet obiektówką nazwać nie można. Najlepiej, gdyby wymarł.

fifi209 - są takie dziedziny w których zmiana czegokolwiek jest bolesnym procesem. Dlatego zasada "działa, nie rusz!" jest tak często stosowana

ad. ADODB - w najnowszych wersjach można go zmusić do używania PDO, choć u mnie wystąpiły pewne problemy z tym (przy użyciu Data Dictionary), ale sam odczyt i zapis w Active Record działał bez zarzutu. Zaś wydaje mi się że w ADODB o ile tworzy się zapytania bindując do nich wartości powinny być tak samo bezpieczne jak z użyciem PDO.

Znasz Prawa Murphy'ego ?



To kilka z wielu fajnych.

fifi209: nie zawsze się da. Jeśli masz działające od lat serwisy, które były pisane jeszcze pod php4, to musiałbyś je przepisywać na php5 albo stopniowo, albo hurtem. A niestety to zajmie trochę czasu. prościej ustawić na serwerze by zamiast php5 użył php4, a to podpada pod 3 podane przez Ciebie prawo