Безопасность

Security capstone: чтение кода и конфигов

Суть Читай реальные сниппеты auth/веб-приложения поперёк трека — валидация JWT, объектная авторизация, конфиг куки/CSRF, хранение паролей — и выбирай фикс с наибольшим рычагом, который security-сеньор делает первым.

Высота — путь к senior

НольJuniorMiddleSenior

Ты на senior-высоте — в орбите

◷ 14 min

Баги безопасности читаются в коде и конфигах, а не в лозунгах. Каждый сниппет ниже — небольшой кусок реального стека безопасного приложения. Прочитай, найди шов и выбери фикс, который сеньор делает раньше всего — тот же цикл, что и на ревью или в инциденте.

Цель

Отработай цикл ревью поперёк всего трека: заметь сломанную проверку токена, отсутствующую проверку владения, куку, которая снова открывает CSRF, и секрет, превращающий конфиг в брешь — затем выбери фикс с наибольшим рычагом.

Сниппет 1 — верификация токена

// Express-мидлварь, защищающая API
function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(" ")[1];
  const claims = jwt.decode(token);          // только декод
  if (claims?.sub) {
    req.user = claims;                        // доверяем payload
    return next();
  }
  return res.status(401).end();
}

Викторина

Эта мидлварь аутентифицирует каждый запрос. В чём критический изъян и фикс?

Сниппет 2 — эндпоинт под OAuth

// access token уже верифицирован выше; req.user = { sub, scope }
app.get("/accounts/:id/statements", requireScope("statements:read"),
  async (req, res) => {
    const rows = await db.query(
      "SELECT * FROM statements WHERE account_id = $1", [req.params.id]
    );
    res.json(rows);
  });

Викторина

Токен валидирован и scope проверен. Пользователь с валидным токеном всё равно читает statements чужого аккаунта. Почему и в чём фикс?

Сниппет 3 — сессионная кука

res.cookie("session", token, {
  httpOnly: true,
  secure: true,
  // sameSite не задан
});

// в другом месте, «удобный» маршрут
app.get("/account/delete", deleteAccountHandler);  // изменение состояния на GET

Викторина

HttpOnly и Secure заданы, поэтому XSS не прочитает куку. Какая экспозиция CSRF остаётся и как её закрыть?

Сниппет 4 — конфиг и регистрация

// config.js (закоммичен в репо)
export const config = {
  dbPassword: "S3cr3t-prod-pw!",
  jwtSecret: "supersecret",
};

// регистрация
const hash = crypto.createHash("sha256").update(password).digest("hex");
await db.users.insert({ email, hash });

Викторина

В этих нескольких строках сидят два отказа поперёк трека. Назови оба и фикс для каждого.

Итог

Каждый сниппет был швом между двумя юнитами трека. jwt.decode ничего не аутентифицирует — верифицируй подпись и закрепляй алгоритм. Валидный токен и scope — это не владение; добавь объектную проверку owns(subject, object), чтобы убить IDOR. HttpOnly останавливает кражу через XSS, но не CSRF — задай SameSite, добавь токен и держи изменения состояния подальше от GET. А закоммиченный секрет уже взломан (ротируй, не удаляй), тогда как быстрый несолёный хеш отдаёт столбец паролей (используй Argon2id с солью на пользователя). Читай код, находи шов между правильными с виду слоями и чини структурный пробел.

Продолжить восхождение ↑Security capstone: модель угроз и харденинг веб-приложения