Czy jeśli chcemy zabezpieczyć się przed atakami typu CSRF to czy CSRF token powinien być tylko dodawany jako dodatkowe pole w formularzu czy też CSRF token powinien być wysyłany przy każdym requeście HTTP ?
0
1
puchatek11 napisał(a):
Czy jeśli chcemy zabezpieczyć się przed atakami typu CSRF to czy CSRF token powinien być tylko dodawany jako dodatkowe pole w formularzu czy też CSRF token powinien być wysyłany przy każdym requeście HTTP ?
Wszystko jedno.
Idea jest taka żeby zescrapowanie tokenu było jak najtrudniejsze dla chcącego wysłać request. Możesz go wrenderować jako pole w formularzu, jako tag, wyrenderować zmienną w widoku. Najlepiej zrobić to tak, żeby Twój formularz miał do niego łatwy dostęp, ale trudno go było wyciągnąć automatycznie.
Często widzę jak ludzie dodają po prostu tag <div class="csrf">tutaj mój token</div>, i myślę - boże, przecież to niweluje całą ideę. Gość w selenium zrobi getElementByClassName("csrf") i masz po sprawie. Chodzi o to żeby komuś się nie opłacało fałszować requestu, bo wyciąganie tego tokenu jest za trudne.
Możesz też zmieniać miejsce z którego go bierzesz, np w parzyste godziny wstawiać go w tag, a w nieparzyste w atrybut :D
2
@Riddle: trochę przesadzasz, idea csrf polega na tym by ktoś podsyłając ci linka nie ukrył tam np usuwania konta. Tradycyjnie csrf to najzwyklejsze pole hidden w formularzu i jest to wystarczające by spełnić założenia obrony przed tym atakiem.
0
ehhhhh napisał(a):
@Riddle: trochę przesadzasz, idea csrf polega na tym by ktoś podsyłając ci linka nie ukrył tam np usuwania konta.
Noo, nie wiem czy taka była idea.
Ja byłem przekonany że to po to żeby nie dało się po prostu "strzelić pod endpoint", tylko trzeba było najpierw sparsować response formularza.
To z tym wysyłaniem trefnych linków, to nie jestem do końca przekonany, bo jak wkleisz link to przeglądarka strzeli pod niego GET, plus tam ukryjesz jedynie query params.
Tradycyjnie csrf to najzwyklejsze pole hidden w formularzu i jest to wystarczające by spełnić założenia obrony przed tym atakiem.
Zgadzam się że jest to najczęściej implementowane w taki sposób, co nie znaczy że dobrze.
3
Jest dobrze, bo potwierdza że formularz wysłał ten kto go wyrenderował + robi to świadomie.
0
Czyli przy strzałach do endpointów csrf tokena się nie używa żeby się zabezpieczyć przed atakami typu CSRF ?
0
@puchatek11: nie używa bo i nie ma potrzeby. We frameworkach jak dajesz coś do api to automatycznie wyłączają csrf dla tych endpointów.
0
ehhhhh napisał(a):
@puchatek11: nie używa bo i nie ma potrzeby. We frameworkach jak dajesz coś do api to automatycznie wyłączają csrf dla tych endpointów.
"jak dajesz coś do api". Co to jest te "coś" ? Bo nie rozumiem do końca co miałeś na myśli.
2
Riddle napisał(a):
Często widzę jak ludzie dodają po prostu tag
<div class="csrf">tutaj mój token</div>, i myślę - boże, przecież to niweluje całą ideę. Gość w selenium zrobigetElementByClassName("csrf")i masz po sprawie.
Nie, nie może nikt zrobić getElementByClassName bo nie można czytać danych z innej strony chyba że poluzujemy cross origin policy przez CORS. Idea jest taka żeby inna strona nie mogła w imieniu użytkownika wysłać danych, a nie żeby utrudnić spreparowanie requesta w zewnętrznym sofcie. Przecież skoro twoja aplikacja może to zrobić to każdy może to zrobić używając zewnętrznego softu poza przeglądarką, ukrywanie tego to security by obscurity. W ogóle nie o to chodzi
1
Jako ciekawostkę powiem, że jak masz tylko API i strzały jakimś ajaxem z frontu to wydaje się, że wystarczającą ochroną przed CSRF jest dodanie jakiegokolwiek customowego headera nawet ze stałą wartości, typu X-Requested-With: <cośtam>.
Przy odpowiednich ustawieniach CORS przeglądarki nie pozwolą dodać customowego headera z innego origina niż twoja apka.