Существует много дискуссий о сегодняшнем исправлении для ASP.NET для предотвращения атаки, которая может быть использована для получения ключей шифрования из приложения. В одном обсуждении я прочитал, что его также можно использовать для того, чтобы обработчик WebResource.axd возвращал любой файл в приложении, подделывая параметры запроса так, чтобы они указывали на известное местоположение файла (где /web.config был бы наиболее очевидным выбором).
Это правда?
нет, но есть ScriptResource.axd, об этом написано в блоге здесь: http://eglasius.blogspot.com/2010/09/aspnet-padding-oracle-how-it-relates-to.html. Я рекомендую прочитать его, так как там было много информации, которая не вникала в то, что и когда было раскрыто / или было неточным. Я также добавил дополнительную информацию в комментарии:
Используя рефлектор, это прямо здесь: ScriptResourceHandler.ProcessRequestInternal.
Обратите внимание, как он получает VirtualFileReader. Расшифрованный параметр d начинается либо с q, либо с r.
Значения берутся из параметра, разделенного символом |, и их должно быть кратно 2. Он обрабатывает их парами, где первым кажется сборка.
Он проходит через этот путь кода, когда вы не указываете сборку. Второе значение в паре имеет список, разделенный запятыми.
Я остановился на коде, но запрос от сборки наверное такой: qsomeAssembly|resource а запрос файла q|somefile
Прямо перед публикацией патча ms один из исследователей ответил мне на вопрос в твиттере, который подтверждает, что они получили ключи шифрования, только получив доступ к ключам в файле web.config.
Перед этим они взломали часть шифрования/дешифрования, но это не позволило им взломать что-либо, что было подписано, пока не получили ключи в web.config (по умолчанию там в DotNetNuke).
Дополнительное подтверждение этого в связанном сообщении в блоге в этом ответе: как была исправлена атака-заполнения оракула в сети ASP. Патч ограничивает ScriptResourceHandler только обслуживанием js / может быть отключен при необходимости. Кроме того, обратите внимание, что этого не было до .net 3.5 SP1, что является еще одним подтверждением, поскольку в информации об исправлении, опубликованной ms, явно упоминается, что раскрытие файла произошло только после этой версии и выше.
