Potential threats brought by reflection-Discussion

In the previous article Article (Potential threats brought by reflection) I mentioned the consequences of access to private member through reflection. Here I will discuss how to deal with this problem!

Method 1: No doubt, that is, try not to put confidential informationCodePublish. This is also the most reliable method. However, in many cases, we cannot do this. In this case, we have to continue to seek other solutions ......

Method 2: Set strongnameidentitypermissionattribute (thanks to the articles provided by hbifts) to limit the scope of callers, as shown below:

[Strongnameidentitypermissionattribute (securityaction. Demand, publickey = "002400000...")]
Private Static string decrypt (byte [] D)
{
}

In this case, the runtime will throw a securityexception. Unfortunately, the caller can use the following statement to disable the security check before calling:

Securitymanager. securityenabled = false;

In this way, our security settings are still useless. Based on the principle of this method-checking the identity of the called user, I thought of the following method:

Method 3. there is a stacktrace stuff under the diagnostics namespace (I recently used it to write a helper class that records stack details when writing logs. I will post this stuff in two days-Haha, I made an advertisement !), With it, we can get the Caller information, and then ...... Well, let's just talk nonsense. You can see the code:

Private Static string decrypt (byte [] D)
{
Checkcaller ("seclib, version = 1.0.1713.28332, culture = neutral, publickeytoken = NULL ");
...
}

Private Static void checkcaller (string fullname)
{
Stacktrace ST = new stacktrace (2, false );
Stackframe Sf = ST. getframe (0 );
Methodbase MB = SF. getmethod ();

If (mb. declaringtype. Assembly. fullname! = Fullname)
Throw new exception ("invalid caller! ");
}

In this way, we force a caller identity check, which is obviously not affected by system security settings. Here I use assembly. fullname to determine whether the caller is legal. Of course, you can use other logic, such as determining whether the caller is using reflection.

In conclusion, method 1 is undoubtedly the most reliable, so follow it as much as possible. Method 2 does not provide protection. The preceding figure only shows that the idea of method 3 comes from the former. Method three has basically achieved our goal, but there are many limitations, such as: others can still see our code through reflection (you can use obfuscators before release, of course, however, protection of code is not a concern of this article); or use various means to skip our checks ...... There is no way. Since you want to walk on the street, you cannot avoid being photographed :)

Download the complete code for this example: reflectiontrap1.zip