Рекомендации по обеспечению безопасности (TLS/SSL, CSRF, SQL-инъекции, XSS)
(продолжение предыдущего поста)

### Почему безопасность важна

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

### TLS/SSL (безопасность транспортного уровня / защищённый сокетный слой)

→ Обеспечивает шифрование между клиентом и сервером.
→ Предотвращает прослушивание, подмену данных и маскировку.
→ Лучшие практики: всегда используйте HTTPS, применяйте надёжные сертификаты и отключайте слабые шифры.

### CSRF (межсайтовая подделка запросов)

→ Злоумышленники обманом заставляют пользователей отправлять несанкционированные запросы (например, перевод денег, изменение настроек учётной записи).
→ Лучшие практики:

✓ Внедрите CSRF-токены в формы.
✓ Используйте SameSite-куки для блокировки сторонних эксплойтов.
✓ Проверяйте заголовки реферера для валидации запросов.

### SQL-инъекции

→ Возникают, когда злоумышленники внедряют вредоносный SQL-код в запросы для доступа к базам данных или их изменения.
→ Лучшие практики:

✓ Всегда используйте параметризованные запросы или подготовленные операторы.
✓ Избегайте конкатенации динамических SQL-строк.
✓ Применяйте принцип минимальных привилегий для пользователей баз данных.

### XSS (межсайтовый скриптинг)

→ Внедрение вредоносного JavaScript-кода на сайт для кражи cookies, перехвата сессий или распространения вредоносного ПО.
→ Лучшие практики:

✓ Очищайте и экранируйте все пользовательские данные.
✓ Используйте политику безопасности контента (CSP).
✓ Кодируйте выходные данные перед их отображением в HTML, JavaScript или URL.

### Аналогии

→ TLS/SSL → Как запечатывание писем в конверты с защитой от вскрытия.
→ CSRF → Как обман человека, чтобы он подписал чек, который не писал.
→ SQL-инъекции → Как вставка скрытых инструкций в форму заказа.
→ XSS → Как размещение вредоносной листовки на общественной доске объявлений.

### Чек-лист безопасности для backend-разработчиков

✓ Используйте HTTPS везде с TLS/SSL
✓ Проверяйте и очищайте все пользовательские данные
✓ Используйте параметризованные запросы для доступа к базе данных
✓ Экранируйте выходные данные для предотвращения XSS-атак
✓ Внедрите защиту от CSRF с помощью токенов и SameSite-куки
✓ Применяйте принцип минимальных привилегий для ролей базы данных и сервера
✓ Регулярно обновляйте программные зависимости и применяйте патчи безопасности
✓ Отслеживайте журналы на предмет подозрительной активности
✓ Используйте ограничение частоты запросов для блокировки брутфорс-атак
✓ Проводите тесты на проникновение и сканирование уязвимостей

### Типы портов VLAN

1. Access Port:
- Каждый порт привязан к одному VLAN.
- Передаёт и принимает немаркированные пакеты (Untagged Packets).
- Коммутатор добавляет тег VLAN на основе конфигурации порта.
- Конечным устройствам не требуется знание о VLAN.
- Один широковещательный домен на VLAN.

2. Trunk Port:
- Используется для соединения с другими коммутаторами.
- Передаёт маркированные пакеты (Tagged Packets), принадлежащие нескольким VLAN.
- Обеспечивает изоляцию VLAN.
- Поддерживает до 4094 VLAN (стандарт 802.1Q).

### Структура пакетов

1. Untagged Packet:
- Стандартный кадр Ethernet II.
- Не содержит информации о VLAN.
- Размер кадра: 64–1518 байт.
- Используется конечными устройствами (компьютеры, телефоны и т.д.).

2. Tagged Packet (802.1Q):
- Содержит 4-байтовый тег VLAN (общий размер кадра: 60–1522 байт).
- Включает:
- TPID (0x8100): идентификатор тега.
- PCP (Priority Code Point): приоритет (0–7).
- VLAN ID (1–4094): идентификатор VLAN.
- Ethernet Original Type: тип Ethernet.

### Пример сетевой диаграммы

На диаграмме показаны два коммутатора (Switch A и Switch B), соединённые через Trunk Port. Trunk Port передаёт маркированный трафик (Tagged Traffic) между несколькими VLAN (VLAN 1, VLAN 2, VLAN 3). Конечные устройства подключены через Access Ports и используют немаркированные пакеты.

Типы портов VLAN
(диаграмма к предыдущему посту)

Закон Конвея и архитектура программного обеспечения

Архитектура программного обеспечения часто отражает структуру вашей организации.

Вы слышали о законе Конвея (𝗖𝗼𝗻𝘄𝗮𝘆'𝘀 𝗟𝗮𝘄)? Это теория, созданная компьютерным учёным Мелвином Конвеем (Melvin Conway) в 1967 году, которая гласит: «Организации, которые разрабатывают системы, склонны продуцировать проекты, которые отражают коммуникационные структуры этих организаций»
(в оригинале: "𝘖𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯𝘴, 𝘸𝘩𝘰 𝘥𝘦𝘴𝘪𝘨𝘯 𝘴𝘺𝘴𝘵𝘦𝘮𝘴, 𝘢𝘳𝘦 𝘤𝘰𝘯𝘴𝘵𝘳𝘢𝘪𝘯𝘦𝘥 𝘵𝘰 𝘱𝘳𝘰𝘥𝘶𝘤𝘦 𝘥𝘦𝘴𝘪𝘨𝘯𝘴 𝘸𝘩𝘪𝘤𝘩 𝘢𝘳𝘦 𝘤𝘰𝘱𝘪𝘦𝘴 𝘰𝘧 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘶𝘯𝘪𝘤𝘢𝘵𝘪𝘰𝘯 𝘴𝘵𝘳𝘶𝘤𝘵𝘶𝘳𝘦𝘴 𝘰𝘧 𝘵𝘩𝘦𝘴𝘦 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯𝘴.").

Проще говоря, структура программной системы часто находится под влиянием структуры и паттернов коммуникации внутри команды, создающей её.

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

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

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

Чтобы смягчить это влияние, можно использовать манёвр «Обратная Конвея» (𝗜𝗻𝘃𝗲𝗿𝘀𝗲 𝗖𝗼𝗻𝘄𝗮𝘆 𝗺𝗮𝗻𝗲𝘂𝘃𝗲𝗿). Этот метод включает привлечение архитекторов программного обеспечения, инженеров и руководителей к определению организационных структур. Это может привести к созданию более качественного программного обеспечения.

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

Добавил канал сайта в менеджере Max. Канал доступен по адресу:
https://max.ru/metanit
https://web.max.ru/metanit (веб-версия)

Основные концепции работы с ACL (Access Control Lists) в Linux

1. ACL как расширение стандартных прав доступа:
- ACL позволяет добавлять права доступа для конкретных пользователей и групп, что расширяет стандартные права (владелец, группа, остальные).
- Пример: создание каталога и проверка его прав с помощью команд ls -ld dir и getfacl dir.

2. Добавление прав доступа для пользователей и групп:
- Используется команда setfacl для назначения прав. Например, setfacl -m u:jay:r dir добавляет права чтения для пользователя jay.

3. Роль маски (mask):
- Маска определяет максимальные права, которые могут быть назначены пользователям и группам через ACL.
- Она автоматически обновляется при изменении прав с помощью chmod или setfacl.
- Пример: удаление прав группы с помощью chmod g-r dir и влияние этого на ACL.
#linux

Кэшировать или не кэшировать?

Это один из самых частых вопросов, которым задаются backend-разработчики.
Под «кэшированием» здесь понимается временное хранение данных в быстродоступной памяти для ускорения работы приложения.

Большинство инженеров кэшируют слишком много данных.
Это признак ленивого подхода к разработке.

Вот система критериев, которая поможет принять правильное решение:

1. Часто ли обращаются к этим данным?
2. Дорого ли их получать?
3. Изменчивы ли они?
4. Объёмны ли они?
5. Влияют ли они на воспринимаемую пользователем задержку?
6. Безопасно ли их кэшировать?
7. Есть ли способ их обновить или аннулировать?

Схема на картинке позволяет принять решение по поводу кэширования

Хук useEffect из React при неаккуратном обращении убивает

Cloudflare совершила DDoS-атаку на саму себя, используя хук useEffect из React
Cloudflare призналась в ошибке кода, связанной с использованием хука useEffect из React, который известен своей сложностью при неаккуратном обращении. Эта ошибка привела к сбою панели управления платформы и многих её API.

Сбой произошёл 12 сентября, длился более часа и был вызван ошибкой в ​​панели управления, которая, по словам вице-президента по разработке Тома Лианзы, привела к «повторным ненужным вызовам Tenant Service API». Этот API является частью логики авторизации запросов API и, следовательно, повлиял на другие API.

Причину было сложно устранить, поскольку очевидная проблема была связана с доступностью API, скрывая тот факт, что именно панель управления перегружала её.

Lianza сообщила, что основная проблема заключалась в хуке React useEffect с «проблемным объектом в массиве зависимостей». Хук useEffect — это функция с параметрами, включая функцию настройки, возвращающую функцию очистки, и необязательный список зависимостей. Функция настройки запускается каждый раз при изменении зависимости.

В данном случае с Cloudflare функция вызывала API Tenant Service, и одной из зависимостей был объект, который «пересоздавался при каждом изменении состояния или свойства». В результате хук срабатывал многократно во время одного рендеринга панели управления, хотя должен был запускаться только один раз. Функция запускалась так часто, что API перегружался, что и приводило к сбою.

Этот инцидент вызвал в сообществе обсуждение плюсов и минусов useEffect и целесообразности его использования.

https://www.theregister.com/2025/09/18/cloudflare_ddosed_itself/?td=rt-3a

Из заметки Andrew Ng, известного специалиста в области ИИ, про необходимость тестирования кода, произведенного ИИ:
"

ИИ-агенты для коддинга действительно могут ошибаться! Мы активно их используем и сталкивались со следующими проблемами:

* Множество ошибок, введённых ИИ-агентами, включая тонкие инфраструктурные баги, на поиск которых у людей уходили недели.
* Уязвимость в системе безопасности, которая появилась в нашей производственной системе, когда ИИ-агент упростил сброс паролей для упрощения разработки.
* Взлом системы вознаграждений, когда ИИ-агентмодифицировал тестовый код, чтобы упростить прохождение тестов.
* ИИ-агент выполнил команду «rm *.py» в рабочем каталоге, что привело к удалению всего кода проекта (к счастью, он был сохранён на GitHub).

В последнем случае, когда ИИ-агента спросили о случившемся, он извинился и согласился, что «это была невероятно глупая ошибка». Нам стало легче, но ущерб уже был нанесён!

"
https://www.deeplearning.ai/the-batch/issue-319/

Практикум по Docker: обновление контейнерного приложения без потери данных 🐳

Контейнеры по умолчанию получают относительно устойчивую файловую систему — изменения, внесённые приложением, сохраняются после перезапуска контейнера, вызванного сбоями приложения, перезагрузкой хоста и т. д. Однако иногда может потребоваться использовать тома, чтобы сделать одни части файловой системы контейнера более надёжными, чем другие. Благодаря томам, даже если вы полностью удалите контейнер (вместо его простого перезапуска), вы сможете продолжить использовать данные приложения в его преемнике (например, в том же приложении, но с более новым образом).

#docker

Сравнение HTTP/2 и HTTP/3
(продолжение в следующем посте)

Сравнение HTTP/2 и HTTP/3
(продолжение предыдущего поста)

В чем же разница между протоколами HTTP/2 и HTTP/3? Начнем с основ:

* 1996 → HTTP 1
* 1997 → HTTP 1.1
* 2015 → HTTP 2
* 2022 → HTTP 3

HTTP 1.1:
✓ Персистентные соединения — повторное использование соединений вместо открытия новых.
✓ Частичная передача — отправка данных частями вместо ожидания полного ответа.
✓ Улучшенный кеш — добавлены заголовки для лучшего управления кешем и соединениями.
🅇 Последовательные запросы — запросы блокируют друг друга (блокировка в очереди на уровне запросов).
🅇 Множественные соединения — браузеры использовали несколько TCP-соединений для ускорения.

Он ввел основные функции, которые используются до сих пор.

HTTP 2:
✓ Мультиплексирование — несколько запросов в одном TCP-соединении.
✓ Сжатие заголовков (HPACK) — уменьшение размера метаданных.
✓ Приоритет потоков — обеспечение загрузки критических ресурсов в первую очередь.
🅇 Блокировка в очереди (HoL) — потеря пакета блокирует все потоки.

Хотя HTTP 2 оптимизировал TCP, он оставался ограниченным из-за блокировки в очереди TCP.

HTTP 3:
✓ Построено на QUIC (UDP) — больше нет узких мест TCP.
✓ Независимые потоки — потеря пакета в одном потоке не влияет на другие.
✓ Быстрые рукопожатия — объединение настройки транспорта и шифрования в один шаг.
✓ Мандатное шифрование (TLS 1.3) — безопасность по умолчанию.
✓ Миграция соединений — бесперебойная работа при изменении сети.

Итог: HTTP 2 оптимизировал TCP, но HTTP 3 внедряет QUIC, делая соединение быстрее, надежнее и зашифрованным по умолчанию.

Покрывающие индексы (Covering indexes)
(продолжение предыдущего поста)

Покрывающие индексы — это индексы, которые при грамотном использовании способны значительно повысить производительность системы.

Покрывающий индекс — это такой индекс, который используется для получения всех столбцов результата запроса без необходимости обращения к основному хранилищу данных таблицы. Для Postgres это означает обход файла куч таблицы, а для MySQL — обход кластеризованного индекса данных таблицы.

Рассмотрим пример запроса:

SELECT name, email
FROM user
WHERE name > 'C' AND name < 'G';

Если у нас есть индекс только по имени, например:

CREATE INDEX idx_name
ON your_table (name);

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

В качестве альтернативы можно использовать составной индекс:

CREATE INDEX idx_name_email 
ON your_table (name, email);

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

В руководство по языку Java добавлены новые статьи:

Файлы JAR, их создание и выполнение
http://metanit.com/java/tutorial/13.1.php

Создание и подключение библиотеки JAR
http://metanit.com/java/tutorial/13.2.php

Установка пути к классам Java
http://metanit.com/java/tutorial/13.3.php

#java

Как говорит встроенный калькулятор на MacOS: память есть? А если найду?

Игра для извращенцев)
Исходный код: https://gist.github.com/NSG650/74143df2a3eaea089e68cea8f551ba1d

Практические советы по использованию индексов в базе данных
(описание в следующем посте)

Практические советы по использованию индексов в базе данных
(продолжение предыдущего поста)

Индексируйте столбцы в WHERE
* Если столбец используется в WHERE, он должен быть проиндексирован.
* Начинайте с высокоселективных столбцов (например, user_id, email, status).

Покрывайте запрос
* Используйте покрывающие индексы, включающие все столбцы, используемые в запросе.
* Это позволяет избежать возврата к таблице (ускоряет чтение).

Индексируйте соединения и внешние ключи
* Если по столбцу выполняется в JOIN, индексируйте его.
* Отсутствие индекса на внешних ключах = медленные соединения, гарантировано.

Используйте частичные индексы (Postgres) или фильтрованные индексы (SQL Server)
* Индексируйте только те строки, которые имеют значение.
* Пример: индексируйте только активных пользователей.

Удаляйте неиспользуемые индексы
* Индексы замедляют запись.
* Используйте pg_stat_user_indexes, sys.dm_db_index_usage_stats или эквивалент для удаления лишнего.

Используйте составные индексы (правильно)
* Порядок имеет значение: индекс (user_id, created_at) ≠ (created_at, user_id).
* Подбирайте индекс под фильтры и сортировки запросов.

Избегайте низкоселективных индексов
* Не индексируйте булевы значения или столбцы с малым количеством уникальных значений.
* Они не фильтруют данные, а только занимают место.

Следите за функциями в WHERE
* WHERE YEAR(created_at) = 2024 = полное сканирование таблицы.
* Вместо этого: created_at BETWEEN '2024-01-01' AND '2024-12-31'.

Измеряйте, а не угадывайте
* Используйте EXPLAIN, ANALYZE или планы запросов, чтобы увидеть, что происходит.
* Не доверяйте интуиции; доверяйте плану выполнения.

Тестируйте до и после
* Измеряйте время выполнения запросов до и после изменений индексов.
* Если улучшение менее 80%, пересмотрите дизайн.