I was having a discussion with Eric Nelson on his blog the other day. I was having a rant about requirements, which I think is one of the most vital aspects of software today.

For instance, I've been told by a number of developers that MVC is the 'correct' way to develop a web application. However, I disagree strongly with this.

I don't doubt that Model View Controller is very useful for certain applications. It is a valid design pattern for solving certain problems.

However, it's not 'the correct' way to develop a web application. The only thing that is correct is the requirements. If you use MVC, and it either hinders achieving the requirements, or it adds nothing to those requirements, than MVC is not the correct design pattern to follow. Simple as that.

There have been similar patterns used in security that added no value. I worked on a project three years ago that used WS-Security, because it was the latest 'cool thing'. At the end of the day, it added no value, as SSL matched the security requirements more efficiently.

So, when should you use WS-Security? I wrote an article recently that is on the MSDN Developer Security page.

The article matches requirements to technologies, and has been used by various clients as I was writing it. I hope you find it useful.

Data access moves on - LINQ for SQL and other technologies such as Hibernate can allow data access logic to be moved out of the database and into the application tier. Those of us with a dba background may recoil in horror, but I'm starting to accept that we have a new paradigm here, and we have to adjust.

 

There are mixed feelings – how can database access be tuned if the queries are taken away from the database? I don’t mean execution plans here (DLINQ is quite efficient in that respect), but rather implementation of proper indexes. If you don’t index properly, your million dollar SQL cluster scales down to a very expensive version of Access 2.0.

 

What happens when you have locking problems? A DBA can ensure that stored procs always access tables in the correct order. That dba won’t be able to look into your code.

 

In any case, the move is being made, and it’s proper to accept that we have to make the new paradigm work, rather than argue against it. The solution is to find new practices and patterns to allow this to work.

 

So, we move on to security. The traditional model, using stored procedures within the database, offers the following security advantages:

Defence against sql injection attacks – using command parameters prevents execution of rogue sql strings

 

Least privilege and segregation of duties are enforced at a more granular level

 

Table level permissions do not have to be granted

Granting execute permissions to stored procedures means that the security model is that of allowing exactly the access we wish to grant. Compare this to the execution of dynamic sql, where we have to validate against every possible attack that might occur.

 

How secure is LINQ to SQL? An article by Jason Schmitt demonstrates the parameterized queries created by the LINQ infrastructure can prevent SQL injection. Use of the sp_executesql command certainly prevents injection attacks of this type.

 

What about the granting of CRUD access to tables within the database? Well, here’s an issue.

 

The role based security at the database boundary breaks down. We lose some granularity of least privilege and separation of duties as we access the server.

 

Granting correct table/column access directly to tables becomes incredibly complex when you have more than perhaps three roles. The greater the complexity, the more prone to error your security strategy is.

 

Sprocs allow access to be restricted to certain rows, via joins and where clauses. Table access doesn't do this. Although you can restrict which rows you access in your LINQ code, you've lost that security granularity at the database server level. What if an internal user downloads the SQL utilities to his/her desktop?

 

There’s a way to work with this.

 

It seems that flowing the security context is probably going to be ruled out in applications that use LINQ to SQL. To have the flexibility to allow developers to put data access logic within the code, a fair few table permissions would be required.

 

A rogue user downloading, say, the SQL Management tools would be able to disrupt database activities due to the security barrier at the database server being relaxed.

 

What about a trusted subsystem approach? Database access would be restricted to an application, and the application would have to enforce the appropriate access to tables. This would mean granting the necessary access to a role that the application service account belongs to. And don’t think that means you can put the account into the dbo role!

 

This is the security context in which many web apps work, and is not exactly rocket science. It’s quite effective.

 

However, it will mean a change for Windows Forms apps that run in the context of the logged on user. You may have to write a component running in a separate process on the database server to handle data access, rather than just use the SQL provider to access directly. The Windows app would then access the component, perhaps via a web service. The Windows front end would stay dumb.

 

At the moment, this is more of a ‘thoughts of Chairman Chris’ rant, but perhaps it’s the seed of so far unwritten best practice. Please give me your thoughts, and perhaps we can achieve something more solid.

I'm just about to do my talk at the Barbican, so I figured I'd better get the slides onto my blog ready for everyone to download.

If you've just seen the presentation, I hope you enjoyed it.

PS. Code from the talk is now attached to this post also.

What do you do if your application has been developed using FullTrust, but you now find that it is necessary to move it to partial trust?

This could arise from a risk assessment that requires mitigation against code injection attacks. An example of such an attack would be to insert a web page into an Asp.Net application using sql injection, although there are many other vectors that could get bad (malicious or poorly written) code onto a web server.

So, after all the development and testing that's taken place, you find that altering the <trust /> element from Full to, say, Medium stops the application working. Perhaps it's so bad that you don't even get a detailed error message - just a line saying that the application requires more permissions than are granted by the security policy.

Well, I've had to move applications to partial trust for a number of clients. The basic guide is that you must try to make your .aspx pages as dumb as possible.

This means that Asp.Net pages should only contain code that relates to the user interface. Anything else (that accesses server resources such as files or a database etc.) should be moved to assemblies. Place these assemblies into the GAC, so that they have full trust.

Next, create a business facade layer. A business facade roughly corresponds to use case diagrams for your system. The facade exposes methods that embody all interaction between the user and the system. Place this code into the GAC also.

The facade methods will have Assert statements that stop the stack walk progressing further. This means that your web app won't be stopped by CAS Demands due to the lower trust level.

Create a custom permission. Make demands for this permission within the business facade methods (remember - always combine an Assert with a Demand to ensure that the component is not being called by bad code or the wrong application).

Now add the custom permission to the Asp.Net permission set for the web application in the security config file. This ensures that only this web app can call the business facade, rather than another web app or web service on the same server.

You've now got a situation where CAS will only allow a specified web app to call the business facade. Supposing malicious code is placed onto the server, it can only call the business facade methods, which should not really let it do much more than use the intended system functionality anyway.

If you've cut down the permissions declared in the Asp.Net permission set, then other server resources are locked down so that they can't be called directly by malicious code in this web app.

Although CAS can be applied in different ways, this pattern fits with the advice in the 'Improving Web Application Security' document created by Patterns and Practices.

I'm writing a fuller explanation of this for Paul Maher's 'Tales of an Evangelist' on MSDN, and would welcome comments from anyone who has been in a similar situation. The final article will also have some rough metrics of how long it takes to implement, as well as covering some of the trickier aspects of what goes in the ASP.Net permission set.

Working on a very large SharePoint project earlier this year, I had to recommend where to install assemblies. Looking at the available SharePoint documentation, it seems that there are two choices:
In the /bin directory;
In the GAC.

However, digging deeper, it turned out that the issue was more complex.   more »

Here is the code and slides for the VBUG talk I gave last night on Code Access Security.

Lots of boilerplate stuff, including a custom permission.   more »

It's a common misconception that querystrings are not protected by SSL. Many developers go to great lengths to protect the data (encrypting the contents, POSTing a form instead) because they think that a network monitor can pick up the querystring data.

This is actually a misconception. SSL strips the querystring off and places it into the encrypted data block.

Nobody can then see your querystring data.

Here are some references:

http://www.owasp.org/documentation/appsec_faq.html
http://www.ourshop.com/resources/ssl_step1.html
http://msdn.microsoft.com/chats/transcripts/net/vstudio_030702.aspx

The real reason for avoiding placing information in the querystring is that it's easier for the logged on user to hack the querystring. Also, if you send someone a link to a page, then it's also possible that you're sending them some personal information (if that web site wasn't developed with security in mind).

There's a useful discussion here:

http://blogs.msdn.com/cjacks/archive/2005/08/31/458571.aspx   more »

I contribute to a number of forums, answering questions (my username is oldbear). On all of these forums, there are many posts asking questions on communicating with SQL Server, and the same answers are always needed. I thought I'd put something down here for good practice, and then refer people from the forums to this article. In the meantime, anyone who disagrees can add a comment below. Here we go.   more »