Nie uważam, by wybór takiej lub innej technologii miał decydujące znaczenie dla bezpieczeństwa całego rozwiązania. Z drugiej jednak strony na pewno nie jest on pomijalny. Pisałem o tym, że na przykład środowisko ASP.NET (patrz na przykład: Next Generation .NET Vulnerabilities) ma wbudowanych kilka rozwiązań pozytywnie wpływających na bezpieczeństwo, podobnie jest również w przypadku JSF. Czasami kluczowy okazuje się wybór serwera aplikacyjnego...
Bezpieczeństwo nie jest "vendor neutral" - przykład JSESSIONID
Przykład - istnieje coś, co określa się jako Session Fixation. Szybko można jednak znaleźć rozwiązanie (albo i powód):
(...) The following example shows a snippet of code from a J2EE web application where the application authenticates users with LoginContext.login() without first calling HttpSession.invalidate(). (...)Innymi słowy - w celu zabezpieczenia się przed Session Fixation w J2EE należy robić coś takiego:
session.invalidate(); session=request.getSession(true);Proste? Prawie...
Comment: Please note that JBOSS has proven to NOT regenerate a new session id via this method as of December 2007.Teoretycznie rozwiązanie tego problemu opisane jest w tym wątku: SessionFixationProtectionFilter does not work on JBoss i polega na zmianie parametru emptySessionPath (co spowodować może jakieś problemy w pewnych sytuacjach, w końcu z jakiegoś powodu wartość ta została zmieniona z domyślnej false na true).
Co w praktyce to oznacza? Programista może postąpić zgodnie z zaleceniami, zmieniać identyfikator sesji po uwierzytelnieniu lub innych zmianach stanu (np. po przejściu między HTTP i HTTPS), mogą zostać nawet przeprowadzone testy penetracyjne, które w przypadku wykorzystania Tomcata pokażą, że podatności session fixation nie ma. Później podjęta zostanie decyzja o zmianie Tomcata na JBOSS i...
No właśnie. Czy spotykając aplikację w J2EE działającą z JBOSS i podatną na session fixation należy zakładać, że winny jest programista, czy JBOSS?
