[PHP]Sugerowana kolejność funkcji, Zabezpieczenie danych otrzymanych z formularza Opcje

[sadistic_son]

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. ?

Ten post edytował sadistic_son 2.03.2011, 21:02:44

[wookieb]

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

[sadistic_son]

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

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.

[Grzyw]

Nie szkoda Wam wieczoru na spięcia?(IMG:style_emoticons/default/smile.gif)

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.

Ten post edytował Grzyw 2.03.2011, 23:52:12

[sadistic_son]

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.

Ten post edytował sadistic_son 3.03.2011, 00:05:05

[Crozin]

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

[Grzyw]

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

[sadistic_son]

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?

[wNogachSpisz]

Ś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ś (IMG:style_emoticons/default/smile.gif)

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)



Ten post edytował wNogachSpisz 3.03.2011, 02:00:57

[Prezi2907]

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... (IMG:style_emoticons/default/smile.gif)
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 (IMG:style_emoticons/default/smile.gif)

[wNogachSpisz]

Wyrażenia regularne cechuje mniejsza czytelnośc oraz mniejsza wydajność..
więc u mnie przegrywają na całej linii (IMG:style_emoticons/default/smile.gif)
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.


Ten post edytował wNogachSpisz 3.03.2011, 02:15:03

[Prezi2907]

Wyrażenia regularne cechuje mniejsza czytelnośc oraz mniejsza wydajność..
więc u mnie przegrywają na całej linii (IMG:style_emoticons/default/smile.gif)

Chce mi się śmiać za każdym razem jak słysze "oh, to przyśpieszy Twój skrypt tylko o 0,0002 sek".
Takie argumentowanie jest bez sensu.

Mnie intereują fakty, 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 (IMG:style_emoticons/default/smile.gif) i umie (IMG:style_emoticons/default/smile.gif)

[wNogachSpisz]

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 (IMG:style_emoticons/default/smile.gif) i umie (IMG:style_emoticons/default/smile.gif)

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 (IMG:style_emoticons/default/smile.gif) 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.

Ten post edytował wNogachSpisz 3.03.2011, 02:48:04

[Prezi2907]

Pozostane przy swoim jeżeli chodzi oczytelność.
Czytając kod naładowanymi wyrażeniami musisz poświęcić więcej czasu na zrozumienie co każde z nich tak na prawde robi, istny koszmar!
Przy stosowaniu prostych funkcji takich jak isset() is_int() is_numeric() is_bool() is_scalar(), ten problem nie występuje, rzucasz okiem i już wiesz o robi skrypt..
Dodatkowo nie wygłupisz się pisząć niezoptymalizowane wyrażenie powodujące przykładowo wiele tysiący wycofań co ubije wydajność, o podobne błędy jest łatwo...
Nauka wyrażeń regularnych zajmuje duużo więcej niż kilka godzin, w kilka godzin możesz conajwyżej opanować podstawy...
Istnieje też potencjalne ryzyko bezpieczeństwa, konkretnie chodzi mi o modyfikator /e.
No i ta czytalność, elegancja kodu, dla mnie kod poprzecinami 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()( (IMG:style_emoticons/default/smile.gif) 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ść (IMG:style_emoticons/default/smile.gif) . A co do podstawowej walidacji będziesz używał tych wszystkich funkcji ? (IMG:style_emoticons/default/smile.gif) Wystarczy wymieniona przeze mnie tutaj (IMG:style_emoticons/default/smile.gif) 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 (IMG:style_emoticons/default/smile.gif)

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ć (IMG:style_emoticons/default/smile.gif)

[wNogachSpisz]

Cóż, powstrzymam się od komentarza..

Może tylko..

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

:-]

[hyhyhy]

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 (IMG:style_emoticons/default/smile.gif)

[thek]

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? (IMG:style_emoticons/default/wink.gif) 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.

[Prezi2907]

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? (IMG:style_emoticons/default/wink.gif) 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 (IMG:style_emoticons/default/smile.gif) 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... (IMG:style_emoticons/default/smile.gif) 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...

[thek]

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" (IMG:style_emoticons/default/wink.gif) 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ą.

[rasten]

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