[sclug] sclug Digest, Vol 81, Issue 5

Neil Haughton haughtonomous at googlemail.com
Mon Jun 7 16:07:05 UTC 2010


Thanks for the replies.

This is a Windows environment, and the executables of interest will be exe.
It sounds like that has a bearing on security concerns.

Control of what is executed is not entirely outside our realm because we add
value by configuring this application for the customer, to provide unique
functionality. Part of that is (I am told) to be able to execute an
application (could be notepad, could be Crystal Reports, could be *anything
else*) from the browser to provide additional 'fringe' functionality, ie to
extend the web application. The customer (admins) can also do this
themselves, if they choose.

I too thought that an integral part of browser design, if not spirit, was to
prevent the arbitrary execution of local apps from within the browser
context. My concern still is what view corporate sysadmins are going to take
of this kind of functionality in our application. My instinct says 'dim',
but I want to get a wider opinion.

TIA

Neil

On 7 June 2010 13:00, <sclug-request at sclug.org.uk> wrote:

> Send sclug mailing list submissions to
>        sclug at sclug.org.uk
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://sclug.org.uk/mailman/listinfo/sclug
> or, via email, send a message with subject or body 'help' to
>        sclug-request at sclug.org.uk
>
> You can reach the person managing the list at
>        sclug-owner at sclug.org.uk
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sclug digest..."
>
> Today's Topics:
>
>   1. Local execution form web app (Neil Haughton)
>   2. SCLUG meeting this Wednesday 9th June at 19:30 (Simon Heywood)
>   3. Re: Local execution form web app (Neil Brown)
>   4. Re: Local execution form web app (Tim Sutton)
>   5. Re: Local execution form web app (Darren Davison)
>   6. Re: Local execution form web app (simon at spudley.com)
>
>
> ---------- Forwarded message ----------
> From: Neil Haughton <haughtonomous at googlemail.com>
> To: sclug at sclug.org.uk
> Date: Mon, 7 Jun 2010 09:58:48 +0100
> Subject: [sclug] Local execution form web app
> I apologise if this is off-topic-ish, but I would like a general opinion.
>
> I am currently working with a web application that is being developed for
> sale to customers ranging from small companies to corporates. The general
> public will not have access. One of the requirements is to be able to
> execute an arbitrary local executable from within the web app. 'Arbitrary'
> in the sense that the actual choice of executable can be configured by the
> user, the idea that a customer can configure the app to launch some local
> process as part of some action he has taken within the application. The
> configuration can be locked down by the user (eg customer sysadmin) and for
> the most part will be used on an intranet.
>
> A typical use case is to configure the web app to download a text file (say
> some auto-generated report) from the web server and open it in a local text
> editor - but there are no limits on what the local application could  be.
>
> My instincts are that this will meet with resistance from sysadmins,
> corporates in particular, for security reasons, but then again logic tells
> me that on an intranet and given the ability to lock down the configuration
> so local users cannot tinker with it, this isn't a security issue in the
> first place.
>
> Are there any 'sysadmins' out there who can give me their views on whether
> I
> am seeing a problem where one doesn't exist, or are my instincts right?
>
> TIA
>
> Neil.
>
>
>
> ---------- Forwarded message ----------
> From: Simon Heywood <simon at triv.org.uk>
> To: sclug at sclug.org.uk
> Date: Mon, 7 Jun 2010 10:00:02 +0100 (BST)
> Subject: [sclug] SCLUG meeting this Wednesday 9th June at 19:30
> The next meeting of the SCLUG will be at the Back of Beyond pub in
> King's Road, Reading, at 19:30 this Wednesday.
>
> See http://www.sclug.org.uk/ for directions.
>
>
>
> ---------- Forwarded message ----------
> From: Neil Brown <neil at neilzone.co.uk>
> To: haughtonomous at googlemail.com
> Date: Mon, 07 Jun 2010 10:05:42 +0100
> Subject: Re: [sclug] Local execution form web app
> Quoting Neil Haughton <haughtonomous at googlemail.com>:
>
>
>   'Arbitrary'
>> in the sense that the actual choice of executable can be configured by the
>> user, the idea that a customer can configure the app to launch some local
>> process
>>
>
>
> If the customer (i.e. the corporate) can define which applications are
> launched, then, the end users can only (absent a bug) launch applications
> which the environment owner provides for them to launch.
>
> The end user launches a pre-defined application, and so, whilst not a
> sysadmin, this seems no different to clicking a icon on a desktop, which was
> pre-installed by the company for them to use?
>
> --
>
>
>
> Neil
>
> neil at neilzone.co.uk | http://neilzone.co.uk
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Tim Sutton <tim at linfiniti.com>
> To: haughtonomous at googlemail.com
> Date: Mon, 7 Jun 2010 11:06:08 +0200
> Subject: Re: [sclug] Local execution form web app
> Hi
>
> On Mon, Jun 7, 2010 at 10:58 AM, Neil Haughton
> <haughtonomous at googlemail.com> wrote:
> > I apologise if this is off-topic-ish, but I would like a general opinion.
> >
> > I am currently working with a web application that is being developed for
> > sale to customers ranging from small companies to corporates. The general
> > public will not have access. One of the requirements is to be able to
> > execute an arbitrary local executable from within the web app.
> 'Arbitrary'
> > in the sense that the actual choice of executable can be configured by
> the
> > user, the idea that a customer can configure the app to launch some local
> > process as part of some action he has taken within the application. The
> > configuration can be locked down by the user (eg customer sysadmin) and
> for
> > the most part will be used on an intranet.
> >
> > A typical use case is to configure the web app to download a text file
> (say
> > some auto-generated report) from the web server and open it in a local
> text
> > editor - but there are no limits on what the local application could  be.
> >
>
> I thought that an integral part of browser design was to prevent the
> arbitrary execution of local apps from within the browser context? I
> think you can do it using evil microsoft activex technologies but not
> from a standard javascript / applet context....or am I wrong?
>
> Regards
>
> Tim
>
>
> > My instincts are that this will meet with resistance from sysadmins,
> > corporates in particular, for security reasons, but then again logic
> tells
> > me that on an intranet and given the ability to lock down the
> configuration
> > so local users cannot tinker with it, this isn't a security issue in the
> > first place.
> >
> > Are there any 'sysadmins' out there who can give me their views on
> whether I
> > am seeing a problem where one doesn't exist, or are my instincts right?
> >
> > TIA
> >
> > Neil.
> >
>
>
>
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==============================================
> Visit http://linfiniti.com to find out about:
>  * QGIS programming services
>  * Mapserver and PostGIS based hosting plans
>  * FOSS Consulting Services
> Skype: timlinux Irc: timlinux on #qgis at freenode.net
> ==============================================
>
>
>
> ---------- Forwarded message ----------
> From: Darren Davison <darren at davisononline.org>
> To: sclug at sclug.org.uk
> Date: Mon, 7 Jun 2010 10:33:30 +0100
> Subject: Re: [sclug] Local execution form web app
> On Mon, Jun 07, 2010 at 09:58:48AM +0100, Neil Haughton wrote:
> > A typical use case is to configure the web app to download a text file
> (say
> > some auto-generated report) from the web server and open it in a local
> text
> > editor - but there are no limits on what the local application could  be.
>
> erm, isn't this exactly what most browsers do out of the box? i.e. enable
> you to configure apps to launch to handle certain downloads?  Personally I
> have OpenOffice launch to handle a .doc file I d/l, or gvim to handle a
> .txt
> file etc. etc.
>
>
> --
> Darren Davison
> Public Key: 0xE855B3EA
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEUEARECAAYFAkwMvOkACgkQVgOfSOhVs+pgeQCgjfrerY8cpQ2It+Y+wa7VN6SH
> DFMAljGF1CMpUzSzxvzWYe6Xo/ksL2s=
> =3X2J
> -----END PGP SIGNATURE-----
>
>
> ---------- Forwarded message ----------
> From: simon at spudley.com
> To: sclug at sclug.org.uk
> Date: Mon, 07 Jun 2010 10:13:12 +0100
> Subject: Re: [sclug] Local execution form web app
>
>
> You wrote:
> > A typical use case is to configure the web app to download a text file
> (say
> > some auto-generated report) from the web server and open it in a local
> text
> > editor - but there are no limits on what the local application could  be.
>
> On a conceptual level, you're not asking for anything more than they
> already do -- pdf, doc, and a bunch of other file types will likely already
> be configured by the users' browsers to do exactly the sort of thing you're
> proposing. All you're asking for is an arbrtrary new file type to be
> configured in the browser along the same lines.
>
> Unless it's a file type with known security issues like .exe or .scr,
> there's no reason for a sysadmin to particularly want to block the file type
> from being downloaded, especially in a local intranet context (an external
> block may still be reasonable, but that's not an issue for you).
>
> The security risk will be in what program you specify to open the files
> with, and what that program does with files that it opens. But since that's
> entirely configurable at the client end, it's outside your realm.
>
> All your web app needs to do is present the file for download, and leave it
> up to the browser how to handle it.
>
> You'll never have a 100% smooth "click on the link and open the program",
> because the browser will always offer to open the file or download it, but
> users are used to that functionality already so it should be good enough.
>
> HTH.
>
>
>   Simon C.
>
>
>
>
> _______________________________________________
> sclug mailing list
> sclug at sclug.org.uk
> http://sclug.org.uk/mailman/listinfo/sclug
>



More information about the Sclug mailing list