Developing code with .NET is hard enough without worrying about security. This means that most developers take the easy way out and assume that their code will execute in a fully trusted environment.
Stories by Don Kiely
If you aren't using Web services yet, there's a good chance that you will in the near future, whether you intend to or not. More tools are appearing every day to make such services easy to develop and use, led by Microsoft's flagship Visual Studio.NET. Web services are one of a long line of Web technologies that has yet to prove itself in the real world, but there is plenty of momentum behind them already.
Recently I spoke with Scott Culp of the Microsoft Security Response Center (MSRC). It was hard not to be impressed by the (MSRC) dedication to fixing its products. No matter what you think of Microsoft, an awful lot of very smart, very dedicated people work there. I think I found just such a group in MSRC.
Because XML is proliferating applications both on the Internet and the workstation, there are many initiatives under way to apply security technologies to XML data. This week I'll begin with a look at XML Signature.
The hottest buzzword on the Web these days is Web services. (As evidence, Google today had almost 2 million hits on that phrase.) The promise of Web services is wonderful: cross-platform object and method invocation that makes the Internet one, big, componentized software application. It's nowhere that simple of course, but it certainly opens up plenty of new ways to build distributed applications.
Last week, I provided an overview of the security zones built into Internet Explorer 6 -- and making their way into other Microsoft products -- as well as their default security settings. In that discussion, I mentioned the security templates that provide the default settings for each zone.
Internet Explorer has distinguished between different security zones for a couple of versions now, letting users and admins set a policy establishing a degree of trust for specific sites. Each URL security zone has a set of URL actions with a URL policy assigned to each action. The URL actions cover all operations that have security implications. A URL policy is assigned to each URL action to determine how that URL action will be handled.
Evidence abounds that Microsoft is bloody tired of taking the hit for all the world's security problems, and evidence of that continues to appear in new products it ships. One of the areas where it has been hit hardest is in scripting, both through email and its built-in support for scripting through the Windows Scripting Host (WSH). Far too many viruses have been unleashed through those innocent looking .vbs and .js files, but Microsoft is fighting back.
As I discussed a few weeks back, Microsoft has publicly gotten the security religion. No doubt, there is a new emphasis on security in its products, but the results have been mixed so far. Only time will tell if it is sufficient and whether they truly "get it."
Last week I described an attack on databases that is becoming popular with the cracker crowd, SQL Injection Attacks. Fortunately, as scary as these attacks can be, there are some basic preventive measures you can take. It requires that developers and DBAs talk and work together, something that isn't always an easy accomplishment in some shops!
There is a not so new attack increasingly making the rounds these days, popularly called SQL injection attacks. Any relational database connected to the network is theoretically susceptible, regardless of operating system or database engine. Perhaps worse, it is one that developers and DBAs have to set aside their rivalries in order to reliably protect against.
How to reliably and safely store data associated with a chunk of executing code persistently troubles secure computing in the Windows world. Giving the code permission to read or write disk files is risky -- even the controlled environments of Web browser cookies have exposed risks -- and allowing access to the Windows registry exposes yet another set of risks. So the choice largely has been between limiting benefits to the code's user in the name of safety or giving even friendly code carte blanche access to a system.