Over the past few months, I have had a number of discussions with clients at open forums relating to software vulnerabilities, and what can be done for long-term protection or risk management. A point often made by participants is that "our biggest concern is that Microsoft's software is full of security holes," closely followed by "why can't they just write secure code?"

From my perspective, there are a large number of vulnerabilities with the Microsoft products that my clients operate in critical areas which can be successfully exploited if the hosts have not been properly hardened or fully patched.

Without sounding as if I am standing on a soap-box, I have to question the legitimacy of the Microsoft bashing. Having access to a dedicated security research team who break software as a day job, Microsoft's software actually fares pretty well in comparison to most of the commercial, "off-the-shelf" software we assess. It just tends to be much bigger and more complex, so the opportunity for finding "something" tends to be greater. But then again, the size and complexity is driven by the inclusion of advanced features – features that make it popular with Microsoft's customers.

I like to point out that, for all of Microsoft's published flaws, people should realize that it actually goes to considerable lengths to train its developers in how to code securely, implement and police secure coding policies, and is generally a very security conscious company. I then have to question what lengths their own organization goes to securing their internally developed software. In most cases, they would be lucky to have sent a team of developers on a C++ course within the previous six months, let alone given them any training on secure coding practices.

If, through all this, security flaws still make it into Microsoft's commercial software, why do they think that the security of their in-house developed software is any better?

This is certainly borne out during onsite penetration tests or security assessments against environments that include newly developed corporate applications. Without doubt, the easiest way to compromise data integrity and access restricted information is through those applications the client has developed themselves.

Many of the findings can be attributed to a lack of basic knowledge about application security, or understanding of modern attack vectors.

The most common vulnerabilities include storing confidential information locally on the client (caching user login credentials, offline copies of customer address details, detailed transactional logs and debug files, and so on), using clear-text communication protocols for login and validation purposes, depositing and retrieving critical data files from public shares, and a reliance on client-side data validation.

While I hope the message is getting through to corporate organizations that client-side content checking in web-based applications provides absolutely no security to the application, the message has so far fallen on deaf ears for developers of in-house applications. In almost all cases, developers assume that the user of their software will either never attempt to subvert the client application, or will not have the technical ability to do so. Therefore, they naively believe that client-side content checking is all the security they need.

In many security assessments of internally developed compiled software, I see the same classes of vulnerabilities as I would expect to see in poorly developed web-based applications – except this time the financial impact is much greater. For instance, several recent applications have built SQL data queries from user supplied data to retrieve data from a central database. Using a standard debugger, it was possible to modify the data submissions to pull back more informative and confidential data, or even access command shells on un-hardened database servers. In one case, this was an "advanced" finding – since the application stored database DSN connection strings that were unencrypted locally, and users could create their own connections using Microsoft Access anyway.

In another assessment, client-side application logic disabled certain buttons from working if a monetary value was too high. Using standard tools within the locked-down user desktop, it was possible to write a simple "Shatter" attack to re-enable buttons as required. The absence of server-side checking meant that the high-value transactions were accepted and security (such as data integrity) was successfully breached.

So if you think that the commercial software you buy has too many security flaws, you might want to take a closer look at your own development processes first.