Зачем веб-приложению .net необходимо проверять, имеет ли открытый ключ имени ВЫЗЫВАЮЩЕЙ сборки такую ​​же длину, что и ВЫПОЛНЯЮЩАЯСЯ сборка?

Унаследованное мною старое веб-приложение .NET изобилует странной «проверкой безопасности сборки»: оно проверяет, что открытый ключ имени вызывающей сборки имеет ту же длину, что и открытый ключ имени выполняющейся сборки.

Звонки выглядят так:

CheckAssembly(System.Reflection.Assembly.GetCallingAssembly(), System.Reflection.Assembly.GetExecutingAssembly(), this);

... и этот метод:

public static void CheckAssembly(Assembly callingAssembly, Assembly executingAssembly, object useObject)
    {
        byte[] assemblyPublicKey = executingAssembly.GetName().GetPublicKey();
        byte[] callingPublicKey = callingAssembly.GetName().GetPublicKey();
        if (callingPublicKey == null || assemblyPublicKey.Length != callingPublicKey.Length)
        {
            throw new SecurityException("The calling assembly does not have permission to use objects of type '" + useObject.GetType().FullName + "'");
        }
        for (int i = 0; i < assemblyPublicKey.Length; i++)
        {
            if (assemblyPublicKey[i] != callingPublicKey[i])
            {
                throw new SecurityException("The calling assembly does not have permission to use objects of type '" + useObject.GetType().FullName + "'");
            }
        }
    }
  1. Я думаю, он проверяет, не были ли сборки (файлы DLL) заменены или изменены или что-то еще. Это правильно? Если нет, то что делает этот код? Есть догадки, зачем это было написано?

  2. Я думал, что фреймворк .net все равно сделает это, если понадобится. Правильно?

  3. Может быть, это старый код, когда приложение было приложением winforms, а не веб-приложением? Поскольку это веб-приложение, мы полностью контролируем, какие библиотеки DLL находятся на сервере, поэтому никакой угрозы безопасности, верно?

(При необходимости могу предоставить дополнительную информацию).


person MGOwen    schedule 30.07.2013    source источник
comment
Лучшее место для этого кода - thedailywtf.com   -  person Hans Passant    schedule 30.07.2013
comment
Спасибо @HansPassant, так что мои предположения о том, что это совершенно бесполезно, верны?   -  person MGOwen    schedule 31.07.2013
comment
Я собираюсь предположить, что первая проверка должна, возможно, избежать выполнения второй проверки (более интенсивной, я думаю, или что-то в этом роде). Не знаю, как часто они бывали разной длины.   -  person Mike Cheel    schedule 31.07.2013


Ответы (1)


Ваши три предположения, вероятно, верны, хотя у № 2 есть немного странная история, которая может быть здесь уместна. Существует разрешение .NET Framework CAS, StrongNameIdentityPermission, который можно было использовать для проверки подобных вещей еще во времена .NET 1.x. Однако в .NET 2.0 полностью доверенный код начал проходить все проверки разрешений идентификации, в том числе для StrongNameIdentityPermission (http://blogs.msdn.com/b/eugene_bobukh/archive/2005/05/06/415217.aspx).

До этого изменения поведения запрос ссылки на StrongNameIdentityPermission был одним из механизмов, который люди использовали для создания полуоткрытых API. Основным недостатком этого было то, что «защищаемые» типы и члены имели общедоступную видимость, а проверка происходила только во время выполнения. Это означало, что благонамеренный пользователь библиотеки, содержащей такой код, не будет иметь никакого способа узнать, что он нарушает предполагаемые правила использования, до фактического выполнения своего кода, что довольно раздражало. Начиная с .NET 2.0, предпочтительным механизмом для создания полуобщественного API является использование InternalsVisibleToAttribute для объявления "дружественных сборок ".

person Nicole Calinoiu    schedule 01.08.2013