I am using CSLA for a click-once app and the DataPortal is hosted on IIS. As usual, after authentication, a Principle and an Identity objects are sent to and fro the Dataportal to perform security at the Server. I am wondering what you would do to defend against the following attack:
A user downloads my click-once, decompiles it, and adds a reflection call somewhere in the app to change the Identity object to have whatever rights they desire. The user then logs in normally, invokes the method, and uses this modified Identity to make all further calls. They have not actually modified the CSLA assembly in any manner so Strong Naming does not help directly. Is it possible to setup the CSLA assembly to only be allowed to be run by my app?
Similary, the user sets up a local DataPortal masquerading as the foreign DataPortal. When the click-once is run it initially authenticates against the real DataPortal, but afterwords the local web service is started. Thereafter the click once hits the local DataPortal, which then desiralizes the call, writes a new Identity and forewards it onto the foreign DataPortal. Same fix as above?
Finally, setup an http socket in the middle, reads in the byte stream, modifies it accordingly and passes it on to the foreign server. No CSLA in the middle involved, just hacking together a modified message.
Why is the Identity even being passed back and forth anyways, why not store it in the Session object at the server, where the client can't get at it?
Thanks all for considering this, it is much appreciated.
Muaddib
muaddib:
A user downloads my click-once, decompiles it, and adds a reflection call somewhere in the app to change the Identity object to have whatever rights they desire.
If you don't trust the client, then you must stop and rethink.
Client/server and n-tier architectures include the client as part of the architecture, and thus by definition the client exists within the application's trust boundary.
If your client is actually outside your trust boundary, then it can not be part of your application. Instead, the client must be viewed as being a separate application that is communicating with your server application. This is the foundation of SOA, and is (imo) the correct way to view this scenario.
In this model, your "real" application (the one on the server) doesn't trust anything coming from the client. It assumes that the client is incorrect - either by accident or due to malicious intent.
The client application might well include a lot of code. It might have all the business logic, so it can provide the user with a great experience. But the server must always recheck everything, acting under the assumption that the client was compromised.
This is the world of SOA.
The best way to accomplish this, with CSLA, is to literally implement everything twice. Once on the server, with a service-oriented interface (see chapter 11), and once on the client, where the clinet-side objects have DataPortal_XYZ methods that merely call the services provided by the server application.
If you are clever (and are willing to break a major rule of SOA), you can share most/all of your business objects between client and server. See the DeepData sample app for ideas on how to use data transfer objects (DTOs) to entirely separate data access from your business objects. Using that technique, your DAL in the client app calls web services, while the DAL on the server talks to the database - but the objects are the same either way.
Obviously there's a lot of duplicate processing and inefficiency introduced in this model. But it is safe, because the server always runs all the business logic (authorization, validation, etc), so if the client is compromised it doesn't matter.
Why is the Identity even being passed back and forth anyways, why not store it in the Session object at the server, where the client can't get at it?
Because most app servers are entirely stateless. Imposing the requirement of Session is a pretty high bar for most app servers, and does imply you are hosting in ASP.NET. Not everyone does - nor does the data portal require it. Some people host in custom Windows services, and in the future I think most people will host in WAS, skipping IIS/ASP.NET entirely.
But honestly, if you don't trust your client, changing the identity is the least of your worries. They can mount replay attacks and all sorts of fun stuff if they control the client.
This is why SOA is the right answer. A well-implemented, highly paranoid server application (which almost no one actually does, because it is too expensive, but still...) can address these issues.
One of the best places to look for really good implementations of this sort of thing are online games. Especially the MMORPGs, because they learned long ago how to defeat exploits by rabid, dishonest, gamers who control the client and feel free to hack and break code, create man-in-the-middle modules and all sorts of stuff.
There's a series of books by Charles River Media on game design (a couple series actually) and some of those books have good chapters dealing with this stuff.
Of course, as with all security issues - make sure you do a good threat assessment first. Preventing some of these hacks is really hard and thus really expensive, and so you need to make sure the cost and likelihood of compromise is high enough to offset the cost of prevention.
Copyright (c) Marimer LLC