Как я могу предотвратить доступ несанкционированного кода к моей сборке в .NET 2.0? - PullRequest
7 голосов
/ 07 января 2009

В .NET 1.x вы можете использовать StrongNameIdentityPermissionAttribute в вашей сборке, чтобы гарантировать, что только код, подписанный вами, сможет получить доступ к вашей сборке. Согласно документации MSDN,

В .NET Framework версии 2.0 и новее требования к идентификации разрешения неэффективны, если вызывающая сборка имеет полное доверие.

Это означает, что любое приложение с полным доверием может просто обойти мои требования безопасности.

Как предотвратить доступ несанкционированного кода к моей сборке в .NET 2.0?

Ответы [ 3 ]

5 голосов
/ 07 января 2009

Согласно предложению Эрика, я решил это, проверив ключ самостоятельно. В коде, который я хочу защитить, я добавляю следующий вызов,

EnsureAssemblyIsSignedByMyCompany( Assembly.GetCallingAssembly() );

Тогда реализация этого метода будет

  /// <summary>
  /// Ensures that the given assembly is signed by My Company or Microsoft.
  /// </summary>
  /// <param name="assembly"></param>
  private static void EnsureAssemblyIsSignedByMyCompany( Assembly assembly )
  {
     if ( assembly == null )
        throw new ArgumentNullException( "assembly" );

     byte[] pubkey = assembly.GetName().GetPublicKeyToken();
     if ( pubkey.Length == 0 )
        throw new ArgumentException( "No public key token in assembly." );

     StringBuilder builder = new StringBuilder();
     foreach ( byte b in pubkey )
     {
        builder.AppendFormat( "{0:x2}", b );
     }
     string pkString = builder.ToString();
     if ( pkString != "b77a5c561934e089" /* Microsoft */ &&
          pkString != "abababababababab" /* Ivara */ )
     {
        throw new ArgumentException( "Assembly is not signed by My Company or Microsoft. You do not have permission to call this code." );
     }
  }

** Имена и ключи изменены, чтобы защитить невинных. Любое сходство с реальными именами или компаниями - просто совпадение. *

1 голос
/ 07 января 2009

Как указал Джоэл, вам не повезло в отношении CAS. Однако вы можете выполнить проверку самостоятельно любым способом, который нужно защитить, используя Assembly.GetCallingAssembly (), чтобы получить ссылку на сборку, содержащую вызывающий код, а затем вручную проверить строгое имя этой сборки.

1 голос
/ 07 января 2009

См. Эту статью:
http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx

Особенно эта часть:

В последних версиях .NET «полное доверие означает полное доверие». Таким образом, полностью доверяемый код удовлетворяет всем требованиям, в том числе требованиям для таких элементов, как «был подписан этим ключом», независимо от того, был ли он подписан или нет.

Разве это не смертельный недостаток в системе безопасности? Нет. У полностью доверенного кода всегда была возможность сделать это, потому что у полностью доверенного кода есть способность управлять свидетельством, связанным с данной сборкой. Если вы можете контролировать доказательства, тогда вы можете создать сборку, которая выглядит так, как будто она пришла от Microsoft, без проблем. (И если у вас уже есть вредоносный код полного доверия в вашем процессе, значит, вы уже потеряли - ему не нужно олицетворять сборки, подписанные Microsoft; у него уже есть возможность делать все, что может сделать пользователь.)

По-видимому, разработчики .Net чувствовали, что этот атрибут не очень эффективен и для кода полного доверия в .Net 1.x.

...