VBScript, Chrome, and Orchard

Topics: Troubleshooting, Writing modules
Dec 10, 2012 at 11:52 PM

I have been using Orchard on my intranet site for a while now to provide links to vbscripts that map drives and network printers to my office. I have noticed that Chrome handles file:// urls differently now (when you click the link nothing happens). Also, if you right click the link, copy the address, and paste it into another window, it just shows the text of the script and does not execute.

I have read that this is an added security feature in Chrome, which kind of puts a torpedo in my current system of management. Hoping some of you have ideas on how to accomplish this.

Developer
Dec 11, 2012 at 6:11 AM

Perhaps use the http protocol instead? When the user clicks the link of a script, he will be prompted to save or run the file.

Dec 11, 2012 at 2:20 PM
Edited Dec 11, 2012 at 2:21 PM

That would require the file to be on the local web server somewhere in the web folder, right? The files are being stored on a separate file server. Normally I just used the file protocol like such: file://<server>/<path>

Developer
Dec 11, 2012 at 3:36 PM

Not necessarily, if your file server has IIS installed and configured you can have IIS serve your VB Scripts. I understand that you prefer to use the file protocol, but I suppose there's nothing much you can do about Chrome's security regarding the file protocol, right? Except for redirecting the user to the installation page of IE of course :)

Dec 11, 2012 at 4:28 PM
Hah, yep. I think I'll go that route with IIS, thanks for your input. Our corporate standard for machines is IE anyway, but I don't like prohibiting browsers if I can help it.

On Tue, Dec 11, 2012 at 9:36 AM, sfmskywalker <notifications@codeplex.com> wrote:

From: sfmskywalker

Not necessarily, if your file server has IIS installed and configured you can have IIS serve your VB Scripts. I understand that you prefer to use the file protocol, but I suppose there's nothing much you can do about Chrome's security regarding the file protocol, right? Except for redirecting the user to the installation page of IE of course :)

Read the full discussion online.

To add a post to this discussion, reply to this email (orchard@discussions.codeplex.com)

To start a new discussion for this project, email orchard@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Dec 11, 2012 at 10:59 PM
Edited Dec 11, 2012 at 11:22 PM

I've decided to go the route of blocking Chrome since most of our office is using IE anyway. How would I block or redirect Chrome users? I've done some digging and found some javascript, is this correct?

 

<script type="text/javascript">
    if (navigator.userAgent.indexOf('Chrome') !=-1)
    {
    	// Using Chrome
		window.location = "~/chromepg.html"
	}
</script>

 

I have added it into my global includes on my layout.cshtml file as:

Script.Include("~/browsercheck.js").AtHead();

I've tested it and Chrome still works though, not sure what I'm doing wrong.

Developer
Dec 12, 2012 at 8:55 AM

What exactly is the value of navigator.userAgent when browsing with Chrome? Do an alert or set a breakpoint to find out. If the conditional statement is correct, then maybe try replacing the window.location part with window.location.href or location.href.

Alternatively, you could implement a serverside actionfilter that will perform a check on the user agent, and set a RedirectActionResult from there.

Coordinator
Dec 14, 2012 at 2:06 AM

Terribly dangerous thing to do in the first place. Deploying that sort of dangerous software through a browser is crazy, and Chrome is right to block it, and I hope IE follows suit. I think the right thing to do is to find a safer way to deploy those scripts. There's plenty of proper tools out there for that sort of thing.

Dec 14, 2012 at 2:29 AM

The scripts map network printers and network drives in a domain environment using UNC commands. The modification of these scripts that the page is linking to are locked down and cannot be modified by any user without domain admin credentials. I'm not sure what you mean by that being dangerous, again these scripts just automate two of the more mundane processes in a business environment.

Coordinator
Dec 14, 2012 at 2:30 AM

If the browser is configured to accept those scripts, it is also configured to accept malware. Simple as that.

Dec 14, 2012 at 2:37 AM
Our WAN portal allows very specific outbound traffic, and all common http/https requests across the WAN circuit are blocked due to the nature of our business. The browser for our office is essentially just a portal for intranet sites, so outbound threats aren't a risk. Even say we did have open access and the file:// protocol was allowed, the concept that users are at any greater risk for infection is highly debatable since opening any link via the traditional file:// protocol over web initiates the "Do you want to open or save this file" prompt from the user. It is much easier to float malware across the web using redirects or deceptive popup windows.

On Thu, Dec 13, 2012 at 8:30 PM, bertrandleroy <notifications@codeplex.com> wrote:

From: bertrandleroy

If the browser is configured to accept those scripts, it is also configured to accept malware. Simple as that.

Read the full discussion online.

To add a post to this discussion, reply to this email (orchard@discussions.codeplex.com)

To start a new discussion for this project, email orchard@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Coordinator
Dec 14, 2012 at 2:41 AM

Yes, but many attacks come from the inside, and user prompts are notoriously inefficient at preventing users from shooting themselves in the foot. Look, I'm just suggesting that maybe a browser is not the best way to deploy software, and that there are more appropriate and secure ways to do that. Do what you will with the advice ;)