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

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

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

Микросервисы и контейнеры для их развертывания сейчас являются стандартом в крупных компаниях. Для разработчиков и DevOps-инженеров это удобный подход: он дает больше возможностей и ускоряет процессы.

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

Меня зовут Саша Рахманный, я разработчик в команде информационной безопасности в Lamoda Tech. В этой статье я сравню разные базовые образы для .NET с точки зрения безопасности их компонентов и быстродействия. 

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

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

Меня зовут Дмитрий Кочнев, я разработчик в команде интернет-платежей и в этой статье расскажу о том, какой путь проделала компания в этом направлении, какое положение дел сейчас и какие планы. Статья написана в формате мини-историй, каждая из которых может стать отдельной статьёй с большим количеством подробностей, если к ней возникнет интерес с вашей стороны.

С первой частью рассказа о микрофронтендах в Dodo можно ознакомиться тут

Мы спокойно сидели и пилили новый проект на нашем устоявшемся стеке (React + TypeScript + Webpack + SingleSPA + SystemJS + Jest). Пока одним прекрасным утром не пришел наш техлид и такой: «Чуваки, а давайте затащим Vitest!».

Ниже я расскажу о том, как заменить ваш VPN провайдер собственным сервером, развернутым на DigitalOcean с использованием WireGuard.

В чем главная проблема VPN провайдеров? Вы не знаете что они делают с вашими данными.
Очень мало VPN провайдеров прошли сторонний аудит и почти никто из них не открывает свой код.
Даже в случае открытого кода и пройденного аудита, для параноиков вопрос про то, что же происходит на стороне провайдера — остается открытым.

Решение достаточно простое — развернуть свою VPN ноду.

Я хочу сделать это просто

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

Цель статьи - поделиться практиками, которые я применил для защиты данных при поднятии собственного VPS в публичной сети. Всегда, когда твой IP открыт всему Миру напоказ и доступен извне внутренних контуров сети - это означает, что любой прохожий может устроить тебе неприятности: похитить твои данные, завладеть твоим сервером и сломать твое замечательное приложение. Я буду приводить пример атаки, показывать, как ее можно заметить и после этого будем разбирать возможные способы защиты.

Доброго времени суток, друзья!

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

Сначала мы с вами кратко разберем основные виды уязвимостей веб-приложений, а также основные виды атак, основанные на этих уязвимостях. Далее мы рассмотрим все современные заголовки, каждый — по отдельности. Это в теоретической части статьи.

В практической части мы реализуем простое Express-приложение, развернем его на Heroku и оценим безопасность с помощью WebPageTest и Security Headers. Также, учитывая большую популярность сервисов для генерации статических сайтов, мы настроим и развернем приложение с аналогичным функционалом на Netlify.

Исходный код приложений находится здесь.

Демо Heroku-приложения можно посмотреть здесь, а Netlify-приложения — здесь.

Основными источниками истины при подготовке настоящей статьи для меня послужили следующие ресурсы:

• Security headers quick reference — Google Developers
• OWASP Secure Headers Project
• Web security — MDN

Речь идет о поправках к закону о персональных данных, что вступили в силу в марте. Теперь любые персональные данные обязаны убрать откуда угодно по первому требованию их владельца. Причем владельцу не надо ничего никому доказывать и объяснять.

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

Что касается нововведений, я попытался разложить все по полочкам. А еще собрал в отдельный список то, что придется поменять и добавить владельцам сайтов.