Comments
инъекции (SQL, XSS, XML, XXE, XPath, XQuery, Linq и т. п.),

Что такое «Linq-инъекция»?
В Dynamic Linq можно повлиять на построение запроса, если не проводить параметризацию, а собирать из строк типа такого:
dataset.Where("allowed == 1 and code == \"" + user_entered_data + "\"");


Атакующий может передать туда
200" or allowed == 0 and code == "200


В результате это все развернется в
select ... from ... where allowed == 1 and code == "200" or allowed == 0 and code == "200"


Еще вариант — какая-нибудь уязвимость в стороннем LINQ-провайдере, позволяющая инжекцию.
На скриншотах представлены диффы по патчам, сгенерированным автоматически экспериментальной версией Application Inspector (рассказывал об этом на PHDays V: www.slideshare.net/kochetkov.vladimir/ss-48743308). Отсюда и странные имена у добавленных патчами идентификаторов.
У вас в примерах кода используется http (UriComponents.HttpRequestUrl). Это просто безразличный к http/https парсер, или в рассматриваемом куске кода применяются http запросы?
Первое. Но по-хорошему, пробрасываемая пользователем схема протокола также должна жестко контролироваться, чтобы у атакующего не было возможности перенаправить браузер жертвы по незащищенному каналу. Но это уже сильно зависит от семантики конкретного фрагмента кода. У кода из статьи семантика: «пример, демонстрирующий уязвимость к атакам XSS» :)
Интересно про Padding Oracle и нестойкий CBC. Получается, что если мы хотим хранить на клиенте зашифрованные данные, ключ от которых есть только на сервере, то имеет смысл всегда добавлять к ним HMAC?
Сначала стоит подумать об отказе от CBC (и ECB, если вдруг) в пользу более достойных режимов, позволяющих организовать аутентифицированное шифрование (CCM, GCM — предпочтительнее). Если по каким-либо причинам это невозможно, тогда стоит реализовать encrypt-then-autheticate, например добавлением к зашифрованным данным их HMAC, да.
И еще такой вопрос: В Википедии написано, что TLS требует всегда проверять, что при дешифровании padding заполнен правильными данными. Чем опасно отсутствие такой проверки?
TLS требует всегда проверять, что при дешифровании padding заполнен правильными данными

Именно в такой формулировке? Можно ссылку на статью?

Но в целом, если дополнение заполнено некорректными данными, то это значит, что целостность сообщения была нарушена, а т.к. в SSL и ранних версиях TLS использовался подход authenticate-then-encrypt, то в этом случае на этапе дешифровки проконтролировать целостность можно только проверяя корректность дополнения.
Насколько я помню, там речь шла о том, что не все реализации TLS в случае неправильного дополнения отправляли алерт bad_record_mac, что и позволяло атакующему отличить ошибки дополнения от ошибок контроля целостности.
Only those users with full accounts are able to leave comments. Log in, please.