Bezpieczeństwo Cookie

Question

Cześć.

Mam zagwozdkę z cookie w aplikacjach REST API.  Otóż flaga HttpOnly Uniemożliwia w ataku xss zabaranie ma naszego ciacha. Więc nie da się go pobrać ani utworzyć za pomocą JS. Więc rodzi mi się pytanie jak sobie można poradzić z ustawieniem HttpOnly -> true. Próbowałem pobrać asynchronicznie z serwera ciastko, ale googlechrome nie dołącza go. Czy jest jakiś sposób na to?

Na froncie używam Angulara 9. 

Comments

Zerknij na te dwa pytania: https://stackoverflow.com/questions/8064318/how-to-read-a-httponly-cookie-using-javascript

https://stackoverflow.com/questions/11596485/get-httponly-cookies-with-javascript

Z tego co mi wiadomo nie da się tego zrobić przy użyciu javascriptu. 

---

 But there is an easy way to hijack a session despite the HTTPOnly flag. You can still ride on the session without knowing the session id. The MySpace Samy worm did just that. It used an XHR to read a CSRF token and then perform an authorized task. Therefore, the attacker could do almost anything that the logged user could do

Tego nie wiedziałem, że jest patent na zabranie ciastka mimo tej flagi. Nasuwa mi się jedno zdanie. Że tak naprawdę kluczową role robi serwer. Jeśli go dobrze zabezpieczmy w postaci sprawdzania np. sprawdzania zgodności adresów ip.(user podczas logowani wysyła swój ip i podczas trwania sesi jest sprawdzany ten ip) usera, to atakujący i tak będzie mieć access deny.  

---

Jak chcesz przechowywać poświadczenia użytkownika to powinieneś użyć Credential Management. Tu link do Google Google Web i Mozilla. Obecnie to najlepsze rozwiązanie. 

---

Dzięki za wskazówkę. Tylko finalnie nie rozumiem gdzie to jest przechowywane na froncie ? W indexDB ?

---

Na froncie. Gdzieś w przeglądarce. JavaScript nie może odczytywać tych wartości. Można je jedynie wysłać wraz z żądaniem.

---

W miejscu, do którego nie masz dostępu, bo nie ma absolutnie żadnego powodu, żebyś wiedział, jakie dane logowania ma user. Ciebie obchodzi jedynie to, czy serwer zaakceptował dane podane przez przeglądarkę.

Answer 1

Co chcesz osiągnąć? Bo jeśli chcesz autoryzować usera, to to powinien robić backend! Nie ma absolutnie żadnego powodu, dla którego potrzebujesz ściągać ciastko sesyjne z backendu. IMO bezpieczniej i wygodniej byłoby posłać do backendu request logowania i dostać w zwrotce token. Ten token później odsyłałbyś do backendu przy każdym żądaniu w nagłówku Authorization i serwer by sobie już weryfikował, czy wszystko jest ok.

Jeśli już naprawdę musisz pobrać, to opcja credentials w fetch albo withCredentials w XHR powinna Ci to umożliwić, ale tylko pod warunkiem, że serwer zwraca odpowiedni nagłówek.

Comments

IMO bezpieczniej i wygodniej byłoby posłać do backendu request logowania i dostać w zwrotce token. Ten token później odsyłałbyś do backendu przy każdym żądaniu w nagłówku Authorization i serwer by sobie już weryfikował, czy wszystko jest ok.

To tak też się dzieje. User za każdy razem kiedy o coś pyta musi wysyłać nagłówek a serwer już sobie weryfikuje na tej podstawie dostęp. Bo chciałem tylko i wyłącznie dążyć do tego aby cookie było dodatkowo zabezpieczone przed xss. Bo finalnie i tak jeśli ktoś mi ukradnie ciastko to serwer zweryfikuje jeszcze ip z kąt jest wysyłany a jaki był podczas logowania(Myślę, że to zabezpieczy przed niechcianą autoryzacją ? co Ty o tym sądzisz ?). Więc to tylko czysty dodatek.

---

No to jako forma obrony HttpOnly jest dobrym rozwiązaniem. Do tego można dorzucić flagę Secure i nie pozwalać na pobieranie ciastka Ajaxem. Można jeszcze pokusić się o SameSite, ale prawdę mówiąc nie wiem, jak się zachowa w takiej sytuacji – musiałbyś potestować.

---

Tylko tu jest problem, że ciężko bo nie znalazłem nigdzie żadnej publikacji jak w REST API na Angularze ogarniać HttpOnly aby móc to obsłużyć.

---

Hm… Chyba jednak nie rozumiem. Skoro autoryzacja i tak leci przez nagłówek Authorization, to do czego w tym jest potrzebne cookie?

---

To moja wina trochę zawile opisałem swój problem.

User wysyła login i hasło. Po poprawnej weryfikacji otrzymuje JWT token. Token jest wysyłany.

Front odbiera odpowiedź od serwera jaką jest token. A następnie wrzuca ją do ciastka. I kiedy user coś pyta serwer angular bierze ciastko i wstawia do nagłówka Authorization. Nie wiem czy to nie zbyt skomplikowałem to działanie. 

---

No ok… ale skoro to jest ciastko, z którego korzysta tylko front, to czemu je ustawiłeś tak, żeby dostęp do niego miał tylko serwer?

W takim wypadku po prostu zastosowałbym localStorage i tam przechowywał token. W ten sposób nie ma żadnego problemu, bo wyciągasz stamtąd bezpośrednio, bez kombinowania. Natomiast zabezpieczenie przed XSS-em i tak najpewniejsze gwarantuje Content Security Policy.

---

 

No ok… ale skoro to jest ciastko, z którego korzysta tylko front, to czemu je ustawiłeś tak, żeby dostęp do niego miał tylko serwer?

No dobra to mógł by tak zrobić, ale jak pobrać. Async w nagłówku nie za bardzo chce chrome dołączyć do ciastek. 

W takim wypadku po prostu zastosowałbym localStorage i tam przechowywał token. W ten sposób nie ma żadnego problemu, bo wyciągasz stamtąd bezpośrednio, bez kombinowania. Natomiast zabezpieczenie przed XSS-em i tak najpewniejsze gwarantuje Content Security Policy.

W sumie racja tego nie wziąłem po uwagę. I to jest w sumie może być rozwiązanie tego problemu. Dziękuje za pomoc