Geek Answers Handbook

I Need Help Understanding Silverlight 4 Security

Does anyone else think that the security of Silverlight 4 is a bit of chatter?

Look at the following scenario:

  • Silverlight, when installing a trusted application and exiting browser mode, allows you to view the file using the file open dialog.
  • You need a file path name to open it from any COM automation. For example (excel / word), but it could be anything.
  • Unable to retrieve the full file path from the dialog due to security restrictions.
  • However, you can use COM FileSystemObject - to do what you want for the user file system, including creating folders, moving and deleting files.

In other words, why all the fuss about security in Silverlight that actually interferes with real business use cases, when you can access any file in any case using COM?

Saying it differently if a user launches a silverlight malware application is unlikely to say - well, that was a COM error. After that, COM was called by the Silverlight application.

Here is what I mean ....

  • The user is viewing the file - c: \ myFile.xls
  • Silverlight does not allow you to get the path (for security reasons)
  • Silverlight lets you work with my documents
  • With COM, you can do anything on the file system in the background. Including copying this file to my documents if you knew this name! But in addition, you can destroy any file potentially if it is not used.

In my opinion, the Silverlight security model is erroneous, or they should have given developers full trust and allowed us to run applications as if they were running locally

or

Silverlight is not allowed to access COM.

Is it just me, or can anyone else see that this is a bad implementation?

This triggers security warnings:

OpenFileDialog flDialog = new OpenFileDialog(); FileInfo fs = flDialog.File; string fileName = fs.FullName;

Is not

 dynamic fileSystem = AutomationFactory.CreateObject("Scripting.FileSystemObject"); fileSystem.CopyFile(anyFileName,anyDestination);
+4
source share
4 answers

I do not agree with your point of view. The fact that you can do almost anything that a COM object can install is not the reason for changing a whole group of existing Silverlight code so you can do the same things.

Why? Since in the process of opening this code, there is also the possibility that in some unexpected way the same code could be launched when the Silverlight component is not working in reliable mode. If this happened even after the media attacked him, and Silverlight's reputation would probably have been unfair, in tatters.

Personally, I am pleased with the very cautious approach to security that MS takes with Silverlight.

+2
source

Some Silverlight controls, such as OpenFileDialog, work in both trusted and untrusted modes. These controls were carried over from previous versions of Silverlight, where new levels of trust were not considered.

Thanks Anthony for this.

Developers should be aware of the definition of trust we are discussing here. Running a Silverlight application in full trust with elevated privileges is not the same as starting a local Silverlight Windows-based application. It is also much more restrictive than ActiveX.

It is possible that the trust provided by Silverlight meets your specific business requirements. However, it is likely that there are scenarios in which you find Silverlight too restrictive, it is best to do your research in advance and run code samples so that you can do critical things before jumping in heels.

+1
source

Microsoft ensures that the public Silverlight API has the same behavior for both Windows and MacOS platforms. Thus, functionality is limited by a common denominator and technical feasibility. Refer to COM introp as a specific case, considering only the Windows platform and only in full trust mode, and it will not work the same for other platforms. Therefore, the security restrictions are valid because they are the same for both worlds in terms of reusing the API.

+1
source

I agree with the original poster. I think this is a bad implementation. We are given a built-in dialog to search for a file, including the directory structure. We can select a file and get a FileInfo object, but security does not allow us to get FullName (directory and file name). What for? How does this increase security? How to start a dialog with an open file?

And as the original poster with these dynamic objects is mentioned, we can change the local file system ... which seems like a possible security hole.

All I want to do is read some data from an excel file ... a way for my users to import Excel data into the application, and the file can be saved anywhere on my computer. These are sales representatives using excel files to record orders locally until they can connect to the Internet. Who knows where they all save this file ... so I'm not going to suggest that we tell all of them to store it in the same place in "my documents." I will laugh if I offer this.

It seems like it should be incredibly simple. But this "security measure", which prevents us from getting the directory that the user selected from the built-in dialog box with an open file, makes it so that we cannot use the dialog for the purpose for which it was created.

So what is the alternative? Is there a way to select files using these dynamic objects? Do I have to write my own file selection tool using those objects that can modify the file system? Since I don't need anything other than reading the file, and because I read something somewhere, that we have access to the file stream ... is there a way to use the file stream to open the file for reading with AutomationFactory

0
source

More articles:


All Articles