• 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

VPS Starter Arubacloud
0 głosów
115 wizyt
pytanie zadane 10 czerwca 2019 w PHP przez progNewbie Obywatel (1,130 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 2019 przez Arkadiusz Waluk Ekspert (287,550 p.)
wybrane 10 czerwca 2019 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 2019 przez progNewbie Obywatel (1,130 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 2019 przez Arkadiusz Waluk Ekspert (287,550 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 2019 przez progNewbie Obywatel (1,130 p.)
Bardzo dziękuję za podpowiedzi !! :)

Podobne pytania

0 głosów
1 odpowiedź 236 wizyt
pytanie zadane 23 sierpnia 2020 w PHP przez anski Nowicjusz (120 p.)
0 głosów
0 odpowiedzi 348 wizyt
pytanie zadane 2 grudnia 2019 w PHP przez manager96 Bywalec (2,050 p.)
0 głosów
2 odpowiedzi 270 wizyt
pytanie zadane 24 października 2019 w PHP przez GameDev newbie Nowicjusz (120 p.)

92,455 zapytań

141,263 odpowiedzi

319,099 komentarzy

61,854 pasjonatów

Motyw:

Akcja Pajacyk

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

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Akademia Sekuraka 2024 zapewnia dostęp do minimum 15 szkoleń online z bezpieczeństwa IT oraz dostęp także do materiałów z edycji Sekurak Academy z roku 2023!

Przy zakupie możecie skorzystać z kodu: pasja-akademia - użyjcie go w koszyku, a uzyskacie rabat -30% na bilety w wersji "Standard"! Więcej informacji na temat akademii 2024 znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...