Forwarded from вольтаж
file://localhost/etc/passwd что вернёт?
В RFC 8089, верный формат протокола описан как
file://<host>/<path>, в то время как все шпоры на LFR при SSRF говорят лишь о file:///<path>Причём, в
<host> возможно вписать домен. Система резолвнет его, и если тот указывает на 127.0.0.1, то вернётся содержимое файла. В противном случае получишь лишь отстук в DNS. питон пок
from urllib.request import urlopen
content = urlopen(
"file://yoogle.com/etc/passwd", timeout=2,
).read().decode('utf-8')
print(content)
Представил сколько возможностей для обхода фильтров? И это не последний твой приступ FOMO за сегодня.
В статье The Minefield Between Syntaxes от @yeswehack, автор вскрывает проблемы разных синтаксисов и как парсеры выживают с ними.
Представим, ты нашёл SSTI, но WAF блокирует символ$
Что делать?
Неприятно, но не критично, ведь в Python / Perl возможно представить символ через
\N{CHARACTER NAME}. Пример обхода фильтра
\N{dollar sign}{7*7} == ${7*7} == 49Уже на стену лезешь? Погоди, я с тобой ещё не закончил.
Давай дальше по загрузке файлов. Видел же в
Content-Disposition есть параметр filename?В RFC 6266 описан базовый подход с именем файла, но RFC 8187 вышибает дверь с... чего.. какие юникод байты
# RFC 6266
filename="image.png"
# RFC 8187
filename*=UTF8''image%0a.png
RFC 8187 вводит новые правила для
filename параметра, включая поддержку всего Unicode + способности кодировать произвольные байты через % То есть, ты можешь закодировать перенос строки (
%0a == \n) и всячески ломать как парсинг имени файла, так и куда тот запишется. . . .
FOMO карусель закрыта.
Как восстановишь силы, пробегись по статье автора ради:
⚀ разбор CVE из-за проблем синтаксиса [^]
⚀ кейс бб, из cache poisoning в stored xss через пролом валидации parse_url в PHP [^]
⚀ кейс бб, из слепого чтения файлов через SSRF в arbitrary file read [^]
Затем разнеси CTF по ресерчу
1. обход фильтров SSTI [^]
2. иной подход к протоколу file:// [^]
3. проломparse_urlв PHP [^]
#web #waf_bypass
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заметки Слонсера (Slonser)
https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
React UNAUTH RCE
CVSS 10
По патчу успел понять в чем проблема (PoC пока пишу)
Уже сейчас могу сказать что похоже действительно уязвимы прям стандартные версии
То есть разработчику не нужно даже написать стремный код / использовать конкретный модуль
Достаточно написать:
То есть имеем очень страшное RCE by default на миллионах сайтов
Реверсим патч и лутаем миллионы на багбаунти...
React UNAUTH RCE
CVSS 10
По патчу успел понять в чем проблема (PoC пока пишу)
Уже сейчас могу сказать что похоже действительно уязвимы прям стандартные версии
То есть разработчику не нужно даже написать стремный код / использовать конкретный модуль
Достаточно написать:
npx create-next-app
То есть имеем очень страшное RCE by default на миллионах сайтов
Реверсим патч и лутаем миллионы на багбаунти...
This media is not supported in your browser
VIEW IN TELEGRAM
рабочий PoC CVE-2025-55182 подвез maple3142
https://gist.github.com/maple3142/48bc9393f45e068cf8c90ab865c0f5f3
https://gist.github.com/maple3142/48bc9393f45e068cf8c90ab865c0f5f3
Forwarded from wr3dmast3r vs pentest
Данный материал подготовлен мной совместно с моим учеником для всех, кто пытается начать свой путь в области безопасности веб-приложений ☺️
На мой взгляд, PortSwigger является фаворитом среди всех обучающих материалов по информационной безопасности, и мне бы хотелось, чтобы вы в первую очередь пользовались именно бесплатными источниками знаний, а не платили за сомнительные курсы. Тем более, что большинство курсов на русском языке и так заимствуют значительную часть материалов, представленных здесь🤓
Дальнейшее развитие репозитория возможно с вашей помощью: каждый из вас может внести вклад, добавляя решения лабораторных работ. Со своей стороны я буду по мере сил пополнять разделы, и вместе мы сделаем вход в изучение веб-безопасности бесплатным и доступным для каждого🎧
Подробнее
На мой взгляд, PortSwigger является фаворитом среди всех обучающих материалов по информационной безопасности, и мне бы хотелось, чтобы вы в первую очередь пользовались именно бесплатными источниками знаний, а не платили за сомнительные курсы. Тем более, что большинство курсов на русском языке и так заимствуют значительную часть материалов, представленных здесь
Дальнейшее развитие репозитория возможно с вашей помощью: каждый из вас может внести вклад, добавляя решения лабораторных работ. Со своей стороны я буду по мере сил пополнять разделы, и вместе мы сделаем вход в изучение веб-безопасности бесплатным и доступным для каждого
Подробнее
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда меня спрашивают, как вкатиться в айти с нуля, а тем более в хакинг, я всегда отвечаю, что понятия не имею. Абсолютно искренне.
То, что я никакущий учитель - это одна причина. Вторая, менее очевидная - наличие хакерской смекалки. Я не знаю, откуда она берется: врожденное ли это качество или приобретенное. Не уверен я и в том, что без нее вообще никуда. Наверное, можно на базовом уровне находить IDOR'ы.
Но все действительно сильные и вдохновляющие эксплойты всегда ею обладают. Уже не первый год я пою дифирамбы этому исследованию: https://projectzero.google/2021/12/a-deep-dive-into-nso-zero-click.html. Для меня это лучший пример эксплойта, с которым я когда-либо сталкивался. Идеальная иллюстрация хакерской смекалки в её высшем проявлении.
Я часто возвращаюсь к этой статье в моменты потери стимула или недостатка мотивации - это невероятно вдохновляет. Если отбросить этическую составляющую этой истории и оценивать только техническую сложность и изобретательность... это шедевр.
Я часто думаю: что должно двигать человеком, чтобы начать искать подобную уязвимость и довести её до такого импакта? Ответа у меня нет.
То, что я никакущий учитель - это одна причина. Вторая, менее очевидная - наличие хакерской смекалки. Я не знаю, откуда она берется: врожденное ли это качество или приобретенное. Не уверен я и в том, что без нее вообще никуда. Наверное, можно на базовом уровне находить IDOR'ы.
Но все действительно сильные и вдохновляющие эксплойты всегда ею обладают. Уже не первый год я пою дифирамбы этому исследованию: https://projectzero.google/2021/12/a-deep-dive-into-nso-zero-click.html. Для меня это лучший пример эксплойта, с которым я когда-либо сталкивался. Идеальная иллюстрация хакерской смекалки в её высшем проявлении.
Я часто возвращаюсь к этой статье в моменты потери стимула или недостатка мотивации - это невероятно вдохновляет. Если отбросить этическую составляющую этой истории и оценивать только техническую сложность и изобретательность... это шедевр.
Я часто думаю: что должно двигать человеком, чтобы начать искать подобную уязвимость и довести её до такого импакта? Ответа у меня нет.
projectzero.google
A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution - Project Zero
Posted by Ian Beer & Samuel Groß of Google Project Zero We want to thank Citizen Lab for sharing a sample of the FORCEDENTRY exploit with us, and...
Там, если что, порствиггер запустил очередное ежегодное голосование. Кто упустил за год крутые исследования, можно догнать и ознакомиться. А я тем временем заболел, лежу с температурой и читаю классику - Back to the Roots: "Введение в C++" Андрея Столярова, 5-е издание.
📌 Взять на заметку, интересный сценарий
У Tesla было два раздельных портала для входа в системы:
На публичном портале (
Исследователь задался вопросом: а что, если зарегистрироваться на email-адрес бывшего сотрудника? Его учетная запись во внутреннем портале (
Внимание исследователя привлек внутренний инструмент Tesla Retail Tool (TRT), содержащий крайне конфиденциальную информацию: логины и пароли для сетевого оборудования, данные по аренде помещений, финансовую информацию, внутренние фотографии объектов и т.д. Этот инструмент позволял входить как через внутренний, так и через публичный портал.
Схема атаки:
1. Нашел в LinkedIn профили бывших сотрудников Tesla
2. Для найденных имен он сформировал корпоративные email-адреса (например,
3. Используя эти новые учетные данные, он смог войти в конфиденциальный Tesla Retail Tool (TRT). Система TRT видела "правильный" корпоративный email в токене авторизации и предоставляла доступ, не проверяя, через какой именно портал был выполнен вход. Привилегии в системе были все еще привязаны к этому email.
https://bugcrowd.com/disclosures/4d9d22af-3a9f-45ce-8eef-8d4fba06a205/auth-tesla-com-account-takeover-of-internal-tesla-accounts
У Tesla было два раздельных портала для входа в системы:
sso.tesla.com - внутренний, для действующих сотрудников и auth.tesla.com - публичный, для внешних пользователей, например, владельцев автомобилей.На публичном портале (
auth.tesla.com) можно было без какой-либо проверки по электронной почте зарегистрировать учетную запись на корпоративные email-адреса Tesla (@tesla.com). При попытке использовать адрес действующего сотрудника система сообщала, что он "занят". Однако…Исследователь задался вопросом: а что, если зарегистрироваться на email-адрес бывшего сотрудника? Его учетная запись во внутреннем портале (
sso.tesla.com) уже удалена, но его адрес, вероятно, оставался в списках доступа некоторых внутренних систем.Внимание исследователя привлек внутренний инструмент Tesla Retail Tool (TRT), содержащий крайне конфиденциальную информацию: логины и пароли для сетевого оборудования, данные по аренде помещений, финансовую информацию, внутренние фотографии объектов и т.д. Этот инструмент позволял входить как через внутренний, так и через публичный портал.
Схема атаки:
1. Нашел в LinkedIn профили бывших сотрудников Tesla
2. Для найденных имен он сформировал корпоративные email-адреса (например,
ivan.ivanov@tesla.com) и зарегистрировал на них учетные записи на публичном портале auth.tesla.com3. Используя эти новые учетные данные, он смог войти в конфиденциальный Tesla Retail Tool (TRT). Система TRT видела "правильный" корпоративный email в токене авторизации и предоставляла доступ, не проверяя, через какой именно портал был выполнен вход. Привилегии в системе были все еще привязаны к этому email.
https://bugcrowd.com/disclosures/4d9d22af-3a9f-45ce-8eef-8d4fba06a205/auth-tesla-com-account-takeover-of-internal-tesla-accounts
Bugcrowd
Auth.Tesla.com Account Takeover of Internal Tesla Accounts - CrowdStream - Bugcrowd
Bugcrowd's bug bounty and vulnerability disclosure platform connects the global security researcher community with your business. Crowdsourced security testing, a better approach! Run your bug bounty programs with us.
📌 Бывает так, что приложение не проверяет, что все шаги процедуры (запрос сброса пароля → ввод OTP → установка нового пароля) выполняются одним и тем же пользователем (с одной и той же сессией) в одном непрерывном процессе.
1. Злоумышленник, зная email жертвы, заходит на сайт
2. Когда приложение запрашивает OTP-код (который отправляется жертве на почту), злоумышленник копирует URL из адресной строки своего браузера. Этот URL содержит уникальный идентификатор (
3. Атакующим создается фишинговое письмо (например, "Обнаружена подозрительная активность в вашем аккаунте. Для сброса пароля перейдите по ссылке") и отправляется жертве. В письме - подлинная ссылка с сайта компании (что делает ее менее подозрительной)
4. Жертва переходит по ссылке, попадает на легитимную страницу сброса пароля на
5. Пока жертва выполняет шаг 4, атакующий в своем браузере начинает периодически обновлять страницу. В момент, когда жертва введет OTP, ответ сервера для атакующего изменится - вместо формы ввода кода он получит форму для установки нового пароля (потому что уникальный token в URL теперь активирован жертвой).
6. Атакующий, получив форму для смены пароля, вводит имя жертвы и задает новый пароль от аккаунта до того, как это сможет сделать сама жертва. После этого он может войти в аккаунт с новым паролем.
1. Злоумышленник, зная email жертвы, заходит на сайт
www.example.com, инициирует процедуру "Забыли пароль?" и вводит email жертвы.2. Когда приложение запрашивает OTP-код (который отправляется жертве на почту), злоумышленник копирует URL из адресной строки своего браузера. Этот URL содержит уникальный идентификатор (
token или session_id) для этого конкретного процесса сброса.3. Атакующим создается фишинговое письмо (например, "Обнаружена подозрительная активность в вашем аккаунте. Для сброса пароля перейдите по ссылке") и отправляется жертве. В письме - подлинная ссылка с сайта компании (что делает ее менее подозрительной)
4. Жертва переходит по ссылке, попадает на легитимную страницу сброса пароля на
www.example.com и вводит полученный по SMS/email OTP-код, думая, что защищает свой аккаунт. На этом этапе приложение считает процесс "подтвержденным".5. Пока жертва выполняет шаг 4, атакующий в своем браузере начинает периодически обновлять страницу. В момент, когда жертва введет OTP, ответ сервера для атакующего изменится - вместо формы ввода кода он получит форму для установки нового пароля (потому что уникальный token в URL теперь активирован жертвой).
6. Атакующий, получив форму для смены пароля, вводит имя жертвы и задает новый пароль от аккаунта до того, как это сможет сделать сама жертва. После этого он может войти в аккаунт с новым паролем.
Forwarded from [DeteAct] Оценка защищённости
Захват аккаунта через telegram-бот: от своего номера к чужому профилю
Всего пять минут ожидания, один чужой номер телефона и обычная кнопка для получения ссылки — этого оказалось достаточно, чтобы обнаружить критическую уязвимость. Настолько минимальный сценарий неожиданно вскрыл проблему в логике обработки данных.
Читать 👉 https://blog.deteact.ru/account-takeover-thru-telegram-bot/
Всего пять минут ожидания, один чужой номер телефона и обычная кнопка для получения ссылки — этого оказалось достаточно, чтобы обнаружить критическую уязвимость. Настолько минимальный сценарий неожиданно вскрыл проблему в логике обработки данных.
Читать 👉 https://blog.deteact.ru/account-takeover-thru-telegram-bot/
Deteact - Тестирование на проникновение. Информационная безопасность
Захват аккаунта через telegram-бот: от своего номера к чужому профилю - Deteact
Автор баги: arkiix Всего пять минут ожидания, один чужой номер телефона и обычная кнопка для получения ссылки — этого оказалось достаточно, чтобы обнаружить критическую уязвимость. Настолько минимальный сценарий неожиданно вскрыл проблему в логике обработки…
Я очень люблю уязвимости в бизнес-логике. Посему ещё пост в продолжение к предыдущим 🤭
📌 Отсутствие привязки к сессии
Критически важные действия должны быть жестко привязаны к сессии или токену того пользователя, который инициировал это действие. Сервер должен сверять параметры в ссылке с данными в текущей авторизованной сессии пользователя.
Пример уязвимости:
1. Исследователь создает две учетные записи на целевом сайте:
2. В аккаунте
3. Исследователь копирует эту ссылку, выходит из аккаунта
4. Сервер, не проверяя сессию, обрабатывает запрос по ссылке и применяет изменение email к текущей авторизованной сессии - аккаунту жертвы. Email
Идиома "Insecure Direct Object References (IDOR)": Уязвимость можно рассматривать как разновидность IDOR, где "объектом" является операция по изменению email, а токен подтверждения выступает в роли прямого указателя на эту операцию без должной проверки прав доступа.
📌 Отсутствие привязки к сессии
Критически важные действия должны быть жестко привязаны к сессии или токену того пользователя, который инициировал это действие. Сервер должен сверять параметры в ссылке с данными в текущей авторизованной сессии пользователя.
Пример уязвимости:
1. Исследователь создает две учетные записи на целевом сайте:
victim@gmail.com (жертва) и attacker@gmail.com (атакующий).2. В аккаунте
attacker@gmail.com инициируется смена email на контролируемый ящик (например, 123@gmail.com). На этот ящик приходит ссылка для подтверждения.3. Исследователь копирует эту ссылку, выходит из аккаунта
attacker@gmail.com, входит в аккаунт victim@gmail.com и вставляет ссылку в браузер.4. Сервер, не проверяя сессию, обрабатывает запрос по ссылке и применяет изменение email к текущей авторизованной сессии - аккаунту жертвы. Email
victim@gmail.com меняется на 123@gmail.com.Идиома "Insecure Direct Object References (IDOR)": Уязвимость можно рассматривать как разновидность IDOR, где "объектом" является операция по изменению email, а токен подтверждения выступает в роли прямого указателя на эту операцию без должной проверки прав доступа.
Forwarded from Очерк
Иногда, когда читаешь раскрытый репорт или статью на Medium об уязвимости в багбаунти, хочется потрогать это руками и заложить у себя в навыках ту или иную багу немного глубже.😵💫
Так вот, в итоге из этой мысли я сделал: https://labs.hackadvisor.io/
Все машинки собраны из публичных репортов и статей ресерчеров. Сейчас можно разворачивать стенд, решать задачи, получать подсказки и разбор уязвимости по итогу. Буду потихоньку пилить интересные машинки из раскрытых отчётов — надеюсь, вы тоже закинете что-то интересное: оно обязательно появится.
Сразу дисклеймер: у меня пока небольшой опыт в создании таких заданий, так что где-то может быть шероховато. Но со временем буду делать лучше — и сами задания, и их подачу — и добавлять больше интересных сценариев.
В целом Labs — это всего лишь MVP и первый этап будущей полноценной экосистемы HackAdvisor, которая, как и всё для сообщества, совершенно бесплатна.
Всех обнял, жду фидбек, баги и фича-реквесты🙌🏻
Ну и, пожалуйста, не ломайте сам Labs (даже если очень хочется) — пока там всё очень хрупко 🫠
Так вот, в итоге из этой мысли я сделал: https://labs.hackadvisor.io/
Все машинки собраны из публичных репортов и статей ресерчеров. Сейчас можно разворачивать стенд, решать задачи, получать подсказки и разбор уязвимости по итогу. Буду потихоньку пилить интересные машинки из раскрытых отчётов — надеюсь, вы тоже закинете что-то интересное: оно обязательно появится.
Сразу дисклеймер: у меня пока небольшой опыт в создании таких заданий, так что где-то может быть шероховато. Но со временем буду делать лучше — и сами задания, и их подачу — и добавлять больше интересных сценариев.
В целом Labs — это всего лишь MVP и первый этап будущей полноценной экосистемы HackAdvisor, которая, как и всё для сообщества, совершенно бесплатна.
Всех обнял, жду фидбек, баги и фича-реквесты🙌🏻
Ну и, пожалуйста, не ломайте сам Labs (даже если очень хочется) — пока там всё очень хрупко 🫠
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from BlackFan
Интересная уязвимость, связанная с кэшированием HTTP ответов из S3, может возникнуть если немного перестараться с настройкой.
Условия:
1) Сайт хранит статику в S3 и по определенным условиям проксирует туда запросы, либо имеет отдельный поддомен, который проксирует запросы на S3 бакет
2) Чтобы не гонять 10 мегабайтные JavaScript файлы, кэшируется контент из S3 для любого HTTP ответа с кодом 200
3) Так как кэшируется только статика - не включаем в ключ кэша cookie или query-параметры
Казалось бы, все в порядке, но проблема заключается в том, что S3 умеет отвечать с кодом 200 не только возвращая контент файла, но еще и при получении другой информации об объекте.
Например, для получения списка тегов достаточно в query-параметры добавить
В результате, вместо контента файла вернется следующий HTTP ответ:
И если так запросить статику на сайте в момент, когда кэш HTTP ответа будет обновляться - это приведет к тому, что всем следующим пользователям вместо JS вернется некорректный ответ и сайт станет недоступен на время жизни зараженного кэша.
Если
Как проверить уязвимость и не аффектить реальных пользователей:
1) Находим через архивы устаревшие JS на сайте
2) Так как к ним никто не обращается, следующий запрос будет с обновлением кэша, поэтому сразу запрашиваем с
3) Проверяем, что зараженный HTTP ответ возвращается без указания query-параметров
3) Проверяем, что кэш не привязан к текущему пользователю запросив с другого устройства / IP / от имени другого пользователя
Как исправить уязвимость:
1) Убрать из проксируемого HTTP запроса query-параметры при передаче на S3
2) Добавить query-параметры в ключ кэша
Условия:
1) Сайт хранит статику в S3 и по определенным условиям проксирует туда запросы, либо имеет отдельный поддомен, который проксирует запросы на S3 бакет
2) Чтобы не гонять 10 мегабайтные JavaScript файлы, кэшируется контент из S3 для любого HTTP ответа с кодом 200
3) Так как кэшируется только статика - не включаем в ключ кэша cookie или query-параметры
Казалось бы, все в порядке, но проблема заключается в том, что S3 умеет отвечать с кодом 200 не только возвращая контент файла, но еще и при получении другой информации об объекте.
Например, для получения списка тегов достаточно в query-параметры добавить
?tagging, что часто разрешают для неавторизованных запросов.https://site.tld/static/somefile.js?tagging
В результате, вместо контента файла вернется следующий HTTP ответ:
<?xml version="1.0" encoding="UTF-8"?>
<Tagging xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<TagSet></TagSet>
</Tagging>
И если так запросить статику на сайте в момент, когда кэш HTTP ответа будет обновляться - это приведет к тому, что всем следующим пользователям вместо JS вернется некорректный ответ и сайт станет недоступен на время жизни зараженного кэша.
Если
?tagging, ?acl и подобные методы возвращают 403, можно попробовать параметры из GetObject API и, например, закэшировать некорректный Content-Type, указав в запросе ?response-content-type=text/html. Это приведет к тому, что браузер откажется выполнять JavaScript с некорректным типом, что также приведет к нарушению работы сайта (это поведение еще зависит от наличия в ответе заголовка X-Content-Type-Options: nosniff).Как проверить уязвимость и не аффектить реальных пользователей:
1) Находим через архивы устаревшие JS на сайте
2) Так как к ним никто не обращается, следующий запрос будет с обновлением кэша, поэтому сразу запрашиваем с
?tagging или ?response-content-type=text/html3) Проверяем, что зараженный HTTP ответ возвращается без указания query-параметров
3) Проверяем, что кэш не привязан к текущему пользователю запросив с другого устройства / IP / от имени другого пользователя
Как исправить уязвимость:
1) Убрать из проксируемого HTTP запроса query-параметры при передаче на S3
2) Добавить query-параметры в ключ кэша
Когда я только начинал в CTF, мне казалось, что эти все баги такие искусственные, что такое в жизни никогда не встретишь. Что всё оторвано от реальности.
Когда я познакомился с одним топовым хантером, я задавал ему кучу вопросов, он мне даже раскрыл несколько багов. И я, мягко говоря, ахуел. Я не мог поверить, что такая банальная хрень может быть в сервисе, которым пользуются миллионы.
Когда я уже стал работать в анализе защищенности, я застал появление двух баг-баунти платформ в России. Я видел, как росло количество репортов на глазах. Я поисследовал одну из программ и нашел парочку medium-багов, за которые мне заплатили. При этом параллельно я видел, как заводились репорты high и critical с существенными выплатами. Я думал: как так? Я же всё просмотрел. Что они там нашли такого, чего я не заметил?
Позже на одном из оффзонов я встретил и пообщался с автором этих репортов - и опять то же чувство. Постфактум всё кажется легким, всё лежало на поверхности, но нашел не я. Я с ужасом осознал, на каком шаге я бы уже отвалился и не полез дальше. Тот маркер, за который он зацепился и начал копать глубже, я даже не заметил - прошел мимо.
Я очень люблю BAC как концепцию и верю, что он есть везде. После того как я стал уделять этому больше внимания, почти во всех проектах (за редким исключением) я стал его находить в том или ином виде.
Сейчас понимаю: как ничто другое, важен накопленный арсенал. Надо больше исследовать.
Когда я познакомился с одним топовым хантером, я задавал ему кучу вопросов, он мне даже раскрыл несколько багов. И я, мягко говоря, ахуел. Я не мог поверить, что такая банальная хрень может быть в сервисе, которым пользуются миллионы.
Когда я уже стал работать в анализе защищенности, я застал появление двух баг-баунти платформ в России. Я видел, как росло количество репортов на глазах. Я поисследовал одну из программ и нашел парочку medium-багов, за которые мне заплатили. При этом параллельно я видел, как заводились репорты high и critical с существенными выплатами. Я думал: как так? Я же всё просмотрел. Что они там нашли такого, чего я не заметил?
Позже на одном из оффзонов я встретил и пообщался с автором этих репортов - и опять то же чувство. Постфактум всё кажется легким, всё лежало на поверхности, но нашел не я. Я с ужасом осознал, на каком шаге я бы уже отвалился и не полез дальше. Тот маркер, за который он зацепился и начал копать глубже, я даже не заметил - прошел мимо.
Я очень люблю BAC как концепцию и верю, что он есть везде. После того как я стал уделять этому больше внимания, почти во всех проектах (за редким исключением) я стал его находить в том или ином виде.
Сейчас понимаю: как ничто другое, важен накопленный арсенал. Надо больше исследовать.