.NET Security Concerns re: Client/Server Systems

[Jeff Stewart]

I'm about to start development on a large client/server system using .NET
for both, barring any security concerns. Namely, I'm still a little vague
on what is exposed to end-users in a .NET assembly. Does the possibility
exist that a client assembly can be examined, using common tools -- say,
included in the .NET SDK -- and information extracted that could be used to
exploit the server? Particularly, how does reflection enter into all of
this? In using .NET's reflective features, what, if anything, do you have
to be on the lookout for to prevent including sensitive information/code as
readable text in an assembly? Are there any common pitfalls for this kind
of scenario?

 

[David Browne]

I'm about to start development on a large client/server system using .NET
for both, barring any security concerns. Namely, I'm still a little vague
on what is exposed to end-users in a .NET assembly. Does the possibility
exist that a client assembly can be examined, using common tools -- say,
included in the .NET SDK -- and information extracted that could be used
to exploit the server?
Yes.

Particularly, how does reflection enter into all of this? In using .NET's
reflective features, what, if anything, do you have to be on the lookout
for to prevent including sensitive information/code as readable text in an
assembly? Are there any common pitfalls for this kind of scenario?

Anything you deploy to the client is available for them to inspect. There
are obfuscators which make it harder, but in general you can't hide
sensitive information in a deployed assembly.

It's really a new mindset from the old Client/Server days. Think of it like
this: Code running on the client's computer belongs to the client. The
client "owns" it. The client can debug it, decompile it and run it in
unintended ways. Only code running on the server belongs to you.

David

 

[Lucas Tam]

Namely, I'm still a little vague
on what is exposed to end-users in a .NET assembly. Does the
possibility exist that a client assembly can be examined, using common
tools -- say, included in the .NET SDK -- and information extracted
that could be used to exploit the server?

..NET assemblies can be easily decompiled back to the original source code.
This is a limitation of compiling to an intermediary language. FYI, Java
can be decompiled just as easily.

To prevent this, you should obfuscate your code before deploying it.
VS.NET 2003 includes a free obfuscater with limited features. Or there are
several obfuscators you can purchase on-line which do a more complete job
of "encrypting" the source code.

 

[Jeff Stewart]

.NET assemblies can be easily decompiled back to the original source code.
This is a limitation of compiling to an intermediary language. FYI, Java
can be decompiled just as easily.

The source code, in this case, is CLR code, right? If so, then in that
respect -all- executables can be decompiled. Can original high-level source
code (VB/VC#/VC++) be decompiled as well?

To prevent this, you should obfuscate your code before deploying it.
VS.NET 2003 includes a free obfuscater with limited features. Or there are
several obfuscators you can purchase on-line which do a more complete job
of "encrypting" the source code.

Is there a reigning opinion on the value of obfuscators in general? Due to
the nature of .NET, can they really do an effective job?

Since it was mentioned that the client/server relationship is a little
different in .NET, well, what does that mean for writing client/server apps
in .NET? Why would anyone write a client in .NET if it's so easily
"hackable"? Is it possible to write a .NET client whose relationship with a
server is -not- predicated on the client having sensitive information, given
that an authentication scheme must exist between the two?

 

[Lucas Tam]

The source code, in this case, is CLR code, right? If so, then in
that respect -all- executables can be decompiled. Can original
high-level source code (VB/VC#/VC++) be decompiled as well?

By source code I literally mean the code you see in VS.NET:

Msgbox("Helloworld")

With some decompilers online, you'll literally get every line of code
you typed - especially if the debug symbols are included with your
distribution. Without the symbols, you'll still get the source code, but
the function names, variables, etc will be autogenerated names (i.e.
var1, var2, function1, function2). Regardless, having readable source
code is worrisome.

Any .NET language can be decompiled to high-level source code due to the
way the .NET compiler works.

Is there a reigning opinion on the value of obfuscators in general?
Due to the nature of .NET, can they really do an effective job?

Obfuscators implement a number of features which makes decompilation
harder. You can check the makers of the obfuscator's website for more
information. They usually list the techniques the obfuscator uses to
hide the original source code.

Since it was mentioned that the client/server relationship is a little
different in .NET, well, what does that mean for writing client/server
apps in .NET? Why would anyone write a client in .NET if it's so
easily "hackable"? Is it possible to write a .NET client whose
relationship with a server is -not- predicated on the client having
sensitive information, given that an authentication scheme must exist
between the two?

Any client can be hacked - .NET or otherwise. The question you pose here
probably applies to all Client/Server environments... you probably want
to build the client as dumb as possible, and place as much business
logic in the server piece as possible - that way even with a compromised
client, unauthorized transactions will still be blocked by the server.

Also, you should send only blocks of data to the client, rather than
dumping the entire database.

There are a lot of strategies you can use to minimize exposure... I
don't have any links to client/server best practises, but perhaps
someone else in this group does.

 

[David Browne]

.. . .

Is it possible to write a .NET client whose relationship with a server
is -not- predicated on the client having sensitive information, given that
an authentication scheme must exist between the two?

Yes. Think about a web application. The client code is 100% open and all
the client data is easilly viewable and changable, but it can still be
secure.

The client and the server communicate using a standard, well understood
network protocol.
The client provides authentication credentials to the server and the server
controls what functions the client can perform and what data the client can
see.

The same principles apply to a Client/Server application in .NET. Your
server can be a webservice, or a Database Server or whatever, but you need
to control authentication and autorization functions at the server.

When desiging your server, pretend that you will publish the spec on how to
connect to the server, and the user will write their own client. If it's
secure for that, then it's secure.

David

 

[Jeff Stewart]

I can understand this approach, but our client has to do a little more work.
This client will not only depend on our server for data, but it will depend
on a vendor's web service for imagery -based- on the data. Our server won't
have the horsepower to act as an imagery proxy -- connecting and making
requests to the vendor service on the client's behalf -- so the client is
responsible for connecting to the imagery service using my company's
credentials, and making the appropriate requests.

What concerns me is the hacker that extracts those vendor service
credentials, and starts racking up unauthorized (or,
ungoverned-by-our-client) bandwidth charges using our account.

 

[Jeff Stewart]

I'm gonna move this discussion to microsoft.public.dotnet.general to stay a
little more on-topic.

 

[Lucas Tam]

What concerns me is the hacker that extracts those vendor service
credentials, and starts racking up unauthorized (or,
ungoverned-by-our-client) bandwidth charges using our account.

..NET or not... in this case, someone could run a sniffer to read the
traffic between your client and the imagery server. So you might want to
rethink your approach.