I have a security question/concern...
We in the process of using CSLA to re-write our corporation's purchasing module. The tentative plan is this. The front-end will be Windows forms and the back end is a remote dataportal and CSLA-based business objects. The back-end dataportal/DLLs will reside at our corporate headquarters and the front end EXE/DLLs will reside at several franchises throughout the country.
We are very concerned about being hacked, even internally. In one of our other legacy web apps, we've had trouble internally from a creative franchise tech who has written some spiders/scripts with benevolent intent, that has unfortunately had very malevolant results. For political reasons, this franchise tech cannot be touched. So we are extremely paranoid about security on this new app. Which leads to my question/concern...
So say if someone (like the franchise tech) has access to our DLLs, config file, and dataportal URL. Is there anything to stop them from writing their own EXE to bypass/replace our client app EXE -- and have their own code use our DLLs to hit our dataportal and database? If that is possible, is there anything we can do to minimize this threat?
Jason
Can you use non CSLA standard naming for the connection strings etc...then encrypt the configs? Then if he snagged your DLLs he'd have to make his own config file but it wouldn't do him any good as you'd have different key/name pairs than the docs he'd find here.
There's probably a gap here that still exploitable though.
Maybe if you kept a CRC/Hash signature of your app in your tables and on each DB operation do a compare...again another gap in there most likely...but I'm just spitballing.
Since your remoting, you wouldn't need to include the database config on the client side, this would force them to use the server. Some sort of hash to pass along might help. Depending on how savy the user is, they may be able to sniff a hash or find it in the library itself. You'd want to make sure everything is SSL. You may also want to encrypt your config file containing the dataportal url. There are a number of examples on how to encrypt web config files out on the web, they work just as well encrypting the app.config.
If possible, you would want to put all your business rules in the library, in case they are able to use the library, they would still have to follow the business rules and only have the rights of their user.
True...we definitely need to encrypt our config file. That would at least slow someone down in getting the dataportal URL. But I think someone would still get it fairly easily by monitoring the internet communications between the client app and the dataportal.
I expect our franchise tech will also crack open our files (EXEs/DLLs). So we're planning on using the "Dotfuscator" to scramble the insides of our DLLs and EXEs. I'm not too worried about him re-writing the DLLs/objects. Even if he could decipher and re-write them, it is my understanding that the CSLA code will throw an error if the object/DLL on the client does not match the object/DLL residing in the dataportal folder on the server. Even if he changes his DLLs, it won't matter because he can't change the DLLs on our server (dataportal).
My main concern is that still that once someone has our DLLs and the DataPortal URL, they can use them to write their own custom app. I've toyed with the idea of having DLLs confirm which app/code is calling their factory methods. I thought about adding a parameter to the factory methods that is some kind of security code - but I'm also wondering if that could be monitored/discovered somehow.
On another train of thought, one of you guys mentioned the business rules inside our DLLs/objects.....all of our critical business rules are enforced inside the objects/DLLs. So unless we missed something in our rules, maybe the hacker won't be able to do anything that we don't already allow them to do through our client app. So, am I making a big deal about nothing?
It's so hard to know how far to go with these security concerns.
Jason
xxxJasonxxx:
My main concern is that still that once someone has our DLLs and the DataPortal URL, they can use them to write their own custom app. I've toyed with the idea of having DLLs confirm which app/code is calling their factory methods. I thought about adding a parameter to the factory methods that is some kind of security code - but I'm also wondering if that could be monitored/discovered somehow.
On another train of thought, one of you guys mentioned the business rules inside our DLLs/objects.....all of our critical business rules are enforced inside the objects/DLLs. So unless we missed something in our rules, maybe the hacker won't be able to do anything that we don't already allow them to do through our client app. So, am I making a big deal about nothing?
Well that's right; he could only push in data that passes your validation rules. so the only threat would be him reading / writing data that does conform to your rules, but shouldn't be there for some other reason. Like if he wanted to import a bunch of customers and had privledges to do so. You probably would want to go with Windows Authentication, if possible. That way he'd have to be running as someone else (probably a no-no in your company) or use his own credintials, which would lead back to him if he screwed up.
It's so hard to know how far to go with these security concerns.
Yes, I suppose that's why security is as much of an art as engineering.
HTHIf you have a unique custom security code passed from the client to the portal I am sure there's a way to make certain another client is not currently using that same code and if they are you can shun any activity from them. It's a heavyweight solution because you'd have to track alot of activity by an IP address or whatever over a long period of time.
Its really a larger view of the security mantra "Never trust user input". If all the real logic/validation is in the dataportal itself then you should be good. But it will probably mean there is logic on multiple tiers.
All these things are well and good and should be explored to their fullest.
I know you said politically he can't be touched...and I know you are looking for a technical solution. But the real solution is strict policy enforcement. IMHO there's no room for political niceities when it comes to security.
Copyright (c) Marimer LLC