 Walidacja formularza, mysql i formularz php |
  |
| Walidacja formularza, mysql i formularz php |
 26.08.2011, 22:58:29
Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 30 Pomógł: 0 Dołączył: 23.09.2010 Ostrzeżenie: (0%) 
 |
Witam,
piszę portal w którym uzytkownik wypełnia dane zapisywane poźniej do bazy mysql. Robiąć walidacje zmiennych spr -długośc -czy liczba (jeśli muszą być cyfry) -htmspecialchars() -addslashes() i zastanawiam się co jeszcze powinienem uwzględnić, czytałem o sql injection itd, jakich funkcji powinienem uzyć  czy mysql_escape_string() i addslashes() wystarczy?? Czy możecie mi podać jakiś funkcje do walidacji np. adresu mail?? Zastanawiałem się także nad wyrażeniami regularnymi, czy jeśli zastosuję metody powyżej to wougle ma sens?? Nigdy wcześniej nie robiłem walidacji więc będę bardzo wdzięczny za uwagi jeśli coś pominołem Z góry bardzo dziękuję za pomoc |
 |
 
|
|
26.08.2011, 23:01:41
Post
#2
|
|
 Grupa: Moderatorzy Postów: 4 069 Pomógł: 497 Dołączył: 11.05.2007 Skąd: Warszawa |
Addslashes nie ma nic wspólnego z bezpieczeństwem
 mysql_real_escape_string dla zwykłego mysql_, a jeszcze lepiej naucz się PDO i binduj dane. Do walidacji masz jeszcze filter_var |
|
|
|
|
27.08.2011, 08:52:31
Post
#3
|
|
 Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%)
|
Dobra walidacja powinna zostać przeprowadzana dwuwarstwowo, niezależnie od walidacji po stronie klienta w javascripcie (i tu np. użyć jakiejś gotowej wtyczki do jQuery) należy też sprawdzić poprawność danych po stronie serwera. W tym drugim przypadku najczęściej stosowanymi zabiegami są:
- wymuszanie spodziewanego typu danych z określonego pola formularza poprzez rzutowanie do określonego typu (intval, floatval lub old-retro $zmienna = (int) $zmienna, $zmienna = (float) $zmienna itd.) - sprawdzanie długości (string strlen i sustr) i maksymalnej wartości (int, float, double) zmiennej z forma - użycie ukrytych pol formularza z zastosowaniem mechanizmu generowania tokenów w celu zwiększenia prawdopodobieństwa, że dane z formularza pochodzą z naszej strony - sprawdzanie opcji selekta (pomimo stosunkowo małego prawdopodobieństwa nadużyć dla tego typu pól) i filtrowanie wartości które przychodzą z forma do tyko tych zdefiniowanych (np. w tablicy) - wysyłanie metodą POST zamiast GET - użycie PDO do operacji na bazie danych - użycie wspomnianych już filtrów do walidacji poprawności np. adresu e-mailowego - zastosowanie sprawdzonych implementacji do walidacji numerów NIP, PESEL, KRS, kodów pocztowych itp. - usuwanie znaków specjalnych i białych (np. trim), wycinanie ze stringów wszystkiego, spoza zdefiniowanej tablicy znaków dozwolonych Polecam korzystanie z gotowych rozwiązań, np. walidatorów dla Zend_Form, wtyczek do walidacji formularza opartych o np, jQuery. Jest jedna naczelna zasada: nigdy nie ufaj danym pochodzącym od użytkownika, sprawdzaj wszystko, niezależnie od typu pola w samym formularzu i wymuszaj określony typ, długość i zestaw dozwolonych znaków. Dobry pomysłem jest również zastosowanie recaptcha przeciw spamerom. -------------------- Nie pomagam na pw, tylko forum.
|
|
|
|
|
27.08.2011, 10:41:22
Post
#4
|
|
|
Grupa: Zarejestrowani Postów: 30 Pomógł: 0 Dołączył: 23.09.2010 Ostrzeżenie: (0%)
|
Dlaczego dwustronnie?? Jeśli pobieram dane z formularza $_POST->skrypt walidacyjny->require("skrypt docelowy"), to po co jeszcze walidacja po stronie klienta??- tz czy jest konieczna z powodu bezpiecześńtwa, czytałem gdzieś że nie, ale może to było złe źródło??
- użycie ukrytych pol formularza z zastosowaniem mechanizmu generowania tokenów w celu zwiększenia prawdopodobieństwa, że dane z formularza pochodzą z naszej strony mógłbyś podać przykład?? - sprawdzanie opcji selekta (pomimo stosunkowo małego prawdopodobieństwa nadużyć dla tego typu pól) i filtrowanie wartości które przychodzą z forma do tyko tych zdefiniowanych (np. w tablicy) o co chodzi?? |
|
|
|
|
27.08.2011, 14:21:35
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%)
|
Chodzi o to, żeby nie zostawiać walidacji tylko po stronie klienta, ale zawsze jeszcze dodatkowo walidować po stronie serwera (php).
Token Odnośnie selektorów to, pomimo, że mamy jedynie takie opcje po stronie klienta, jakie narzuci twórca formularza, jednak walidować mimo wszystko dodatkowo po stronie klienta czy wybrana opcja należy do zestawu dozwolonych możliwych wartości dla tego pola, to tak na wypadek, gdyby ktoś próbował nam się "wbić" curlem podając jakąś zupełnie inną opcję spoza listy. // edit heh ~Spawnm Pomógł: 404 Not Found 
Ten post edytował darko 27.08.2011, 14:22:48 -------------------- Nie pomagam na pw, tylko forum.
|
|
|
|
|
27.08.2011, 14:40:12
Post
#6
|
|
|
Grupa: Zarejestrowani Postów: 30 Pomógł: 0 Dołączył: 23.09.2010 Ostrzeżenie: (0%)
|
Chodzi o to, żeby nie zostawiać walidacji tylko po stronie klienta, ale zawsze jeszcze dodatkowo walidować po stronie serwera (php).
ok to rozumiem, ja się pytam po co walidacja po stronie klienta, skoro jest po stronie serwera?? Czy nie wystrczy tylko po stronie serwera?? selektory- dnx cenna uwaga, wogle jakoś o tym zapomniałem... |
|
|
|
|
27.08.2011, 14:58:33
Post
#7
|
|
|
Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%)
|
Nie ma nigdzie obowiązku walidowania pól formularza po stronie klienta, jednak z wielu względów się to robi, np. łatwiej jest od razu pokazać użytkownikowi gdzie popełnił błąd bez przeładowania strony zamiast zajeżdżać każdorazowo serwer ze źle wypełnionym formularzem i ponownie i jeszcze raz wysyłać błędne dane. Dlatego wstępną walidację przeprowadza się w javascripcie. Jednak najważniejsze jest sprawdzenie danych po stronie serwera.
-------------------- Nie pomagam na pw, tylko forum.
|
|
|
|
|
27.08.2011, 20:07:06
Post
#8
|
|
|
Grupa: Zarejestrowani Postów: 30 Pomógł: 0 Dołączył: 23.09.2010 Ostrzeżenie: (0%)
|
ok czyli podsumowując:
1)walidacja po stronie klienta dla ulatwienia życia/ walidacja po stronie serwera dla bezpieczeństwa 2)Chciałbym napisać funkcje uniwersalną ktora będzie sprawdzać każdy tekst (oprucz selectów), ktory idzie do bazy, czy ten zestaw funkcji będzie ok: function wal($z) { $z=mysql_real_escape_string($z); $z = strip_tags($z); $z = trim($z); return $z; } + oczywiście sprawdzanie długości danych strlen($z) + token /w przypadku selctow zakres liczbowy + walidacja maila/kodu pocztowego (jak napisze wrzuce na forum dla potomności:)) |
|
|
|
|
27.08.2011, 22:16:15
Post
#9
|
|
|
Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%)
|
1) dokładnie
2) Nie ma czegoś takiego, jak "funkcja uniwersalna", a sprawdzanie poprawności kodu pocztowego czy adresu e-mail potraktuj jako twórcze wymyślanie koła na nowo w celach edukacyjnych  // edit Właśnie tak rozkminiam czy odpowiedź na to pytanie podpada pod punkt zakazanych praktyk na forum, mianowicie - pomoc w łamaniu zabezpieczeń. ps. (oprÓcz selectów)
Ten post edytował darko 27.08.2011, 22:26:48 -------------------- Nie pomagam na pw, tylko forum.
|
|
|
|
|
27.08.2011, 22:33:29
Post
#10
|
|
|
Grupa: Zarejestrowani Postów: 30 Pomógł: 0 Dołączył: 23.09.2010 Ostrzeżenie: (0%)
|
uniwersalna miałem na mysli funkcje które ZAWSZE niezależnie od typu pola należy wykonać- po to aby nie powtarzać 10 razy tego samego. Dlaczego koła od początku?? Czy jest jakiś dobra ogólno dostępna funkcja np do walidacji mail'a
(...google ok, ale tam jest kilka funkcji i przeważnie każda ma jakieś wady ), jeśli przeoczyłem to bardzo poproszę .Mam jeszcze wątpliwość co do tokenów...załóżmy że mamy katalog firm i pola co...gdzie....(walidacja ->kwerenda->wyniki) Jeśli wprowadzam tokeny to konieczne jest rozpoczynanie sesji, wszystko to wpływa na obciążenie serwera, czas wykonania itd. Biorąc pod uwagę sporą liczbę zapytań, czy wprowadzenie tokenu jest w takim przypadku zasadne?? //zakazanych - dlaczego?? intencją tego wątku jest zabezpieczenie, dzięki poruszanym kwestią czytający ten wątek będą wiedzieli jak zabezpieczyć swoje serwisy. Nie pytam się jak się włamać tylko jak zabezpieczyc stronę przed włamaniem. Pokazywanie ludzią potencjalnych luk w zabezpieczeniach wpływa na świadomosc i bezpieczeństwo internetu- nie mówiąć już o tym że w tym wątku od razu dostają recepte. Ten post edytował doomink 27.08.2011, 22:39:17 |
|
|
|
 28.08.2011, 00:23:06
Post
#11
|
|
|
Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%)
|
To, że nagradzasz każdą moją wypowiedź w tym wątku nie znaczy, że złamię regulamin, odpowiadając. Błąd w Twoim rozumowaniu może polegać na tym, że chciałbyś dostać receptę uniwersalną i pozbyć się problemu. Niestety - może Cię zmartwię - nie ma uniwersalnego panaceum na próby włamań. To, co przez cały wątek starałem się przekazać miało Ci pomóc w utwierdzeniu się w przekonaniu, że dbałość o bezpieczeństwo wymaga działań na wielu płaszczyznach. Nie wystarczy dbać po stronie php o wszelkie zabezpieczenia, zapominając o prawidłowej konfiguracji serwera. W ogóle temat bezpieczeństwa jest na tyle zaawansowany, że to, co chcesz osiągnąć przy obecnym stanie wiedzy nie ma prawa być wystarczające w zapobieżeniu jakiejkolwiek próbie włamania na Twój czy kogokolwiek innego serwer. Niestety.
Ten post edytował darko 28.08.2011, 00:24:16 -------------------- Nie pomagam na pw, tylko forum.
|
|
|
|
|
28.08.2011, 01:03:32
Post
#12
|
|
|
Grupa: Zarejestrowani Postów: 30 Pomógł: 0 Dołączył: 23.09.2010 Ostrzeżenie: (0%)
|
żle mnie zrozumiałeś, o innych kwestiach wiem i mam je rozwiązane, pytam o konkretną rzecz jakim jest walidacja formularza i związane z nim niebezpieczeństwo, przedstawiłem w jaki sposób na razie waliduje formularz i proszę Was - tych którzy lepiej niż ja się znają o uwagi co jeszcze warto dodać i o czym pamiętać.
Jesli widzicie że coś pominołem i warto dodac do zestawu nazwijmy to uniwersalnych funkcji walidacji zmiennych tekstowych to proszę o pomoc. Byłbym również wdzięczny za podpowiedz jak wpływa mechanizm tokena - szukam ale nie moge znaleźc. P>S nagradzam każdy post który mi pomógl i coś wnosi. Dziekuje że podzieliłeś się wiedzą. Prosze czytaj moje posty, PYTAM JAK UCHRONIĆ SIĘ PRZED WŁAMANIEM A NIE JAK SIĘ WŁAMAĆ  !!
|
|
|
|
|
28.08.2011, 01:21:17
Post
#13
|
|
|
Grupa: Zarejestrowani Postów: 715 Pomógł: 47 Dołączył: 5.12.2010 Ostrzeżenie: (0%)
|
Niektórzy może zapominają o tym,ale formą zabezpieczenia jest także ograniczanie ilości dopuszczalnych znaków w polu input poprzez atrybut maxlength.
Ważną rzeczą przy walidacji są wyrażenia regularne,na nich także powinien się Pan koncentrować. Jeśli chodzi o całą stronkę,to można zastosować SSL jako formę zabezpieczenia Widzę,że koncentruje się Pan na walidacji ,nie zaprzeczam że nie jest to ważne ,ale pozostają także inne elementy do zabezpieczenia jak sesje ,cookies,baza danych itp. Taka dobra rada niech Pan zacznie używać PDO do połączenia z bazą danych i używać parametrów zamiast zmiennych-wtedy sqlInjection raczej będzie niegroźny. Ten post edytował Rid 28.08.2011, 01:31:02 |
|
|
|
|
|
Wersja Lo-Fi | Aktualny czas: 26.04.2025 - 04:02 |
