C# and const?

[Jesper]

Is it possible to secure a reference parameter from modification using c#?

E.I. something like const would do in c++.

I've tried to do it by limiting the object to an interface with only get
functions, but that doesnt stop a malicious user from using reflection to
set it...Like:

---Example--------

public interface IFoo
{
int Param {get; }
}

public class Foo : IFoo
{
private int param;
public int Param
{
get { return param; }
set { param = value; }
}
}
public class UntrustedClass
{
public static void Bar(IFoo foo)
{
// Following line will generate a compile error. (Good)
// foo.Param = 15;
// However, this wont. (Bad). And it will execute correctly. (Really bad).
PropertyInfo[] ps = foo.GetType().GetProperties();
ps[0].SetValue(foo, 15, null);
}
}
---Example End--------

So..What are my options? Can I use attributes to stop reflection? Can I use
other security options? I plan on giving the untrusted code its own
AppDomain anyway, but can it stop reflection?

[Nick Malik [Microsoft]]

Why is this a problem?

No offense, but unless you are protecting a password, you are worrying about
something that is pretty darn close to meaningless.

Sure... it's not secure.

Interfaces are there to encapsulate code, not protect it. Breaking
encapsulation isn't criminal... it's stupid.
Why protect yourself from stupid programmers?

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Jesper" <[e-mail]> wrote in message
news:uF**************@tk2msftngp13.phx.gbl...

Is it possible to secure a reference parameter from modification using c#?

E.I. something like const would do in c++.

I've tried to do it by limiting the object to an interface with only get
functions, but that doesnt stop a malicious user from using reflection to
set it...Like:

---Example--------

public interface IFoo
{
int Param {get; }
}

public class Foo : IFoo
{
private int param;
public int Param
{
get { return param; }
set { param = value; }
}
}
public class UntrustedClass
{
public static void Bar(IFoo foo)
{
// Following line will generate a compile error. (Good)
// foo.Param = 15;
// However, this wont. (Bad). And it will execute correctly. (Really bad).
PropertyInfo[] ps = foo.GetType().GetProperties();
ps[0].SetValue(foo, 15, null);
}
}
---Example End--------

So..What are my options? Can I use attributes to stop reflection? Can I
use other security options? I plan on giving the untrusted code its own
AppDomain anyway, but can it stop reflection?

[Jesper]

"Nick Malik [Microsoft]"

Why is this a problem?

No offense, but unless you are protecting a password, you are worrying
about something that is pretty darn close to meaningless.

Sure... it's not secure.

Interfaces are there to encapsulate code, not protect it. Breaking
encapsulation isn't criminal... it's stupid.
Why protect yourself from stupid programmers?

Im not trying to protect myself from stupid programmers. I'm trying to
protect myself from *malicious* programmers, and in my case, it makes good
sense:

My host application is being written to accept user-created plugins. And I
can't trust those. I require that they support a specified interface, and as
mentioned I'm giving them their own AppDomain to run in. My problem is,
however, that I want to give them read access to alot of data in my host
process. Giving them an interface wrapping of my data was just mentioned
because thats the 'solution' I had seen others give to replace 'const'. I'll
take other solutions.

My last resort is to create a new class which only has read properties, and
copy all my data into this class before each call to the plugin. But for
performance reasons (its alot of data), and maintenance reasons
(syncronizing 2 classes) I 'd prefer if I could avoid it.

[Peter Rilling]

You could try using some security classes to mitigate the problems --
StrongNameIdentityPermission and ReflectionPermission.
"Jesper" <[e-mail]> wrote in message
news:ej**************@TK2MSFTNGP14.phx.gbl...

"Nick Malik [Microsoft]"

Why is this a problem?

No offense, but unless you are protecting a password, you are worrying
about something that is pretty darn close to meaningless.

Sure... it's not secure.

Interfaces are there to encapsulate code, not protect it. Breaking
encapsulation isn't criminal... it's stupid.
Why protect yourself from stupid programmers?

Im not trying to protect myself from stupid programmers. I'm trying to
protect myself from *malicious* programmers, and in my case, it makes good
sense:

My host application is being written to accept user-created plugins. And I
can't trust those. I require that they support a specified interface, and

as mentioned I'm giving them their own AppDomain to run in. My problem is,
however, that I want to give them read access to alot of data in my host
process. Giving them an interface wrapping of my data was just mentioned
because thats the 'solution' I had seen others give to replace 'const'. I'll take other solutions.

My last resort is to create a new class which only has read properties, and copy all my data into this class before each call to the plugin. But for
performance reasons (its alot of data), and maintenance reasons
(syncronizing 2 classes) I 'd prefer if I could avoid it.

[Helge Jensen]

Jesper wrote:

Im not trying to protect myself from stupid programmers. I'm trying to
protect myself from *malicious* programmers, and in my case, it makes good
sense:
But is very hard: The user can just run your program in their own
implementation of the .NET framework, or under a simulator and inspect
and change the data if they really want to.

If you don't worry about the alternative runtime-implementations, you
can use the interface solution you mention.

You can probably prevent the use of reflection by using the appropriate
access specifier: private, or internal on the IFoo implementation.
Although you will have to check yourself, I don't have that much
knowledge on .NET introspection and reflection.

The standard way would probably be to pass a proxy which protect access:

private class ConstFoo: IFoo {
private IFoo real;
public ConstFoo(IFoo real) { this.real = real; }
public int Param {
get { return real.Param; }
}
}
Untrusted.Bar(new ConstFoo(foo));

But you still rely on .NET enforcing access to "real" through reflection
here.

Anyway defending against malicious plugin programmers isn't likely to be
the area of development where you get the most value for your
development-time.
process. Giving them an interface wrapping of my data was just mentioned
because thats the 'solution' I had seen others give to replace 'const'. I'll
take other solutions.
It works moderately fine, probably good for most things.
My last resort is to create a new class which only has read properties, and
copy all my data into this class before each call to the plugin. But for
performance reasons (its alot of data), and maintenance reasons
(syncronizing 2 classes) I 'd prefer if I could avoid it.

1. don't try to defend against maliciousness
2. don't copy, proxy.
3. ???
4. PROFIT!

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Bruno Jouhier [MVP]]

// no need to go through reflection to break it. The following line will
also break it:

((Foo)foo).Param = 15;

If you want to prevent it, you have to restrict the accessibility on Foo
(make it internal or private), or on the set accessor for Param (you need
VS2005 for that because VS2003 won't let you set different accessibility
levels on set and get).

Bruno.

"Jesper" <[e-mail]> wrote in message
news:uF**************@tk2msftngp13.phx.gbl...

Is it possible to secure a reference parameter from modification using c#?

E.I. something like const would do in c++.

I've tried to do it by limiting the object to an interface with only get
functions, but that doesnt stop a malicious user from using reflection to
set it...Like:

---Example--------

public interface IFoo
{
int Param {get; }
}

public class Foo : IFoo
{
private int param;
public int Param
{
get { return param; }
set { param = value; }
}
}
public class UntrustedClass
{
public static void Bar(IFoo foo)
{
// Following line will generate a compile error. (Good)
// foo.Param = 15;
// However, this wont. (Bad). And it will execute correctly. (Really bad).
PropertyInfo[] ps = foo.GetType().GetProperties();
ps[0].SetValue(foo, 15, null);
}
}
---Example End--------

So..What are my options? Can I use attributes to stop reflection? Can I
use other security options? I plan on giving the untrusted code its own
AppDomain anyway, but can it stop reflection?

[Nick Malik [Microsoft]]

Hi Jesper,

"Jesper" <[e-mail]> wrote in message
news:ej**************@TK2MSFTNGP14.phx.gbl...

"Nick Malik [Microsoft]"

Interfaces are there to encapsulate code, not protect it. Breaking
encapsulation isn't criminal... it's stupid.
Why protect yourself from stupid programmers?

Im not trying to protect myself from stupid programmers. I'm trying to
protect myself from *malicious* programmers, and in my case, it makes good
sense:

My host application is being written to accept user-created plugins. And I
can't trust those. I require that they support a specified interface, and
as mentioned I'm giving them their own AppDomain to run in. My problem is,
however, that I want to give them read access to alot of data in my host
process. Giving them an interface wrapping of my data was just mentioned
because thats the 'solution' I had seen others give to replace 'const'.
I'll take other solutions.

Perhaps I just need to understand a little better.

When I approach security concerns, I use a technique called "Threat
Modeling". In this technique, I first identify the things that need
protection, and the I identify the different approaches to "harming" these
things, and then I characterize an attack that will effect that harm. In
other words, it a technique to make programmers think like hackers. :-)

So, let me understand the threat that reflection poses for you.

You have an object that you use for returning and updating a sizable set of
data. You want to share this object with plug-ins written by users. You
said something about synchronization, so I assume you want to allow these
users, in some cases, to update the data... but not all of it. Some of the
data should not be updatable. (I'm guessing here... please correct me).

The threat, if I understand correctly, is that your application has the
ability to modify a great deal of data. You want to share the data but not
the ability to modify it. The threat scenario would then be: malicious
programmer writes plug-in to access your objects, and uses reflection to get
access to data items that you don't want him or her to change, changes those
data items, and your class will react by writing that data back to the
server.

This leads to a few questions. I can see a couple of different designs, but
I don't know which to recommend without further info...

How many of the fields in your data structure do you want the compliant
(non-malicious) user to be able to change?
Is the data structured in a hierarchy of objects, or is this a single object
with many fields?
Does your application have a data access layer that is composed of objects
using non-static methods?

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--