Re: Embedding Simple MFC GUI app into website
- From: "Pete Delgado" <Peter.Delgado@xxxxxxxxx>
- Date: Tue, 3 Oct 2006 11:35:12 -0400
"Daniel James" <wastebasket@xxxxxxxxxxxxxxxx> wrote in message
news:VA.00000f12.12d67418@xxxxxxxxxxxxxxxxxxx
In article news:<uU8f6Mk5GHA.400@xxxxxxxxxxxxxxxxxxxx>, Pete Delgado
wrote:
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.
Whilst I understand what you're saying, I don't think Joe is overreacting
in
his denouncement of ActiveX and Java (and Flash, though he didn't mention
that one this time around) as technologies for the public internet (as
opposed to private, corporate networks).
I suppose that only the original poster knows whether the question pertains
to the public internet or a corporate intranet. However, as I stated
earlier, using alarmist language serves no purpose but to confuse and cloud
the issue and stops us from thinking about the problem in a rational manner.
ActiveX, in particular, is an antipattern for security. No amount of
code-signing and certificate checking will ever make up for the fact that
allowing ActiveX controls in your web browser is an open invitation to
malware writers and system crackers to run just whatever they want on your
computer.
The *whole* point of signing code is to ensure that you are able to
determine the origin of the code in question and that it has not been
tampered with since it ws signed. Once the origin of the code has been
determined, *you* decide whether to allow it to run on your system. If you
are indescreet, then you get what you deserve!
Since you must obtain a certificate for code signing from the trusted
authority, it is unlikely that a "cracker" will obtain a valid certificate
from a trusted authority that names a reputable company that a user would be
likely to trust, hence your argument that this is an open invitation to
malware writers and system crackers is misleading at best.
As a side note, we have had more systems compromised by people downloading
and installing the latest screen saver or opening word documents than we
have had by using web sites that contained ActiveX controls.
In my opinion Microsoft was irresponsible in the extreme by ever spawning
this hateful technology, and has done computer users all over the world an
incalculable disservice ...
I disagree. The technology was an effort for Microsoft to compete in a
space that was once dominated by Java. The technology has been useful -if
only for intranet applications. Certainly there are security reasons not to
use it for a general purpose web site as we have all discussed, but one
cannot deny that the technology filled a need at the time of its
introduction and can still play a role, however small, today.
but it all happened years ago, when Microsoft's
mantra was "make everything just happen for the user, with the minimum
effort" and the security issues that we now see every day were
undreamed-of.
I recall that Sun "dreamed" of most of the security issues with ActiveX and
agressively touted them as reasons to choose Java over any of the Microsoft
technologies. Interestingly, the JVM has had many security issues with its
"sandbox" technology over the same period.
In addition, if your firewall is stripping out ActiveX controls, then how
are you using Windows Update?
You can't. Microsoft are compounding their error by insisting that
everyone
make their system insecure in order to obtain security updates.
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?
That's a good point: we shouldn't allow ourselves to be complacent because
we think we aren't allowing downloaded software to run. Buffer overflows
and
similar exploits can still make that a possibility.
Correct. As long as you are connected or other have access to your
computer, there will always be the potential of a security breach.
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".
That a certificate has been issued by a well-known authority is not always
an adequate guarantee. The certificate must have been issued for the
purpose
for which it is being used (code-signing) and it must be certified to a
sufficiently high level. Verisign offer certification to a high level, at
high cost, but they also sell cheap certificates that guarantee very
little.
At the end of the day a certificate only guarantees the identity of the
party that signed the code.
*Exactly*. Then *you* decide whether the "FlounderCraft Software" ActiveX
control should be downloaded and installed on your computer. (Sorry Joe, I
couldn't resist!)
You also have to decide whether you trust that
party not to compromise your machine. I suspect most people would have
trusted a Verisign-signed code-signing certificate in the name of Sony,
but
Sony was responsible for distributing a (unsigned, as it happens) rootkit
on
audio CDs a while back.
Your point is taken, but since the Sony rootkit was installed from a CDROM
and was installed as a result of an autoplay executable, it is really not in
the same category. Unless you have configured your system to always install
ActiveX controls, the browser will warn you before installing the control.
The Autoplay rootkit executable from Sony offered no such option -which is
one of the things that made it such a breach of trust and why Mark
Russinovich rallied against it.
Google for the much-publicized phish attack in which an American bank
called
Mountain America Credit Union was spoofed by a hacker using a genuine SSL
certificate he had obtained in the name of mountain-america.net from
Equifax
(part of Geotrust, normally regarded as a reputable CA). The bank's real
domain name (AFAIK, don't take my word for this) is not
mountain-america.net
but mtnamerica.org ... but how is the average phishing victim at home
supposed to know that?
Again, your point is taken, but I don't hear you or Joe decry DNS, SSL or
any other web technology! If an authority, certificate or identity is
compromised, all bets are off for *all* web technologies that deal with
identity -not just ActiveX.
Ask yourself what would happen if your local DNS server started directing
you to phishing sites even though you were entering the correct URL or ip
address. Then ask yourself what would happen if the ICANN servers were
hacked (it's happened) to direct *all* users to phishing sites? Aren't both
your local DNS server and the ICANN servers examples of trusted authorities?
Does this mean that we abandon the internet and computers because the
potential risks are too great? For some people, that is the right answer,
but for the majority of us the level of risk is acceptable given the
potential rewards.
In the specific example that you cite, it was unfortunate that the customers
went to the wrong web site that had a similar URL, but IMHO this is the
fault of the customer for entering the wrong URL and the bank for not
communicating the correct URL.
One web site that I access has given me a smart card reader along with a
card that contains the URL of the site and my credentials. When I insert
the reader and card I am directed to the company web site with no need to
log in. Certainly this is a more secure process, but it too is subject to
the DNS flaw I described above.
The point is that we can minimize our risks because of the internet, but we
can never eliminate them unless we plan to go back to doing business in
person. At that point, we become subject to other risks such as being
robbed etc.
-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
- From: jeremyje
- 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: Daniel James
- Embedding Simple MFC GUI app into website
- Prev by Date: Re: Changed behavior of ::SHFileOperation() in Vista
- Next by Date: Re: Debuging A MFC project Highily multithreaded and Realtime
- Previous by thread: Re: Embedding Simple MFC GUI app into website
- Next by thread: Re: Embedding Simple MFC GUI app into website
- Index(es):
Relevant Pages
|
|