Re: Embedding Simple MFC GUI app into website
- From: "Pete Delgado" <Peter.Delgado@xxxxxxxxx>
- Date: Mon, 9 Oct 2006 14:17:06 -0400
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:6rpai2hjbh7gvq49do2jbsmhoqk0j8rrbr@xxxxxxxxxx
On Mon, 2 Oct 2006 12:53:50 -0400, "Pete Delgado"
<Peter.Delgado@xxxxxxxxx> wrote:
Comments inline:*****
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:d1prh2tap5l5os9ntlod77r1jr774s393t@xxxxxxxxxx
Generally, ActiveX used on Web sites should be referred to by its proper
name,
"ActiveVirus". When used on Web sites, I consider this a fundamentally
evil technology. I
have three layers of firewall that strip out all ActiveVirus and
JavaVirus
from Web sites.
Generally, you should assume you have no right to execute anything in
any
way on the end
user's machine. The unfortunate presumption that this should EVER make
sense is the
source of nearly all invasive malware.
Joe, I understand that you dislike the technologies you've listed above
and
that you have some valid points for your opinion, but to say that a
particular technology is "evil" goes beyond common sense and increases the
liklihood that your warning will be ignored as hyperbole.
In addition, if your firewall is stripping out ActiveX controls, then how
are you using Windows Update? Or perhaps you are back on UNIX? ;)
I don't use Windows Update. I will NOT use any technology that requires
ActiveVirus.
The term "evil" is carefully calculated. A technology whose main purpose
is to run
unmanaged code without restriction on a target machine is inherently evil.
Are you saying that any technology that allows you to download a native
executable is evil? FTP is thus considered evil because I can download
Visual Studio Express from Microsoft and after the code is downloaded and
run, it can do anything that it wants to my system?
At what point does the user take some responsibility for what he/she has
downloaded or allowed to exist on the computer?
It shows a
lack of any kind of responsibility. A "fix" was kludged up to use code
signing, but there
are some fascinating means of creating signed exploits.
The real problem is that a technology that can download, without my
permission, and
execute, without my control, any code from the Internet, can only be
described as "evil".
Without your permission?
I suggest that you try to download an ActiveX control from the Microsoft web
site and see what happens. Unless you have modified your configuration for
IE I believe that you will be notified that the web page wishes to load the
control.
Even the Windows Update site and the "Genuine Windows Advantage" control
will trigger IE to prompt you to accept or deny the control.
My big problem with such technologies is that the users become so accustomed
to clicking "OK" and "Accept" on the numerous security dialogs and prompts
that Windows throws at them, that they inadvertently accept controls and
downloads that they really shouldn't because they just want the dialogs to
go away.
The key here is that there is absolutely no way for me to force such code
to be sandboxed,
at least not without investing in relatively expensive third-party
products.
There are many products out there such as Virtual PC that can be used for
such purposes. Virtual PC is now free as are some of the other products.
JavaScript
and ActiveX are both technologies whose execution cannot be restricted and
sandboxed, and
in fact, are not inherently restricted or sandboxed.
That is a grossly inaccurate statement. The execution of both can be
restricted and by default are. Take a look at the help files for IE and the
various KB articles such as KB240797 for more information on how to "lock
down" IE.
most of the exploits that require security patches turn out to be
triggered by such
exploits.
There was a wave of such exploits some time ago, but it seems to me that the
majority of the exploits uncovered over the past year or so are unrelated to
either JavaScript or ActiveX. I admit though, I am too lazy to take a look
to verify my suspicion!
*****
****
Do everything server-side. That's safe.
I would say that it's *safer*. The only way to be "safe" is to not use
the
web at all! Recall the bug in the jpeg software that Microsoft patched
last
year?
Another clear example of a fundamentally incompetent design; the jpeg file
format allowed
for arbitrary code to be included. Only a committee consisting entirely
of idiots would
have allowed this design to escape. This kind of design illustrates the
complete lack of
responsibility going on right now in the world.
Joe,
Not everyone who creates a bug or writes a piece of bad code is an *idiot*.
The JPEG code was written at a time when functionality and speed were of far
greater concern than security. To hold the developers to the security
standards of today is unfair and dishonest.
Today's corporate developers often are driven by schedules and feature sets.
While I believe that the majority of the professionals working today are
fully capable of creating secure applications, the fact is that unless your
company has the luxury of unlimited time and budget, at some point
compromises have to be made. Even the best and most secure design can be
thwarted by a rushed implementation.
****
****
Note that possession of a certificate is only
barely acceptable (who verifies that the certificate was issued to a
valid
address and
not, say, to a company located on a vacant lot in the Cayman Islands?).
Which is exactly why I stated that the certificate must come from a
"well-known authority". Companies such as Verisign make their living out
of
being trusted authorities. If they don't engender trust and confidence,
they go under.
And what, exactly, does a certificate prove? It proves that Verisign
believes the company
to be legitimate. If my goal is industrial espionage, I could get a
certificate. By the
time the espionage is discovered and traced to me, I'm living in some
country without
extradition treaties. For that matter, suppose my legitimate ActiveX
control contains
code that I didn't put there? The number of workarounds to certificates
is quite large,
and I know how to do several of them.
****
A certificate proves that the trusted authority believes that you are who
you say you are *and* that the code has not been modified since it was
signed.
We could play the "what if" game all night Joe, but in the end there will
always be a certain amount of risk. The question is do you completely go
dark or do you minimize your exposure?
****
The first thing you should assume when the idea crosses your mind to use
ActiveVirus is "I
am making a fundamental error here" and proceed with that assumption as
the basis of all
decisions.
Which is why I tried to gently lead the OP in a different direction. The
security problems with ActiveX along with the fact that nobody will want
to
have to install it should leave the OP with the impression that there is
likely a better solution.
There is always a better solution.
****
Perhaps, but is there always a better solution that fits into the timeframe
and budget of your company? Is there a better, more elegant more scalable
solution or is there a duct-tape solution that eliminates one form of risk
only to introduce 10 others?
I believe that ActiveX still has a place but that in *most* cases that it is
proposed there is indeed a better, safer solution that provides the required
functionality.
-Pete
.
- Follow-Ups:
- Re: Embedding Simple MFC GUI app into website
- From: Joseph M . Newcomer
- Re: Embedding Simple MFC GUI app into website
- From: Daniel James
- Re: Embedding Simple MFC GUI app into website
- References:
- Embedding Simple MFC GUI app into website
- From: jeremyje
- Re: Embedding Simple MFC GUI app into website
- From: Pete Delgado
- Re: Embedding Simple MFC GUI app into website
- From: Joseph M . Newcomer
- Re: Embedding Simple MFC GUI app into website
- From: Pete Delgado
- Re: Embedding Simple MFC GUI app into website
- From: Joseph M . Newcomer
- Embedding Simple MFC GUI app into website
- Prev by Date: Causing OnSetExtent to be called (Or how to cause the browser's scrollbar to behave)
- Next by Date: PostMessage with WM_ENABLE to control in parent dialog
- Previous by thread: Re: Embedding Simple MFC GUI app into website
- Next by thread: Re: Embedding Simple MFC GUI app into website
- Index(es):