Witam wszystkich,
chciałbym poruszyć temat zabezpieczeń stron internetowych. Poza takim atakiem jak SQL Injection, który jest łatwy do "odparcia" są dwa typy bardzo groźnych ataków, które wymieniłem w temacie. Chciałbym napisać co wiem na ich temat oraz zadać kilka pytań. Mam nadzieję że ten post pomoże też innym osobom zrozumieć to zagadnienie. Od razu polecę artykuł na którym wzoruję swoją wypowiedź: http://php.pl/Wortal/Artykuly/Bezpieczenstwo/Sesja-uzytkownika-w-PHP-zagrozenia-i-ochrona
Działam na WebServ 2.0.
Zacznę od Session Hijacking. Jest to próba otrzymania numeru ID sesji.
W ogólnie dostępnych artykułach piszą o tym by nie przekazywać numeru sesji (PHPSESSID) w URL'ach co jest akurat oczywiste, tylko w ciastkach. Mimo to wystarczy komuś podsunąć link z kawałkiem kodu JavaScript zapisującego ciastko (document.cookie) do jakiegoś pliku na naszym serwerze.
- W takim razie jaka jest metoda obrony ? Czyżby tylko regeneracja session_id ?
- Jeżeli ktoś ma wyłączoną obsługę ciastek to oznacza że automatycznie link będzie zapisany do URL ?
- Jak poprawnie ustawić session.cookie_path ?
- Czy taki kod zabezpiecza użytkownika mimo kradzieży jego sesji ?:
<?
session_start();
if (!isset($_SESSION['RESET']))
{
session_regenerate_id(true); // nie wiem czy lepiej usuwać poprzednią sesję, czy nie ?
$_SESSION['RESET'] = true; // tutaj widziałem zastosowanie z haszowaniem md5()
$_SESSION['IP'] = $_SERVER['REMOTE_ADDR'];
}
if($_SESSION['IP'] !== $_SERVER['REMOTE_ADDR'])
{
// nowa sesja
}
?>
W podanym przeze mnie artykule omawiana jest kwestia sposobu przechwytywania sesji bo jest ona zapisana do katalogu /tmp, twierdząc że standardowo CHMOD jest ustawiony na 777.
5. Ja mam 711, więc chyba po kłopocie ?
6. Omawiane są tam jeszcze kwestie długości identyfikatora, ale on jest automatycznie tworzony, czy się mylę ?
Cross Site Scripting (XSS)
Na serwerze jakim działam mimo wersji PHP 5.2.5, nie mam opcji w php.ini tj. session.cookie_httpOnly. W dodatku napisali, że działa tylko do jednej z dwóch wymienionych metod.
7. Czy ona jest na pewno ważna ?
8. Czy tak naprawdę jest jakaś skuteczna obrona przed tym ? Czy tylko nie wchodzenie w różne głupie linki ?
Session Fixation
9. W artykule został umieszczony taki kod, który jest chyba lepszym odpowiednikiem z pytania 4 ?:
session_start();
$now = time();
$regenerateSec = 1800;
$regenerateReq = 10;
if (!isset($_SESSION['started']))
{
$_SESSION['started'] = true;
$_SESSION['time'] = $now;
$_SESSION['req'] = 1;
} else {
$_SESSION['req']++;
// regeneracja sesji po określonym czasie
if (isset($_SESSION['time']) && ((int)$_SESSION['time'] + $regenerateSec < $now))
{
session_regenerate_id(true);
$_SESSION['time'] = $now;
}
// regeneracja sesji po określonej liczbie żądań
if (isset($_SESSION['req']) && ((int)$_SESSION['req'] > $regenerateReq))
{
session_regenerate_id(true);
$_SESSION['req'] = 1;
}
}
Wypunktowałem pytania do łatwiejszego odpowiadania (by nie było nieporozumień). Bardzo proszę o odpowiedź i wszelkie podpowiedzi związane z zabezpieczeniami. Chce się dowiedzieć czy jest możliwość zabezpieczenia się przed wszystkimi atakami, a jeżeli nie to wszystkimi możliwymi atakami na serwis poza atakami na "głupich" użytkowników, którzy wtedy sami sobie robią kuku.
Pozdrawiam i czekam na odpowiedź.