Потенциальная уязвимость в ASP.NEt приложении из-за неправильного управления ключами шифрования

Пока ничего не поломал ещё. Но в поисках... :) В поисках, прежде всего, в уже написанных нами приложениях.

Поднял для себя ещё одну уязвимость, которую можно сделать в ASP.NET приложении. Ошибку такую в уже существующих приложениях мы делали, но до дыры это не доводило. А может и доводило...
Собственно, хватит предыстории, пора и к делу.

Проблема связана с шифорованием, вернее, с использованием ключей для шифрования. Ещё вернее, с использованием одних и тех же ключей для шифрования разной информации. Помню, несколько моих ответов на вопрос, где положить ключики для шифрования, "да давай мэшин кэйем - такой чёрта-с-два угадаешь и достанешь:)". Причём не важна была задача, для которой шифруется. А между прочем, этот же ключик ASP.NET используется для шифрования auth и role "печенюшек".

В чём собственно дыра. К примеру, пользователь расскрыл для себя возможность получать с сайта шифрованный текст на его любые вводимые данные (к примеру, генерация шифрованного урл параметра по паролю пользователя для его последующего сброса (в открытом же виде не гоже пароли слать ;))). и более того, это функционал использует machinekey для шифрование и дешифрования. дальше дело техники. аuth кук содержит только имя пользователя - пароля нет в шифрованной печенюшке. пользователь составляет в текстовом виде как выглядит незашированный текст FormsAuthenticationCookie (можно рефлектором поднять место перед шифрацией (byte[] FormsAuthentication.MakeTicketIntoBinaryBlob(FormsAuthenticationTicket ticket)) для пользователя скажем admin или karlito (ты ведь помнишь, что пароль не нужен) и посылает этот текст на шифрацию. Класс, сервер возвращает нам шифрованный текст (читай аутекатионный кук). Теперь, точно дело техники. как послать запрос с определённым куком - это, надеюсь, ты знаешь. Кста, role-кук это отдельный кук содержащий только имя пользователя и роли. , но тоже пользуется мэшин кэйем для шифрования. Короче, поняли.

Посыл простой:
1) Внимательнее с использованием одних и тех же ключей для разной функциональности
2) Стараться не давать пользователю функциональности, получить по тексту его шифрованный эквивалент. Если по спеке так надо, тогда добавляй какой нить RandomId поле в шифрованный контент.
3) Осторожней с печенюшками, особенно с такими критическими как аутеканционными

Что такая уязвимость существует - это минус, что мы о ней знаем - это плюс.

Ссылочная информация:
http://www.cacr.math.uwaterloo.ca/hac/about/chap13.pdf
http://blogs.msdn.com/ace_team/archive/2008/11/29/vulnerabilities-in-web-applications-due-to-improper-use-of-crypto-part-2.aspx

ЙА - karlito