.NET Разработчик

День 2231. #Безопасность
Атрибуты Безопасности Файлов Cookie
Один из самых распространённых способов, которым веб-браузеры используют cookie, — это аутентификация пользователя и сохранение сессии. Злоумышленники могут украсть или подделать cookie для получения доступа к аутентифицированным областям и существующим сессиям пользователя.

Существует 3 распространённых атаки с использованием cookie:
1. Атаки с использованием межсайтового скриптинга (XSS) и атаки типа «человек посередине» (MITM) часто используются для кражи файлов cookie.
2. Атаки с использованием межсайтовой подделки запросов (CSRF) используют способ обработки файлов cookie браузерами для выполнения вредоносных действий от имени аутентифицированных пользователей.

Спецификация протокола HTTP содержит несколько механизмов, которые разработчики могут использовать для снижения риска доступа злоумышленников к содержимому cookie с конфиденциальными данными, их повторного использования или подделки. Ниже перечислены атрибуты заголовка HTTP Set-Cookie, которые можно использовать для повышения безопасности файлов cookie.

1. Expire и Max-Age
Определяют срок действия cookie. Expire устанавливает абсолютную дату/время истечения срока действия (формат: weekday, DD-MM-YYYY hh:mm:ss GMT), а атрибут Max-Age - ограничение по времени с момента установки cookie. Если Expire и Max-Age не установлены, браузер обрабатывает cookie как сеансовый и удаляет его при закрытии браузера. Если установлены, сохраняет cookie как постоянный на стороне клиента и удаляет в соответствии со значениями Expire и Max-Age (в зависимости от того, что наступит раньше).

2. Secure
Указывает, что cookie может передаваться только с использованием HTTPS-соединений и никогда не отправляется в открытом виде. Браузер не будет отправлять Secure cookie с запросами HTTP.
Атрибут Secure предназначен для защиты от атак типа «человек посередине» (MITM). Однако он защищает только конфиденциальность файла cookie, а не его целостность. Злоумышленник не получит cookie с сервера через незашифрованное соединение, но всё равно может отправить поддельный cookie на сервер в виде обычного текста.

3. Domain
Объявляет домен, на который будет отправлен cookie (а также все поддомены). Если атрибут Domain не установлен, cookie будет отправлен только на исходный хост (без поддоменов). Поэтому наиболее безопасный способ — не устанавливать атрибут Domain, если это не необходимо.

4. Path
URL-путь, по которому будет отправлен cookie (включая все подпути). По умолчанию - / (все URL-пути на сервере).

5. HttpOnly
Введён для предотвращения атак XSS. Браузер будет отправлять cookie с этим атрибутом только в ответ на HTTP-запросы, т.е. к ним нельзя будет получить доступ из клиентского кода JavaScript. Однако атрибут HttpOnly не защищает cookie от перезаписи. Браузер может хранить только ограниченное количество файлов cookie для домена. Злоумышленник может использовать атаку переполнения хранилища cookie, тем самым удаляя исходный cookie из памяти браузера и добавляя cookie с тем же именем без атрибута HttpOnly.

6. SameSite
Предписывает веб-браузерам отправлять cookie по-разному в зависимости от того, как посетитель взаимодействует с сайтом, установившим cookie. Используется для защиты от атак CSRF. Может иметь одно из следующих значений:
- SameSite=Strict: cookie отправляется только, если вы в данный момент находитесь на сайте, который установил cookie. Если вы переходите с другого сайта (например, из результатов поиска в Google), такой cookie не отправляется с первым запросом.
- SameSite=Lax: файл куки отправляется с GET-запросами верхнего уровня, но не отправляется для встроенного контента (рисунки, CSS, JS).
- SameSite=None: ограничений нет.
Внимание: если атрибут SameSite не установлен, можно ожидать разного поведения браузеров и разных версий одного браузера.

См. также Cookie и Управление Сессиями

Источник: https://www.invicti.com/learn/cookie-security-flags/

День 2230. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 43. Решая вопрос о качестве ПО, вы выбираете: платить немало сейчас или позже, но ещё больше

Если вы собрали требования, а на следующий день клиент позвонил и попросил кое-что изменить, это легко - достаточно обновить требование. Но если клиент позвонил через полгода, когда уже частично реализован дизайн и написан код – это гораздо дороже. У каждого изменения есть цена. Даже обсуждение возможности добавления функциональности или исправления ошибки, а затем решение не делать этого требуют времени. Стоимость исправления дефекта зависит от того, когда он был допущен в продукте и когда кто-то его исправил. Она тем больше, чем позднее дефект обнаруживается.

Порядок увеличения затрат во многом зависит от того, какой объём работы был выполнен для реализации ошибочного требования и как много теперь необходимо переделать. Исправить быстро найденную ошибку в коде почти ничего не стоит. Но если клиент звонит, чтобы сообщить об ошибке уже после релиза ПО, то её исправление обойдется намного дороже. Есть и другой важный аспект: негативное влияние на пользователей. Чем позднее обнаружится проблема, тем более широкий круг заинтересованных сторон она затронет.

Ранние действия по улучшению качества
1. Предотвращайте дефекты, а не исправляйте их
Деятельность по обеспечению качества в первую очередь направлена на предотвращение дефектов. Усовершенствованные процессы, лучшие технические приёмы, более опытные специалисты и немного больше времени на тщательное выполнение работы помогают предотвратить ошибки и избежать затрат на их исправление.

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

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

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

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

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

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

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.

День 2229. #юмор
Сегодня порекомендую вам прекрасный канал Developer Timeline с пародиями на распространённые случаи из жизни разработчиков. Видео переозвучивают известные фильмы и сериалы. Из понравившихся мне:
- I Am The Documentation
- Pull Request With A Few Minor Changes
- First Day Of Programming
- Git Commit, Git Push and Leave the Building
- Developer Interviews In 2025 Be Like
Не то, чтоб уморительно смешно, но жизненно.

День 2228.
Почему Разработчики Должны Заботиться о Безопасности
Разрабатывает ли кто-нибудь ПО, в котором сбои не имеют последствий? Даже незначительные сбои ПО могут иметь далеко идущие последствия: компании теряют миллионы, а пользователи доверие, и всё из-за сбоев, которые можно было бы предотвратить. Вспомним Crowdstrike. Не должны ли все разработчики думать о безопасности и надёжности, даже при создании приложений, которые кажутся некритичными?

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

1. Всё ПО следует считать высокорискованным
Каждый сбой имеет последствия. Где-то потеря активов или дохода, а где-то от этого могут зависеть жизни. Этот принцип означает признание того, что каждая система взаимодействует с пользователями, данными или процессами способами, сбои в которых могут иметь каскадные эффекты. Готовясь к сбоям, разработчики улучшают коммуникацию, проектируют с оглядкой на надёжность, и в итоге предоставляют системы, которым пользователи могут доверять.

2. Проектирование для неизбежного сбоя
Сбои неизбежны. Каждая система в итоге столкнётся с условием, для которого она явно не была разработана, и то, как она реагирует на это, определяет, вызовет ли сбой серьёзную проблему.
В критически важных системах множественные сбои могут происходить без потери функциональности или данных. Но не нужно заходить так далеко для повседневного ПО.
Например, при активно-пассивном проектировании систем активный компонент обрабатывает запросы, а резервный остаётся бездействующим. Если активный компонент выходит из строя, пассивный берёт на себя управление, сводя к минимуму время простоя. Прокси и балансировщики нагрузки распределяют трафик между несколькими экземплярами, гарантируя, что отказ в одном не сможет вывести из строя всю систему.
Распределённые системы также упрощают изоляцию и восстановление после сбоев, поскольку отдельные сервисы можно перезапускать или изменять, не влияя на другие.
Разработчики также могут вести непрерывный мониторинг для раннего обнаружения проблем. Чем быстрее вы можете обнаружить и диагностировать проблему, тем быстрее вы сможете её исправить.
Тестирование на отказ не менее важно. Такие практики, как хаос-инжиниринг, подразумевающие намеренное внесение сбоев в систему, помогают выявлять слабые места и обеспечивать корректное восстановление.

3. Изучение критически важных для безопасности практик
Отрасли, где безопасность критически важна, вкладывают значительные средства в упреждающую защиту. Защитное программирование является ключевой практикой: надёжная проверка ввода, обработка ошибок и подготовка к крайним случаям. Простая ошибка ввода может привести к сбою сервиса, если её не обработать должным образом. Создание систем с учётом этого гарантирует, что вы всегда будете предвидеть неожиданности.
Нормой должно быть строгое тестирование, а не только модульные тесты. Рассмотрите тестирование с внедрением неисправностей (потерянные пакеты, повреждённые данные или недоступные ресурсы), чтобы наблюдать, как реагирует система.
Постепенная деградация — ещё один принцип, который стоит принять. Если система выходит из строя, она должна это делать безопасным и понятным образом. Система онлайн-платежей может временно отключить обработку кредитных карт, но позволить пользователям сохранять товары в корзине. Сервис потокового видео может снизить качество воспроизведения вместо полной остановки. Пользователи должны иметь возможность продолжать работу с ограниченной функциональностью, а не сталкиваться с полными отключениями.

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

Источник: https://stackoverflow.blog/2025/01/22/why-all-developers-should-adopt-a-safety-critical-mindset/