User
По встроенным механизмам безопасности ASP .NET Core написано мало статей. Даже официальная документация имеет пробелы. В этой статье мы пройдём по всем основным компонентам, имеющим отношение к безопасности, и разберём, как это работает внутри.
Если вы используете старый добрый ASP .NET, то для вас будет полезна информация по внутреннему устройству компонентов безопасности и лучшим практикам их использования. Здесь вы найдёте ответы на следующие вопросы: как реализованы современные анти-XSS механизмы и как их правильно использовать в ASP .NET Core? Как правильно работать с cookies и какие подводные камни там могут встретиться? Как был переписан механизм защиты от CSRF? Как правильно работать с криптографическими алгоритмами? Кроме того, рассказывается про опыт участия в Bug Bounty по поиску уязвимостей в ASP .NET Core.
Перед чтением рекомендуется освежить в памяти атаки из списка OWASP Top 10.
Прототипом статьи является доклад Михаила Щербакова на конференции DotNext 2017 Moscow. Михаил — Microsoft .NET MVP, участник .NET Core Bug Bounty Program, соорганизатор сообщества .NET программистов (Московское комьюнити называется MskDotNet, питерское — SpbDotNet). По работе последние 5 лет занимается безопасностью. Работал в Positive Technologies, в Cezurity, сейчас как консультант работает напрямую с заказчиками, по большей части в этой же сфере. Профессиональные интересы: статический и динамический анализ кода, информационная безопасность, автоматизация отладки кода, исследование внутреннего устройства .NET CLR.
В этом тексте огромное количество картинок со слайдов. Осторожно, трафик!
В сети можно встретить много советов по эффективной работе в консоли. В большинстве таких статей авторы рассказывают про банальности типа "выучите горячие клавиши" или "sudo !! запустит последнюю команду под sudo". Я же расскажу о том, что делать, когда вы уже выучили горячие клавиши и знаете про sudo !!.
Захотелось как-то мне, чтобы сообщения одного из чатов телеграма сохранялись у меня на диске (не запуская обычного клиента). Не буду раскрывать своих побудительных мотивов, но возможность эта показалась мне нужной и полезной.
Для этого в телеграме есть боты. На Хабре есть несколько статей, посвященных ботам, например: "Чат-помощник на сайт".
Бот позволяет читать и посылать сообщения, для регистрации бота не нужен телефон и количество ботов может быть любым. Но название бота включает в себя слово "bot", что может вызвать у хозяина чата ненужные вопросы.
Но, как говорится, правильно поставленный вопрос — половина ответа.
Нет времени и желания изучать километровые файлы WiX, чтобы собрать MSI инсталлер для своего проекта, погружаясь при этом в бездны MSDN? Хотите собирать инсталлер, описывая его простыми и понятными терминами, в несколько строк? Есть клиническая склонность к кроссплатформенности и сборкам под Linux & Docker? Ну тогда вам под кат!
Задайте себе вопрос — как правильно хранить пароль от базы данных, которая используется вашим сервисом? В отдельном репозитории с секретами? В репозитории приложения? В системе деплоя (Jenkins, Teamcity, etc)? В системе управления конфигурациями? Только на личном компьютере? Только на серверах, на которых работает ваш сервис? В некоем хранилище секретов?
Зачем об этом думать? Чтобы минимизировать риски безопасности вашей инфраструктуры.
Начнём исследование вопроса с определения требований к хранению секретов.
ХАБРО-WARNING !!! Уважаемые хабровчане, это не развлекательный пост.
Спрятанные под катом 40+ страниц материалов призваны помочь в работе или учебе людям, специализирующимся на банковском деле или обеспечении информационной безопасности. Данные материалы являются конечным продуктом исследования и написаны в сухом официальном тоне. По сути это заготовки для внутренних документов по ИБ.
Ну и традиционное — «применение сведений из статьи в противоправных целях преследуется по закону». Продуктивного чтения!
Ну что ж, вот и настала пора подружить Windows-обновления с миром Open Source. В этой статье разнообразим быт интеграцией Ansible со всеми возможными источниками обновлений Windows-машин. Хотя возможности системы значительно шире простой раскатки обновлений на серверы и рабочие станции, но ведь надо с чего-то начинать.
Заодно избавимся от досадных неудобств WSUS, если вы предпочитаете «старую школу».
Буфер обмена и PowerShell ускорят, но не ослепят.
Использовать GPP для добавления файлов реестра жутко и неудобно — все эти ветки реестра, тип ключа, значения… Особенно если веток и значений изрядно. Но есть пара лайфхаков, которые могут значительно ускорить работу с групповыми политиками.
Можно, конечно, повесить logon-скрипт с командой импорта ветки реестра. Но это же не наш метод.