2013-07-30 6 views
1

내가 상속 한 이전 .NET 웹 앱은 이상한 "어셈블리 보안 검사"에 흩어져 있습니다. 어셈블리의 이름 인 공개 키가 어셈블리를 호출 할 때 의 공개 키와 길이가 같은지 확인합니다 어셈블리를 실행 중입니다.왜 .net 웹 응용 프로그램은 호출 어셈블리 이름의 공개 키가 EXECUTING 어셈블리와 동일한 길이인지 확인해야합니까?

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을 완벽하게 제어 할 수 있으므로 보안 위험이 없습니다. 맞습니까?

(필요한 경우 추가 정보를 제공 할 수 있음).

+2

이 코드에 가장 적합한 곳은 thedailywtf.com입니다. –

+0

감사합니다. @HansPassant, 그래서 전적으로 쓸모 없다는 가정은 맞습니까? – MGOwen

+0

메신저는 첫 번째 수표가 아마도 두 번째 수표 (더 집약적 인 것 같아요)를하지 않을 것이라고 추측합니다. 나는 그들이 얼마나 다른 길이가 될지 모릅니다. –

답변

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)을 포함하여 모든 ID 확인 검사를 통과하기 시작했습니다.

이 동작이 변경되기 전에 StrongNameIdentityPermission에 대한 링크 요구는 공개 공개 API를 만드는 데 사용되는 메커니즘 중 하나였습니다. 이에 대한 주요 단점은 "보호 된"유형 및 멤버가 공용 가시성을 가지며 검증은 런타임에만 발생한다는 것입니다. 즉, 그러한 코드를 포함하는 라이브러리의 의미있는 사용자는 실제로 코드를 실행할 때까지 의도 한 사용 규칙을 위반했다는 것을 알 수있는 방법이 없었습니다. 이는 꽤 짜증났습니다. .NET 2.0 이후로, semi-public API를 만드는 데 선호되는 메커니즘은 InternalsVisibleToAttribute을 사용하여 "friend assemblies"을 선언하는 것입니다.