Parę pytań odnoście PHP i bezpieczeństwa

pytanie zadane 16 kwietnia 2016 w PHP przez Ivan Maniak (60,650 p.)
edycja 16 kwietnia 2016 przez Ivan

Cześć, bez wstępu oto moja lista pytań odnośnie php. Proszę, aby ktoś odwołał się do moich "pytań". Są to raczej stwierdzenia, ale czy są one "trafne"? Właśnie o to proszę o poprawienie mnie, jeżeli się mylę oraz dodać do tego coś, co mogłem przegapić.

Bezpieczeństwo sesji po przeczytaniu parunastu wątków/blogów nadal nie wiem jak się "zabezpieczyć" oraz co mogę, a czego nie powinienem przechowywać w sesjach. Co wiem? Aby w sesjach przechowywać ip użytkownika i za każdym razem je sprawdzać. Dodatkowo "httponly". Nie rozumiem jak ma działać session_regenerate_id(). IMO może to bardziej zaszkodzić niż pomóc. Na większości stron takie cudo podaje się bez argumentu bool. Czyli działa to tak, że po wygenerowaniu nowego id, gdy ktoś przechwyci stare lub nowe id, będzie on zalogowany, tym samym na koncie będzie "szkodnik" i użytkownik, czego nie chcemy. Podczas gdy podany argument. Działa to już lepiej, ale nadal nie tak jak tego chcemy, ponieważ gdy wygenerujemy nowe id i szkodnik go wychwyci, to użytkownik zostanie wylogowany, a nasz szkodnik zostanie na koncie. W takim razie po co generować nowe id? No i na koniec, co przechowywać w tych sesjach? Mam użytkownika, który się zalogował. Jak mam go identyfikować? Po id z bazy danych? Po emailu/loginie - Tego miałem nie robić, ale chyba to jest najprostszy sposób. Dla "mnie" nie ma problemu, niech użytkownik loguje się za każdym wejściem na stronie [przeładowanie]. Tylko czy to nie zabije bazy danych przy większej ilości użytkowników. Wiem, że przesadziłem, ale chodzi mi nadal o informacje - Co przechowywać, czego nie. Jeżeli np. login jest jawny tj. Za każdym razem pokazujemy go naszemu użytkownikowi jak i innym użytkownikom - Dlaczego więc nie przechowywać go w sesji i tym samym "pomóc" naszej bazie danych?
Tak na rozluźnienie PDO, czym różni się fetch() od fetchAll(). Ilością "wyciąganych" danych oraz tym, że przy większej ilości danych fetchAll jest szybsze. Gdzie możemy wykorzystać fetch()? Bo z tego co próbowałem wyczytać i myślałem to za każdym razem fetchAll wygrywa.
Gdzie sprawdzać wprowadzone przez użytkownika dane? Czy zrobić to w klasie np. logowanie. Klasa > metoda logowania > w niej sprawdzamy wszystkie informacje np. czy login jest stringiem. Czy może zrobić to przed tym tj. Sprawdzanie czy string jest stringiem > Klasa > metoda logowania.

4 odpowiedzi

odpowiedź 16 kwietnia 2016 przez Comandeer Guru (601,550 p.)

Gdzie sprawdzać wprowadzone przez użytkownika dane?

W klasie validatora.

Co do sesji: ciekawy temat → http://www.forumweb.pl/php/sesje-w-przegladarce-miedzy-serwerami,62090

komentarz 16 kwietnia 2016 przez Ivan Maniak (60,650 p.)

Faktycznie, można zrobić osobną klasę :)
Jeżeli chodzi o sesje - po przeczytaniu 2 razy, nadal niczego się nowego nie dowiedziałem, ale dzięki za link.

komentarz 16 kwietnia 2016 przez Comandeer Guru (601,550 p.)

Dobrze zabezpieczona sesja to SSL + flagi httpOnly i secure dla ciasteczka. Do tego warto regenerować id (z parametrem!) przy kluczowych czynnościach.

odpowiedź 16 kwietnia 2016 przez writen Nałogowiec (29,060 p.)

Odnośnie PDO, prosto z manuala:

PDOStatement::fetch — Fetches the next row from a result set

PDOStatement::fetchAll — Returns an array containing all of the result set rows

Czy jest tu coś bardzo trudnego do zrozumienia?

komentarz 16 kwietnia 2016 przez Ivan Maniak (60,650 p.)

To własnie napisałem w poście? "Problem" nie polega na tym, że nie wiem czym to się różni, lecz nie widzę zastosowania praktycznego dla fetch()

komentarz 16 kwietnia 2016 przez Boshi VIP (100,240 p.)

Ciekaawe rozważenie, bo można by przyjąć, że np nie chcesz wyciągać 50k rekordów (fetchAll) tylko 43k i wtedy warunkiem możesz sobie zablokować, problem w tym, że na dobrą sprawę to moża osiągnąć przez zapytanie SQL i fetchAll() co jest raczej bardziej wskazane.

komentarz 17 kwietnia 2016 przez Szymon Lisowiec Mądrala (7,150 p.)

Użycie fetch() powinno zmniejszyć wykorzystanie RAM, przez skrypt.
Przykład:

while($r = $query->fetch()){
     //w $r trzymany jest jeden wiersz.
     echo $r['column'];
}

$rows = $query->fetchAll(); //w zmiennej trzyma wszystkie pobrane rekordy
foreach($rows as $r){
     //dodatkowo trzyma jeden wiersz w $r
     echo $r['column'];
}

1	komentarz 17 kwietnia 2016 przez writen Nałogowiec (29,060 p.) To własnie napisałem w poście? "Problem" nie polega na tym, że nie wiem czym to się różni, lecz nie widzę zastosowania praktycznego dla fetch() Nie, w poście napisałeś co innego.

2	komentarz 17 kwietnia 2016 przez Comandeer Guru (601,550 p.) Użycie fetch() powinno zmniejszyć wykorzystanie RAM, przez skrypt. Pytanie brzmi, czy różnica jest na tyle duża, żeby się tym przejmować. IMO dla 97% aplikacji odpowiedź brzmi: nie.

komentarz 21 kwietnia 2016 przez Szymon Lisowiec Mądrala (7,150 p.)

Tak, ale patrząc na cały kod. Jeżeli autor da masę takich funkcji, to już się zbierze + zależy od rozmiaru bazy. :)

1	komentarz 21 kwietnia 2016 przez Comandeer Guru (601,550 p.) Dalej wydaje mi się, że nie jest to aż tak wielki narzut i na pewno nie byłaby to pierwsza (ani nawet 10) rzecz, którą zrobiłbym w celu optymalizacji kodu ;)

odpowiedź 17 kwietnia 2016 przez Szymon Lisowiec Mądrala (7,150 p.)

Co do sesji...
Masz ciasteczko z id sesji PHP, które użytkownik może edytować i odczytywać.
Masz sesję, którą użytkownik może odczytać.
Ciasteczko trzyma id sesji, wg. którego przypisywana jest Ci sesja.
Jeżeli użytkownik podmieni swoje id sesji na czyjeś. Przejmie jego sesję. Tak samo użytkownik, może posiadać jakieś spyware, które wykradnie id sesji.

To takie rzucenie światła na sesje... ja osobiście zapisuję do sesji dane, dzięki którym można przypisać użytkownikowi rekord z bazy danych (np. login i hasło (przepuszczone przez jakiś hash), id użytkownika itp.) i przepuszczone przez hash IP i User Agent.
W takim przypadku, nawet jeśli "szkodnik" pozyska id sesji użytkownika, to i tak będzie posiadać inne IP, do którego ta sesja nie należy.