We are developing a CSLA 2.1 app that will have a Windows Forms UI with remoting to an application server. The app will have one database with users from different organizations, so we want to be diligent about security and, in particular, making sure our CRUD operations are userID-specific.
I've seen these gamers using a memory editing tool to modify memory values to cheat games, and I am wondering if a similar technique could be used by a malicious user (behind the scenes) to:
1) Change the value of an object's private variable, thus bypassing authorization and rules checking in the property set statements.
2) Change the "Name" value on their CSLA.ApplicationContext.User.Name (if that is where we choose to store the UserID (GUID)
3) Change a GlobalContext name-value pair in CSLA.ApplicationContext.GlobalContext... if that is where we choose to store the USerID.
4) Modify a role name in Csla.ApplicationContext.User.IsInRole (list)
Does anyone have any insight in type of memory tampering?
Thank you.
I actually emailed Rocky about a similar question a few years ago. I had found that, using CSLA custom authentication and reflection, I could change the username on the custom identity object to whatever user I wished. The remoting server would accept my "rogue" identity object as gospel. All I needed was the business object assembly (usually publicly available if you are using Netrun or Click-once), and I could create a rogue client that would successfully impersonate any user I liked.
Rocky's answer was basically that once you can't trust both endpoints, CSLA remoting isn't a good choice. If you can't trust the client computer to be under your control, it can send whatever data it wants to your services, so you can't implicitly trust it. Instead, you should take more of an SOA approach where you verify every bit of input and trust nothing.
What I still don't like about this answer, though, is this: I, as a competent developer could theoretically find out that one of my company's custom systems is using CSLA remoting and custom authentication. I could then use the same tactics I did a few years ago to create a rogue client that references the public business library assemblies and easily elevate my permissions in the app!
That was basically my response, yes.
And it remains true, though not just with CSLA. If you can't trust both endpoints, then you can't build client/server systems. Period.
The reason is that n-tier client/server architectures assume the client is inside the trust boundary. But you are describing a situation where the client is outside the trust boundary (not just security, but trust - a broader concept).
So this means you must always assume that code running on the client has been compromised. You must also assume that the data stream has been compromised, and that you may be subject to replay attacks and various other protocol and network-level attacks.
The basic answer is to implement an SO solution, which is message-based, but moreover employs concepts like isomorphic messaging (meaning each message is absolutely unique, so the service can include code to prevent replay attacks), and the service is entirely self-contained (meaning it does full validation, calculation, etc. on any inbound data).
Obviously even in such an SO setting, the client app (because it isn't a tier now) must provide a good user experience, and so it too will implement much or all of the validation, calculation, etc. That allows the UI to be responsive and nice for the "good" users, but the service never trusts that input and re-applies all logic so as to prevent being compromised by "bad" users.
The original post mentioned gamers. As an amateur MMORPG designer, I can tell you that these games all employ the techniques I'm talking about here. While the game clients do extravegant and exciting things, the server never trusts client input, and includes guards against replay attacks, etc.
Obviously this can get quite expensive. You should do a realistic threat analysis to determine your speicfic needs and how you want to respond to them. This stuff all boils down to a business decision based on cost/benefit and likelihood of compromise. No sense building Pentagon level security to protect mundane data, but similarly, you can't ignore common-but-low-impact issues or uncommon-but-fatal issues.
And I should clarify...it's not that I didn't like your answer, it's that it didn't make me feel any "safer" on the project I was working on at the time. But you were absolutely right - in the end we decided that the likelyhood of a user exploiting these attack vectors and the security level of our data was not worth the effort of going to extremes to stop it.
However, I did do one simple modification that made me feel a little better. I added a private field to the identity object that held an encrypted string. When the user logged in, the server authenticated him and sent back an identity object with that private field set to the username encrypted with a private key (stored in web.config). On each client request, when the client sent its identity object, the server would first decrypt the identity's private field and then compare it with the identity's username. If they matched, the server knew that it is the only one that could have "issued" that identity object, and therefore the user had been previously authenticated. This method, coupled with SSL to prevent snooping and therefore replay attacks, made me feel much better with a minimal investment.
Thank you Josh and Rocky for the responses. I understand that I'll need to do some rethinking. I don't have much experience with SO and web services, so I think I'll start by re-reading chapter 11, but I think the short term solution is going to be to move the client to a web forms app. My hope was to leverage Click Once and remoting to offer a richer UI.
I think the complexity of developing the "good user experience" SO client will make ASP.NET a better (faster, cheaper?) choice for now, but maybe using code generation tools, I could whip up a class library (of stripped-down BOs) that offers validation, calculation, authorization, etc.
OT - Rocky, I've been a "disciple" since 2002 with your VB6 BO book. Thank you for all you've done. I heard an interview once on the web where you explained why you chose to share the framework in this way...very admirable.
Copyright (c) Marimer LLC