21

Re: Чи обов'язково серверне печиво повинно бути HttpOnly ?

Одним словом, якщо в тебе є куки сесії, то вважай що авторизований, якщо не авторизований, то сервер тобі так і скаже, тобі просто треба передбачити обробку такої відповіді.

Подякували: FakiNyan, ostap34PHP2

22

Re: Чи обов'язково серверне печиво повинно бути HttpOnly ?

Q-bart написав:

JWT - ні, його можна підписати. А refresh - uuid і зберігаєм в БД

Є різні реалізації. Те що я написав дозволяє мати багато рефреш токенів на різних пристроях і обнуляти їх при потребі. Зрештою БД дозволяє зробити те саме. Питання чисто функціоналу, що треба зробити.

23

Re: Чи обов'язково серверне печиво повинно бути HttpOnly ?

Vo_Vik написав:

Одним словом, якщо в тебе є куки сесії, то вважай що авторизований, якщо не авторизований, то сервер тобі так і скаже, тобі просто треба передбачити обробку такої відповіді.

ну я це зрозумів, я думав, як мені зрозуміти, чи я авторизований, ще до того, як перший запит до серверу скаже мені, що я неавторизований. Бо в залежності від того, чи я авторизований, юзеру можуть бути доступними деякі сторінки (клієнтська частина в мене на Angular, так що сервер повертає лише сирі дані, а не html), і спочатку показувати йому одну сторінку, а після зафейленого запиту іншу - якось не круто.
Я тут думаю, може завжди робити один запит, коли юзер відкриває будь-яку сторінку мого додатку, і той запит буде слугувати перевіркою авторизації, а поки запит виконується - буду показувати якогось спінера?

24

Re: Чи обов'язково серверне печиво повинно бути HttpOnly ?

Ані автентифікація за допомогою реп'яхів, ані JWT не захищенні від MITM атак. Для цього є https. В першому випадку, можна перехопити id сессії, а другому - JWT.

З Вашого опису я зрозумів, що JWT використовувався майже так само як і session id - валідація стану автентифікації. Переваги JWT полягають у тому, що на відміну від session id, для його валідації не треба лізти до бази (чи кешу), а також, забута Вами головна "фішка", він може містити довільні дані, а id сессії - лише айді сессії. Зазвачай ці дані - інформація про юзера.

Розглянемо наступний приклад: існує захищенний API ендпоїнт для запитів імені поточного (автентифікованого) юзера.
1) Session Id
1.1) Юзер автентифікується, отримує session_id. Робиться запис до бази {session_id, user_id}.
1.2) Юзер надсилає запит з session_id
1.3) Сервер перевіряє чи існує session_id в базі/кеші, та який user_id цій сессії відповідає
1.4) Сервер робит запит про інформацію юзера user_name знову з бази і повертає користувачеві

З мінусів:
- 2 додаткових запити до бази
- треба пільнувати старі сессії, інвалідувати їх
З плюсів:
- відомо які сесії активні
- логування сесії "за дизайном"

2) JWT
2.1) Юзер автентифікується, отримує токен JWT(user_name) ~ (далі) JWT з зашифрованим user_name
2.2) Юзер надсилає запит з JWT
2.3) Сервер дешифрує JWT, отримує user_name і надсилає назад

З мінусів:
- розмір JWT більший і пропорційний кількості додаткових даних вкладених до нього
- додаткові витрати на шифрування/дешифрування

З плюсів:
- довільні дані про юзера одразу в токені
- жодних запитів до бази для перевірки стану автентифікації
- при добрій імплементації, можна також позбутися запитів до бази для авторизації

Подякували: leofun01, ostap34PHP2

25

Re: Чи обов'язково серверне печиво повинно бути HttpOnly ?

при добрій імплементації, можна також позбутися запитів до бази для авторизації

це при якій? адже ім'я з паролем зберігаються в базі, а вони потрібні для порівняння того, що надсилає юзер, коли логіниться

26

Re: Чи обов'язково серверне печиво повинно бути HttpOnly ?

FakiNyan написав:

Я помітив, що ці куки мають прапорець HttpOnly, і виявляється, що через це вони недоступні для читання на стороні клієнта.

Встановлюйте HttpOnly для всіх куків, до яких клієнтський код (JavaScript) не повинен мати доступ.
Памятайте, що наявність заголовка HttpOnly не гарантує того, що клієнт (або його скріпти) не отримає доступ до таких куків. Але з HttpOnly більшість клієнтів будуть захищені від деяких видів атак.
Secure & HttpOnly cookies

27

Re: Чи обов'язково серверне печиво повинно бути HttpOnly ?

iovchynnikov написав:

2) JWT
2.1) Юзер автентифікується, отримує токен JWT(user_name) ~ (далі) JWT з зашифрованим user_name
2.2) Юзер надсилає запит з JWT
2.3) Сервер дешифрує JWT, отримує user_name і надсилає назад

З мінусів:
- розмір JWT більший і пропорційний кількості додаткових даних вкладених до нього
- додаткові витрати на шифрування/дешифрування

З плюсів:
- довільні дані про юзера одразу в токені
- жодних запитів до бази для перевірки стану автентифікації
- при добрій імплементації, можна також позбутися запитів до бази для авторизації

Ну... Це ж спрощений приклад, рідко коли треба отримати лише user_name. +- завжди, захищені запити потребують отримати всього юзера з БД. Тому як мінімум один запит буде.

Подякували: leofun011

28

Re: Чи обов'язково серверне печиво повинно бути HttpOnly ?

FakiNyan написав:

при добрій імплементації, можна також позбутися запитів до бази для авторизації

це при якій? адже ім'я з паролем зберігаються в базі, а вони потрібні для порівняння того, що надсилає юзер, коли логіниться

Не плутайте авторизацію з автентифікацією. Якщо зберігати ролі/дозволи користувача, то для його авторизації не треба лізти до бази.

29

Re: Чи обов'язково серверне печиво повинно бути HttpOnly ?

аа, це типу, при авторизації дістаємо об'єкт юзер з бд, встановлюємо йому якесь поле в true, і тримаємо в пам'яті. А коли приходить реквест, то чекаємо, від якого юзера воно прийшло, і чекаємо, чи цей юзер має те саме поле встановлене в true?