Two new discussion forums have been announced by the CIGS team.



Using CAT.NET Code Analysis Tool

by agrace 22. February 2009 09:52

The Code Analysis Tool (CAT.NET) v1 CTP came out last December and I have been meaning to try it out. There is a 32-bit Visual Studio plug-in version available, although there appears to be some issues with it at this point in time. If you are running a 64-bit machine then you can grab a 64-bit command line version - this version does not suffer from the same limitations as the 32-bit version.

CAT.NET is a static, as opposed to runtime tool. It looks at the assemblies in your project and traces the information flow from start to finish. You then get a report of what it finds in XML and HTML format. I ran it on an application I developed and located two potential XSS vulnerabilities in a library I obtained from another vendor.

CAT.NET Code Analysis Tool


This is an incredibly simple tool to use and I cannot think of any excuse not to take a few moments to run it on an application prior to going live. Think of it as one extra layer of safety.

CAT.NET Code Analysis Tool Result


Currently, it check for the following vulnerabilities:

* Cross Site Scripting
* SQL Injection
* Process Command Injection
* File Canonicalization
* Exception Information
* LDAP Injection
* XPATH Injection
* Redirection to User Controlled Site

This tool and others, such as the Anti-Cross Site Scripting Library, are developed by the Connected Information Security Group (CIGS) at Microsoft. It's definitely worth your while to check out the CIGS Team blog.

Helpful Resources:

* Cross-Site Request Forgeries and You
* How to Prevent Cross-Site Scripting in ASP.NET
* How to Protect from Injection Attacks in ASP.NET

ASP.NET Data Input Validation

by admin 1. November 2008 18:18

Data Input I'm no security expert, and as such, I think I'm a member of an ever-growing group of Web developers who fly by the seat of their pants when it comes to the security of their Web forms. As an ASP.NET developer I have had a tendency to presume that the framework is going to insulate me from most of the "nuts and bolts stuff". Of course this is not the kind of beneficial abstraction that frameworks were meant to provide us with. It is up to each of us to take responsibility for the code we create. Testing, even when it is carried out, shouldn't stop as soon as we find out that our code "is working". There needs to be some baseline better practise for creating everyday Web forms other than relying on ValidateRequest being set to true.

Recently I published a post entitled 500,000 SQL Injection Attacks. The half a million attacks actually occurred in a single week. This is mind boggling. A lot of the attacks targeted older ASP sites and I was surprised at how much of this old code was still out there. What surprised me most was how many idiots were out there calling themselves developers, not to mention the bottom-line execs who hired them in the first place. That 500,000 sites were attacked in a single week should be telling us something. We need more qualified programmers in the industry and we need the education system to introduce students to the World of IT that they are going to be living in.

Most security holes are created by developers with little understanding of security issues. These security holes are then exploited by hackers who understand these security issues only too well. It's a lethal recipe. Developers need to understand what it is they have to protect against and how to go about doing it. The tools and guidance for creating safer Web forms are available to us right now if we know where to look.

From a security point of view, our Web forms are naked and 100% vulnerable. We need to look at all the ways data is passed to them and test as appropriate:

    * Form Fields
    * URL Query Strings
    * Cookies
    * Database
    * ViewState

The most prevalent forms of attack seem to be Script Injection, Cross Site Scripting and SQL Injection. As for SQL Injection, this can be mitigated against by using parameterized queries. It is the act of parameterizing the database queries that make stored procedures so resilient to attack. The other forms of script attack can be handled by downloading and using the Microsoft Anti-Cross Site Scripting Library in your Web application projects.

A best practise would consist of the use of this library in conjunction with proper data validation (validators) and filtering (regular expressions). If you have existing code which you know is vulnerable you can still use tools to inspect your code and then you can implement the necessary protection measures where needed.

On the MSDN Code Gallery, there is a complete ASP.NET 2.0 Reference Security Implementation which you can download and explore. It was created in VS 2005 and includes an installer. This is a very helpful resource to answer any questions you may have. Note: you must have VS 2005 installed for this to work.

I've saved the best news for last :-) The Microsoft CIGS (Connected Information Security Group) are working on the new Security Runtime Engine. It is a HTTP module which will provide protection against the most common Web application security vulnerabilities, including Cross Site Scripting. The CIGS group are currently testing it and the beta should be available shortly.