Just curious about others thoughts on this: but it seems to me that the only way to obtain true security that is built into an SL application is to obfuscate the assembly, otherwise wouldn't there be a rather easy to manipulate security hole?
Here's what's making me think that:
A malicious user could easily get ahold of the .xap package (even though they don't get authenticated). They could then easily decomile the .dll containing logic for Principal and Identity classes and modify the code to allow all users to be authenticated. They could then recompile and hit the exposed endpoints in the ClientConfig and voila, they have access to the dataportal, ne?... Am i crazy for thinking this?
With an apps security assembly that isn't obfuscated, this could take all about 15-20 minutes to do.
There are only two architectures in all the world: n-tier and SOA.
(ok, maybe I'm simplifying a bit - but bear with me).
n-tier architectures assume it is reasonably safe to run code on the client workstation, and so the code running on the client is considered a tier - part of the application.
SOA architectures assume it is not safe to run code on the client workstation, and so the application is entirely server-based. Except that leaves the user with a crappy experience, so it is permissible to write a separate application that runs on the client. While that application may be hacked, the real application is on the server, and it never trusts anything it gets/sends to the client, so everybody is happy. Everybody that is, except the person paying for the system - because they've now funded two apps, often with much duplicate behavior...
CSLA .NET for Silverlight attempts to offer a middle path. You can build your app using n-tier techniques, and then use a MobileFactory attribute to run extra code at the entry point of the web server - so you handle each client request before anything else - so you can re-run business/validation/authentication logic on the server before allowing normal data portal processing.
The idea is to reuse your code on the client, but to not trust the client overmuch. And to do this without radically increasing the cost of the overall system in terms of development and maintenance.
Thanks for the reply Rocky, your explanation found here also helped me understand more about the mobilefactory
http://forums.lhotka.net/forums/thread/34573.aspx
So when using the MobileFactory, you would re-execute authorization rules to provide this added security?
One thing I'm confused about: If the above is true, what's stopping a hacked xap from making a request that contains a hacked principal, then when authorization rules are executed on the server(with CslaAuthentication) isn't the trust still relying on the request sent throught the dataportal?
Again, if you don’t trust the client, you don’t trust the
client. And there’s nothing you can really do to avoid not trusting the client.
If you are actually worried about a hacker cracking the xap file
or the Silverlight runtime, then your only option is to go with an SOA
architecture where the real app only runs on the server, and the client app is
there as a convenience to the user.
Well around here we have a DMZ where our SOAP servers sit.
With our Csla webforms, we would use windows authentication between the web client and the SOAP server.
If for Csla silverlight, if we used CslaAuthentication between the SL app and WebClient endpoint, and then used WindowsAuthentication between the WebClient and the SOAP endpoint, wouldn't that solve the problem?
EDIT: Well, i guess not, because ultimately you're still relying on that inital client request for authentication. :(
Let’s take a step back.
Security is about threat analysis and mitigation. You need to
decide what threats exist, their likelihood, the cost of the threat occurring
and the cost of mitigation. Most people put these in a grid, and score each row
based on the likelihood, cost of occurrence and cost of mitigation.
Then a business decision is made as to which threats are worth
addressing.
The likelihood of someone hacking your xap is probably extremely
low. But I don’t know your application or organization. If you are
government the odds might be higher. If you are financial the odds might be
higher. If you are a widget manufacturer the odds are going to be very low. The
cost of mitigation is quite high, because really not trusting the client is an
expensive proposition.
So you need to decide if it is worth mitigating.
You can absolutely use Windows or ASP.NET forms security to
require that the user log into the web site before they can even get your xap
file. In other words, you can easily prevent random people from getting access
to your web pages, xap file and data portal endpoint.
What you can’t easily stop is an authorized user
from getting the xap file, and then potentially doing as you suggest by hacking
it. One way to mitigate that risk is to not hire hackers as employees :) Or to
use legal remedies to make such hacking distasteful enough that a sane employee
would never do it. That might be a lot cheaper than a technical solution.
Rocky:
One way to mitigate that risk is to not hire hackers as employees :)
LOL. Well put. Thank you very much for your insightful input.
Yes, I'm government, and the information exposed is often very sensitive, hence me being anal. Our users are not necessarily people we hire, but ARE scrutinized for registration.
yea, I've considered the webforms approach. What I fear about that is exposing complete access to the dataportal if the web form authentication gets hacked.
...With some of the sloppy developers around my workplace, the security of our login is only as good as the worst developer we have on staff =/
Perhaps using the MobileFactoryAttribute as well as obfuscation could help alleviate some of my fears... Sure it's not bulletproof, but it would certainly deter even an experienced programmer from bothering. And I if I put the Authorization role logic only on the server, the hacker would further have to determine the string of the role for each authorization. That alongside denying access to the xap through webforms will eliminate most users from even getting the xap. Sounds good to me. Thanks for your help.
I am a little disappointed though that I can't keep everything in the SL app, but c'est la vie I suppose.
Copyright (c) Marimer LLC