нет, но 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).
Дополнительное подтверждение этого в сообщении блога в этом ответе: how-was-the-oracle-padding-attack-on-asp-net-fixed .Патч ограничивает ScriptResourceHandler обслуживанием только js / и может быть отключен при необходимости.Кроме того, обратите внимание, что этого не было до .net 3.5 с пакетом обновления 1 (SP1), что является еще одним подтверждением, поскольку в информации об исправлении, опубликованной ms, явно упоминается, что раскрытие файла происходило только после этой версии и выше.