Spyware Sucks
“There is no magic fairy dust protecting Macs" – Dai Zovi, author of “The Mac Hacker’s Handbook"

Developing Safer ActiveX Controls Using the Sitelock TemplateDeveloping Safer ActiveX Controls Using the Sitelock Template

September 18th 2007 in Uncategorized

The IE team have blogged about the release of a new version of the SiteLock Template for ActiveX Controls.  I can’t stress strongly enough how important it is that developers place security first when developing controls. 

Over the years there have been numerous instances where ActiveX controls have exposed a vulnerability that has been exploited by the bad guys, including controls that were never meant to be used on the internet per se.  IE7 addressed this problem by disabling many pre-installed activex controls, making them inaccessible to Web pages without user permission and interaction.  Microsoft, in conjunction with control developers, have at various times, released killbits to stop controls that were never meant to be used by IE from being used nefariously.  But, such steps do not relieve developers of their basic responsibility to code with security uppermost in their mind.

The great thing about the SiteLock Template is that it helps developers manage how their controls can be used (zone and domain name) and even allows a developer to impose a time frame for use, after which the control will no longer work.

“The Internet” has never been more dangerous than it is now for the casual web surfer and it is going to take a concerted effort by everyone to make a difference – *all* web browsers will have to continue to improve on safety (hopefully without ‘breaking the web’); those who manage sites and servers will have to be conscious of security at all times with appropriate hardware and software defences, always patching and keeping their software up to date; developers will have to take advantage of services such as the SiteLock Template to guard against misuse of their products, and users have to take responsibility for their own safety by patching and updating software, practising safe-hex and not taking silly risks.

Far too often a web site is compromised because the back-end software is an older, vulnerable version, or because patches are missing.  The bad guys find these vulnerable servers and have no hesitation in getting in there and taking advantage of the situation, sometimes gaining access to hundreds, if not thousands, of sites in one fell swoop.  The people who own such servers bear first responsibility for allowing such a situation to develop in the first place, but their clients must also shoulder some responsibility for not educating themselves about the services and software they are using, or failing to make the sometimes financially detrimental decision to go elsewhere if their host will not clean up their act.

Far too often a user is infected because they haven’t patched, or they haven’t installed the latest version of their web browser or other software exposed to “the internet”, or because they’re turned off inbuilt protections or lowered their browser’s security settings.

I miss the old days when internet dangers were pretty much restricted to attachments on email and risky behaviour such as surfing to porn sites or downloading warez, and removing adware or malware was simply a matter of deleting a few files and registry keys.  Nowadays, any web site at any time could potentially present a risk to a visitor – whether it be because of hacking, or malicious advertising.  And some malware is so difficult to remove, and the risk it presents to user security so grave, that reformatting is the only way to guarantee that nothing nasty has been left lying around.

Be careful out there gang.  Don’t just use Windows Update – switch over to using Microsoft Update which will cover not only the operating system but other Microsoft software such as the Office suite – if you use a third party web browser update it.  If you use QuickTime, or Flash, or Java, or whatever else, update it.  Any piece of software that touches the internet is a potential risk that must be managed.


Comments are closed.

On a computer that has Windows Internet Explorer 7 installed, you may be unable to use an FTP application to upload a file to a remote server.
This problem occurs if the application is based on WinINet FTP functions.
This problem occurs because of an access violation that is caused by the InternetWriteFile WinINet API function.
When you […]

Previous Entry

As noted here, a vulnerability involving Firefox and QuickTime was reported, and code advising how to take advantage of that vulnerability has been published.
As noted by Mozilla, “Disabling JavaScript in the browser does not protect against this attack; in vulnerable versions scripts passed through the -chrome option would be executed regardless of the JavaScript setting […]

Next Entry