I am concerned with MITM attacks in the Silverlight application I am writing. The site will be running over SSL. If my site is the victim of a MITM attack, as far as I know, my only defense right now is the warning page the browser displays when the site's certificate is untrusted. Since it is only a browser, the best it can do is simply warn the user and then let them through anyway. User's can be click happy, and tend to not read things. Therefore, chances are they will read this warning, scratch their head, and continue on to the site. My thought was that since I am writing a robust Silverlight application, I should be able to either detect if the browser is seeing a certificate error, or perform that same verification that the browser performs. Then if I determine that there is a problem, I can simply lock down my entire app so that the user does not expose any critical information to the MITM. The problem that I am having is that I can't seem to find the right classes in Silverlight's limited subset of .NET to do what I need to do. Does anyone know how I can accomplish this goal, or a different way around this issue?
This isn't possible as far as I know - Silverlight uses the browser's networking stack, and as a result relies on its networking warnings and security infrastructure.
Silverlight 3 added a new networking stack, but I believe that in general the same applies: your host server's certificate is validated when the .xap (Silverlight application) is downloaded by the browser, and not something you can check or interact with in code.
IMHO You may check the certificate that is stored locally since browser will save a copy of it after SSL request.
Check out this article. I hope it will give you some hints
Related
Just an R&D question. We need to develop an application that can be run in a browser that has the capability of performing some system checks to gather support information to be emailed to us. These checks will include basic system information, but also will need to scan the filesystem and pull out version information about various DLLS, executables, and .NET assemblies that might be installed. The idea being that we can direct a client to a page and have the application gather the relevant information needed for support, and potentially even populate some database fields. We need it to have as small a footprint as possible.
I've worked with ActiveX before, and know it is capable of these things, but particularly on modern systems security is a nightmare to get around, with a lot of people blocking ActiveX altogether. Is Silverlight easier to deliver to clients? Does it have a lighter footprint? Is it even capable of doing these things?
Silveright has access to isolated storage, but I don't think it can do what you are looking for (I may be wrong). As for footprint, if I remember correctly, the runtime is reasonably small, and the .xap packages are limited to 4Mb.
Silverlight out-of-browser has access to the file system. http://msdn.microsoft.com/en-us/library/dd550721(v=vs.95).aspx#special_features_for_outofbrowser_applications
If you intend to run your app in the browser, you will still have to configure the trust as if it where oob. http://msdn.microsoft.com/en-us/library/gg192793(v=vs.95).aspx
However, iTunes has a neat way of doing something somewhat related. It has a custom protocol (itms://) that allows the browser to invoke a client side program (iTunes). Then you can embed html in a webpage that passes parameters as command line arguments to that app. The website also knows if the iTunes is installed by a cookie. We this in mind, you might be able to encourage your users to install some small app that setups the custom protocol on install. You could pass command-line parameters to it from the web, and the app will push information from the client back to the server.
To create a real-time experience, you could use sockets + more javascript to update the page with the info you just got off the machine.
HTH,
Silverlight runs in a pretty restricted silo and can't do a lot of low level things - such as checking the file system. So I would say it does not fit your use case, unfortunately.
I am trying to deploy my WPF application to some users who are outside of our corporate network. Everything works great on our LAN but I can't get the updates working when I turn on security as the user is never prompted for their login details?
Does anyone know of a way to secure my ClickOnce files so that only my users can access it? I am not allowed to put this software up without it being secure.
Any help much appreciated.
There is no way to secure your files as the ClickOnce runtime will blindly return to it's deployment point and never keep hold of the users original credentials. I have heard of ways of getting round this using various techniques but its a fair bit of work.
This might be of use www.clickoncerevolution.com.
You could also always consider an MSI installer but you won't get the automatic updates.
Marty
Internally, you can restrict access to the files on the webserver. Externally, there's not much you can do easily.
We handle this by having our customers log in when they run the application, and we verify their credentials against backend services (running on Azure). So they can't run it unless they can log in.
If you don't want to do that, I'll share this article with you. It shows how to serve up your ClickOnce files from a SQL Server database by intercepting the requests to the webserver and responding. If you were smarter with web applications than I am (not a high bar, mind you), maybe you could figure out how to intercept and ask for authentication credentials at that point.
And here's an article from CodeProject where they show one solution for what you're trying to do.
I want to develop a online trading application using silverlight in which I want to perform all the calculations at the client side instead of server.
First, Is it possible to run the whole application on the client side??
Second, How secure is silverlight xap file to prevent decoding the logic??
Please let me know.
Thanks,
Mahesh
You can use Silverlight Out-of-Browser which will increase your access to the local system if that is needed however is is still sandboxed and you do not get full access to system resources. If that is not a concern then you can perform your logic internal to the Silverlight application which remains in the browser and is indeed client side.
In terms of security to your .XAP file is nothing more then a re-branded .ZIP file. If someone can download your .XAP they can then get access to the .DLL's within the .XAP. Obfuscating the DLL's may hinder individuals from getting access to your code see this, however if intellectual property is something on the top of your list, I'd recommend not performing that logic client side as the other post mentions as well.
I am interesting in hearing if others have addressed release management for Silverlight applications.
I have a business application that is to be released shortly andam concerned about how to "release" updates to this application. Typically this application's users will leave the application open all day (and potentially all night) without reloading it.
What if there is is need to release an change that includes an web service interface change? How can this be deployed w/o causing errors on the client side?
We have grown so used to deploying ASP.Net apps by just dropping the latest code on the server. My only idea currently involves a client version number and a periodic timer on to check for updates.
I would love to know what others have done before implementing this.
Thanks,
Mike
I just answered a question on how to make sure that .xap files are not cached by the browser, which might be of some help:
Prevent Silverlight xap from being cached by proxy server
But that's no use if the users never reload your application. In my own application this is not a problem since users will be automatically thrown out whenever we deploy an update to the web service. But I like your idea with the timer, I would go with that.
Stating the obvious but don't do anything to annoy your users. E.g. could they spend twenty minutes entering data, nip off to the coffee machine and return to click Submit to find the timer has expired, noticed an update and their work is lost due to a forced restart?
If so, and I admit this hasn't had a lot of thought, if e.g. you have to make changes to the web service that break the current release, could you have the new web service version side-by-side such that users don't get thrown out until the timer has expired and the unit of work is complete? Or is this also stating the obvious?
For server code, i.e. endpoints just do as per normal. for the xap's I think you have a few options depending upon how you handle communications. You could have request contain a version number and if the server has been updated then force some code to reload the client, bit lame, messy but do-able. Perhaps a cleaner solution would be to control the clients session, which presumably is part and parcel with requests to the backedn. When you deploy a new version you could invalidate the client session, perhaps forcing a page refresh with custom logic. If your protocol is push base you could send a command to the client to do what ever you want, for many systems that are on all day its likely that this infrastructure would exist (if u've build it nicely :)). For instance our service layer is abstracted away from the repositories models and view models, in our case we'd could send a logout or perhaps a specific command to kick in some custom logic on the client informing the application is being updated and to refresh your browser when done. Our shell is light weight so our modules (basically other xap's) can be updated in time for the refresh.
I would recommend you to use a solution like mentioned in App Arch Guide:
The Guide Chapter I mean see Deployment considerations.
Divide the application into logical
modules that can be cached
separately, and that can be replaced
easily without requiring the user to
download the entire application
again.
Version your components.
Have you considered keeping a WCF polling duplex channel going that alerts the app when it needs to reload? In addition, you can have your WCF calls direct to a virtual directory that contains 'interfaced' calls. For example:
Silverlight app hosted at "x.x.x.x\Default.aspx"
Silverlight talks to WCF at "x.x.x.x\Version2\DataPortal.svc"
DataPortal.svc talks to a GAC (or otherwise base) assembly that can identify what version can handle what calls.
This way, if you upgrade to "x.x.x.x\Version3\DataPortal.svc", you can still make calls against Version2, assuming those calls have code to convert them to a Version3 concept.
This helps in cases where your line of business app has dynamic xap downloading ('main', 'customer', 'inventory', etc.) and you want to release them independently.
I would like to know if there is any way to launch a local application with silverlight. I'm having some security problems doing this with a user control embedded in IE 8, so I would like to convert this into silverlight app. This little issue is stopping me to go forward with silverlight, so if any suggestion, I would appreciate to hear it.
Thanks in advance..
Carlos.
This will be, theoretically possible, using COM interop with Silverlight OOB in SL4, but you will still have the same security issues, and in addition, add some deployment issues.
In order to do this directly from within IE, you'll need to make an add-in that gets installed with proper security permissions. Any "automatic" model for this would violate the standard IE security policies, so there is no direct means of getting from browser->local system.
this would totally invalidate Silverlight security model. So, good luck with that. Pretty sure you can not do it. This is what officially is known as a "Bad Thing."
Things I learned from Jurassic Park: Just because you CAN do something doesn't mean you SHOULD do something.
It is absolutely possible to get "Out of Browser" support using Silverlight 4. But what you need to do in order to access applications on the "Host" machine is the certify the SL4 application as being trusted.
This will involve getting a certificate for it. This could be obtained from CA (or similar for Internet applications) OR you could generate your own certificate for Intranet use and have the users simply install it or have it installed via another automated sys admin style process.
The bottom line is that when the SL4 application is running OOB AND it is trusted, it can access anything on the host machine; to a point.
Even though you can have file access and so forth, you still cannot call the application directly. That is unless it's installed as a COM object.
So what you will need to do is invoke the application using the "script" host COM object. You create a reference to the Script host and then simply pass in the command (and parameters if you like) that would invoke the application.
Hey presto, you broke the wall :-)
It should be noted that the use will still only be able to run the applications on their machine that they are currently allowed to. So you won't be able to invoke Admin tools on a user with limited control.
See here for details
http://msdn.microsoft.com/en-us/library/dd550721(VS.95).aspx
It seems to me that you ought to post a question about the developement of the user control you already have. Ultimately no matter what technology you use you will need to get the user to opt-in manually. Silverlight when hosted by a browser is designed to live in nice and secure sandbox that it can't get out of. It isn't the answer to your problem in this case.
Your Silverlight application should be a trusted application because it runs on a browser.
If you want to launch an application in your local machine use the below code:
AutomationFactory.CreateObject("WScript.Shell").Run(FilePath);
Use the namespace System.Runtime.InteropServices.Automation