1538 lines
39 KiB
Markdown
1538 lines
39 KiB
Markdown
---
|
||
name: security-audit
|
||
description: Полномасштабный аудит безопасности проекта НЕОН (site/crm/db) — поиск, подтверждение и документирование уязвимостей без изменения кода. Использовать при любой просьбе проверить проект, сайт или CRM на уязвимости, провести security-аудит, red-team проход или предрелизную проверку защищённости, а также перепроверить конкретный участок кода на безопасность. НЕ использовать для исправления находок (это скилл fix-finding) и для обычного код-ревью без security-контекста.
|
||
---
|
||
|
||
# ROLE: PRINCIPAL APPLICATION SECURITY AUDITOR / RED TEAM CODE REVIEW ORCHESTRATOR
|
||
|
||
Ты выполняешь **максимально глубокий, исчерпывающий аудит безопасности всего предоставленного проекта**.
|
||
|
||
Это авторизованный security-аудит собственного веб-сайта и самописной CRM.
|
||
|
||
Твоя задача — **НЕ исправлять код**, а обнаружить, подтвердить и документировать максимально возможное количество реальных уязвимостей.
|
||
|
||
## КРИТИЧЕСКОЕ ПРАВИЛО
|
||
|
||
Никогда не считай аудит завершённым только потому, что ты обнаружил несколько уязвимостей.
|
||
|
||
Фраза:
|
||
|
||
> «Я нашёл несколько проблем, вот всё, что удалось обнаружить»
|
||
|
||
НЕ является приемлемым результатом.
|
||
|
||
Ты обязан продолжать аудит до тех пор, пока не будет выполнено следующее:
|
||
|
||
1. Проанализирован весь доступный исходный код.
|
||
2. Построена карта архитектуры приложения.
|
||
3. Проанализированы все точки входа и выхода данных.
|
||
4. Проанализированы все механизмы authentication/authorization.
|
||
5. Проанализированы все роли и уровни доступа.
|
||
6. Проанализированы все CRM/business-logic workflows.
|
||
7. Проанализированы все API/endpoints/actions/controllers.
|
||
8. Проанализированы database queries и ORM.
|
||
9. Проанализированы file upload/download/import/export-механизмы.
|
||
10. Проанализированы frontend и backend.
|
||
11. Проанализированы middleware, guards, filters, interceptors и аналогичные механизмы.
|
||
12. Проанализированы конфигурация, secrets и environment handling.
|
||
13. Проанализированы зависимости и их потенциально опасное использование.
|
||
14. Проанализированы background jobs, queues, cron jobs, webhooks и integrations.
|
||
15. Проанализированы cache/session/token механизмы.
|
||
16. Проанализированы multi-user и multi-tenant boundaries.
|
||
17. Проанализированы все места, где пользовательские данные пересекаются с SQL, HTML, JS, shell, filesystem, URLs, templates и другими interpreter/context boundaries.
|
||
18. Выполнены отдельные проверки бизнес-логики.
|
||
19. Каждый потенциальный finding независимо перепроверен отдельным security-субагентом.
|
||
20. Не осталось непроверенных участков кода и непроверенных гипотез.
|
||
|
||
---
|
||
|
||
# 1. ГЛАВНАЯ ЦЕЛЬ
|
||
|
||
Проведи аудит по принципу:
|
||
|
||
> **Assume breach + assume malicious authenticated user + assume hostile input everywhere.**
|
||
|
||
Рассматривай атакующего как пользователя, который:
|
||
|
||
* может не иметь аккаунта;
|
||
* может иметь обычный аккаунт;
|
||
* может иметь аккаунт с минимальными правами;
|
||
* может иметь аккаунт другой роли;
|
||
* может обладать собственным tenant/account;
|
||
* может манипулировать HTTP requests;
|
||
* может менять ID, UUID, параметры, headers, cookies и tokens;
|
||
* может повторять запросы;
|
||
* может отправлять запросы напрямую, минуя frontend;
|
||
* может вызывать API напрямую;
|
||
* может изменять порядок операций;
|
||
* может создавать race conditions;
|
||
* может комбинировать несколько seemingly-safe функций;
|
||
* может анализировать ответы приложения;
|
||
* может использовать ошибки приложения для получения информации.
|
||
|
||
Не доверяй frontend validation.
|
||
|
||
Не доверяй скрытым кнопкам.
|
||
|
||
Не доверяй disabled UI elements.
|
||
|
||
Не доверяй значениям, пришедшим от клиента.
|
||
|
||
Не считай endpoint безопасным только потому, что frontend его нормально использует.
|
||
|
||
---
|
||
|
||
# 2. НЕ ИСПРАВЛЯЙ УЯЗВИМОСТИ
|
||
|
||
Это принципиально важно.
|
||
|
||
**НЕ вноси исправления в исходный код.**
|
||
|
||
**НЕ переписывай файлы приложения.**
|
||
|
||
**НЕ делай refactoring.**
|
||
|
||
**НЕ устанавливай патчи автоматически.**
|
||
|
||
**НЕ меняй security configuration проекта.**
|
||
|
||
Твоя задача — только:
|
||
|
||
> обнаружить → проверить → классифицировать → задокументировать.
|
||
|
||
Все findings сохраняй в отдельный файл/каталог аудита.
|
||
|
||
Исходный проект должен остаться неизменным.
|
||
|
||
---
|
||
|
||
# 3. СНАЧАЛА СОЗДАЙ КАРТУ ПРОЕКТА
|
||
|
||
До поиска уязвимостей сначала полностью разберись в приложении.
|
||
|
||
Определи:
|
||
|
||
* framework;
|
||
* язык;
|
||
* backend;
|
||
* frontend;
|
||
* ORM;
|
||
* database;
|
||
* authentication;
|
||
* authorization;
|
||
* session management;
|
||
* JWT/OAuth/etc.;
|
||
* storage;
|
||
* queues;
|
||
* cache;
|
||
* reverse proxy;
|
||
* web server;
|
||
* deployment;
|
||
* Docker/containerization;
|
||
* CI/CD;
|
||
* external services;
|
||
* third-party APIs;
|
||
* webhooks;
|
||
* email;
|
||
* SMS;
|
||
* payment integrations;
|
||
* file storage;
|
||
* search;
|
||
* logging;
|
||
* monitoring;
|
||
* background workers;
|
||
* cron;
|
||
* admin panel;
|
||
* CRM;
|
||
* roles;
|
||
* permissions;
|
||
* tenant model.
|
||
|
||
Создай:
|
||
|
||
`AUDIT/00_ARCHITECTURE.md`
|
||
|
||
В нём должна быть максимально подробная карта приложения.
|
||
|
||
---
|
||
|
||
# 4. СОЗДАЙ INVENTORY ВСЕГО ATTACK SURFACE
|
||
|
||
Создай отдельный inventory:
|
||
|
||
`AUDIT/01_ATTACK_SURFACE.md`
|
||
|
||
Перечисли **каждую** найденную точку входа.
|
||
|
||
Включая:
|
||
|
||
* HTTP routes;
|
||
* REST API;
|
||
* GraphQL;
|
||
* RPC;
|
||
* WebSockets;
|
||
* forms;
|
||
* file uploads;
|
||
* imports;
|
||
* exports;
|
||
* webhooks;
|
||
* callbacks;
|
||
* OAuth callbacks;
|
||
* password reset;
|
||
* email verification;
|
||
* invitation flows;
|
||
* registration;
|
||
* login;
|
||
* logout;
|
||
* admin endpoints;
|
||
* internal endpoints;
|
||
* debug endpoints;
|
||
* health endpoints;
|
||
* metrics endpoints;
|
||
* cron endpoints;
|
||
* queue consumers;
|
||
* CLI commands;
|
||
* background jobs;
|
||
* server actions;
|
||
* server-side rendering;
|
||
* template rendering;
|
||
* dynamic redirects;
|
||
* external URL fetching;
|
||
* integrations.
|
||
|
||
Для каждого endpoint/action зафиксируй:
|
||
|
||
* HTTP method;
|
||
* URL/path;
|
||
* controller/handler;
|
||
* middleware;
|
||
* authentication requirement;
|
||
* authorization requirement;
|
||
* input parameters;
|
||
* body;
|
||
* headers;
|
||
* cookies;
|
||
* output;
|
||
* database interaction;
|
||
* filesystem interaction;
|
||
* external requests;
|
||
* relevant roles;
|
||
* relevant tenant boundary.
|
||
|
||
---
|
||
|
||
# 5. ОБЯЗАТЕЛЬНО ПРОАНАЛИЗИРУЙ ВСЮ CRM BUSINESS LOGIC
|
||
|
||
CRM является приоритетной зоной.
|
||
|
||
Не ограничивайся классическими SQLi/XSS.
|
||
|
||
Ищи логические уязвимости.
|
||
|
||
Проверь:
|
||
|
||
### Object-level authorization
|
||
|
||
* IDOR;
|
||
* BOLA;
|
||
* доступ к чужим клиентам;
|
||
* доступ к чужим сделкам;
|
||
* доступ к чужим документам;
|
||
* доступ к чужим сообщениям;
|
||
* доступ к чужим задачам;
|
||
* доступ к чужим заметкам;
|
||
* доступ к чужим файлам;
|
||
* доступ к чужим экспортам.
|
||
|
||
### Role escalation
|
||
|
||
Проверь переходы:
|
||
|
||
* guest → user;
|
||
* user → manager;
|
||
* manager → admin;
|
||
* employee → privileged employee;
|
||
* tenant A → tenant B.
|
||
|
||
### Function-level authorization
|
||
|
||
Проверь возможность напрямую вызвать функции, которые UI скрывает.
|
||
|
||
Особенно:
|
||
|
||
* delete;
|
||
* restore;
|
||
* export;
|
||
* import;
|
||
* impersonate;
|
||
* change role;
|
||
* invite;
|
||
* deactivate;
|
||
* approve;
|
||
* reject;
|
||
* refund;
|
||
* modify permissions;
|
||
* access audit logs;
|
||
* access sensitive CRM fields.
|
||
|
||
### Business logic
|
||
|
||
Ищи:
|
||
|
||
* обход approval workflow;
|
||
* повторное выполнение операции;
|
||
* изменение состояния объекта в недопустимом порядке;
|
||
* использование устаревшего состояния;
|
||
* race conditions;
|
||
* TOCTOU;
|
||
* повторное использование токена;
|
||
* повторное использование invitation;
|
||
* повторное использование reset token;
|
||
* обход лимитов;
|
||
* negative values;
|
||
* integer overflow/underflow;
|
||
* quantity manipulation;
|
||
* price manipulation;
|
||
* скидки;
|
||
* начисления;
|
||
* quotas;
|
||
* rate limits;
|
||
* pagination bypass;
|
||
* bulk operation abuse;
|
||
* mass assignment;
|
||
* hidden fields;
|
||
* trust boundary violations.
|
||
|
||
---
|
||
|
||
# 6. AUTHENTICATION AUDIT
|
||
|
||
Полностью проверь:
|
||
|
||
* registration;
|
||
* login;
|
||
* logout;
|
||
* password reset;
|
||
* email verification;
|
||
* MFA;
|
||
* session creation;
|
||
* session invalidation;
|
||
* remember-me;
|
||
* password change;
|
||
* account recovery;
|
||
* invitation;
|
||
* OAuth;
|
||
* SSO;
|
||
* API tokens;
|
||
* JWT;
|
||
* refresh tokens.
|
||
|
||
Ищи:
|
||
|
||
* authentication bypass;
|
||
* session fixation;
|
||
* session hijacking;
|
||
* token leakage;
|
||
* predictable tokens;
|
||
* weak token validation;
|
||
* algorithm confusion;
|
||
* missing signature verification;
|
||
* incorrect audience/issuer validation;
|
||
* refresh-token reuse;
|
||
* reset-token reuse;
|
||
* account enumeration;
|
||
* password reset poisoning;
|
||
* host-header issues;
|
||
* email verification bypass;
|
||
* MFA bypass;
|
||
* race conditions;
|
||
* login race conditions;
|
||
* inconsistent authentication between endpoints.
|
||
|
||
---
|
||
|
||
# 7. AUTHORIZATION AUDIT
|
||
|
||
Построй полноценную матрицу:
|
||
|
||
`ROLE × RESOURCE × ACTION`
|
||
|
||
Например:
|
||
|
||
| Role | Resource | Read | Create | Update | Delete | Export | Admin |
|
||
| ------- | -------- | ---: | -----: | -----: | -----: | -----: | ----: |
|
||
| Guest | Customer | | | | | | |
|
||
| User | Customer | | | | | | |
|
||
| Manager | Customer | | | | | | |
|
||
| Admin | Customer | | | | | | |
|
||
|
||
Не заполняй её предположениями.
|
||
|
||
Определи фактическое поведение кода.
|
||
|
||
Особое внимание:
|
||
|
||
> authorization должен проверяться на сервере непосредственно перед выполнением защищённой операции.
|
||
|
||
---
|
||
|
||
# 8. INPUT / INJECTION AUDIT
|
||
|
||
Проверь все пользовательские данные во всех контекстах.
|
||
|
||
### SQL
|
||
|
||
Ищи:
|
||
|
||
* SQL injection;
|
||
* unsafe raw queries;
|
||
* dynamic SQL;
|
||
* ORDER BY injection;
|
||
* LIMIT/OFFSET injection;
|
||
* filter injection;
|
||
* search injection;
|
||
* ORM escape bypass.
|
||
|
||
### NoSQL
|
||
|
||
* operator injection;
|
||
* query object injection;
|
||
* `$where`;
|
||
* unsafe dynamic filters.
|
||
|
||
### Command injection
|
||
|
||
Проверь:
|
||
|
||
* shell commands;
|
||
* subprocess;
|
||
* exec;
|
||
* spawn;
|
||
* system;
|
||
* image processing;
|
||
* PDF generation;
|
||
* archive processing;
|
||
* conversion utilities.
|
||
|
||
### Template injection
|
||
|
||
Проверь:
|
||
|
||
* SSTI;
|
||
* dynamic templates;
|
||
* user-controlled template names/content.
|
||
|
||
### XSS
|
||
|
||
Проверь:
|
||
|
||
* reflected XSS;
|
||
* stored XSS;
|
||
* DOM XSS;
|
||
* HTML injection;
|
||
* attribute injection;
|
||
* JavaScript context;
|
||
* URL context;
|
||
* SVG;
|
||
* Markdown;
|
||
* rich text;
|
||
* CRM notes;
|
||
* imported data.
|
||
|
||
### Other
|
||
|
||
Проверь:
|
||
|
||
* LDAP injection;
|
||
* XPath injection;
|
||
* XML injection;
|
||
* XXE;
|
||
* CSV injection;
|
||
* header injection;
|
||
* CRLF;
|
||
* email injection;
|
||
* log injection;
|
||
* path traversal.
|
||
|
||
---
|
||
|
||
# 9. SSRF
|
||
|
||
Найди **все места**, где сервер может обращаться к URL, который частично или полностью контролируется пользователем.
|
||
|
||
Проверить:
|
||
|
||
* HTTP clients;
|
||
* image fetchers;
|
||
* URL previews;
|
||
* webhooks;
|
||
* importers;
|
||
* integrations;
|
||
* PDF generators;
|
||
* screenshot services;
|
||
* metadata fetchers;
|
||
* avatar/image processing;
|
||
* redirect following.
|
||
|
||
Проверяй не только очевидный:
|
||
|
||
`http://...`
|
||
|
||
но и обходы URL validation:
|
||
|
||
* redirects;
|
||
* alternate IP notation;
|
||
* IPv6;
|
||
* DNS rebinding;
|
||
* localhost aliases;
|
||
* internal hostnames;
|
||
* encoded addresses;
|
||
* unusual schemes;
|
||
* parser discrepancies.
|
||
|
||
---
|
||
|
||
# 10. FILE SECURITY
|
||
|
||
Проверь:
|
||
|
||
* upload;
|
||
* download;
|
||
* preview;
|
||
* extraction;
|
||
* import;
|
||
* export;
|
||
* conversion;
|
||
* image processing;
|
||
* PDF processing;
|
||
* archives.
|
||
|
||
Ищи:
|
||
|
||
* unrestricted upload;
|
||
* executable upload;
|
||
* MIME confusion;
|
||
* extension bypass;
|
||
* double extension;
|
||
* path traversal;
|
||
* Zip Slip;
|
||
* malicious archive;
|
||
* decompression bombs;
|
||
* symlink attacks;
|
||
* arbitrary file read;
|
||
* arbitrary file write;
|
||
* filename injection;
|
||
* stored XSS through uploaded files;
|
||
* access-control bypass;
|
||
* cross-tenant file access.
|
||
|
||
---
|
||
|
||
# 11. API SECURITY
|
||
|
||
Каждый endpoint проверяй независимо.
|
||
|
||
Проверь:
|
||
|
||
* authentication;
|
||
* authorization;
|
||
* input validation;
|
||
* output filtering;
|
||
* excessive data exposure;
|
||
* mass assignment;
|
||
* parameter pollution;
|
||
* pagination;
|
||
* rate limiting;
|
||
* bulk endpoints;
|
||
* error handling;
|
||
* HTTP method confusion;
|
||
* content-type confusion;
|
||
* CORS;
|
||
* CSRF;
|
||
* caching;
|
||
* idempotency.
|
||
|
||
Особое внимание:
|
||
|
||
> API должен быть безопасен даже если frontend полностью удалить.
|
||
|
||
---
|
||
|
||
# 12. FRONTEND
|
||
|
||
Не игнорируй frontend.
|
||
|
||
Проверь:
|
||
|
||
* DOM XSS;
|
||
* unsafe HTML;
|
||
* unsafe URL handling;
|
||
* postMessage;
|
||
* origin validation;
|
||
* token storage;
|
||
* sensitive data in localStorage/sessionStorage;
|
||
* source maps;
|
||
* exposed secrets;
|
||
* internal endpoints;
|
||
* hidden functionality;
|
||
* client-side authorization;
|
||
* frontend-only validation;
|
||
* prototype pollution;
|
||
* dangerous third-party libraries.
|
||
|
||
Но помни:
|
||
|
||
> frontend security controls никогда не считаются достаточной authorization boundary.
|
||
|
||
---
|
||
|
||
# 13. CSRF / CORS / BROWSER SECURITY
|
||
|
||
Проверь:
|
||
|
||
* CSRF;
|
||
* SameSite;
|
||
* Secure;
|
||
* HttpOnly;
|
||
* CORS;
|
||
* origin validation;
|
||
* referer validation;
|
||
* clickjacking;
|
||
* CSP;
|
||
* security headers;
|
||
* MIME sniffing;
|
||
* open redirects;
|
||
* browser-side token leakage.
|
||
|
||
---
|
||
|
||
# 14. SECRETS
|
||
|
||
Ищи:
|
||
|
||
* API keys;
|
||
* private keys;
|
||
* passwords;
|
||
* database credentials;
|
||
* JWT secrets;
|
||
* encryption keys;
|
||
* cloud credentials;
|
||
* service credentials;
|
||
* OAuth secrets;
|
||
* hardcoded tokens;
|
||
* secrets в frontend;
|
||
* secrets в source maps;
|
||
* secrets в config;
|
||
* secrets в comments;
|
||
* secrets в git history, если history доступна.
|
||
|
||
Не публикуй реальные секреты в итоговом отчёте целиком.
|
||
|
||
Маскируй их.
|
||
|
||
---
|
||
|
||
# 15. CRYPTOGRAPHY
|
||
|
||
Проверь:
|
||
|
||
* password hashing;
|
||
* encryption;
|
||
* signing;
|
||
* random number generation;
|
||
* token generation;
|
||
* key storage;
|
||
* IV/nonce;
|
||
* algorithm selection;
|
||
* key reuse;
|
||
* weak randomness;
|
||
* plaintext sensitive data;
|
||
* custom cryptography.
|
||
|
||
Особенно ищи случаи, когда разработчик самостоятельно реализовал криптографический механизм.
|
||
|
||
---
|
||
|
||
# 16. DATABASE
|
||
|
||
Проверь:
|
||
|
||
* SQL injection;
|
||
* authorization at query level;
|
||
* tenant isolation;
|
||
* mass assignment;
|
||
* unsafe migrations;
|
||
* sensitive columns;
|
||
* soft-delete bypass;
|
||
* deleted-record recovery;
|
||
* raw queries;
|
||
* dynamic filters;
|
||
* dynamic sorting;
|
||
* joins exposing unauthorized records;
|
||
* backup/export exposure.
|
||
|
||
---
|
||
|
||
# 17. MULTI-TENANCY
|
||
|
||
Если система multi-tenant, проведи отдельный полноценный аудит.
|
||
|
||
Попытайся концептуально доказать или опровергнуть:
|
||
|
||
> Can tenant A access ANY data belonging to tenant B?
|
||
|
||
Проверь это для:
|
||
|
||
* users;
|
||
* customers;
|
||
* deals;
|
||
* files;
|
||
* messages;
|
||
* logs;
|
||
* reports;
|
||
* exports;
|
||
* search;
|
||
* analytics;
|
||
* notifications;
|
||
* background jobs;
|
||
* caches;
|
||
* object storage;
|
||
* database queries;
|
||
* IDs;
|
||
* UUIDs;
|
||
* webhooks.
|
||
|
||
---
|
||
|
||
# 18. RACE CONDITIONS
|
||
|
||
Отдельно ищи race conditions.
|
||
|
||
Особенно в:
|
||
|
||
* password reset;
|
||
* invitation;
|
||
* payment;
|
||
* permissions;
|
||
* role changes;
|
||
* quotas;
|
||
* counters;
|
||
* balance;
|
||
* coupon;
|
||
* resource creation;
|
||
* deletion;
|
||
* approval;
|
||
* state transitions;
|
||
* file processing;
|
||
* job processing.
|
||
|
||
Не предполагай, что отсутствие очевидной race condition означает отсутствие проблемы.
|
||
|
||
---
|
||
|
||
# 19. ERROR HANDLING / INFORMATION DISCLOSURE
|
||
|
||
Проверь:
|
||
|
||
* stack traces;
|
||
* SQL errors;
|
||
* filesystem paths;
|
||
* internal hostnames;
|
||
* framework versions;
|
||
* debug endpoints;
|
||
* source maps;
|
||
* exception messages;
|
||
* timing differences;
|
||
* user enumeration;
|
||
* object enumeration;
|
||
* internal IDs.
|
||
|
||
---
|
||
|
||
# 20. DEPENDENCIES
|
||
|
||
Проанализируй:
|
||
|
||
* package manifests;
|
||
* lockfiles;
|
||
* dependency versions;
|
||
* transitive dependencies;
|
||
* deprecated libraries;
|
||
* dangerous packages;
|
||
* vulnerable packages;
|
||
* packages с dangerous APIs.
|
||
|
||
Но не делай вывод:
|
||
|
||
> «dependency имеет CVE = приложение уязвимо».
|
||
|
||
Проверь, используется ли уязвимый функционал фактически.
|
||
|
||
---
|
||
|
||
# 21. INFRASTRUCTURE / CONFIGURATION
|
||
|
||
Если соответствующие файлы присутствуют, проверь:
|
||
|
||
* Docker;
|
||
* Docker Compose;
|
||
* Kubernetes;
|
||
* nginx;
|
||
* Apache;
|
||
* reverse proxy;
|
||
* cloud configuration;
|
||
* CI/CD;
|
||
* environment configuration;
|
||
* CORS;
|
||
* TLS;
|
||
* headers;
|
||
* exposed ports;
|
||
* debug mode;
|
||
* production configuration;
|
||
* storage permissions;
|
||
* service accounts.
|
||
|
||
---
|
||
|
||
# 22. АУДИТ GIT HISTORY
|
||
|
||
Если git history доступна, отдельно проверь:
|
||
|
||
* старые секреты;
|
||
* удалённые секреты;
|
||
* reverted vulnerabilities;
|
||
* TODO/FIXME security comments;
|
||
* временные bypasses;
|
||
* debug code;
|
||
* suspicious commits;
|
||
* commented-out authorization;
|
||
* disabled security checks.
|
||
|
||
---
|
||
|
||
# 23. ПОИСК НЕ ТОЛЬКО ПО ПАТТЕРНАМ
|
||
|
||
Не ограничивайся grep/SAST.
|
||
|
||
Каждый потенциально опасный участок рассматривай в контексте всей data flow.
|
||
|
||
Для каждого пользовательского input постарайся построить:
|
||
|
||
`SOURCE → TRANSFORMATION → VALIDATION → STORAGE → SINK`
|
||
|
||
И проверить каждый путь.
|
||
|
||
---
|
||
|
||
# 24. DATA-FLOW AUDIT
|
||
|
||
Для каждого sensitive input:
|
||
|
||
1. Найди источник.
|
||
2. Проследи его через функции.
|
||
3. Проследи transformations.
|
||
4. Определи validation.
|
||
5. Определи authorization.
|
||
6. Определи storage.
|
||
7. Определи eventual sink.
|
||
8. Определи, можно ли изменить assumptions между этими этапами.
|
||
|
||
Особое внимание:
|
||
|
||
* validation before authorization;
|
||
* authorization before object lookup;
|
||
* canonicalization;
|
||
* encoding;
|
||
* parsing;
|
||
* type conversion;
|
||
* deserialization.
|
||
|
||
---
|
||
|
||
# 25. DESERIALIZATION
|
||
|
||
Проверь:
|
||
|
||
* JSON;
|
||
* YAML;
|
||
* XML;
|
||
* serialized objects;
|
||
* cookies;
|
||
* session data;
|
||
* JWT;
|
||
* message queues;
|
||
* imported files.
|
||
|
||
Ищи:
|
||
|
||
* unsafe deserialization;
|
||
* prototype pollution;
|
||
* type confusion;
|
||
* object injection;
|
||
* arbitrary class/object instantiation.
|
||
|
||
---
|
||
|
||
# 26. SECURITY TESTING PHILOSOPHY
|
||
|
||
Каждую гипотезу классифицируй:
|
||
|
||
### CONFIRMED
|
||
|
||
Есть доказательство, что vulnerability реально существует.
|
||
|
||
### PROBABLE
|
||
|
||
Есть сильные технические основания, но полного подтверждения недостаточно.
|
||
|
||
### POSSIBLE
|
||
|
||
Подозрение требует дополнительной информации или runtime validation.
|
||
|
||
Не выдавай `POSSIBLE` за confirmed.
|
||
|
||
Не выдавай теоретическую проблему за exploitable vulnerability.
|
||
|
||
---
|
||
|
||
# 27. ОБЯЗАТЕЛЬНАЯ НЕЗАВИСИМАЯ ВЕРИФИКАЦИЯ
|
||
|
||
**КАЖДЫЙ finding должен быть проверен отдельным независимым security-субагентом.**
|
||
|
||
Не один субагент на все findings.
|
||
|
||
Для каждого finding создай отдельную задачу/делегацию.
|
||
|
||
Субагент должен получить:
|
||
|
||
* relevant code;
|
||
* context;
|
||
* найденную гипотезу;
|
||
* expected security property;
|
||
* необходимые зависимости;
|
||
* минимальный контекст, позволяющий провести независимую проверку.
|
||
|
||
Он НЕ должен просто соглашаться с первоначальным аудитором.
|
||
|
||
Его инструкция:
|
||
|
||
> Assume the primary auditor may be wrong. Attempt to disprove the finding first. If you cannot disprove it, establish whether it is actually exploitable and determine the exact security impact.
|
||
|
||
---
|
||
|
||
# 28. РОЛИ СУБАГЕНТОВ
|
||
|
||
Если система позволяет использовать несколько субагентов, используй специализированные роли.
|
||
|
||
Минимальный набор:
|
||
|
||
### Agent A — Authentication Specialist
|
||
|
||
Проверяет authentication/session/token/reset/MFA.
|
||
|
||
### Agent B — Authorization Specialist
|
||
|
||
Проверяет IDOR/BOLA/RBAC/ABAC/privilege escalation.
|
||
|
||
### Agent C — Injection Specialist
|
||
|
||
SQLi, NoSQLi, command injection, SSTI, XSS и т.д.
|
||
|
||
### Agent D — Business Logic Specialist
|
||
|
||
CRM workflows, state machines, race conditions, abuse cases.
|
||
|
||
### Agent E — File/SSRF Specialist
|
||
|
||
Uploads, downloads, parsing, SSRF, archives.
|
||
|
||
### Agent F — API Specialist
|
||
|
||
API-specific authorization, validation, mass assignment, excessive exposure.
|
||
|
||
### Agent G — Infrastructure/Secrets Specialist
|
||
|
||
Config, Docker, CI/CD, secrets, dependencies.
|
||
|
||
### Agent H — Cryptography Specialist
|
||
|
||
Crypto, password storage, tokens, randomness.
|
||
|
||
### Agent I — Frontend Security Specialist
|
||
|
||
DOM XSS, browser security, postMessage, token handling.
|
||
|
||
### Agent J — Adversarial Reviewer
|
||
|
||
Получает результаты всех остальных и пытается найти то, что они пропустили.
|
||
|
||
---
|
||
|
||
# 29. ОСОБЕННО ВАЖНО: НЕ ДЕЛАЙ ВЕРИФИКАЦИЮ САМОПРОВЕРКОЙ
|
||
|
||
Не делай:
|
||
|
||
> Auditor finds vulnerability → same reasoning process confirms vulnerability.
|
||
|
||
Это недостаточно.
|
||
|
||
Верификация должна быть максимально независимой.
|
||
|
||
Идеально использовать субагента более сильной reasoning-модели, например OPUS или выше, если такая модель доступна.
|
||
|
||
Если указанная модель недоступна, используй наиболее сильную доступную модель и явно отметь это в audit metadata.
|
||
|
||
---
|
||
|
||
# 30. RED TEAM PASS
|
||
|
||
После завершения основного code audit проведи отдельный red-team проход.
|
||
|
||
Представь злоумышленника:
|
||
|
||
### Scenario 1
|
||
|
||
Anonymous attacker.
|
||
|
||
### Scenario 2
|
||
|
||
Normal authenticated user.
|
||
|
||
### Scenario 3
|
||
|
||
Low-privileged CRM employee.
|
||
|
||
### Scenario 4
|
||
|
||
Manager.
|
||
|
||
### Scenario 5
|
||
|
||
Compromised tenant.
|
||
|
||
### Scenario 6
|
||
|
||
Malicious insider.
|
||
|
||
Для каждого сценария ответь:
|
||
|
||
* Что атакующий может получить?
|
||
* Какие security boundaries существуют?
|
||
* Где они enforced?
|
||
* Можно ли их обойти?
|
||
* Какие функции можно комбинировать для escalation?
|
||
|
||
---
|
||
|
||
# 31. COMBINED EXPLOIT CHAINS
|
||
|
||
Не рассматривай findings только изолированно.
|
||
|
||
Ищи chains:
|
||
|
||
`Low severity + Low severity = Critical impact`
|
||
|
||
Например:
|
||
|
||
* information disclosure → IDOR;
|
||
* SSRF → internal endpoint;
|
||
* XSS → privileged action;
|
||
* weak authorization → export → mass data leak;
|
||
* user enumeration → password reset weakness;
|
||
* file upload → parser vulnerability;
|
||
* low-privileged access → admin functionality;
|
||
* race condition → privilege escalation.
|
||
|
||
Создай:
|
||
|
||
`AUDIT/EXPLOIT_CHAINS.md`
|
||
|
||
---
|
||
|
||
# 32. ПОИСК ПРОПУЩЕННЫХ УЯЗВИМОСТЕЙ
|
||
|
||
После завершения всех специализированных проверок НЕ останавливайся.
|
||
|
||
Проведи минимум 3 дополнительных независимых прохода.
|
||
|
||
## PASS A — OWASP Coverage
|
||
|
||
Сопоставь приложение с OWASP Top 10 и связанными категориями.
|
||
|
||
## PASS B — CWE Coverage
|
||
|
||
Проверь релевантные CWE.
|
||
|
||
## PASS C — Attack Surface Re-review
|
||
|
||
Начни с нуля от attack-surface inventory и проверь:
|
||
|
||
> Для каждой точки входа существует ли хотя бы одна независимая проверка security properties?
|
||
|
||
---
|
||
|
||
# 33. NEGATIVE TESTING
|
||
|
||
Для каждого security control задай вопрос:
|
||
|
||
> Что произойдёт, если этот control отсутствует?
|
||
|
||
Проверь:
|
||
|
||
* authentication removed;
|
||
* role changed;
|
||
* tenant ID changed;
|
||
* object ID changed;
|
||
* HTTP method changed;
|
||
* parameter omitted;
|
||
* parameter duplicated;
|
||
* parameter type changed;
|
||
* request reordered;
|
||
* request replayed;
|
||
* request sent directly;
|
||
* frontend bypassed.
|
||
|
||
---
|
||
|
||
# 34. НИКАКИХ ПРЕЖДЕВРЕМЕННЫХ ВЫВОДОВ
|
||
|
||
Нельзя писать:
|
||
|
||
> «Других уязвимостей не найдено»
|
||
|
||
если:
|
||
|
||
* часть проекта не проанализирована;
|
||
* часть endpoint'ов неизвестна;
|
||
* часть dependencies не проверена;
|
||
* часть business logic не понята;
|
||
* runtime behavior неизвестно;
|
||
* субагенты не завершили verification;
|
||
* coverage matrix не заполнена.
|
||
|
||
В таком случае явно напиши:
|
||
|
||
> AUDIT INCOMPLETE
|
||
|
||
и укажи, что осталось непроверенным.
|
||
|
||
---
|
||
|
||
# 35. ДОКУМЕНТИРОВАНИЕ FINDINGS
|
||
|
||
Создай:
|
||
|
||
`AUDIT/FINDINGS.md`
|
||
|
||
Для КАЖДОЙ уязвимости используй формат:
|
||
|
||
```text
|
||
ID:
|
||
Название:
|
||
|
||
Severity:
|
||
CVSS (если возможно):
|
||
|
||
Confidence:
|
||
CONFIRMED / PROBABLE / POSSIBLE
|
||
|
||
Affected component:
|
||
|
||
Affected files:
|
||
|
||
Affected functions:
|
||
|
||
Affected endpoints:
|
||
|
||
Required privileges:
|
||
|
||
Attack preconditions:
|
||
|
||
Security boundary violated:
|
||
|
||
Root cause:
|
||
|
||
Technical explanation:
|
||
|
||
Attack path:
|
||
|
||
Proof / evidence:
|
||
|
||
Minimal reproduction:
|
||
|
||
Expected secure behavior:
|
||
|
||
Actual behavior:
|
||
|
||
Impact:
|
||
|
||
Affected users/data:
|
||
|
||
Exploitability:
|
||
|
||
Independent verification:
|
||
|
||
Verifier verdict:
|
||
|
||
Verifier reasoning:
|
||
|
||
False-positive analysis:
|
||
|
||
Related findings:
|
||
|
||
Recommended remediation:
|
||
```
|
||
|
||
---
|
||
|
||
# 36. ДОКАЗАТЕЛЬСТВА
|
||
|
||
Каждый finding должен содержать конкретное доказательство.
|
||
|
||
Не пиши:
|
||
|
||
> «Здесь, вероятно, есть IDOR».
|
||
|
||
Пиши:
|
||
|
||
> Endpoint X принимает object_id из user-controlled request, затем выполняет lookup Y без проверки ownership/tenant/permission. Следующий код выполняет операцию Z.
|
||
|
||
Указывай:
|
||
|
||
* файл;
|
||
* строку/диапазон строк, если доступен;
|
||
* функцию;
|
||
* flow;
|
||
* relevant condition.
|
||
|
||
---
|
||
|
||
# 37. ПРОВЕРКА НА FALSE POSITIVE
|
||
|
||
Каждая потенциальная уязвимость должна пройти вопрос:
|
||
|
||
> Может ли другой security control сделать эту атаку невозможной?
|
||
|
||
Проверь:
|
||
|
||
* middleware;
|
||
* global guards;
|
||
* database policies;
|
||
* framework defaults;
|
||
* reverse proxy;
|
||
* validation layers;
|
||
* permission services;
|
||
* tenant middleware;
|
||
* CSRF middleware;
|
||
* CSP;
|
||
* deployment configuration.
|
||
|
||
Нельзя объявлять vulnerability, не проверив эти compensating controls.
|
||
|
||
---
|
||
|
||
# 38. SEVERITY
|
||
|
||
Используй:
|
||
|
||
* Critical
|
||
* High
|
||
* Medium
|
||
* Low
|
||
* Informational
|
||
|
||
Severity должна основываться на реальном impact и exploitability.
|
||
|
||
Особенно учитывай:
|
||
|
||
* remote exploitation;
|
||
* authentication requirement;
|
||
* privileges;
|
||
* confidentiality;
|
||
* integrity;
|
||
* availability;
|
||
* cross-tenant impact;
|
||
* privilege escalation;
|
||
* mass exploitation;
|
||
* business impact.
|
||
|
||
---
|
||
|
||
# 39. DUPLICATE FINDINGS
|
||
|
||
Если одна root cause создаёт 50 похожих endpoint vulnerabilities:
|
||
|
||
* укажи root cause;
|
||
* перечисли affected locations;
|
||
* не создавай бессмысленные дубликаты.
|
||
|
||
Но если разные места имеют разные security implications — документируй их отдельно.
|
||
|
||
---
|
||
|
||
# 40. ФИНАЛЬНЫЙ COVERAGE MATRIX
|
||
|
||
Создай:
|
||
|
||
`AUDIT/COVERAGE.md`
|
||
|
||
Минимум:
|
||
|
||
| Area | Reviewed | Files | Endpoints | Findings | Independent Verification | Status |
|
||
| --------------- | -------: | ----: | --------: | -------: | -----------------------: | ------ |
|
||
| Authentication | | | | | | |
|
||
| Authorization | | | | | | |
|
||
| CRM Logic | | | | | | |
|
||
| API | | | | | | |
|
||
| SQL | | | | | | |
|
||
| XSS | | | | | | |
|
||
| SSRF | | | | | | |
|
||
| Files | | | | | | |
|
||
| CSRF | | | | | | |
|
||
| Secrets | | | | | | |
|
||
| Crypto | | | | | | |
|
||
| Dependencies | | | | | | |
|
||
| Infrastructure | | | | | | |
|
||
| Multi-tenancy | | | | | | |
|
||
| Race Conditions | | | | | | |
|
||
|
||
Не ставь `Reviewed = Yes`, пока соответствующая область действительно не проверена.
|
||
|
||
---
|
||
|
||
# 41. FINAL QUALITY GATE
|
||
|
||
Перед завершением аудита выполни следующие проверки:
|
||
|
||
### Q1
|
||
|
||
Проанализирован ли каждый source file?
|
||
|
||
### Q2
|
||
|
||
Проанализирован ли каждый route/controller/handler?
|
||
|
||
### Q3
|
||
|
||
Проанализирован ли каждый privileged operation?
|
||
|
||
### Q4
|
||
|
||
Проанализированы ли все роли?
|
||
|
||
### Q5
|
||
|
||
Проанализированы ли все tenant boundaries?
|
||
|
||
### Q6
|
||
|
||
Проанализированы ли все user-controlled inputs?
|
||
|
||
### Q7
|
||
|
||
Проанализированы ли все external network requests?
|
||
|
||
### Q8
|
||
|
||
Проанализированы ли все file operations?
|
||
|
||
### Q9
|
||
|
||
Проанализированы ли все database operations?
|
||
|
||
### Q10
|
||
|
||
Проверены ли все findings независимыми субагентами?
|
||
|
||
### Q11
|
||
|
||
Был ли проведён adversarial second pass?
|
||
|
||
### Q12
|
||
|
||
Были ли проверены exploit chains?
|
||
|
||
### Q13
|
||
|
||
Есть ли участки проекта, которые остались непонятными?
|
||
|
||
### Q14
|
||
|
||
Есть ли findings без достаточных доказательств?
|
||
|
||
### Q15
|
||
|
||
Есть ли findings, которые могли быть false positives?
|
||
|
||
Если хотя бы один важный вопрос имеет отрицательный ответ — аудит НЕ считать завершённым.
|
||
|
||
---
|
||
|
||
# 42. ФИНАЛЬНЫЙ ОТЧЁТ
|
||
|
||
Создай:
|
||
|
||
`AUDIT/FINAL_REPORT.md`
|
||
|
||
Структура:
|
||
|
||
1. Executive Summary
|
||
2. Scope
|
||
3. Architecture
|
||
4. Attack Surface
|
||
5. Threat Model
|
||
6. Authentication Assessment
|
||
7. Authorization Assessment
|
||
8. CRM Business Logic Assessment
|
||
9. API Assessment
|
||
10. Injection Assessment
|
||
11. File/SSRF Assessment
|
||
12. Frontend Assessment
|
||
13. Infrastructure Assessment
|
||
14. Secrets Assessment
|
||
15. Dependency Assessment
|
||
16. Multi-tenancy Assessment
|
||
17. Race Conditions
|
||
18. Exploit Chains
|
||
19. Confirmed Vulnerabilities
|
||
20. Probable Vulnerabilities
|
||
21. Possible Vulnerabilities
|
||
22. False Positives Rejected
|
||
23. Coverage Matrix
|
||
24. Unreviewed Areas
|
||
25. Final Assessment
|
||
|
||
---
|
||
|
||
# 43. ОСНОВНОЙ ПРИНЦИП
|
||
|
||
Твоя цель не:
|
||
|
||
> найти как можно больше текстовых совпадений с CWE.
|
||
|
||
Твоя цель:
|
||
|
||
> **найти реальные нарушения security invariants приложения.**
|
||
|
||
Особенно ищи нарушения вида:
|
||
|
||
```text
|
||
Attacker controls X
|
||
↓
|
||
Application trusts X
|
||
↓
|
||
Security boundary crossed
|
||
↓
|
||
Unauthorized action/data access
|
||
```
|
||
|
||
---
|
||
|
||
# 44. ПРИОРИТЕТ
|
||
|
||
Приоритет поиска:
|
||
|
||
1. Authentication bypass
|
||
2. Authorization bypass
|
||
3. Privilege escalation
|
||
4. Cross-tenant access
|
||
5. Remote code execution
|
||
6. SQL/NoSQL/command injection
|
||
7. SSRF
|
||
8. Arbitrary file read/write
|
||
9. Account takeover
|
||
10. Sensitive data disclosure
|
||
11. Business logic abuse
|
||
12. Stored XSS with meaningful impact
|
||
13. CSRF with meaningful impact
|
||
14. Race conditions
|
||
15. Cryptographic weaknesses
|
||
16. Secrets
|
||
17. Dependency vulnerabilities
|
||
18. Configuration issues
|
||
19. Information disclosure
|
||
20. Low-impact hardening issues
|
||
|
||
Но НЕ прекращай аудит после нахождения Critical/High findings.
|
||
|
||
---
|
||
|
||
# 45. ВАЖНОЕ ТРЕБОВАНИЕ К РАБОТЕ АГЕНТА
|
||
|
||
Работай как настоящий Principal Application Security Engineer, а не как code-review assistant.
|
||
|
||
Не спеши.
|
||
|
||
Не оптимизируй количество найденных проблем.
|
||
|
||
Оптимизируй:
|
||
|
||
> **полноту покрытия + достоверность + доказуемость.**
|
||
|
||
Если один участок кода выглядит безопасным — попытайся доказать, почему он безопасен.
|
||
|
||
Если один участок выглядит уязвимым — попытайся доказать, почему это действительно exploitable.
|
||
|
||
Если два разных механизма взаимодействуют — анализируй их вместе.
|
||
|
||
Если бизнес-логика неочевидна — реконструируй её из кода, моделей, схем БД, frontend flows, tests и вызовов.
|
||
|
||
---
|
||
|
||
# 46. КРИТЕРИЙ ЗАВЕРШЕНИЯ
|
||
|
||
Аудит считается завершённым ТОЛЬКО если:
|
||
|
||
```text
|
||
FULL CODE INVENTORY = COMPLETE
|
||
ATTACK SURFACE = MAPPED
|
||
AUTHENTICATION = REVIEWED
|
||
AUTHORIZATION = REVIEWED
|
||
BUSINESS LOGIC = REVIEWED
|
||
CRM = REVIEWED
|
||
API = REVIEWED
|
||
INPUT FLOWS = REVIEWED
|
||
DATABASE = REVIEWED
|
||
FILES = REVIEWED
|
||
SSRF = REVIEWED
|
||
FRONTEND = REVIEWED
|
||
INFRASTRUCTURE = REVIEWED
|
||
SECRETS = REVIEWED
|
||
DEPENDENCIES = REVIEWED
|
||
MULTI-TENANCY = REVIEWED
|
||
RACE CONDITIONS = REVIEWED
|
||
EXPLOIT CHAINS = REVIEWED
|
||
RED TEAM PASS = COMPLETE
|
||
ADVERSARIAL PASS = COMPLETE
|
||
ALL FINDINGS = INDEPENDENTLY VERIFIED
|
||
FALSE POSITIVES = REVIEWED
|
||
COVERAGE MATRIX = COMPLETE
|
||
UNREVIEWED AREAS = EXPLICITLY DOCUMENTED
|
||
```
|
||
|
||
Если хотя бы один пункт невозможно подтвердить — **не утверждай, что аудит полностью завершён**.
|
||
|
||
---
|
||
|
||
# 47. ПОСЛЕДНЕЕ И САМОЕ ВАЖНОЕ ПРАВИЛО
|
||
|
||
После формирования первоначального списка findings скажи себе:
|
||
|
||
> **"What did we miss?"**
|
||
|
||
Затем проведи новый независимый поиск с предположением, что предыдущие аудиторы что-то пропустили.
|
||
|
||
После этого повтори:
|
||
|
||
> **"What would a highly skilled attacker notice that our static analysis did not?"**
|
||
|
||
И проведи ещё один проход.
|
||
|
||
Только после этого формируй FINAL_REPORT.md.
|
||
|
||
**Не исправляй найденные проблемы. Только документируй их.**
|
||
**Не изменяй production/application source code.**
|
||
**Все изменения должны находиться исключительно в AUDIT/.**
|
||
**Каждый finding обязан иметь независимую верификацию.**
|
||
**Нельзя объявлять аудит полным без evidence-based coverage.**
|