Полное руководство по повышению безопасности вашего Asp.Net Core веб-приложения и API

[SanSYS]

Не лишено смысла не передавать пароль от браузера в апишку
Как это представляется:
1. либо всегда sha256, но где же соль брать?)

Либо:
1. Браузер по логину получает публичный ключ с апишки
2. Шифрует им пароль
3. Приватным ключиком расшифровывается в беке и хешируется PBKDF2

Как следствие:
1. «Man in the middle» в пролёте
2. случайным образом в логи пароли пользователей не попадут
3. сами ключи для расшифрования можно хранить в бд пользователей, предварительно зашифровав более общим ключиком (от посторонних глаз имеющих доступ к базе)

Посмотрите пример тут mail.protonmail.com/login, уверен там сложнее, чем я описал, но суть +- та же

П.С. А да, сама статья заслуживает минуса, не стоило переводить, кмк

[SanSYS]

:D

[mjr27]

1. либо всегда sha256, но где же соль брать?)

как-то так

salt = randChars(20)
hash = sha256(password + salt) + "." + salt;

[SanSYS]

Этот вариант сработает, если в БД сохраняется пароль пользователя, что не является приемлемым
Так что вариант не является рабочим.

Хотя вы можете развить идею в ту, что я описал выше, и получать соль с сервера… однако тогда от этой соли нет никакого толку и hashcat отлично поможет подобрать пароль

[Politura]

Вот простой пример как хорошие намерения превращаются в уязвимость:

А если так?
const killXss = (string) => string.replace(/</, "& lt;");

По статье заголовок 11 параграфа: «LINQ может защитить от SQL инъекций» но в самом параграфе тема вообще не раскрываецца, какжеж линк может защитить-то? :)
Из всех рекомендаций достаточно оставить одну единственную «Всегда используйте параметризованные запросы.». Пункт про энтити это чисто следствие оной ибо энтити использует параметризованные запросы, проверка перед запуском ничего не гарантирует, а вот параметризованные запросы гарантируют, использование хранимок без использования параметризованных запросов к ним ни от чего не защитит.

Тема про проверки десериализации тоже нифига не раскрыта. Что именно там проверять?
Ну вот есть у меня некий десериализер, у которого есть метод, что из строки получает экземпляр некоего класса, типа:
Deserialize<T>(string data);
оный метод создает новый экземпляр класса T затем ищет в данных поля с именами совпадающими с именами полей этого класса и заполняет его значениями поля созданного экземпляра, все остальное что там есть в данных игнорируется.
вот я его использую, передавая ему свой DTO не имеющий методов, чистые данные:
var x = serializer.Deserialize<AccountDTO>("some string");
и что тут мне страшного может подсунуть злоумышленник? на каком этапе и что именно я должен проверять согласно этому пункту рекомендаций?

[Politura]

А теперь вам нужно пропускать < потому что мы хотим ставить динамические теги…

Но смысл не в этом. Даже если ваш код на 100% защищает от ХSS сейчас, это не гарантирует что это будет работать и потом.

Ну, может быть, я где-то на 95% бакенд, поэтому не особо в курсе что там за подводные камни с этим ХSS.

[beskaravaev]

А что делает эта красота?

[asjp]

Есть уязвимости десериализации, позволяющие выполнять произвольный код (например, при десериализации в объект процесса можно запустить код; видел эту тему сто лет назад, точно не скажу, где, скорее всего на dotnext). Другое дело, что на кой чёрт в системе может понадобиться такая сущность…

[y4ppieflu]

Небезопасная сериализация возникает, когда атакующий имеет контроль над типом объекта, которые десериализуется на сервере. К «небезопасным» маршаллерам относятся BinaryFormatter, JavascriptSerializer с SimpleTypeResovler, Newtonsoft.Json c TypeNameHandling!=None и т.п. Это бывает иногда нужно, в таких случаях рекомендуется добавлять перед десериализацией guard, который проверит тип переданного объекта по белому списку. Это необходимо, т.к. даже если ваше приложение не ожидает объект другого типа и кинет в ходе десерилиализации исключение — подсунутый код все равно выполнится.
В Вашем случае — если тип заранее предопределен и не передается вместе с самим объектом — проблемы нет.
Тык Тык

[Politura]

Это бывает иногда нужно

Ну вот мне и интересен сценарий, когда именно это нужно?
Из первой ссылки:
IRunnable run = (IRunnable)fmt.Deserialize(stm);
Неужели на самом деле у кого-то в подобном есть острая необходимость, или это просто теоретические изыскания? Просто за лет 10-15 использования всяких сериализеров в работе ни разу не возникало необходимости в подобном. Ну и я-бы сторонился десериализеров которые возвращают Object, а не генерик метод создающий и возвращающий именно то, что я ожидаю получить.

[y4ppieflu]

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

Не совсем понял, о чем речь. Любой сериализатор возвращает Object, другое дело, что не всегда есть возможность повлиять на тип этого объекта.
Это не теоретические изыскания. В случае использования нативной бинарной сериализации (там, насколько я знаю, тип всегда передается с объектом) никто просто не задумывается о том, что что-то может пойти не так.
Если речь про JSON/XML — я пару раз сталкивался с ситуацией, когда контроллер должен уметь обрабатывать объекты разных типов, разработчик идет по пути наименьшего сопротивления и включает «polymorphic type handling».
Пара примеров из реальной жизни, например, тут.

[Politura]

Не совсем понял, о чем речь. Любой сериализатор возвращает Object, другое дело, что не всегда есть возможность повлиять на тип этого объекта.

Я имел ввиду, что, например, в оригинальном Json чистые данные, тип значения не передается, чтобы десериализовать из него в какой-то объект нам надо указать тип этого объекта, например дженериком:
JsonConvert.DeserializeObject<Какой-то_тип>(строка откуда сериализуем)
И если у нас «Какой-то_тип» это DTO без логики, чистые данные, то ничего страшного злоумышленник подсунуть нам не сможет.
А по ссылке в примерах в JSON передаются типы данных вместе со значениями, вот-такого бы я старался избегать всеми силами, хотя это не всегда удобно.

[y4ppieflu]

С чего Вы вообще взяли, что в статье речь про санитизацию?
Регулярки — неплохой способ проверять входные данные. В свою очередь, валидация — один из основополагающих механизмов веб-безопасности, т.к. при правильном применении помогает уменьшить attack surface и является превентивной мерой для целых классов атак. Если в приложении на текстбокс имя-фамилия валидация [a-zA-Z0-9,_]{,20}, то шанс пропихнуть через него хранимую XSS стремится к нулю, даже если где-то на выводе забыли про экранирование.
В том же OWASP ESAPI вся валидация сделана на регулярках, а его разработчики явно понимают в этом вашем аппсеке.

[y4ppieflu]

Как будто валидация и XSS никак не связаны. Это Вы сами почему-то решили, что «сохраняйте в базе только проверенные данные» значит, что из пользовательского ввода надо вырезать script. Хотя имеется в виду именно валидация. Остальные два аргумента комментировать не берусь, т.к. вообще не понял к чему они.
Статья в целом плохая, но конкретно этот пункт, к которому у вас появились претензии, вполне имеет право на жизнь.

[UnclShura]

Никогда не понимал требования не показывать исключения (а как пользователь — люто его ненавижу!). Нечего криво совт писать. Я серьёзно. Нечего криво софт писать.

[mjr27]

Временно блокируйте IP после нескольких неудачных попыток входа в систему.

Прекрасный способ выбесить пользователей, не зацепив сеть ботов.

Сделайте ваш пароль сложным для подбора, а именно содержащим в себе буквы(A-Z и a-z), цифры(0-9) и специальные символы(!, @,., #, $,%, ^, &, * и т.д.).

Автор хоть раз пытался набрать такой пароль с телефона?

HTML-шифрование с помощью Razor

Экранирование.

Всегда следите за актуальными версиями ваших фреймворков и библиотек и обновляйте их регулярно.

По умолчанию на последнюю минорную предпоследней мажорной.