Bezpieczeństwo skryptów PHP, Jak zabezpieczyć się przed włamaniem Opcje

[marcinek37]

1. rozumiem, szkoda
2. to dla pewności lepiej wszystkie zmienne z $_SERVER sprawdzę
3. [brak odpowiedzi]
4. działa
5. [brak odpowiedzi]
6. faktycznie, działa prawidłowo - czy zatem to jest najlepsze zabezpieczenie przed kradzieżą identyfikatora sesji, czy może jeszcze coś warto zrobić?
7. nie rozumiem, możesz troszkę jaśniej? który chmod będzie najbezpieczniejszy, skoro config jest jedynie includowany przez silniczek
8. [brak odpowiedzi]
9. tworzy się sesja i jedną z ich wartości jest 'user_id', system sprawdza, czy jest użytkownik o podanym ID i ładuje od niego informacje, jeśli bym do bazy zapisywał ID sesji, to bym zaraz go stracił, skoro używam session_regenerate_id() - chyba że po zalogowaniu się będziemy tworzyć w sesji unikalny 'hash', który będzie stały po odświeżeniach i jego wartość zapiszemy w bazie - ale w sumie co za różnica, ID usera to żadna tajemnica
10. [proszę o ponowną odpowiedź w związku z prowadzoną dyskusją w punkcie 9]

[erix]

1. za każdym razem. Bo wystarczy, że komuś podeślesz (przypadkiem) raz linka i potem Ci odsyła kuku.
2. wszystko, co pochodzi od użyszkodnika, jest złe. Sodoma i Gomora. Nawet, jeśli uważasz, że jest dobry. Jest zły, będziesz spał spokojniej z takim założeniem.
3. tylko że to zawiedzie w przypadku NAT-a...
4. i tak za pierwszym razem SID musi zostać wysłany przez parametr w żądaniu, bo ciastko zostanie wysłane do serwera dopiero za drugim razem.

5. ale gdy go dodaje, pojawia się błąd

   
   Szklana kula rozwalona.
6. dla mnie, to już poziom=paranoid... jak masz zabezpieczenie przed CSRF, to to nie ma sensu...
7. zależy od uprawnień i serwera - jeśli proces PHP jest uruchamiany z Twoimi uprawnieniami - jak najbardziej, takie uprawnienie jest nawet wskazane. Wyjątek: sytuacja, gdy plik musi zostać zaczytany przez httpd, wtedy grupie nadajesz uprawnienia do odczytu.
8. nie hashuj hasha! Sól doklejaj, ale nie rób z tego hasha. Dlaczego? Jest przyklejony wątek o podwójnym hashowaniu haseł. PHPass jest o tyle lepsze, że wolniejsze. A im wolniejszy hash, tym lepiej, bo wykonanie ataku brute-force jest trudniejsze.
9. generalnie im więcej danych, które pozwalają użytkownika zidentyfikować, tym lepiej.
10. ~hind, przejmę SID, wgram do siebie ciasteczko o odpowiedniej wartości i co, mogę sobie przejąć ot tak zawartość Twojej sesji?

[hind]

10. jak przejmiesz SID to co za problem (głównie ataki XSS i inne robactwo systemowe)?
Jedyne co w tym wypadku pozostaje to sprawdzanie danych dodatkowych jak adres IP (zmienny), przeglądarka internetowa, czy inne parametry, ale to wszystko i tak można przejąć.

Inna sprawa że autologowanie można ograniczyć do jednego komputera (tylko na jednym komputerze autologowanie) + regeneracja klucza autologowania.
A jeszcze lepsza opcja to prośba o podanie hasła przy ważniejszych zmianach.

ogólnie nie widzę żadnej możliwości zabezpieczenia się przed wykorzystaniem przejętego SID (wygoda VS bezpieczeństwo).

[erix]

Jedyne co w tym wypadku pozostaje to sprawdzanie danych dodatkowych jak adres IP (zmienny), przeglądarka internetowa, czy inne parametry, ale to wszystko i tak można przejąć.

Połącz to sobie z JS, localStorage, w którym generujesz jakieś losowe tokeny, które są dolepiane do każdego żądania.

[hind]

Najlepiej jakby każda otwarta karta miała swój własny identyfikator, a do tego każde użycie sesji zliczane. Ale to tylko umożliwia zabezpieczenie przed przejęciem.

Ale jak skutecznie zabezpieczyć autologowanie?
(sprawdzanie IP, przeglądarki, danych JS jak localStorage, geolokacja, e-tagi, certyfikat, czy jeszcze jakieś inne możliwości)

[marcinek37]

1. wyjaśnione

2. wyjaśnione

3.

tylko że to zawiedzie w przypadku NAT-a...

zatem w jaki sposób mogę zabezpieczyć się przed przejęciem SID? bo w tym momencie, wystarczy, że ktoś pozna SID i robi ze stroną co mu się podoba...
moim jedynym pomysłem jest to, aby w sesji zapisać także jego IP, przeglądarkę - jeśli te dane nie będą się zgadzać, sesja zostanie zlikwidowana - drążę w dobrym kierunku?
czy wg Ciebie w tablicy $_SERVER są jeszcze jakieś dane, które warto zapisać i potem sprawdzić, czy aby na pewno ten, kto posiada SID, jest do tego upoważniony?

4.

i tak za pierwszym razem SID musi zostać wysłany przez parametr w żądaniu, bo ciastko zostanie wysłane do serwera dopiero za drugim razem.

czy mógłbyś rozwinąć myśl? czy sugerujesz, że mimo to problem istnieje? jeśli tak, masz pomysł, aby jemu zaradzić?

5. ten .htaccess chyba mogę zignorować, skoro działa ten kod:

[PHP] pobierz, plaintext 
<?
ini_set('session.use_only_cookies', 1);
?>
[PHP] pobierz, plaintext 

o którym mowa w punkcie 4.

6. zatem zrezygnuję z regeneracji SID

7. czyli ustawię chmod 600, a jeśli system przestanie działać, zmienię chmod na 666 - dobrze myślę?

8. właśnie cały przyklejony temat dotyczący hashowania przeczytałem uważnie i nie rozumiem, dlaczego mój pomysł jest zły - do hasła doklejam sól aż dwukrotnie (systemową i indywidualną) i dopiero wtedy przepuszczam przez md5, wklejam ponownie schemat z drobną zmianą:
HASH = md5( sól systemowa [16 znaków] + hasło użytkownika + idywidualna sól nadana dla użytkownika zapisana w bazie [16 znaków] )

nie jestem kryptologiem, ale jaka jest szansa, że ktoś znając chociaż jedną sól, może shakować hasło, skoro nie zna drugiej soli - czy ktoś łopatologicznie może mi to wyjaśnić

9.

generalnie im więcej danych, które pozwalają użytkownika zidentyfikować, tym lepiej

i też tak właśnie myślę, i tutaj ponawiam pytanie: jakie dane z tablicy $_SERVER mogę jeszcze wyciągnąć i zapisać w sesji - najlepiej, jeśli to możliwe - podaj proszę nazwy pól, np. "user_agent"

10. to może po wybraniu opcji "autologowanie" wyśle się ciastko z hashem, o którym mowa w punkcie 8, oraz ID usera
jeśli user wejdzie na stronę po tygodniu, system sprawdzi, czy jest takie ciastko, poszuka usera o podanym ID oraz hashem i wtedy porówna aktualne dane z tablicy $_SERVER z tymi, które przy logowaniu zostały zapisane w bazie danych, tj. "user_agent", "remote_addr" (+ te, które mam nadzieję ktoś poda w ramach pkt 9.) - tylko tworzy to pewien problem, bo jeśli ktoś ma zmienne IP, autologowanie nie nastąpi

Ten post edytował marcinek37 28.10.2012, 17:59:14

[Damonsson]

Nie wiem czy dobrze zrozumiałem, ale chodzi o to, żeby zamiast $_SESSION['userId'] zapisywać $_SESSION['hashGenerowanyZUserId']? Po co?

I przy okazji mam jedno pytanie, na które każdy odpowiada inaczej, można w końcu manipulować danymi przechowywanymi w zmiennej sesyjnej czy też nie można? np. $_SESSION['czyAdmin']?
Pomijając kwiatki typu $_SESSION['czyAdmin'] = $_POST['jakiespole'] gdzieś w kodzie.

Ten post edytował Damonsson 29.10.2012, 12:27:38

[CuteOne]

Legendy głoszą, że na serwerach współdzielonych, można było "podkradać" pliki sesji innych użytkowników danego serwera

[d3ut3r]

To zależy od konfiguracji serwera, ale generalnie local session hijacking to nie legenda Wszystko opiera się na założeniu, że serwer składuje dane sesji w katalogu np. /tmp do którego dostęp jest globalny dla shared hostingu, przy takiej konfiguracji możesz sobie te pliki odczytać. Przynajmniej takie jest założenie.

Proste doświadczenie, uruchom skrypt:

[PHP] pobierz, plaintext 
$files=(array)glob(session_save_path().'/*');
 
if (count($files)>0){
 
  foreach ($files as $k=>$file){
 
    $fileName=basename($file);
 
    if (substr($fileName,0,5)=='sess_'){
 
      $session_id=substr($fileName,5);
 
      echo 'Dump for: '.$session_id.'<br />';
      var_dump(file_get_contents($files[$k]));     
 
    }
 
  }
}
[PHP] pobierz, plaintext 

naprzykład na xamppie i spokojnie sobie odczytasz wszystkie pliki sesji.

[marcinek37]

kwestią zabezpieczeń serwera chyba nie muszę się martwić, bo mam wykupiony serwer u porządnej firmy - z tego co wiem przynajmniej

czy ktoś może odpowiedzieć na moje pytania?
szczególnie na pytania: 3 (jak zabezpieczyć się przed kradzieżą sesji), 8, 9, 10

[d3ut3r]

Moim zdaniem jeżeli twoja strona będzie odporna na XSS dodatkowo masz regenerację id sesji i porządnie skonfigurowany serwer to jedyną opcją na przejęcie session_id jest bezmyślne podanie go komuś, jednak przed głupotą się nie uchronisz. Jeżeli masz taką możliwość użyj SSL.

Zabezpieczenie z IP jest jakimś rozwiązaniem, jednak ma swoje ograniczenia ktoś już wspominał o NAT.

[Damonsson]

Załóżmy, że session_regenerate_id się nie wywołało i ktoś przejął moje aktualne PHPSESSID z ciastka.
Kiedy będzie chciał się podać za mnie, to wtedy przy session_start, zrobi się session_regenerate_id(true) i jeśli np. ip będzie różne to session_destroy.
Wszystko ładnie, on się nie zaloguje. Ale jednocześnie session_destroy będzie też dotyczyć Bogu ducha winnego mnie, więc będę musiał się znowu zalogować. Jest na to jakiś sposób, aby nie wiem, niszczyło jemu sesję i zmieniało PHPSESSID, a mnie nadawało nowy PHPSESSID z wartościami sesji, takimi jakie miałem ?

Ten post edytował Damonsson 29.10.2012, 21:56:10

[hind]

Nie ma takiej możliwości, chyba że umiesz w magiczny sposób rozpoznać kto jest prawidłowym właścicielem sesji. A tak to najbezpieczniej wywalić obu.

[marcinek37]

ok, więc skoro nie ma możliwości przed zabezpieczeniem się przed kradzieżą sesji, to czy ktoś może mi pomóc z punktami: 8, 9, 10?

[CuteOne]

Na twoim miejscu zamiast wymyślać koło na nowo(z możliwością popełnienia błędów) zobacz w gotowe skrypty np. tego forum IP.Board

[jaslanin]

2. adresów IP raczej nie powinno się przechowywać jako string tylko jako int
8. szybkie algorytmy hash'ujące nie są zalecane do przechowywania haseł, bo chcesz właśnie żeby atakujący musiał poświęcić dużo zasobów do odkrycia stringa odpowiadającego hash'owi. Tu masz to opisane:

http://php.net/manual/en/faq.passwords.php
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

[marcinek37]

czy reasumując:
1. nie ma możliwości, aby napisać system w ten sposób, aby za jego pośrednictwem ktoś mógł wykraść sesję i ją wykorzystać
2. szybkie hashowanie jest niebezpieczne, bo jeśli ktoś ukradnie mi hash i pozna sól systemową i indywidualną dla użytkownika, będzie mógł poznać hasło (tyle że najpierw musi poznać obie sole)
3. przy logowaniu do sesji mam zapisać jak najwięcej danych, które się z nim będą identyfikowały, prócz adresu IP, bo ktoś może mieć zmienny adres
4. autologowanie jest niebezpieczne i lepiej go nie robić

[jaslanin]

1. nie ma możliwości, aby napisać system w ten sposób, aby za jego pośrednictwem ktoś mógł wykraść sesję i ją wykorzystać

Można, wystarczy mieć luki XSS: https://www.owasp.org/index.php/Session_hijacking_attack

[pyro]

czy reasumując:
1. nie ma możliwości, aby napisać system w ten sposób, aby za jego pośrednictwem ktoś mógł wykraść sesję i ją wykorzystać
2. szybkie hashowanie jest niebezpieczne, bo jeśli ktoś ukradnie mi hash i pozna sól systemową i indywidualną dla użytkownika, będzie mógł poznać hasło (tyle że najpierw musi poznać obie sole)
3. przy logowaniu do sesji mam zapisać jak najwięcej danych, które się z nim będą identyfikowały, prócz adresu IP, bo ktoś może mieć zmienny adres
4. autologowanie jest niebezpieczne i lepiej go nie robić

Tak generalnie rzecz biorąc każdy z tych podpunktów to w mniejszym lub większym stopniu bzdura

[Damonsson]

Ale 3. do słowa "prócz" chyba jest prawdą? No bo jak inaczej identyfikować prawdziwego użytkownika?

edit: Również mając wzgląd na wyeliminowanie, multi-kontowości.

Ten post edytował Damonsson 25.11.2012, 19:45:03