Към съдържанието
wannacode

JWT и капаните му

Накратко: JWT е подписан токен от header, payload и подпис; payload-ът не е криптиран и се чете от всеки, а сървърът трябва сам да проверява алгоритъма, подписа и exp.

Проблем

Токенът, който стана admin

Мобилното приложение на магазина не ползва страници, а API. Екипът избира JWT, „за да не пази сървърът сесии“, и копира проверката на токена от стара статия в блог. Месеци по-късно изследовател на сигурността пише на магазина: с токен, който е написал на ръка, е влязъл в API-то за възстановяване на пари като admin.

Ключът на магазина не е изтекъл. Паролата на администратора също. Изследователят не е разбил нищо: проверката сама е приела токена му.

Идеята

Подписан пропуск

Сесията от предишния урок е номерче от гардероба: сървърът пази таблица кой е зад всяко id. JWT (JSON Web Token) е друг подход: самият токен казва кой си и до кога важи, а сървърът го подписва, за да не може да се промени.

Токенът има три части, разделени с точки:

  • header: как е подписан, например {"alg":"HS256","typ":"JWT"};
  • payload: какво казва, например {"sub":"maria","exp":1793000900}. sub е потребителят, exp е моментът на изтичане в секунди от 1.1.1970;
  • подпис: HMAC-SHA256 върху „header.payload“ с таен ключ на сървъра.

Header-ът и payload-ът са JSON, записан в base64url: base64 с - и _ вместо + и / и без = накрая, за да става за адрес и заглавка. Base64url е запис, не криптиране. Токенът е подписан, не таен: всеки го чете, но без ключа никой не може да го промени, без подписът да спре да съвпада.

Виж го

Трите части и подправеният токен

def verify(token, now):
    parts = token.split(".")
    if len(parts) != 3:
        return "✗ формат"
    # алгоритъмът е закован: не го взимаме от токена
    if json.loads(decode(parts[0])).get("alg") != "HS256":
        return "✗ алгоритъм"
    mac = sign(parts[0] + "." + parts[1]).encode()
    if not hmac.compare_digest(mac, parts[2].encode()):
        return "✗ подпис"
    claims = json.loads(decode(parts[1]))
    exp = claims.get("exp")
    if not isinstance(exp, int) or now >= exp:
        return "✗ изтекъл"
    return "✓ " + claims["sub"]
Стъпка по стъпка, с думи
  1. Header-ът казва как е подписан токенът: HS256. JSON-ът става текст в base64url.
  2. Payload-ът казва кой и до кога: sub maria, exp след 15 минути. Също base64url.
  3. Подписът е HMAC-SHA256 върху „header.payload“ с ключа на сървъра. Без ключа никой не може да го направи.
  4. Токенът е трите части с точки. Мобилното приложение го праща с всяка заявка.
  5. Който има токена, чете payload-а без ключ: base64url не е криптиране. Подписан е, не е таен.
  6. Сега подправен токен: header-ът казва alg none, payload-ът казва sub admin, а подпис няма.
  7. Наивната проверка пита токена кой алгоритъм да ползва. „none“ прескача подписа и admin влиза.
  8. Поправката заковава алгоритъма: само HS256, решено от сървъра. alg none е отказан преди всичко друго.
  9. Истински, но стар токен: подписът е верен, но exp е минал. Наивната проверка го пусна, тази не.
  10. Три проверки в този ред: алгоритъмът, избран от сървъра, подписът, срокът. Payload-ът никога не е тайна.

Подписът и base64url са в стандартната библиотека на всеки език. Ключът тук е демо: истинският е 32 случайни байта, пазени извън кода (урокът „Тайни“).

KEY = b"demo-key-only-for-this-lesson"  # демо ключ; истинският е 32 случайни байта от хранилище за тайни




def b64(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()




def encode(obj):
    return b64(json.dumps(obj, separators=(",", ":")).encode())




def sign(data):
    return b64(hmac.new(KEY, data.encode(), hashlib.sha256).digest())
def issue(user, exp):
    header = {"alg": "HS256", "typ": "JWT"}
    payload = {"sub": user, "exp": exp}
    data = encode(header) + "." + encode(payload)
    return data + "." + sign(data)
json.dumps(…, separators=(",", ":")) пише JSON без интервали, както другите езици. base64.urlsafe_b64encode слага = накрая, затова rstrip(b"=") ги маха.

Токен за Мария, който важи 15 минути:

now = 1_793_000_000
token = issue("maria", now + 900)
parts = token.split(".")
print("header:  " + parts[0])
print("payload: " + parts[1])
print("подпис:  " + parts[2])
print("payload без ключ:", decode(parts[1]))
Изход
header:  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
payload: eyJzdWIiOiJtYXJpYSIsImV4cCI6MTc5MzAwMDkwMH0
подпис:  mXfW7XuQCRb8pXyoR6d687Dzn8zr5Y5uET-UFxEvOKw
payload без ключ: {"sub":"maria","exp":1793000900}

Ключът и „сега“ са фиксирани, затова токенът е един и същ при всяко пускане и на четирите езика. Последният ред е payload-ът, прочетен без ключа.

Пробвай

Предвиди изхода

Някой е хванал токена на Мария. Ключ няма. Какво ще отпечата?

token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJtYXJpYSIsImV4cCI6MTc5MzAwMDkwMH0.mXfW7XuQCRb8pXyoR6d687Dzn8zr5Y5uET-UFxEvOKw"
payload = token.split(".")[1]
print(base64.urlsafe_b64decode(payload + "=" * (-len(payload) % 4)).decode())
Отговор

Идеята

Капан 1: алгоритъмът идва от токена

Ето проверката от статията. За да чете header и payload, тя ползва две помощни функции:

def decode(part):
    return base64.urlsafe_b64decode(part + "=" * (-len(part) % 4)).decode()
# НЕ ТАКА: вярва на алгоритъма от самия токен
def naive_verify(token):
    parts = token.split(".")
    alg = json.loads(decode(parts[0]))["alg"]
    if alg == "HS256":
        if sign(parts[0] + "." + parts[1]) != parts[2]:
            return "✗ подпис"
    # "none": токенът сам казва, че няма подпис
    return "✓ " + json.loads(decode(parts[1]))["sub"]

Тя чете alg от header-а и проверява подписа само ако там пише HS256. Стандартът наистина има алгоритъм none: „токен без подпис“. Ето четири токена: истинският, същият с подменен payload, ръчно написан токен с alg: none, sub: admin и празен подпис, и истински, но изтекъл токен:

now = 1_793_000_000
good = issue("maria", now + 900)
p = good.split(".")
admin = encode({"sub": "admin", "exp": now + 900})
# подменен payload, старият подпис
changed = p[0] + "." + admin + "." + p[2]
# alg: none и никакъв подпис
none = encode({"alg": "none", "typ": "JWT"}) + "." + admin + "."
old = issue("maria", now - 60)
print("истински:", naive_verify(good))
print("подменен payload:", naive_verify(changed))
print("alg: none:", naive_verify(none))
print("изтекъл:", naive_verify(old))
Изход
истински: ✓ maria
подменен payload: ✗ подпис
alg: none: ✓ admin
изтекъл: ✓ maria

Подменен payload се хваща, защото подписът спира да съвпада. Но alg: none пуска admin без никакъв подпис, а изтеклият токен минава, защото exp не се гледа. Header-ът е вход от потребителя, като всичко в токена, докато подписът не е проверен (урокът „Недоверен вход“). Проверка, която пита токена как да го провери, вярва на атакуващия.

Виж го

Поправката: три проверки в ред

def verify(token, now):
    parts = token.split(".")
    if len(parts) != 3:
        return "✗ формат"
    # алгоритъмът е закован: не го взимаме от токена
    if json.loads(decode(parts[0])).get("alg") != "HS256":
        return "✗ алгоритъм"
    mac = sign(parts[0] + "." + parts[1]).encode()
    if not hmac.compare_digest(mac, parts[2].encode()):
        return "✗ подпис"
    claims = json.loads(decode(parts[1]))
    exp = claims.get("exp")
    if not isinstance(exp, int) or now >= exp:
        return "✗ изтекъл"
    return "✓ " + claims["sub"]
  1. Алгоритъмът е закован. Сървърът знае, че подписва с HS256, и не приема нищо друго. none спира тук.
  2. Подписът се сравнява за постоянно време, както CSRF токенът в предишния урок.
  3. exp е задължителен. Токен без exp или с минал exp е отказ.

Същите четири токена:

now = 1_793_000_000
good = issue("maria", now + 900)
p = good.split(".")
admin = encode({"sub": "admin", "exp": now + 900})
# подменен payload, старият подпис
changed = p[0] + "." + admin + "." + p[2]
# alg: none и никакъв подпис
none = encode({"alg": "none", "typ": "JWT"}) + "." + admin + "."
old = issue("maria", now - 60)
print("истински:", verify(good, now))
print("подменен payload:", verify(changed, now))
print("alg: none:", verify(none, now))
print("изтекъл:", verify(old, now))
Изход
истински: ✓ maria
подменен payload: ✗ подпис
alg: none: ✗ алгоритъм
изтекъл: ✗ изтекъл

Пробвай

Попълни

Кой алгоритъм приема проверката?

if json.loads(decode(parts[0])).get("alg") != "":
    return "✗ алгоритъм"

Пробвай

Намери грешката

Тази проверка заковава HS256 и сравнява подписа правилно. Но една стара версия на приложението издаваше токени без exp, а те и днес работят. На кой ред е грешката?

Избери реда с грешката.

Идеята

Капан 2: къде стои токенът и как се отменя

localStorage. Уеб приложенията често пазят JWT в localStorage, защото е удобно. Но всеки скрипт на страницата чете localStorage. Една XSS дупка и чуждият скрипт праща токена на атакуващия, който го ползва до изтичането му. Подписът не помага: токенът не е подправен, а откраднат цял. В браузъра по-сигурното място е бисквитка с HttpOnly, но тогава тя тръгва сама и трябва защитата от CSRF от предишния урок.

Отмяна. Сървърът проверява само подписа и exp. Ако телефонът на Мария е откраднат, токенът ѝ работи до exp, дори да смени паролата си. Затова токените за достъп са кратки (5 до 15 минути), а дългият вход е с refresh токен, който сървърът пази и може да изтрие. Друг начин е списък с отменени токени на сървъра, но тогава сървърът пак пази състояние, както при сесията.

Кога сесията е по-проста. Ако имаш един уеб сайт с един сървър, бисквитката със сесия от предишния урок е по-простото решение: отменя се, като изтриеш реда, няма подпис за проверяване и няма алгоритъм, който да се обърка. JWT има смисъл, когато токена го проверяват много услуги без обща таблица със сесии, или между различни фирми (вход с Google е OpenID Connect, а той е JWT).

По-точно, за любопитните

Библиотеките. В истински проект JWT не се пише на ръка: Java има jjwt, java-jwt (Auth0) и Nimbus JOSE + JWT; C# има Microsoft.IdentityModel.JsonWebTokens, а ASP.NET Core проверява токените с AddJwtBearer; Python има PyJWT; Node има jsonwebtoken и jose. И с библиотека алгоритъмът се заковава изрично: jwt.decode(token, key, algorithms=["HS256"]) в PyJWT, jwt.verify(token, key, { algorithms: ["HS256"] }) в jsonwebtoken, ValidAlgorithms в TokenValidationParameters, verifyWith(key) в jjwt. Старите версии на някои библиотеки приемаха none, когато не им кажеш алгоритъма.

RS256 и ES256. С тях подписва частен ключ, а проверява публичен: така много услуги проверяват, без да могат да подписват. Тогава има и друг капан, объркване на алгоритъма: сървър, който очаква RS256, но пита токена, може да приеме HS256 с публичния ключ като HMAC ключ. Поправката е същата: закован алгоритъм.

Други полета. iat (кога е издаден), nbf (не по-рано от), aud (за коя услуга е), iss (кой го е издал), jti (уникално id, за отмяна). Часовниците на сървърите се разминават, затова библиотеките позволяват няколко секунди толеранс при exp.

Криптиран JWT има (JWE), но рядко трябва: по-просто е да не слагаш тайни в токена.

Упражнение

Изход от всички устройства

Реши задачата в редактора си.

Мария губи телефона си и натиска „Изход от всички устройства“. Добави в payload-а jti, случайно уникално id на токена. Напиши logout, който записва jti на токена в множество от отменени, и проверка, която след verify отказва отменения токен с „✗ отменен“. Новият вход дава нов токен, който работи.

Изход
преди изхода: ✓ maria
след изхода: ✗ отменен
нов вход: ✓ maria

Още задачи

  • Кратък живот. Направи токена за достъп 5 минути и добави refresh токен, който се пази на сървъра в таблица. Какво трябва да изтриеш при „Изход от всички устройства“ сега?
  • Чистене. Отмененото jti трябва да се пази само докато токенът и без това не изтече. Пази и exp и махай старите записи.

Тест

Провери се

1. Кой може да прочете payload-а на JWT?
2. Защо проверката заковава алгоритъма (само HS256), вместо да го прочете от header-а?
3. Уеб приложение пази JWT в localStorage. Какво става, ако страницата има XSS дупка?
4. Телефонът на Мария е откраднат, а токенът на приложението важи 30 дни. Какво може магазинът?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·