Geeks With Blogs
Teucer's Quiver Me && .net

Security is one of the areas which I am constantly interested in and as my work revolves around smart clients in the last few years I decided to write down this post. Many of these items described below would apply not only to smart clients but for most applications (irrespective of Web services, Server side apps, alike). I don't consider myself a strong SQL developer hence I am not comfortable right now to post such security considerations for SQL code. May be some day later. Do note that these items are in no order of priority considering that one or more than one of these items could threaten the application's credibility. So lets get started...

Never ship something which you are not using
Most of us have done this before and whether we admit or not there is a security risk involved in shipping something with your app which is not used by your application. Items include sample code for one of those components which your app uses, Debug files, test harness assemblies. The last thing you know your app was safe until someone found a vulnerability with that additional file you shipped and which is going to tarnish the repute of your app and mandate a hotfix. Don't build them or ensure that they are removed after install or during an update if you have already shipped one.

Common sense dictates that the more services available on a server, the greater the opportunities for possible attack. Thus, a minimalist approach can be a positive security action. Remove unneeded files and components from your app.

Turn on integer overflow and underflow checks
Buffer overflows have been a traditional attack vector for almost all types of apps (including web apps). A detailed description of what attack patterns exist have been summarized by Michael Howard in this MSDN article. Visual Studio C# environment can check for integer overflows and underflows and cause a run-time exception instead of continuing execution with incorrect data. However, by default these checks are turned off (I am yet to figure out why). So set the CheckForOverflowUnderflow element to true in the .csproj file or otherwise using the project properties page. "Properties -> Build Tab -> Advanced -> Check for arithmetic overflow/underflow checkbox".

Be aware of luring attacks due to LinkDemands
So you wrote a nice neat library which does lots of good things and makes the developers life easy. It takes care of using CAS but there is a small short coming you are doing LinkDemands instead of regular Demands which makes the CLR to only walk one caller up the call stack. The malicious code may not be the immediate caller on the call stack due to which the CLR is lured into performing an operation without adequate trust from the original caller.

Some practices for LinkDemands are listed below.
1. Don't use them unless absolutely necessary. Be defensive rather than reactive for an exploit to be isolated and reported.
2. If you do not know the list of callers for the trusted assembly then do not use LinkDemands.
3. If you are developing an API which in turn is going to call another method which is marked with a LinkDemand ensure that you enforce adequate checks so that calls of your API can be trusted or do not malicious intent.
4. LinkDemands are attributes applied only to that class method so in case your method marked with a LinkDemand is going to be overridden in a derived class then ensure to decorate that override with a LinkDemand too.
5. Use the right access specifier for your class and method in which you are doing LinkDemands. It would be useless to mark a method with a LinkDemand if the class is internal or the method is private.


Don't store private public key pairs (Strong Name keys) as part of the source repository (better use Delay signing)
Well you strong name your assembly which is one level of security or authenticity of your assembly. Well Done but where and how do you store your strong name keys? From a development perspective if you consider your application assemblies as assets of your application then the strong name keys used to mark the validity of your assembly is a secret which should not be shared with anybody else outside the development team. Some one who could get their hands on the app source code and could potentially build a malicious assembly with the same name and authenticity and ship the binary. Its easy to spot whether an .snk file has both the private public keypair together; the key pair size is 596 bytes and public key alone is 160 bytes. Ok I understand the issue what do we do? Well don't keep the private and public keys together in one .snk file. Or use different keys during "dev & test" & another for the production version. One of the approaches which I had implemented for our app is to keep the public,private key file in a secure share and marked the AssemblyInfo.cs file to locate the file from that file share. The file share is accessible only to people who are part of a security group which is of course only members of our development team. Even if you get hold of the app code you cannot build the app unless you have access to that share.

Shawn Farkas blog contains a lot of posts regarding the subject of strong names and assemblies.

Sign your documents (which contain code)

IMHO Infopath was the most unpopular tool in the Office suite in Office 2003 but with Infopath 2007 it is the killer front end in my opinion. Having worked for the web and been constantly working on smart clients I always wanted a way to present the same UI for both web and desktop apps. Infopath 2007 is probably the only application in my knowledge which can be used by information workers today to build such UI. Infopath docs with the Office Forms Server allow rendering Infopath forms in the native Infopath application or otherwise accessible from the browser on machine which do not have the Infopath application installed. One consistent UI for both the web and the desktop. Super Cool isn't XAML is still not yet there to the masses where a day to day office user could build his/her own data entry form from scratch without much programming knowledge. Now to the issue in hand.

Infopath Templates must be signed, as they contains script code which gets downloaded to the clients machine, which is similar to the excel file with macros.The Infopath file downloaded by the client if replaced by an attacker with another malicious file, there is no way the client would be knowing that he is using the malicious file. If the file is code signed, then the certificate would be prompted to the user to prove the genuinity of the file and that it belongs to the issuer(in this case your app or corpwide certificate). This would make sure that the file is not tampered and it is provided by the legitimate party which can be trusted by the client who is invoking it.

Well I gotta go now and have a huge list of items which I plan to write more in the coming days. I just updated this post title with a "I"... and I anticipate at least 3-4 more parts. Do keep posting your comments in case you are interested to discuss more on these areas.

Posted on Saturday, November 18, 2006 7:29 PM Technical | Back to top

Comments on this post: Security considerations for smart client applications - I

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Tameem Ansari | Powered by: