Luka w zabezpieczeniach związana z atakiem i przejęciem sesji przez CSRF

Z informacji o wersji 1.8CE Alpha:

Sklep internetowy Magento ma dodatkowe zabezpieczenia CSRF (Cross Site Request Forgery), co oznacza, że ​​oszust nie może już podszywać się pod nowo zarejestrowanego klienta i wykonywać działań w jego imieniu.

i:

We wcześniejszych wersjach Magento był podatny na atak utrwalania sesji podczas procesu rejestracji. Po zalogowaniu się na konto identyfikator sesji zarejestrowanego użytkownika nie zmienił się. Dlatego, jeśli osoba atakująca wiedziała o nieautoryzowanym identyfikatorze sesji i jeśli ten użytkownik pomyślnie się zarejestrował, mógł przejąć nowo zarejestrowane konto. Teraz identyfikator sesji zmienia się po udanej rejestracji, uniemożliwiając nieautoryzowane korzystanie z konta.

Jeśli znajduje się to w informacjach o wydaniu i nie widzę wydania punktowego na temat poprzednich wersji, które to rozwiązuje (czy szukam w złym miejscu?) - oznacza to, że obecne sklepy sprzed wersji 1.8 są potencjalnie otwarte na te ataki wektory ?

Źródło: http://www.magentocommerce.com/knowledge-base/entry/ce-18-later-release-notes

W skrócie tak. CE 1.7 jest nadal podatny na te konkretne ataki, ponieważ nie wydano żadnej wersji zabezpieczeń, która zawiera łatkę.

W przypadku tego drugiego, ataku utrwalającego sesję, zmiana jest ulepszeniem praktyk bezpieczeństwa, które Magento już stosowało, aby zachować zgodność z obecnymi najlepszymi praktykami bezpieczeństwa. Nie jest to coś, co prawdopodobnie zostanie wydane CE 1.7, jeśli opublikują łatkę z poprawkami CSRF.

Prawdziwe pytanie brzmi: jakie dokładnie zostały usunięte luki w CSRF? Bez wątpienia dobrą rzeczą jest to, że nie uwzględnili one szczegółów w informacjach o wydaniu, tym samym zagrażając wszystkim wcześniejszym wydaniom, ale byłoby miło wiedzieć, że ze względu na łatanie starych implementacji.

AKTUALIZACJA # 1: Po skontaktowaniu się z Magento, aby dowiedzieć się, kiedy będą wydawać łaty dla powyższych luk, otrzymałem następującą odpowiedź:

Daj mi trochę czasu na dalsze badania. Nie jestem pewien, czy są dostępne łaty dla tych dwóch przedmiotów, ponieważ są one wymienione w naszym systemie jako ulepszenia produktu, a nie jako błędy. Zaktualizuję cię, gdy otrzymam więcej informacji.

Prześlę tutaj dalsze szczegóły, gdy je otrzymam, i dołożę wszelkich starań, aby łatki zostały wydane, ponieważ wydaje się, że obecnie nie ma żadnych łatek.

AKTUALIZACJA # 2: Po przejściu z zespołem wsparcia udało mi się uzyskać odpowiednią łatkę dla Magento EE 1.12.0.2. Nie wydano łaty dla Magento CE 1.7.0.2 i, o ile technik, który zajrzał do mnie wewnętrznie, wie, nie ma planów wydania oficjalnej łaty dla CE 1.7.x zamiast rozwiązania problemów tylko w nadchodzącym CE 1.8 wersja stabilna.

Jeśli chodzi o specyficzny dla EE plik łatki, nie mogę tutaj opublikować go (ani narzędzia do aplikacji łatek), ponieważ byłoby to z pewnością sprzeczne z NDA między Magento a mną osobiście i firmą, dla której pracuję. Nazwa odpowiedniej poprawki to: „PATCH_SUPEE-1513_EE_1.12.0.2_v1.sh” - Jeśli korzystasz z wersji Enterprise Edition lub klienta, z której ją korzystasz, powinieneś móc poprosić o tę łatkę od zespołu wsparcia Magento wraz z notatką o podatności CSRF, które ma naprawić.

Dla użytkowników CE 1.7.0.2 skorzystałem z możliwości wygenerowania pliku łatki (opartego na łatce dostarczonej przez Magento), który zawiera tylko fragmenty kodu, które zmieniają podstawowe pliki kodu Magento CE 1.7.0.2. W normalny sposób zawiera niepotrzebne fragmenty dodanych komentarzy i dostosowane formatowanie wraz z odpowiednimi zmianami kodu. Utworzenie tego wymagało ręcznej zmiany oryginalnej łatki w celu zastosowania jej za pomocą dostarczonego narzędzia do nakładania łatek, a następnie użycia git do wygenerowania łatki na podstawie zastosowanych zmian.

Plik poprawki, który utworzyłem, można pobrać z tej listy: https://gist.github.com/davidalger/5938568

Aby zastosować łatkę, najpierw cd do katalogu głównego instalacji Magento i uruchom następujące polecenie: patch -p1 -i ./Magento_CE_1.7.0.2_v1-CSRF_Patch.diff

Łatka specyficzna dla EE obejmowała sprawdzanie poprawności klucza formularza do kontrolerów specyficznych dla przedsiębiorstwa, zmiany w plikach szablonów Enterprise / default i Enterprise / iPhone w celu uwzględnienia kluczy formularzy w formularzach używanych do poprawionych działań kontrolera oraz dodatkową funkcjonalność Pełnej pamięci podręcznej strony, aby poprawnie uwzględnić przekazywanie kluczy formularzy tam iz powrotem na buforowanych stronach.

WYŁĄCZENIE ODPOWIEDZIALNOŚCI: NIE TESTowałem ani łatki EE dostarczonej przez Magento, ani łatki, którą przesłałem do powiązanej listy. Łatka podana w odnośniku jest dostarczana BEZ GWARANCJI i może, ale nie musi, w pełni rozwiązać luki wymienione w informacjach o wydaniu CE 1.8. Jako niesprawdzona łatka nie ma też gwarancji, że będzie działać w całości lub w części. Używam na własne ryzyko i dołożę należytej staranności, aby przetestować przed wdrożeniem w środowisku produkcyjnym. Jeśli znajdziesz problemy z łatką, daj mi znać, a ja ją zaktualizuję.

Nie jestem w 100% pewien, ponieważ nie byłem w stanie odtworzyć problemu, ale

co oznacza, że ​​oszust nie może już podszywać się pod nowo zarejestrowanego klienta

oznacza, że ​​do tej pory „oszust” mógł podszyć się pod nowo zarejestrowanego klienta.
Mam nadzieję, że to tylko „semantyka”, ale myślę, że oznacza to, czego się boisz.