• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Obsługa inputów na stronie internetowej

0 głosów
55 wizyt
pytanie zadane 10 czerwca w PHP, Symfony, Zend przez progNewbie Użytkownik (880 p.)

Hej Wam,

Chciałbym się dowiedzieć kilku rzeczy w temacie obsługi inputów na stronie. 

Wiem ,że jeśli dane wprowadzone przez userów, które później trafią do bazy danych powinny być obsłużone funkcją mysqli_real_escape_string(). Połączenie z DB powinno mieć ustawiony odpowiedni charset. I używać wersji MySQL nie niższej niż 5.1 aby być praktycznie w 100% bezpiecznym.

Czytałem też, że można uzyć Prepared Statements, ale jeszcze nie zagłębiałem się do tematu.

ALE:

Co z inputami, które nie trafiają do bazy danych? Najlepiej obsłużyć je wszystkie funkcją htmlspecialchars() ?

Nawet te dane, które trafiają z tagu select dla których optiony przez nas są ściśle określone powinienem obsłużyć funkcją htmlspecialchars() ?  Czy osoba próbująca włamać się do serwisu jest w stanie zmodyfikować treść value option'a?

Jest jakaś reguła co obsłużyć, a co nie? Czy reguła ograniczonego zaufania podlega wszystkim inputom gdzie user ma jakiekolwiek możliwości wprowadzenia jakichś treści?

Bardzo proszę o wypowiedź, ewentualnie linki gdzie już jakiś inny początkujący zadawał takie pytania.

Dziękuję.

 

 

1 odpowiedź

+2 głosów
odpowiedź 10 czerwca przez Arkadiusz Waluk Ekspert (249,210 p.)
wybrane 10 czerwca przez progNewbie
 
Najlepsza

Czytałem też, że można uzyć Prepared Statements, ale jeszcze nie zagłębiałem się do tematu.

Nawet bym powiedział, że trzeba. To daje Ci pełną ochronę przed SQL injection, bo osobno wysyła do bazy zapytanie i osobno wartości, więc manipulacja zapytaniem przez wartości staje się niemożliwa. 

Co z inputami, które nie trafiają do bazy danych? Najlepiej obsłużyć je wszystkie funkcją htmlspecialchars() ?

Zależy co z nimi robisz. Dane wrzucane do bazy też można przepuścić tą funkcją (lub inną podobną) jeśli nie chcesz, aby w bazie znalazł się kod możliwy do wykonania gdzieś. Czasem jest to pożądane (np. jak masz panel zarządzania postami, który ma obsłużyć HTML), a częściej raczej nie (np. jak użytkownik dodaje komentarze, które wyświetlą się na stronie i wstrzyknie tam kod, który dołączy złośliwy plik JS).

Czy osoba próbująca włamać się do serwisu jest w stanie zmodyfikować treść value option'a?

W sensie value z selecta w HTML? Oczywiście, to można zrobić inspektorem przeglądarki albo po prostu wysłać ręcznie request pod dany adres, nie korzystając wcale z Twojego formularza.

Jest jakaś reguła co obsłużyć, a co nie? Czy reguła ograniczonego zaufania podlega wszystkim inputom gdzie user ma jakiekolwiek możliwości wprowadzenia jakichś treści?

Tak, nigdy nie możesz ufać temu co przychodzi od użytkownika. Kwestia jak to sprawdzić zależy od tego, do czego potrzebujesz danych informacji. 

komentarz 12 czerwca przez progNewbie Użytkownik (880 p.)
Hej, sory, że tutaj, mogę ew. założyć nowy temat. Chciałem się jeszcze tylko dopytać o sesję.

Załóżmy, że przy logowaniu tworzona jest zmienna sesyjna, zawierająca jakiś tam string.

Następnie ta zmienna będzie używana na jakiejś innej podstronie w zapytaniu SQL'owym.

Czy przed takim zapytaniem powinienem jeszcze obsłużyć tą zmienną pod kątem security lub po prostu użyć tych Prepared Statements?

Czy tworzenie zmiennych sesyjnych przy logowaniu zawierających jakieś tam dane potrzebne potem przy zapytaniach SQL'owych jest ok?

Czy raczej powinienem omijać taką praktykę?

Przykład:

User loguje się, tworzy się $_SESSION['branch'] = '1';

Na podstronie potem używana jest ta zmienna $_SESSION['branch'] w zapytaniu SQL'owym.

Czy lepiej dopiero na tej podstronie zapytaniem SQL'owym wyciągnąć, że branch = 1 i wykorzystać go dalej i nie zapychać sesji takimi rzeczami?

Moje przemyślenia:

Wydaję mi się, że lepiej nie zaśmiecać sesji danymi, które zostaną wykorzystane tylko w poszczególnych miejscach, a wywoływać je zapytaniami dopiero w tym miejscu gdzie one faktycznie są potrzebne.

Czy sesja tworzona przy logowaniu powinna zawierać tylko dane potrzebne do autoryzacji?

 

Sory, że tak zalewam pytaniami, ale strasznie dręczą mnie te sprawy.
komentarz 12 czerwca przez Arkadiusz Waluk Ekspert (249,210 p.)

Czy przed takim zapytaniem powinienem jeszcze obsłużyć tą zmienną pod kątem security lub po prostu użyć tych Prepared Statements?

 Zakładam, że w takiej zmiennej będzie np. jakaś cyfra wcześniej pobrana z bazy, id użytkownika czy coś - wtedy nie ma sensu tego obsługiwać, bo wiesz, że tam jest bezpieczna wartość z bazy. Puścić przez prepared statements nie zaszkodzi, osobiście wszystkie wartości w zapytaniach tak wysyłam.

Czy tworzenie zmiennych sesyjnych przy logowaniu zawierających jakieś tam dane potrzebne potem przy zapytaniach SQL'owych jest ok?

Jak najbardziej, dlaczego by nie. Zależy oczywiście co chcesz tam zapisać, niektóre rzeczy mogą mieć mniej sensu, inne więcej, a to też zależy od sytuacji. Ale generalnie tak, nie widzę problemu i średnio sobie wyobrażam jakbyś np. trzymał informację kto jest zalogowany w danej sesji jeśli nie przez zapisanie w niej id użytkownika.

Czy lepiej dopiero na tej podstronie zapytaniem SQL'owym wyciągnąć, że branch = 1 i wykorzystać go dalej i nie zapychać sesji takimi rzeczami?

Zależy czym jest to branch. Jeżeli jest potrzebne akurat w tej sesji albo tak będzie lepiej to nie widzę problemu.

 Wydaję mi się, że lepiej nie zaśmiecać sesji danymi, które zostaną wykorzystane tylko w poszczególnych miejscach, a wywoływać je zapytaniami dopiero w tym miejscu gdzie one faktycznie są potrzebne.

Jak wyżej - zależy od sytuacji, musisz indywidualnie ocenić czy to się przyda akurat w sesji z jakiegoś powodu czy nie. Jeśli jest to czasem używana informacja to może być pobierana z bazy za każdym razem. Z resztą pytanie czy zawsze sprawdzenie informacji o użytkowniku nie powinno polegać na odczytaniu id z sesji, zapytaniu z bazy o jego dane i na nich dalszych operacjach.

Czy sesja tworzona przy logowaniu powinna zawierać tylko dane potrzebne do autoryzacji? 

Nie słyszałem o takim wymogu. 

komentarz 17 czerwca przez progNewbie Użytkownik (880 p.)
Bardzo dziękuję za podpowiedzi !! :)

Podobne pytania

+1 głos
2 odpowiedzi 73 wizyt
+1 głos
2 odpowiedzi 75 wizyt
0 głosów
1 odpowiedź 100 wizyt
Porady nie od parady
Zadając pytanie postaraj się o poprawną pisownię i czytelne formatowanie tekstu.Kompozycja

65,806 zapytań

112,454 odpowiedzi

237,603 komentarzy

46,734 pasjonatów

Przeglądających: 213
Pasjonatów: 14 Gości: 199

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto dwie polecane książki warte uwagi. Pełną listę znajdziesz tutaj.

...