Русский перевод и адаптация OWASP Application Security Verification Standard

Стандарт верификации требований к безопасности приложений — это перечень требований к безопасности приложений (тестов), которыми могут пользоваться архитекторы, разработчики, тестировщики, специалисты по безопасности, разработчики инструментов и конечные пользователи для проектирования, разработки, тестирования и контроля безопасных приложений.

Пятая версия стандарта верификации требований к безопасности приложений опирается на предыдущие версии ASVS, начиная с первой, вышедшей в 2008 году, и до четвертой, в 2019 году.

После выхода версии ASVS 4.0 в 2019 году и ее незначительного обновления (v4.0.3) в 2021 году, версия 5.0 является значительным шагом вперед — она была модернизирована, чтобы учесть последние достижения в области безопасности программного обеспечения.

ASVS 5.0 стал результатом масштабного вклада руководителей проекта, членов рабочей группы и широкого сообщества OWASP, направленного на обновление и совершенствование этого важного стандарта.

Область действия ASVS
Область действия ASVS определяется его названием: Приложение (Application), Безопасность (Security), Верификация (Verification) и Стандарт (Standard). Он устанавливает, какие требования включены в стандарт, а какие — исключены из него, с глобальной целью определения основополагающих принципов безопасности, которые должны быть достигнуты. Область действия также учитывает требования к документации, которые служат основой для требований к реализации.

Не существует такого понятия, как «область действия» для злоумышленника. Поэтому требования ASVS должны оцениваться в совокупности с рекомендациями по другим аспектам жизненного цикла приложения, включая процессы CI/CD, хостинг и операционную деятельность.

Приложение
ASVS определяет «Приложение» как разрабатываемый программный продукт, в который должны быть интегрированы механизмы безопасности. ASVS не регламентирует процессы жизненного цикла разработки и не указывает на методы сборки приложения в CI/CD. Его задача — описать требуемый уровень защищённости, который должен быть достигнут в конечном продукте.

Компоненты для обработки HTTP-трафика (WAF, балансировщики нагрузки, прокси) могут считаться частью приложения в контексте безопасности, поскольку некоторые механизмы безопасности напрямую зависят от них или могут быть реализованы с их помощью. Это касается требований по кешированию, rate limiting, а также фильтрации входящих/исходящих подключений по источнику и получателю.

В свою очередь, ASVS не включает требования, не относящиеся к приложению напрямую или находящиеся за пределами его зоны ответственности. Так, например, проблемы DNS обычно относятся в ведении отдельной команды или функции.

Аналогично, хотя в зону ответственности приложения входит обработка входящих данных и генерация исходящих данных, если внешний процесс взаимодействует с приложением или его данными, это считается выходящим за рамки ASVS. Например, резервное копирование приложения или его данных обычно выполняется внешними процессами и не контролируется самим приложением или его разработчиками.

Безопасность
Каждое требование должно иметь очевидное влияние на безопасность. Отсутствие требования должно привести к снижению уровня защищённости приложения, а реализация требования должна либо уменьшить вероятность возникновения риска безопасности, либо смягчить последствия.

Все прочие аспекты, такие как функциональные характеристики, стиль кода или требования политик, выходят за рамки стандарта.

Верификация
Требование должно быть верифицируемым, а его проверка должна приводить к однозначному решению: «не выполнено» или «выполнено».

Стандарт
ASVS представляет собой набор требований безопасности, которые необходимо реализовать для соответствия стандарту. Это означает, что требования ограничиваются определением целевого показателя безопасности, которого необходимо достичь. Прочая сопутствующая информация может быть надстроена на основе ASVS или связана с ним через сопоставления.

PDF RU

Memory Bank: как сделать ИИ-кодера умнее и дешевле 🧠💰

Всем добрый вечер!

Хотел бы рассказать про крутую фишку для работы с ИИ-кодерами — Memory Bank.
Это система, которая делает Cline, RooCode, Cursor и другие ИИ-инструменты в разы эффективнее.
По сути, это развитие подхода авто-трекинга изменений проекта, о котором писал еще в начале года.

Что такое Memory Bank? 📁
Это набор markdown-файлов, которые ИИ-кодер автоматически создаёт и обновляет, чтобы "помнить" всё о вашем проекте между сессиями. Все это для того, чтобы у вашего ИИ-кодера появилась долговременная память!

Какие файлы создаются? 📋
Memory Bank состоит из 6 основных файлов:

• projectbrief.md — основа проекта, цели и требования
• productContext.md — для чего нужен продукт, какие проблемы решает
• activeContext.md — над чем работаем сейчас, текущие задачи
• systemPatterns.md — архитектура, технические решения
• techContext.md — используемые технологии и зависимости
• progress.md — что сделано, что осталось, известные проблемы

Зачем это нужно? 🤔

1️⃣ Экономия денег — не нужно держать огромные дорогие треды, где повторяется контекст

2️⃣ Экономия времени — не нужно каждый раз объяснять ИИ, что вы делаете

3️⃣ Лучшее качество кода — ИИ помнит все паттерны и решения проекта

4️⃣ Документация на автомате — получаете структурированную документацию как побочный эффект

Как настроить? ⚙️
1) Создайте папку memory-bank/ в корне проекта
2) Добавьте специальные инструкции в настройках ИИ-кодера:

• В Cline: Settings → Custom Instructions → вставьте инструкции
• В Cursor: создайте .cursor/rules/memory-bank.mdc

3) Напишите ИИ-кодеру: initialize memory bank

И всё! Теперь ваш ИИ будет автоматически поддерживать актуальную "память" о проекте.

Как использовать? 🚀
• Начинайте новые чаты с фразы follow your custom instructions
• Когда нужно обновить память, пишите update memory bank
• Используйте режимы Plan (планирование) и Act (реализация)

Особенно круто, что можно переключаться между разными ИИ-инструментами — они будут читать одни и те же файлы Memory Bank!

Мой опыт 💡
Я заметил, что с Memory Bank:
• Расход токенов снизился, примерно на треть
• ИИ стал делать меньше ошибок
• Не нужно постоянно напоминать контекст
• Появилась хорошая документация проекта

Попробуйте сами — это улучшает подход к работе с ИИ-кодерами!

Источники
• Cline Memory Bank | Cline
• Cline Memory Bank - Custom Instructions (GitHub)
• How to add Cline Memory Bank feature to your cursor (Cursor Community Forum)
• Roo Code Memory Bank (Github)

#ИИ #разработка #Cline #RooCode #Cursor #MemoryBank

Злоупотребление сервисами (абьюз) ограничений Wi-Fi на борту самолета: SNI-bypass и DNS-туннеллирование и доверенные сервисы

British Airways
Автор описывает, как авиакомпания фильтрует бесплатный «месседжинг»-тариф по SNI (Server Name Indication) — по доменам, которые видны в начале TLS-рукопожатия; если SNI совпадает с разрешёнными доменами «мессенджеров», соединение пропускается, иначе — сбрасывается.

Обход: создать HTTPS-прокси на своём VPS, прогнать через него трафик и вручную установить SNI в клиентском TLS-handshake (например, через --resolve в curl или правку hosts), чтобы провайдер «думал», что это трафик к разрешённому домену (в статье используется wa.me (whatsapp) как пример). Для TLS-обёртки автор использует stunnel/самоподписанный сертификат и игнорирование проверок на клиенте.

Air Canada
Поскольку шлюз самолета не блокирует DNS-запросы, теоретически мы могли бы замаскировать наш прокси-сервер под DNS-сервер, открыть порт 53 для службы DNS, направлять все запросы через прокси-сервер, замаскированный под DNS-запросы, и таким образом обойти ограничения.

PySkyWiFi
PySkyWiFi — это сильно упрощённая версия протокола TCP/IP, которая передаёт все HTTP-запросы через аккаунт AirMiles из самолёта на компьютер, подключенный к интернету на земле. Служба, работающая на этом компьютере, отправляет HTTP-запросы за пользователя, а затем передаёт готовые HTTP-ответы обратно через аккаунт AirMiles в самолёт.

_______________

Почему Wi‑Fi в самолете такой ужасный, дорогой и до сих пор есть не везде и как это работает.