Какво откриваме в действителност: повтарящи се модели от нашите ангажименти

След години тестове на уеб приложения, API, мобилни приложения, облачни и вътрешни среди виждаме повтарящи се първопричини. Статията представя качествени наблюдения от анонимизирана клиентска работа. Категориите по-долу показват къде целенасочени промени могат да отстранят значителна част от сериозните слабости, които откриваме.

Наблюденията се подкрепят и от данни: в 21 анонимизирани ангажимента и 190 констатации от последните ни тестове проблемите с висока и критична тежест представляват около 17% от оценените констатации. Те са малцинство, но често позволяват постигане на целите на теста. Сред най-честите първопричини са неправилната конфигурация и пропуските в управлението на системите. Пълното разпределение по критичност и първопричини е в нашия доклад:

Изтеглете „Състоянието на нашите констатации 2026“ (PDF) ↓

1. Най-сериозните констатации са свързани с данни за достъп, а не с изобретателни експлойти

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

Изводът: преглед на управлението на тайните и на правата често е по-ценен от още един кръг тестване на нивото на кода.

2. Контролът на достъпа все още е класът дефекти номер едно в приложенията

Нарушената оторизация на ниво обект (IDOR/BOLA), роли, които дават повече, отколкото обозначението им подсказва, и операции без проверка за оторизация от страна на сървъра се появяват в повечето от нашите тестове на приложения. Моделът е почти винаги един и същ: интерфейсът налага правилото, сървърът допуска, че интерфейсът го е направил. Нападателите не използват интерфейса.

Изводът: при всеки достъп до обект и всяка операция, която променя данни, сървърът трябва да проверява собствеността и ролята. Включете тези проверки в автоматизираните тестове.

3. Подсилената защита не означава, че работата е приключила

Много от приложенията, които тестваме, са добре защитени срещу инжектиране и други класически уеб уязвимости, но имат пропуски в бизнес логиката. Един оператор може сам да пренасочи или спре плащания; експортирани стойности могат да се изпълнят като формули в електронна таблица; работни процеси могат да се доверят на статуси и дати, подадени от клиента. Техническите защити работят, но правилата на бизнеса не са проверени със същата дълбочина.

Изводът: помолете тестерите си изрично да изследват бизнес логиката и разделянето на отговорностите, не само OWASP Top 10.

4. Токените живеят твърде дълго и пътуват твърде далеч

Управлението на OAuth и сесиите е повтарящ се източник на констатации с висока критичност: дълготрайни токени, връщани в URL адреси или вградени в скриптове на страницата, токени, които не се отменят при изход, password grant, оставен включен за публични клиенти. Един дълготраен токен, разкрит на едно място, често означава цял ден достъп до това, което той защитава.

Изводът: authorization code + PKCE, кратки срокове на валидност, отмяна от страна на сървъра и никога токен в URL или в глобална променлива на JavaScript.

5. Пропуски в управлението на Active Directory водят до пробиви и без zero-day

При вътрешната и red team работата пътят до Domain Admin почти винаги е верига от хигиенни провали: служебни акаунти, подлежащи на Kerberoasting, с много стари пароли, акаунти, подлежащи на AS-REP roasting, неподписан SMB/LDAP, който позволява relay, остарели администратори с пароли без срок. Писали сме за погледа на BloodHound към това; смисълът тук е, че поправките са конфигурация, не обновяване.

Изводът: доброто управление на привилегированите акаунти и защитите срещу relay чрез подписване могат значително да намалят реалния риск във вътрешната мрежа.

Добрите новини, които също отчитаме

Не всеки тест завършва с тежки проблеми. Проверявали сме добре защитени външни периметри, уеб приложения само с констатации с ниска критичност и банки, чиито защити срещу фишинг, подготовка на служителите и мрежова сегментация издържаха при red team упражнения. Документираме тези резултати също толкова внимателно. Независимата проверка на работещите защити е полезно доказателство.

Къде да насочите средствата си

1. Тайни и права — откъдето произлизат най-лошите ви констатации.
2. Оторизация от страна на сървъра — за всеки обект и всяко действие.
3. Бизнес логика и разделение на отговорностите — правила, които общите сканирания може да не покриват без специфичен приложен контекст.
4. Жизнен цикъл на токените — кратък, отменим от сървъра, никога в URL адреси.
5. Хигиена на Active Directory — най-евтините вътрешни победи с голямо въздействие.

Нищо от това не е ново и точно това е смисълът. Нападателите, които печелят днес, не използват техниките на утрешния ден; те използват същите пет първопричини, които намираме всеки месец.

Ако трябва да предадете само един извод на ръководството

Основният извод за ръководството е прост: успешните атаки срещу подобни организации често използват познати пропуски — повторно използвана парола, акаунт с прекомерни права, тайна в хранилище за код или неактуализирано гранично устройство. Защитата изисква последователно отстраняване на тези възможности и проверка, че корекциите работят. Това е целта на устойчивата програма за тестване.

Защо програмата превъзхожда теста в един момент от времето

Единичният тест показва състоянието в определен момент. Редовната програма позволява да проследите подобрението: тествате, отстранявате проблемите с най-висок приоритет и проверявате корекциите повторно. Постоянният подход и съпоставимите доклади показват дали едни и същи първопричини продължават да водят до нови констатации.