Uważam, że trudno będzie znaleźć ostateczną odpowiedź na to pytanie, dlaczego token CSRF jest „potrzebny” w akcji GET dodawania do koszyka Magento. Spróbuję zinterpretować jego cel. W żadnym wypadku nie jestem ekspertem od bezpieczeństwa i taka jest moja interpretacja CSRF w tym konkretnym kontekście.
Kontekst
Od owasp.org
Fałszowanie żądań między witrynami (CSRF) to atak, który zmusza użytkownika końcowego do wykonania niepożądanych działań w aplikacji internetowej, w której jest obecnie uwierzytelniony. Ataki CSRF dotyczą w szczególności żądań zmieniających stan, a nie kradzieży danych, ponieważ osoba atakująca nie ma sposobu, aby zobaczyć odpowiedź na sfałszowane żądanie.
Jednym z przykładów tego ataku jest osadzenie ukrytego obrazu w wiadomości e-mail lub na innej stronie internetowej:
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">
Serwer internetowy nie rozróżniałby, skąd pochodzi żądanie, i wiernie dodawałby przedmiot do koszyka tego użytkownika.
Celem zapobiegania atakom CSRF jest zapobieganie żądaniom zmieniającym stan . Dodanie przedmiotu do koszyka będzie uważane za zmianę stanu. Ogólnie uważam, że jest to nieszkodliwa zmiana stanu w porównaniu ze złożeniem zamówienia, przekazaniem środków lub aktualizacją adresu e-mail.
Jeśli chodzi o zmiany stanu i metody HTTP, RFC 2616 mówi, co następuje:
W szczególności ustanowiono konwencję, że metody GET i HEAD NIE POWINNY mieć znaczenia innego niż odzyskanie. Metody te należy uznać za „bezpieczne”.
Magento i CSRF
Magento implementuje mechanizm zapobiegania CSRF zarówno dla obszarów administracyjnych, jak i frontendowych za pomocą tokena (klucza formularza). Zakładam, że celem Magento, jako platformy przeznaczonej do budowania przez innych programistów, jest zabezpieczenie wszystkich żądań zmieniających stan. Powodem jest to, że nie mają pojęcia, co deweloperzy wdrażający lub rozszerzenia innych firm mogą przypadkowo ujawnić. Bezpieczniej jest zabezpieczyć wszystkie żądania zmieniające stan niż mieć coś ujawnionego przez moduł innej firmy i mieć zły PR dla platformy. Nie wiem, czy wszystkie żądania zmiany stanu są zabezpieczone przed atakami CSRF.
Należy zauważyć, że Magento nie zawsze używa klucza formularza do ochrony żądań zmieniających stan. Na przykład żądania Usuń z koszyka ( /checkout/cart/delete/id/{ID}) i Usuń adres klienta ( /customer/address/delete/id/{ID}) to żądania GET, które przekazują identyfikator jednostki. Kontroler (lub modele) następnie zapewniają, że użytkownik jest uprawniony do usunięcia tych rekordów encji (zmiany stanu). Są to dwa przypadki, w których Magento nie stosuje się do RFC 2616 . Szczerze mówiąc, w niektórych przypadkach użycia może nie być to praktyczne lub konieczne.
Wygląda na to, że kontrola klucza formularza w Mage_Checkout_CartController::addActionmetodzie została dodana w wersji 1.8. Z informacji o wersji mamy następujące:
Rozwiązane problemy, które mogły spowodować fałszowanie żądań między witrynami (CSRF) w sklepie internetowym.
Niestety, język jest niejasny, a słowo „mógł mieć” prowadzi mnie do przekonania, że wynikało to z wcześniejszego założenia: bezpiecznego żądania zmiany stanu. Może istnieć możliwość wysłania dodatkowych parametrów, które powodują pewne niezamierzone zachowanie:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
Chodzi o to, że po dodaniu czegoś do koszyka pojawia się trochę kodu (rdzeń lub strona trzecia), który jest uruchamiany podczas dodawania do koszyka, np. Poprzez wysłanie zdarzenia.
Wydaje się mało prawdopodobne, aby taka luka istniała od razu po wyjęciu z pudełka, a gdyby tak się stało, można mieć nadzieję, że Magento lepiej poradziłby sobie z ujawnieniem szczegółów / ryzyka. Jednym z zagrożeń, które widziałem, jest to, że Magento ślepo przechowuje parametry żądania podczas dodawania do koszyka w product_optionskolumnie tabeli pozycji zamówienia sprzedaży (patrz info_buyRequest:). Teoretycznie ktoś może nakłonić grupę użytkowników do dodania elementów do koszyka za pomocą dziwnych parametrów zapytań, które zostaną zapisane w sales_flat_quote_item_optiontabeli, a ostatecznie w sales_flat_order_itemtabeli, jeśli będą oni również w stanie przekonać tych użytkowników do konwersji. W większości przypadków wydaje mi się to mało prawdopodobne.
Dodaj do koszyka Kluczowe problemy
Jednym z głównych problemów, na jakie napotykają ludzie przy implementacji FPC i tokenach CSRF, jest to, że kończą się buforowaniem. Pierwszy klient, który ogrzewa pamięć podręczną, generuje token, a gdy drugi klient otrzyma HIT pamięci podręcznej, otrzymuje teraz stronę z tokenem pierwszego użytkownika. Podczas przesyłania formularza tokeny nie będą pasować.
Magento Enterprise używa symboli zastępczych do znajdowania / zastępowania kluczy formularzy na buforowanych stronach. Implementacje lakieru będą podobnie używać ESI wszędzie tam, gdzie używany jest klucz formularza.
Byłbym ciekawy, czy niektóre bardziej popularne rozszerzenia „Cart Cart” kończą sprawdzanie tokena CSRF podczas ich dodawania do koszyka.
Jedną z funkcji, w której kończę rezygnację z tokena CSRF dla akcji „dodaj do koszyka”, jest możliwość tworzenia linków „dodaj do koszyka” do użycia w wiadomościach e-mail lub innych witrynach internetowych (media społecznościowe). Czasami marketing chce, aby użytkownicy bezpośrednio dodawali produkt do koszyka i natychmiast przekierowywali go do koszyka lub do kasy. Nie można tego łatwo zrobić, jeśli wymagany jest token CSRF. Polecam to tylko wtedy, gdy czujesz się komfortowo na poziomie ryzyka i ufasz swojemu i dowolnemu kodowi strony trzeciej.