Перейти на PRO

Какие основные методы обеспечения безопасности веб-приложений ты знаешь?

Тип вопроса: HTTP и веб-протоколы Вероятность: 10% Категория: QA Тестировщик

Ответ

Основные методы защиты веб-приложений от распространённых уязвимостей (OWASP Top 10):

  1. Защита от инъекций (SQL, NoSQL, OS)

    • Как: Использование параметризованных запросов (prepared statements) или ORM.

    • Пример (Python/Psycopg2):

      # Уязвимый код
cursor.execute(f"SELECT * FROM users WHERE name = '{user_input}'")

# Безопасный код
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

  2. Защита от межсайтового скриптинга (XSS)

    • Как: Экранирование (escaping) пользовательских данных перед выводом в HTML/JS/XML.
    • Пример: Использовать textContent вместо innerHTML или шаблонизаторы с авто-экранированием (Jinja2, React).

  3. Защита от межсайтовой подделки запроса (CSRF)

    • Как: Использование CSRF-токенов, проверяемых на сервере для всех state-changing запросов (POST, PUT, DELETE).
    • Пример (форма Django): 
      <form method="post">
  {% csrf_token %}
  <!-- остальные поля -->
</form>

  4. Безопасная аутентификация и хранение паролей

    • Как: Хэширование паролей с использованием адаптивных алгоритмов (bcrypt, Argon2, PBKDF2) и уникальной соли (salt) для каждого пользователя.

  5. Использование HTTPS

    • Как: Принудительное использование TLS/SSL для всего трафика. Настройка HSTS (HTTP Strict Transport Security).

  6. Валидация и санация входных данных

    • Как: Строгая проверка всех входящих данных на стороне сервера по принципу "whitelist" (разрешённые символы/паттерны).

  7. Настройка заголовков безопасности HTTP

    • Как: Установка заголовков, таких как:
      • Content-Security-Policy (CSP) — для ограничения источников скриптов и стилей.
      • X-Frame-Options — для защиты от clickjacking.
      • X-Content-Type-Options: nosniff — чтобы браузер не "угадывал" MIME-тип.

Главный принцип: Не доверяй пользовательскому вводу. Всегда проверяй, экранируй и валидируй данные на стороне сервера.

Ответ 18+ 🔞

А, слушай, вот это тема — как не просрать своё веб-приложение к хуям собачьим. OWASP Top 10, эта десятка, которая как мантра для параноика. Ёпта, сейчас разжуем, но без паники.

Ну первое, что всех ебёт — это инъекции. SQL, NoSQL, OS — не суть. Суть в том, что какой-нибудь умник через форму ввода попробует тебе базу развалить. Как защищаться? Да не изобретай велосипед, блядь! Параметризованные запросы или ORM используй. Смотри, в чём разница между мудаком и адекватом:

# Вот так делать — это прям приглашение: "На, еби мой сервер, падла"
cursor.execute(f"SELECT * FROM users WHERE name = '{user_input}'")

# А вот так — уже по-человечески. Psycopg2 сам всё проэкранирует.
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

Видишь? Вместо того чтобы слепить строку как попало, ты передаёшь данные отдельно. База их обработает как данные, а не как команду. Проще говоря, ты не даёшь пользователю возможности впендюрить свою хуйню в твой SQL. Всё.

Дальше — XSS (межсайтовый скриптнг). Это когда злодей пытается впихнуть тебе в страницу свой скрипт, чтобы, например, куки воровать. Защита — экранирование, ёбта! Никогда не вставляй сырые пользовательские данные прямо в HTML через innerHTML. Используй textContent или, что ещё лучше, современные шаблонизаторы вроде Jinja2 или React — они по умолчанию всё экранируют. Если очень надо вставить HTML — санкционируй его, вырезай все теги кроме безопасных. Но вообще, подозрение ебать чувствую к таким задачам.

CSRF — это вообще хитрая жопа. Пользователь залогинен у тебя на сайте, а его в это время на какой-нибудь левый сайт заманили, и оттуда невидимо шлется запрос на твой сервер от его имени. "Переведи денег", например. Как бороться? CSRF-токены, блядь! Для всех важных запросов (POST, PUT, DELETE) генерируй уникальный токен, вкладывай его в форму, а на сервере проверяй. Вот как в Django:

<form method="post">
  {% csrf_token %} <!-- Вот эта строчка — твой телохранитель -->
  <!-- остальные поля -->
</form>

Без этого токена сервер запрос отфутболит. Красота.

Пароли. Ёперный театр, если ты хранишь пароли в открытом виде или даже в MD5 — ты полупидор. Хэшируй их адаптивными алгоритмами: bcrypt, Argon2, PBKDF2. И соль (salt) уникальную для каждого пользователя добавляй. Чтобы даже если утечка данных случится, взломать это было овердохуища сложно.

HTTPS. Это даже не обсуждается. В 2024 году без TLS/SSL — это просто пиздец. Настрой HSTS (HTTP Strict Transport Security), чтобы браузеры даже не пытались стучаться по HTTP.

Валидация входных данных. Вот тут главный принцип всей этой ебли: НЕ ДОВЕРЯЙ ПОЛЬЗОВАТЕЛЬСКОМУ ВВОДУ НИ НА ЙОТУ. Всегда, блядь, всегда проверяй данные на стороне сервера. И не по принципу "blacklist" (что запрещено), а по "whitelist" (что разрешено). Ждёшь номер телефона? Принимай только цифры, плюс и скобки. Ждёшь имя? Вырежи все теги и спецсимволы. Волнение ебать, но так надо.

И последний штрих — HTTP Security Headers. Поставь их, как замки на дверь.

  • Content-Security-Policy (CSP) — скажешь браузеру, откуда можно грузить скрипты и стили. Если скрипт попробует прилететь с левого домена — браузер его заблочит.
  • X-Frame-Options — защита от clickjacking, чтобы твою страницу нельзя было встроить в iframe на другом сайте и тыкать пользователя по невидимым кнопкам.
  • X-Content-Type-Options: nosniff — чтобы браузер не пытался "угадать" тип файла, а слушался того, что сказал сервер. Иначе какой-нибудь JPEG может внезапно исполниться как JS. Пиздец.

Короче, вся философия укладывается в одну фразу: относись ко всему, что приходит от пользователя, как к заражённому и потенциально враждебному. Валидируй, экранируй, хэшируй. И будет тебе счастье, а не взлом в 3 часа ночи, когда ты уже на второй бутылке.

© ХакСобесов, 2026
support@hacksobesov.com