Liferay is a Gartner Magic Quadrant Leader for the Sixth Year! Find out why

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Jarosław Łakomy
Liferay podatny na ataki CSRF?
February 19, 2013 2:49 AM
Answer

Jarosław Łakomy

Rank: New Member

Posts: 6

Join Date: November 9, 2011

Recent Posts

Ostatnio miałem okazję uczestniczć w dyskusji o potencjalnej podatności platformy na ataki typu CSRF.

Jak mi się wydawało platforma w sposób odpowiedni zabezpiecza się przed tego typu atakami poprzez stosowanie mechanizmów "AuthenticationToken" czyli (http://www.liferay.com/community/wiki/-/wiki/Main/Authentication+Token)

Według drugiej strony w dyskusji:
1. token nie powinien być w parametrach GET-owych requestu tj. jeśli generujemy action url-a dla formularza to parametr p_p_auth powinien być polem formularza
2. token powinien być unikalny per request a nie jak to robi platforma per sesja ponieważ mimo użycia https-a parametr może wyciec

Moje spojrzenie na argumenty wygląda tak że po pierwsze nie ważne czy parametr jest wysyłany w ramach get czy post to jeśli miał bby być odkodowany w komunikacji to nie ma zupełnie znaczenia czy jest w sekcji url requestu http czy też w danych post-a. Ciekawa jest też dla mnie opcja ryzyka odkodowania requestu nawet przy użyciu https wydaje mi się sie to raczej mało prawdopodobne (w szczególności przy użyciu odpowiednio długiego klucza https)


Co wy sądzicie na ten temat? Czy Liferay powinien zmienić implementację tokenów dodawanych do action requestów. Czy powinny być one generowane per request czy raczej obawy o wyciek tokena są nieuzasadnione? Co wy sądzicie na ten temat? Jak zabezpieczacie aplikacje przed atakami typu CSRF?

Mam w zanadrzu leszcze kilka arguemntów ale nie chcąc nic sugerować najpierw licze na dyskusję ;)

Na dokładkę linki do stron OWASP.
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
Milen Dyankov
RE: Liferay podatny na ataki CSRF?
February 25, 2013 4:56 AM
Answer

Milen Dyankov

LIFERAY STAFF

Rank: Regular Member

Posts: 236

Join Date: October 30, 2012

Recent Posts

Hej,

Jarosław Łakomy:
Moje spojrzenie na argumenty wygląda tak że po pierwsze nie ważne czy parametr jest wysyłany w ramach get czy post to jeśli miał bby być odkodowany w komunikacji to nie ma zupełnie znaczenia czy jest w sekcji url requestu http czy też w danych post-a.


Z tym się zgadzam. Może ktoś ma jakiś przykład gdzie to ma znaczenie bo ja na ten moment nie jestem w stanie wymiślić.

Jarosław Łakomy:
token powinien być unikalny per request a nie jak to robi platforma per sesja ponieważ mimo użycia https-a parametr może wyciec


Nie będę udawał że jestem wielkim ekspertem od security ale wydaję mi się że to zbyt paranoiczne podejście. O ile dobrze rozumiem to CSRF, w dużym uproszczeniu, działa tak (na przykładzie Liferay.com)
  • jestem zalogowany na Liferay.com
  • odwiedzam jakieś hakerski site gdzie ktoś umieścił sprytny JS
  • JS uderza do Liferay.com i pobiera jakieś dane które tam są prezentowane bo jestem zalogowany

Token ma służyć jako dodatkowe zabezpieczenie tutaj bo atak pochodzi z tej samej przeglądarki która ma otwarta sesja do strony. Jeśli ktoś jest w stanie się do tego tokena dobrać to znaczy że jest w sanie się dobrać również to ciastka sesyjnego a tym samym odtworzyć moją sesje na swojej przeglądarce (czy innej aplikacji) i robić dalej co tylko zechce w moim imieniu.

Oczywiście można generować tokena per request - ale za jaką cenę? Biorąc pod uwagę ile jest (prawie że) jednoczesnych requestów do portalu należałoby przechowywać pula tokenów, zaimplementować timeout, .... Wydaję mi się praca jaką trzeba w to włożyć, plus narzut na wydajność oraz kompleksowość rozwiązania jest niewspółmierna do efektu.
Milen Dyankov
RE: Liferay podatny na ataki CSRF?
February 25, 2013 5:22 AM
Answer

Milen Dyankov

LIFERAY STAFF

Rank: Regular Member

Posts: 236

Join Date: October 30, 2012

Recent Posts

Zapomniałem dodać że jestem gotów się założyć że twój rozmówca pracuje (lub pracował) w banku ;)

Jeśli tak jest - to odpuść sobie. Token per request to standardowe podejście w bankowości elektronicznej (gdzie niema pop-up, nie można otworzyć strony w nowym oknie, brak różnych AJAX wodotrysków, ...) ale w przypadku typowych portali jest to moim zbyt ograniczające. Natomiast IT w bankowości jest wyczulone na temat security tak że nie masz szans go przekonać.