Całość I Część

Protokół HTTP jest protokołem bezstanowym. Oznacza to, że serwer WWW rozpatruje każde żądanie niezależnie od innych, nie szukając żadnych powiązań w stylu wysyłania ich przez tego samego internautę. Utrudnia to teoretycznie tworzenie wszelkich systemów autoryzacji, które wymagają śledzenia poczynań użytkownika na naszej stronie i przenoszenia jego danych autoryzacyjnych między kolejnymi żądaniami.
Sesje są rozwiązaniem problemu bezstanowości protokołu HTTP, w którym żądania nie są ze sobą powiązane. Umożliwiają one identyfikacje żądań poszczególnych użytkowników za pomocą przekazania identyfikatora sesji. Jest on dołączany do każdej odpowiedzi serwera jako "ciastko", ukryte pole w kodzie strony lub jako dodatkowy parametr adresu URL.

Fizycznie są to pliki tekstowe zawierające dane przypisane do konkretnych użytkowników.

Niebezpieczeństwo sesji.

• Atak session fixation

php_value session.use_only_cookies 1
php_value session.use_trans_sid 0

Drugim zabezpieczeniem jest wygenerowanie nowego identyfikatora sesji z każdym wykonaniem skryptu - zmniejsza to możliwość podszycia się pod użytkownika gdy nastąpi kradzież identyfikatora. Służy do tego funkcja

session_regenerate_id( );

Przykład skryptu w PHP

• Atak session poisoning

Skutecznie przeprowadzony atak session poisoning skutkuje możliwością modyfikacji danych znajdujących się w sesji agresora. Może on tego dokonać dwojako.

• Pierwszym sposobem jest wykorzystanie błędu braku filtrowania danych płynących od użytkownika, które są umieszczane w sesji.

Poniżej fragment napisany w PHP umożliwiający manipulację zmiennymi sesyjnym

';
print_r( $_SESSION);
echo '

';
if( $_GET['user'] )
$_SESSION[$_GET['user']] = $_GET['login'];

?>

• 
  

• Atak session injection

Posiadając konto u jednego z providerów internetowych dzielimy zasoby serwera z innymi użytkownikami. W skład tych zasobów wchodzą między innymi pliki. O ile dostępu do plików na naszym koncie chronią poprawnie ustawione uprawnienia dostępu, o tyle sytuacja taka nie zawsze ma miejsce jeśli chodzi o katalog z plikami sesji. Niepoprawnie skonfigurowany serwer może dać nam możliwość nie tylko podglądu ale i modyfikacji plików sesji.Pliki te nie są szyfrowane.

Poniżej fragment skryptu PHP umożliwiający listowanie oraz podgląd plików sesji.

';
              }


?>

Sposobem na zabezpieczenie się przed podglądem pliku sesji jest zmiana katalogu, w którym będą one przechowywane. Możemy tego dokonać korzystając z funkcji

session_save_path( );

Należy pamiętań, aby katalog z plikami sesji nie był publicznie dostępny dlatego powinien znajdować się powyżej katalogu public_html

• Atak session riding

Celem ataku session riding jest wykonanie złośliwego kodu z uprawnieniami zalogowanego użytkownika. Może to doprowadzić do kradzieży danych użytkownika, zamówienie przez niego jakiegoś produktu, lub w przypadku wykonania kodu przez administratora "dostęp” do panelu administratora.

Zabezpieczenie przed CSRF( skrót - bo taki ten atak posiada) może wydawać się trudne lecz istnieje kilka sposobów by tego dokonać. Dwa najciekawsze opierają się na tokenach, czyli losowo wygenerowanych ciągach znaków.

http://www.przyklad.com/?element=jakis&element=inny&akcja=zrob

Po zmianie wyglądów adresów po użyciu "tablicy routingu"

http://www.przyklad.com/?token=djPana76ashHSB

Implementacja własny mechanizm obsługi sesji.

Sposobem na zabezpieczenie się przed problemami związanymi z natywną obsługą sesji jest stworzenie własnego systemu obsługi sesji. Największy nacisk powinien w niej zostać położony na sposób przechowywania danych oraz zarządzania identyfikatorem sesji.

Najbezpieczniejszym miejscem na przechowywania danych jest baza danych. Aby uzyskać do niej dostęp należy znać dane umożliwiające logowania lub wykonać atak typu SQL Injection. Ze względu na swoją naturę możemy pominąć pierwszy sposób. Drugi atak może zostać przeprowadzony tylko w przypadku błędnie napisanego kodu. Można więc zauważyć, że poprawnie napisany system oraz własny mechanizm sesji daje nam całkowite bezpieczeństwo.

Sposób generowania identyfikatora zależy już tylko od inwencji twórców systemu zabezpieczeń tworzonej aplikacji. Można się do tego posłużyć funkcjami generującymi losowe znaki oraz funkcjami hashującymi. Co ważne po każdym wygenerowaniu ID trzeba się upewnić, że jest ono unikalne i nie zostało już wcześniej przydzielone innemu użytkownikowi.

Wygenerowany identyfikator powinniśmy umieścić w cookies oraz dodać dodatkowe zabezpieczenie uniemożliwiające przeprowadzenie ataku session fixation.

W PHP istnieje możliwość napisania własnych funkcji zarządzania sesją pod natywną obsługę sesji. Służy do tego funkcja session_set_save_handler Oznacza to tyle, że odwołując się do superglobalnej tablicy sesji ($_SESSION) odwołujemy się niejawnie do naszych funkcji. Oprócz tego, że sposób ten jest wygodny jest również bezpieczny na zmiany w kodzie oraz w sposobie przechowywania danych.

Wymienione w nawiasie -“m_open”,”m_close”,”m_read”,”m_write”,”m_destroy”,“m_gc”) to nic innego jak nazwy własnych ( funkcji napisanych w php )

Poniżej przykład funkcji użytkownika.

function m_open($save_path, $session_name){
  $r = mysql_connect() or die(“komunikat błędu”);
  mysql_select_db($save_path, $r) or die(”"komunikat błędu);
  return define(‘__ses_db’, $r);
}
function m_close() {
return mysql_close(__ses_db);
}

Źródło:

1. Ilia Alshanetsky - "Php|architect’s Guide to Security" -Marco Tabini & Associates, Inc. 2006
2. php.net - http://pl2.php.net/manual/pl/ref.session.php
3. Blog - iBlog - Ilia Alshanetsky
4. Securing PHP Applications
5. Blog - http://www.askapache.com/
6. Neil Daswani, Christoph Kern - "Foundations of Security: What Every Programmer Needs to Know" - Apress 2007 - http://www.apress.com