Comments 25

Признаюсь, первый минус статье поставил я, из-за:


Используйте регулярные выражения как на стороне клиента, так и на стороне сервера.

Пожалуйста, никогда, нет — НИКОГДА, нет даже не так: НИКОГДА не используйте регулярные выражения для проверки на XSS. Вот простой пример как хорошие намерения превращаются в уязвимость:


const killXss = (string) => string.replace(/<script>.*<\/script>/, ‘’);
const text = '<script<script>hello world</script> >HEHE</script’;
const result = killXss(text); // '<script >HEHE</script >'

Оставьте это профессионалам, даже они не всегда справляются (вспоминая SQL Injection которая проскочила WAF и пробила Steam)


П.С. А да, шифрование на клиенте симметричными алгоритмами это тоже прекрасно. Ключ где клиент возьмет?

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

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

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

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

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

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


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

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

как-то так


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

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

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

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

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

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

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


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


Ну наверное, на всякий stack overflow exception, наверное с помощью fazzing тестирования, наверное… А может и нет, потому что я не знаю, и вы не знаете и Саша с третьего подъезда тоже не знает (хотя в твиттере пишет что знает). В этом то и проблема :)

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

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

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

Не удержался:



Эта красота работала только в огнелисе и только в нескольких версиях. Как с таким бороться я не знаю.

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

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

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

Я имел ввиду, что, например, в оригинальном Json чистые данные, тип значения не передается, чтобы десериализовать из него в какой-то объект нам надо указать тип этого объекта, например дженериком:
JsonConvert.DeserializeObject<Какой-то_тип>(строка откуда сериализуем)
И если у нас «Какой-то_тип» это DTO без логики, чистые данные, то ничего страшного злоумышленник подсунуть нам не сможет.
А по ссылке в примерах в JSON передаются типы данных вместе со значениями, вот-такого бы я старался избегать всеми силами, хотя это не всегда удобно.
С чего Вы вообще взяли, что в статье речь про санитизацию?
Регулярки — неплохой способ проверять входные данные. В свою очередь, валидация — один из основополагающих механизмов веб-безопасности, т.к. при правильном применении помогает уменьшить attack surface и является превентивной мерой для целых классов атак. Если в приложении на текстбокс имя-фамилия валидация [a-zA-Z0-9,_]{,20}, то шанс пропихнуть через него хранимую XSS стремится к нулю, даже если где-то на выводе забыли про экранирование.
В том же OWASP ESAPI вся валидация сделана на регулярках, а его разработчики явно понимают в этом вашем аппсеке.

Все так. Только вместо раздела валидации, где регулярки вполне применимы, автор пишет о них в разделе про XSS — это раз. Об использование белых списков (как в вашем примере) ни слова — это два. И рядовой дев не имеет такую квалификацию как разработчики в OWASP, это три.

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

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

Разные задачи, разные инструменты, разные подходы.

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

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

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


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

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


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

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


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

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

Ах, если бы, если бы.



П.С. Это вторая серьезная уязвимость в .NET за последний месяц.
Предыдущая, правда, была еще хуже, — remote-code-execution в .NET Framework и .NET Core.

Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
otus.ru
Employees
51–100 employees
Registered