Какие знаешь уязвимости

Ответ

  1. XSS (Cross-Site Scripting) — внедрение вредоносного кода в страницу.
    Пример:
    // Уязвимый код
    document.getElementById('output').innerHTML = userInput;
Защита: экранирование (`textContent`), CSP, санитизация (DOMPurify).
  1. CSRF (Cross-Site Request Forgery) — выполнение действий от имени пользователя без его ведома.
    Защита: CSRF-токены, SameSite cookies.

  2. CORS Misconfiguration — неправильная настройка заголовков CORS, позволяющая доступ с любых доменов.
    Пример уязвимости:

    Access-Control-Allow-Origin: *
  1. Инъекции (SQL, NoSQL, Template) — передача небезопасных данных в запросы.
    Пример (NoSQL):
    // Уязвимый запрос
    db.users.find({ login: req.body.login });
  1. Утечка данных — например, через console.log, хранение токенов в localStorage.

  2. Clickjacking — наложение прозрачного iframe на кнопки для скрытого клика.
    Защита: заголовок X-Frame-Options: DENY.

  3. Небезопасные зависимости — использование устаревших пакетов с уязвимостями (проверка через npm audit).

Всегда: валидация, экранирование, HTTPS, принцип минимальных привилегий.

Ответ 18+ 🔞

Слушай, ну вот сидишь ты, пишешь свой код, всё красиво, всё работает. А потом бац — и какой-нибудь ебаный гений с соседнего IP-адреса тебе всю логику ломает, потому что ты, как последний распиздяй, про безопасность забыл. Давай по полочкам, но без занудства.

1. XSS (или "ебушки-воробушки, дай я в твой HTML свою хуйню вставлю") Это когда злоумышленник может впихнуть свой скрипт в твою страницу, и он выполнится у всех пользователей. Представь, в поле для комментария кто-то напишет не "Привет", а <script>alert('Ты лох');</script>.

// Вот так делать — это пиздец как нельзя.
document.getElementById('output').innerHTML = userInput; // userInput может быть тем самым скриптом

Что делать? Не лепить всё в innerHTML как попало. Используй textContent, либо санитайзуй ввод библиотеками вроде DOMPurify. И голову Content-Security-Policy (CSP) настрой — это как сказать браузеру: "слушай, выполняй скрипты только оттуда, откуда я скажу, а не откуда попало".

2. CSRF (или "чувак, ты даже не представляешь, что только что лайкнул") Пользователь залогинился на твоём сайте. Потом он заходит на левый сайт, а там невидимый <form>, который от его имени на твоём сайте деньги переводит. И браузер тупо отправляет куки с авторизацией. Во, блядь, сюрприз! Защита: Используй CSRF-токены (уникальные для каждой сессии) и выставляй кукам атрибут SameSite=Strict. Это как поставить замок на дверь, а не просто табличку "не входить".

3. CORS (или "добро пожаловать, все кому не лень!") Ты на бэкенде пишешь что-то вроде:

Access-Control-Allow-Origin: *

И думаешь: "ну и чё, всем же удобно". А потом оказывается, что твой API дербанит пол-интернета, потому что доступ разрешён буквально с любого говносайта. Подозрение ебать чувствую, когда вижу звёздочку в продакшене. Разрешай только конкретные, нужные тебе домены.

4. Инъекции (SQL, NoSQL и прочая нечисть) Тут всё просто: никогда не доверяй пользовательскому вводу. Никогда. Вот смотри, уязвимый код на Node.js с MongoDB:

db.users.find({ login: req.body.login }); // А если в login передать {"$ne": null}?

И всё, можно всех пользователей получить. Волнение ебать — просто представь эту картину. Всегда используй параметризованные запросы или специальные методы ORM/ODM, которые экранируют данные за тебя.

5. Утечка данных (или "ой, а что это у меня в консоли?") Ты для отладки написал console.log(process.env.DB_PASSWORD) и забыл. Или хранишь JWT-токен в localStorage, откуда его любой XSS может спиздить. Это уровень "сам от себя охуел". Секреты — в переменные окружения, критичные данные на клиенте — по минимуму, а лучше вообще без них.

6. Clickjacking (или "нажми сюда, чтобы получить пизды") На твой сайт накладывают прозрачный iframe, а сверху кнопку "Получить миллион". Пользователь кликает на миллион, а на самом деле подтверждает перевод на Кипр. Защита проще некуда: заголовок X-Frame-Options: DENY или Content-Security-Policy: frame-ancestors 'none'. Всё, теперь твои страницы нельзя встраивать.

7. Зависимости (или "а что у нас в node_modules сегодня?") Ты ставишь пакет left-pad, а там внутри лежит rm -rf /. Шутка. Но не очень. Запусти npm audit, посмотри, какие библиотеки у тебя с дырами. Обновляйся. Не тащи в проект библиотеки с последнего пиратского форума.

Итог, блядь: Валидируй всё, что приходит от пользователя. Экранируй данные перед выводом. Используй HTTPS. Давай права по принципу "минимально необходимых". И не ленись читать документацию по безопасности для своего фреймворка. А то потом будет "удивление пиздец", когда всё полетит к чертям.