Martijn's BlogSpot

Mitigating cookies theft using HttpOnly

2011-10-22T09:39:00.001+02:00

Cross Side Scripting (XSS)

Cross Side Scripting is a technique that enables attackers to inject client-side script into Web pages viewed by other users. It's a computer security vulnerability typically found in Web applications. This means that a hacker would be able to insert JavaScript in a text field, say a blog post. This script would be executed by the browser, through this page, for every user that reads the post thread after it is published. The script could in turn read the current users cookie and send it to a a remote service and store is for later use.

To protect a cookie against the XSS vulnerability there is a header flag available for the “Set-Cookie” HTTP response header. This header will mitigate the risk of client side script accessing the protected cookie (if the browser supports it).

Testing the theory

To test this theory, I will demonstrate it using a test application. Our test application consists of a ASP.Net web application and some javascript. The following paragraphs explain the code in detail.

Javascript

Our test javascript will retrieve the cookie collection from the response , find our specific cookie and post the value in a paragraph.

The code blow shows our simple code that just reads the cookies from the response and displays it in a paragraph.

  1:     <script type="text/javascript">
  2: 
  3:         function getCookie(c_name) {
  4:             var i, x, y, ARRcookies = document.cookie.split(";");
  5:             for (i = 0; i < ARRcookies.length; i++) {
  6:                 x = ARRcookies[i].substr(0, ARRcookies[i].indexOf("="));
  7:                 y = ARRcookies[i].substr(ARRcookies[i].indexOf("=") + 1);
  8:                 x = x.replace(/^\s+|\s+$/g, "");
  9:                 if (x == c_name) {
 10:                     return unescape(y);
 11:                 }
 12:             }
 13:         }
 14: 
 15:         function setCookieValue(c_name) {
 16:             var username = getCookie("testcookie");
 17:             if (username != null && username != "") {
 18:                 document.getElementById('pCookieValue').innerHTML = username;
 19:             }
 20:             else {
 21:                 document.getElementById('pCookieValue').innerHTML = "Cookie not found in request";
 22:                 }
 23:             }
 24:     
 25:     </script>

ASP.Net application

Besides the JavaScript, the ASP.Net page contains the required HTML to display the cookie value.

The code in the ASPX page, used to display the cookie value is displayed below.

  1: <body onload="javascript:setCookieValue('testcookie');">
  2:     <form id="form1" runat="server">
  3:     <div>
  4:         <asp:Button ID="Button1" runat="server" Text="Button" onclick="Button1_Click" />
  5:         <p id="pCookieValue"></p>
  6:     </div>
  7:     </form>
  8: </body>

Code behind

The code behind contains the code to set the cookie value. I use IsPostBack so we see the difference between the initial request and the refresh.

  1: protected void Page_Load(object sender, EventArgs e)
  2: {
  3:     if (IsPostBack)
  4:     {
  5:         var c = Response.Cookies["testcookie"];
  6:         c.Value = "Testcookie Value";
  7:     }
  8: }

Now is we open the page in our browser we get the following response.

Remember this is the expected response, because we did not set the cookie yet. We will set it in the PostBack logic.

So, after we click the “Button” button the cookie is added to the request and the value dispayed on the screen

Addind the HttpOnly

Now we add the security code to make the cookie HttpOnly.
See the OWASP resource link below for more ways to set this flag, and also in other programming languages.

  1: protected void Page_Load(object sender, EventArgs e)
  2: {
  3:     if (IsPostBack)
  4:     {
  5:         var c = Response.Cookies["testcookie"];
  6:         c.Value = "Testcookie Value";
  7:         c.HttpOnly = true;
  8:     }
  9: }

Now when we open the page, and click the “Button” button, the cookie is set again using the HttpOnly flag. But this time the value is not displayed on the screen.

Conclusion

So, to conclude our findings. The HttpOnly flag is applied to prevent a user from accessing the cookie using client side script. A sidenote, although obvious: Keep in mind that some cookie are actually used to pass state information between requests and probably need to be accessed client side.

NOTE: Just to clearify, this does not mean that XSS is also prevented, these two are related but not the same.

Resources

The Open Web Application Security Project (OWASP)
HTTP Cookies
Cross-site scripting

Invert assignment direction in Visual Studio

2010-12-17T13:42:00.001+01:00

Ever wanted to switch the property assignments in a class, for instance in a Set_ of Get_ method.

        1: private Internal _i = new Internal()

       2:  

       3: void SetObject(Object o)

       4: {

       5:     _i.Name = o.Name;

       6: }

       7:  

       8: Object GetObject()

       9: {

      10:     Object o = new Object()

      11:     o.Name = _i.Name;

      12:     return o;

      13: }

Now, above example has only on assignment, but what if you have like 10. There is a way to do this using the build-in replace functionality.

Select the lines you want to swap, Ctrl+H, then replace:

Replace

       1: {.*}:b*=:b*{.*};

with

       1: \2 = \1;

with [Look in:] set to [Selection].

Check the [Use:] checkbox, and select [Regular expressions]

Happy Coding.

Integrating WinMerge in Visual Studio

2010-06-29T15:50:00.001+02:00

I've been using WinMerge for a long time now because i think it's the best, FREE, comparison and merge tool available today. What i really don't like is the comparison tool that ships with Visual Studio.

For instance, the following line has a difference, but what is the difference exactly. You can figure out what it is by really staring at the line OR use WinMerge instead.

The cool part about VS2008 is that you can configure a lot of things, and this also count for customizing tools.

To intergrate WinMerge follow these simple steps.

Go to tools -> options -> source control -> visual studio team foundation server -> "configure user tools" button.
Click Add
Choose the following settings

Extension: .*
Operation: Compare
Compare: C:\Program Files\WinMerge\WinMergeU.exe
Arguments: %1 %2

Now if you compare the files, you get the nice interface of WinMerge and can see directly what the difference in the lines is and enjoy the right features of WinMerge.

WinMerge can be downloaded from the following location.

Enjoy.

Gr.
Martijn.

Yet Another WiX Tutorial Part 3: Customizing the UI dialogs

2010-06-18T10:21:00.001+02:00

Introduction

In a previous post I showed you how to use the UIExtensions library to add predefined user interfaces to you installer. These UIExtensions are easy to use, but what if none of these suit your needs. It is possible to customize the selected UI Extension and it is quit easy to do.

The following example will show you have to remove the LicenseAgreementDlg from the UI sequence of the WixUI_InstallDir extension.

Steps

Get the source code for the UIExtension

First thing you need to do is get the sources for the version of WiX you are using. After you have downloaded them, you van browse to the UIExtension folder to get the wxs fragment file that contains the extension

<SOURCE FOLDER>\src\ext\UIExtension\wixlib

When you open the extension WiX file (in this case WixUI_InstallDir) you will see a fragment with the ID used by the UIRef node.

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
        <UI Id="WixUI_InstallDir">

The fragment contain a set of DialogRef nodes that refer to dialogs defined in fragment files in the same folder, and a series of Publish nodes, that define to order of the dialogs.

Add the fragment to you WiX script

Now select the complete UI node and add it to you WiX script.

<UI Id="WixUI_InstallDir">
	<TextStyle Id="WixUI_Font_Normal" FaceName="Tahoma" Size="8" />
	<TextStyle Id="WixUI_Font_Bigger" FaceName="Tahoma" Size="12" />
	<TextStyle Id="WixUI_Font_Title" FaceName="Tahoma" Size="9" Bold="yes" />
	<Property Id="DefaultUIFont" Value="WixUI_Font_Normal" />
	<Property Id="WixUI_Mode" Value="InstallDir" />
	<DialogRef Id="BrowseDlg" />
	<DialogRef Id="DiskCostDlg" />
	<DialogRef ... />
	
	<Publish Dialog="BrowseDlg" Control="OK" Event="DoAction" Value="WixUIValidatePath" Order="3">1</Publish>
	<Publish Dialog="BrowseDlg" Control="OK" Event="SpawnDialog" Value="InvalidDirDlg" Order="4"><![CDATA[WIXUI_INSTALLDIR_VALID<>"1"]]></Publish>
	<Publish> ... </Publish>
</UI>

Change the Dialog order

Now find the part where the LicenseAgreementDlg is Published. If you look at the dialog published before and the dialog Published after the LicenseAgreementDlg you will see that they are filling in events for two important controls, Next and Back.

<Publish Dialog="WelcomeDlg" Control="Next" Event="NewDialog" Value="LicenseAgreementDlg">1</Publish>
and
<Publish Dialog="InstallDirDlg" Control="Back" Event="NewDialog" Value="LicenseAgreementDlg">1</Publish>

To skip the LicenseAgreementDlg, we need to change the values of the Publish node to the appropriate dialog values.

<Publish Dialog="WelcomeDlg" Control="Next" Event="NewDialog" Value="InstallDirDlg">1</Publish>
and
<Publish Dialog="InstallDirDlg" Control="Back" Event="NewDialog" Value="WelcomeDlg">1</Publish>

Notice that we changed the values of the Publish node from LicenseAgreementDlg to the previous and next dialog ID. You can now remove the LicenseAgreementDlg Publish nodes if you want, or leave them to change back later.

Happy Coding.
Martijn.

Yet Another WiX Tutorial - Index

2009-07-31T17:16:00.001+02:00

I am working on new project where i am introducing the WiX Toolkit as part of our automated build process using TFSBuild. As the project evolves I am publishing my findings on this blog.

The Yet Another WiX Tutorial consists of the following parts:

Enjoy.

Encrypted Cookies using ASP.NET

2009-07-01T15:56:00.001+02:00

Introduction

In order to store use specific information during a ASP.Net session you have to option to place state data in a browser cookie. These cookie are send in plain text and using various tool it is possible to read the content of these cookies.

Although reading might not always be a problem, the ability to change the content of a cookie is a big thread. Tampering with the cookie is actually very easy, and i will demonstrate this using a Firefox extension called TamperData.

Tampering a Cookie

Setup

I started by creating a small ASP.NET application that checks the presence of our cookie. If not sets, a cookie is create and filled in the page load. After that i print the values on the page.

  1: protected void Page_Load(object sender, EventArgs e)
  2: {
  3:     if (Request.Cookies["__IGUZA.NET"] == null)
  4:     {
  5:         HttpCookie cookie = new HttpCookie("__IGUZA.NET");
  6:         cookie["SomeKey"] = "SomeValue";
  7:         cookie["SomeSecondeKey"] = "SomeSecondValue";
  8:         Response.Cookies.Add(cookie);
  9:     }
 10: 
 11:     if (Request.Cookies["__IGUZA.NET"] != null)
 12:     {
 13:         HttpCookie cookie = Request.Cookies["__IGUZA.NET"];
 14:         Response.Write(string.Format("SomeKey : {0}<br />", cookie.Values["SomeKey"]));
 15:         Response.Write(string.Format("SomeSecondeKey : {0}<br />", cookie.Values["SomeSecondeKey"]));
 16:     }
 17: }

Tampering with the cookie

Once we have the code ready we open the page in Firefox. Start Firefox and open TamperData. Open the page and in TamperData select the request. Because the cookie is not there yet we get a Set-Cookie response header with the values.

The cookie values are then displayed on the page by our code.

Now we can start tampering the cookie value. On the TamperData dialog click start tampering. Now refresh the page. TamperData will display a dialog asking if you want to tamper the data.

Now click Tamper and change the value of the cookie we are sending from SomeValue to SomeValueTampered.

When you click OK, the request is send to the server. Inspect the new request in TamperData and see that the new values are send in the cookie.

The new cookie values are displayed on page.

Protecting against tampering

So what does this all mean?.

Well, as you can see, it is very easy to change the value of a cookie. Of course this is not the only way. There are multiple tools that can do this, including Fiddler.

The problem here is that the server is not setting this value for fun. It will probably be using this information for the next requests. Sensitive data could be kept in this cookie. A good example would be a security token that contains you login information. If one would be able to change this data it could be a high security risk.

Encryption is the key

Now let’s demonstrate the part where we protect against tampering. We take the same solution as before, but add some encryption logic that will encrypt the cookie data using the private key of a certificate. The code used to encrypt the cookie takes a string value and a certificate.

NOTE: Of course other key providers are possible to use.

  1: public static string PKIEncrypt(string data, X509Certificate2 certificate)
  2: {
  3:     if (certificate == null)
  4:         throw new ArgumentException("Certificate can not be null.");
  5:     
  6:     if (certificate.HasPrivateKey == false)
  7:         throw new CryptographicException("Certificate does not contain a private key.");
  8: 
  9:     RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)certificate.PublicKey.Key;
 10: 
 11:     byte[] plainbytes = Encoding.UTF8.GetBytes(data);
 12:     byte[] cipherbytes = rsa.Encrypt(plainbytes, false);
 13:     return Convert.ToBase64String(cipherbytes);
 14: }

Of course we also need to decrypt the string before we can use it in code. De decryption method takes a Base64 Encoded string and a certificate.

  1: public static string PKIDecrypt(string Base64EncryptedData, X509Certificate2 certificate)
  2: {
  3:     if (certificate == null)
  4:         throw new ArgumentException("Certificate can not be null.");
  5: 
  6:     if (certificate.HasPrivateKey == false)
  7:         throw new CryptographicException("Certificate does not contain a private key.");
  8: 
  9:     RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)certificate.PrivateKey;
 10: 
 11:     byte[] decryptedBytes = rsa.Decrypt(Convert.FromBase64String(Base64EncryptedData), false);
 12:     return Encoding.UTF8.GetString(decryptedBytes);
 13: }

The only thing we need to do next is change the code in the Page_Load.

First we get the certificate we want to use for encryption.

  1: X509Store store = new X509Store(StoreName.Root, StoreLocation.LocalMachine);
  2: store.Open(OpenFlags.ReadOnly);
  3: 
  4: X509Certificate2 Cert = store.Certificates.Find(
  5:     X509FindType.FindByThumbprint,
  6:     "08 15 b7 a7 26 d3 06 0a 4f 61 b9 eb f7 e4 0f 7a 7c 24 6f 0c",
  7:     false)[0];

Than we add the encryption logic to the part where we assign the cookie to the request.

  1: if (Request.Cookies["__IGUZA.NET"] == null)
  2: {
  3:     HttpCookie cookie = new HttpCookie("__IGUZA.NET");
  4:     cookie["SomeKey"] = "SomeValue";
  5:     cookie["SomeSecondeKey"] = "SomeSecondValue";
  6:     cookie.Value = Encryption.PKIEncrypt(cookie.Value, Cert);
  7:     Response.Cookies.Add(cookie);
  8: }

Then we need to add the decryption logic to the part where we get and read the cookie. The reason we are making a copy of the cookie is that if if we would assign the original cookie the decrypted value, unless we encrypt it again, that would be the new value of the cookie.

  1: if (Request.Cookies["__IGUZA.NET"] != null)
  2: {
  3:     HttpCookie cookie = Request.Cookies["__IGUZA.NET"];
  4:     HttpCookie decryptedCookie = new HttpCookie("TEMP");
  5:     decryptedCookie.Value = Decryption.PKIDecrypt(cookie.Value, Cert);
  6:     Response.Write(string.Format("SomeKey : {0}<br />", decryptedCookie.Values["SomeKey"]));
  7:     Response.Write(string.Format("SomeSecondeKey : {0}<br />", decryptedCookie.Values["SomeSecondeKey"]));
  8: }

Now if we do the requests again making use of TamperData we will see a encrypted cookie value and get the following result.

If we now start tampering and eagerly change some part of the unreadable value, we get a server error (500) because we don’t have a nice try catch logic around my code :).

The only way this would work is if the person trying to change the value has the private key of the certificate used to encrypt the data. He/She would have to copy the encrypted string, decrypt it, change the values, encrypt the string again and assign the encrypted value to the cookie again. The fact that the hacker would have the private key is almost unthinkable.

Conclusion

Because of the fact that cookies are plain text and easy to tamper it is sometime required to protect the cookie against threads. In come cases cookies just contain unimportant data, like LastVisit, FirstName and LastName. This data could as well be send in plain text.

Although it all seams easy in code, the overhead of signing and decrypting should be held against the need to protect your state data.

Happy Coding.

Martijn.

Yet Another WiX Tutorial Part 2: Your First Installer

2009-06-30T17:16:00.001+02:00

Introduction

What is in this tutorial

In this part of the WiX tutorial i will guide you trough your first WiX installer and explain what the important concepts are when creating a WiX file.

Requirements for this part of the tutorial is that you installed the WiX toolkit as described in part 1 of this tutorial.

Structure of a WiX script

If we look at the structure of a MSI package you will see some principles that come back in the WiX script.

A MSI has one or more features.
A feature has one or more components.
A component consists of one or more items to be installed.

A component is a group of items and actions that should be installed or executed when that component is selected to be installed. The most common items would be some files and a shortcut , and an action could be to copy a file.

Creating the project

The WiX project

We start by creating a new solution that contains a WiX project. The WiX Project template presents you with the following WiX script.

For a complete WiX schema I recommend going to the manual page of WiX.

  1: <?xml version="1.0" encoding="UTF-8"?>
  2: <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  3:   <Product Id="e06d9811-b2f8-4e11-81fc-0e82160dae0e" Name="WixTutorial" Language="1033"
  4:     Version="1.0.0.0" Manufacturer="Iguza.Net" UpgradeCode="cea73ef0-4496-4da4-8608-152baf455fec">
  5:     <Package InstallerVersion="200" Compressed="yes" />
  6: 
  7:     <Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />
  8: 
  9:     <Directory Id="TARGETDIR" Name="SourceDir">
 10:       <Directory Id="ProgramFilesFolder">
 11:         <Directory Id="INSTALLLOCATION" Name="WixTutorial">
 12:           <Component Id="ProductComponent" Guid="b0789ba0-c0bb-49aa-8459-a5fac2da9cf4">
 13:             <!--TODO: Insert files, registry keys, and other resources here.-->
 14:           </Component>
 15:         </Directory>
 16:       </Directory>
 17:     </Directory>
 18: 
 19:     <Feature Id="ProductFeature" Title="WixTutorial ConsoleApp" Level="1">
 20:       <ComponentRef Id="ProductComponent" />
 21:     </Feature>
 22:   </Product>
 23: </Wix>

So what do we see here?.

We start out with a product node, which specifies the properties of out installer.

We skip the <Media> node for now. Second thing we see is a directory structure using <Direcory> nodes which defines the installation folder structure. Within this directory structure we insert <component> element in the location where the components should be installed. In our example we will be adding some files that need to be installed.

Adding Files

I started by adding a new console application project names “WixTutorial.ConsoleApp” and implement some simple code in the mail method.

To add this file to the installer add a <File> node in the component. Every item should have a unique ID. The WiX compiler will actually warn you about this beforehand.

  1: <Component Id="ProductComponent" Guid="b0789ba0-c0bb-49aa-8459-a5fac2da9cf4">
  2:   <File Id="FILE_CONSOLEAPP" Name="WixTutorial.ConsoleApp.exe" 
  3:         DiskId="1" Source="$(var.ConsoleFolder)\WixTutorial.ConsoleApp.exe" />
  4: </Component>

First we introduce a variable called $(var.ConsoleFolder). This will make the script more flexible because we can set the value, for instance during a build process. You could provide this variable as a command line parameter but for now we fill it hard coded. To do this, add the following snippet right after the <Wix> node and replace the <%FOLDER LOCATION%> placeholder with the root folder of your console build folder.

  1: <?define ConsoleFolder = "<%FOLDER LOCATION%>" ?>

We should now be able to build the project. After the build has finished we end up with a MSI file in the output folder of the WiX project.

Running this MSI will finish quickly and it will look like it didn’t do much. But is we look in the install folder “c:\program files\WixTutorial” we will actually see our file. Also, using the “Add/Remove Programs” console, we are able to uninstall the application. The reason for this is that our installer does not contain any definition for installation dialogs and simply installs without user interaction.

Adding Interfaces

To include some user interface we can use one of the precompiled UI sequences that come with the toolkit. For a list of these templates i refer you to a very good article at WiX tutorial.

To get started we need to first add a reference to the UI extensions library to our WiX project using the well know “Add Reference” dialog.

Select the WixUIExtention.dll, click add and then OK.

After this reference has been set, we add the most complete user interface to the WiX script. So add the following as a child of the <Product> node.

  1: <UIRef Id="WixUI_Mondo"/>

Using this one line of code, the following main dialogs are included:

The following dialogs are also included:

That’s it, we are done.

Now if we repeat the installation we should see actual screens. One of these would be the “Setup Type” selection dialog and when choosing “Custom” the feature selection dialog pops up.

Some Final Tweaks

This is all pretty neat, but why can’t we set the installation folder?. We need to add one more attribute to our selected feature node.

  1: <Feature Id="ProductFeature" Title="WixTutorial ConsoleApp" Level="1"
  2:          ConfigurableDirectory="INSTALLLOCATION">
  3:   <ComponentRef Id="ProductComponent" />
  4: </Feature>

The ConfigurableDirectory attribute is set to the folder id that we are allowed to change during the installation. If we run the MSI again after the build, we can select the installation folder.

What’s in the next part

That’s it. Our first simple installer is finished. Take a look at the actual XML that was needed and you will see that it’s very straight foreword and easy to read.

The next tutorial will go deeper into tweaking the WiX script and working with variables during a build.

Happy Coding.

A List Of Microsoft Patterns And Practices Documents

2009-06-16T15:55:00.001+02:00

Patterns & Practices

I have put together an interesting list of all Patterns and Practices books available on the internet that i could find. Most of the have some relation to development. If you know some that are missing, please let me know.

Architecture

Application Architecture for .NET: Designing Applications and Services
HTML | PDF

Application Architecture Guide 2.0
HTML | PDF

Enterprise Solution Patterns Using Microsoft .NET
HTML | PDF

Development

.NET Data Access Architecture Guide
HTML – PDF

Exception Management in .NET
HTML | PDF

Improving .NET Application Performance and Scalability
HTML | PDF

Security

Improving Web Service Security Guide
HTML | PDF

Building Secure ASP.NET Applications
HTML | PDF

Web Service Security
HTML | PDF

Security Engineering Explained
HTML | PDF

Improving Web Application Security: Threats and Countermeasures
HTML | PDF

Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication
HTML | PDF

Other

Building Interoperable Web Services
HTML | PDF

Team Development with Visual Studio Team Foundation Server
HTML | PDF

Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005
HTML | PDF

Reliable Message Exchange Using XML Signing

2009-06-14T17:21:00.001+02:00

Introduction

A well known service oriented scenario is where a client and service application communicate using message exchange over a channel. This channel is either secured, using for instance SSL, or unsecured where the data is send in plain text.

One of the commonly used message bases is XML. XML is a standard way of describing relational data, and can be read by most platforms. This makes XML a interoperable message base.

On the downside, this message type is easy to read and it therefore easy to change. If a third party where to intercept the message, for instance using a proxy server, it could easily change the content of the message and send it to the original endpoint. This is called tampering.

To detect changes to the content, a message send through the channel can be signed. Signing is a way to provide reliable messaging over a non-secure channel. It also provides some sort of authentication because the message can be validate that is was send from the expected client.

Principle of signing

A digital signature on a message is like a footprint of that message. Before the message is send, the hash is calculated and encrypted using a key. This key can be a custom key, a fixed key from a key store, or the key from a certificate. On the receiving endpoint, the supplied signature can be validates against the newly calculated value. In any scenario, the sender and receiver should share some sort of key infrastructure to sing and validate the messages.

The following image gives a overview of the signing and validation of a message using the private and public key of a shared certificate.

So let’s put this theory to practice using the .NET Framework

Signing using the .NET Framework

The Setup

To get started, i have a small XML file representing the message to be transferred over the channel. Nothing fancy, just to show what the results will be.

  1: <?xml version="1.0" encoding="utf-8" ?>
  2: <Person>
  3:   <Firstname>John</Firstname>
  4:   <Lastname>Doe</Lastname>
  5: </Person>

Second, i have imported a certificate into the certificate store. The certificate contains a private and public key and will be used for signing and verification purpose. Normally you would use a certificate with private key on the sending endpoint and import the same certificate on the receiving side containing only the public key.

To demonstrate the signing and validation, I'll guide you trough the code required using a console application. Of course in a OOAD pattern, this logic could be in a separate logic library like a utilities library.

Disclaimer:
I did not take all the time to insert nice error handing code so don’t comment me on that. Always implement good exception handling.

Retrieving the certificate

I’m retrieving the certificate from the certificate store using the unique thumbprint. The .NET library has evolved nicely in the part, because it now supports a easy way to do this exact thing.

  1: X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
  2: store.Open(OpenFlags.ReadOnly);
  3: 
  4: X509Certificate2 Cert = store.Certificates.Find(
  5:     X509FindType.FindByThumbprint,
  6:     "e5 d9 de 0f ed 08 34 09 c2 83 0f f2 11 4a e9 a0 b0 7b 86 9f",
  7:     false)[0];
  8: 
  9: // Generate a signing key.
 10: RSACryptoServiceProvider privateKey = Cert.PrivateKey as RSACryptoServiceProvider;

The false bool in the Find method indicated if i only want to use valid certificates. As this is not important in the example i set this to false.

Signing

To sign the XML file, i created a method that takes the filename of the original message, the name of the resulting message, and the key to use for the signing.

  1: // Will sign the XML file using the key proivided and saves it.
  2: SignXmlFile("MySecureDocument.xml", "MySecureDocument-Signed.xml", privateKey);

The first thing we will do is read the XML file into a XmlDocument and create a SignedXml object referencing the message. We then set the key to the SigningKey property.

  1: // Create a new XML document.
  2: XmlDocument doc = new XmlDocument();
  3: 
  4: // Load the passed XML file using its name.
  5: doc.Load(new XmlTextReader(FileName));
  6: 
  7: // Create a SignedXml object.
  8: SignedXml signedXml = new SignedXml(doc);
  9: 
 10: // Add the key to the SignedXml document. 
 11: signedXml.SigningKey = Key;

The SignedXml object is kind of a misleading name, as it does not contain the signed XML but only the signature informational part. In my opinion, a more logical name would be XmlSignature. The SignedXml will be added to the XML message later.

Next, we need to add a Reference object to the SignedXml object. This tells the signing algorithm what part of the message to use to calculate the signature. It also contains a signature transform property that described the way the signature is provided.

  1: // Create a reference to be signed.  Pass "" 
  2: // to specify that all of the current XML
  3: // document should be signed.
  4: Reference reference = new Reference();
  5: reference.Uri = "";
  6: 
  7: // Add an enveloped transformation to the reference.
  8: XmlDsigEnvelopedSignatureTransform env = new XmlDsigEnvelopedSignatureTransform();
  9: reference.AddTransform(env);
 10: 
 11: // Add the reference to the SignedXml object.
 12: signedXml.AddReference(reference);

After the signing algorithm is setup we can start calculating the signature and assign it to the XML message. I say we as in code. .NET Framework does all the calculating for us.

  1: // Compute the signature.
  2: signedXml.ComputeSignature();
  3: 
  4: // Get the XML representation of the signature and save
  5: // it to an XmlElement object.
  6: XmlElement xmlDigitalSignature = signedXml.GetXml();
  7: 
  8: // Append the element to the XML document.
  9: doc.DocumentElement.AppendChild(doc.ImportNode(xmlDigitalSignature, true));
 10: 
 11: // Save the signed XML document
 12: XmlTextWriter xmltw = new XmlTextWriter(SignedFileName, new UTF8Encoding(false));
 13: doc.WriteTo(xmltw);
 14: xmltw.Close();

The resulting XML file will contain a additional Signature node containing all the information to be validated.

  1: <Person>
  2:   <Firstname>John</Firstname>
  3:   <Lastname>Doe</Lastname>
  4:   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  5:     <SignedInfo>
  6:       <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
  7:       <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
  8:       <Reference URI="">
  9:         <Transforms>
 10:           <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
 11:         </Transforms>
 12:         <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
 13:         <DigestValue>haEx+J1wgjeVDYyfdqNr2vdJypE=</DigestValue>
 14:       </Reference>
 15:     </SignedInfo>
 16:     <SignatureValue>PXh7px6IXOVh0ilFbIKhVqBupNIP3He...</SignatureValue>
 17:   </Signature>
 18: </Person>

Validation

Validation is more straight forward. As described in the introduction in our example we validate the signature using the public key of the shared certificate. We can retrieve this again from the certificate store.

  1: // This time we use the public key
  2: RSACryptoServiceProvider publicKey = Cert.PublicKey.Key as RSACryptoServiceProvider;

After this we simulate receiving the message by reading the signed file from disk and assigning it to the SignedXml object.

  1: // Create a new XML document.
  2: XmlDocument xmlDocument = new XmlDocument();
  3: 
  4: // Load the passed XML file into the document. 
  5: xmlDocument.Load(Name);
  6: 
  7: // Create a new SignedXml object and pass it
  8: // the XML document class.
  9: SignedXml signedXml = new SignedXml(xmlDocument);

Then we get the signature node and validate the signature.

  1: // Find the "Signature" node and create a newXmlNodeList object.
  2: XmlNodeList nodeList = xmlDocument.GetElementsByTagName("Signature");
  3: 
  4: // Load the signature node.
  5: signedXml.LoadXml((XmlElement)nodeList[0]);
  6: 
  7: // Check the signature and return the result.
  8: return signedXml.CheckSignature(Key);

And that’s it. Your all done. The bool will tell you if the signature was OK.

Summary

To prevent tampering of data, non-repudiation and to provide extra authentication it is possible to sign your messages. Of course this involves some extra overhead and loss of performance, depending on the size of the document and to overcome this, hardware signing is a possibility.

Keep in mind that you are still sending readable, none encrypted data over the channel if you are not using SSL so it will not prevent someone else from reading it until you do.

Hope you enjoyed this post.

Regards,
Martijn.

Yet Another WiX Tutorial Part 1 : An Introduction

2009-06-12T11:06:00.001+02:00

WiX in a nutshell

Quote:

The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code. The toolset supports a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages.

I could not have said it better myself.

The main components

The three mains components I use from the toolkit are the following.
(Although i found another useful one called heat.exe that I'll explain in a later tutorial)

candle.exe : used to compile a WiX file
light.exe : used to create the MSI from the compiled file
dark.exe : used to decompile a MSI into a WiX script

The usage of WiX

Introduction

In one of the projects I'm working on we use Windows Installer XML (or WiX) to create a setup package during the automated build process. Although we have the build process under control, and we have a generic way of integrating WiX in our build process i wanted to know more about WiX, and see if i could optimize it.

The way the the initial WiX script was created is by taking a working MSI package, that contains a custom installer class, and decompile it to a WiX script. Cleaning it up and adding the appropriate settings (like product name and version) and than create some project specific settings we supply to the WiX compiler using parameters to build the MSI.

Why go trough all this trouble you might ask. Visual studio has a nice setup project template that build using MSBuild as well. Of course that’s true, but it is limited in what it can do. At least we found ourselves writing a lot of logic in a custom installer class, and adding that to the project. Another small detail was updating the version number of the setup during build.

As i found out later, some of this logic was actually supported by WiX and made it all easier as well. That’s why I've put all my findings together and started created this step by step tutorial series.

An example

We use custom code to install a virtual directory under IIS and map it to the web application that comes with the installation. This can actually be done using simple WiX code … and … it’s transactional. No custom rollback or uninstall code.

Another thing we do is that we pack our web applications in a ZIP archive, and add this to the installer. Using the custom installer, we unzip it. This also means that we have to write uninstall logic, as de MSI only knows about the zip file included. I looked into a better solution and found a more generic way to include all the files from a web application, or build output folder, and include the file in the installer. With this solution you are skipping the rollback and uninstall logic, unzipping and install folder cleaning.

Last interesting thing was windows services. We now install them using a custom action. This means that again we have to write rollback logic and uninstall logic. This was error prone because if the service was still running it can’t be deleted.

Conclusion.

Although WiX has a slight learning curve, in the end a good WiX script leave a lot of installation, rollback and uninstall logic to the windows installation process leaving more time to write only the pre installation logic, like configuration dialogs, in the custom installers (although this can also be done using WiX).

The WiX Toolkit

Getting the toolkit

Installation is a piece of cake. Download the latest “RC” version from the SourceForge.Net page. During the course of these tutorials I will be using version 3.0.5217.0.

installation

With the installation you get the complete command line toolset. Besides that Votive is installed. This is the visual studio package. It add a new project type to visual studio, including 5 new project templates. I will come back to this in a next tutorial.

A final suggestion

I recommend adding the installation path of the toolkit (default: “C:\Program Files\Windows Installer XML v3\bin”) of WiX to your environmental variables, so you don’t have to type the whole path every time you run a script from the command line.

What’s in the next part

In the next part of the tutorial I will guide you trough creating a basic installation from scratch, using the WiX project template in visual studio.

Welcome to my blog

2009-06-11T22:16:00.001+02:00

Hi, and welcome to my blog.

I started this blog because i find myself surfing the net for new stuff and never have take the time to keep track of everything. Most of the time i collect info from different resources and in the end lose track of it.

This blog will be my repository for my findings, and should be a resource for later.

I will start with a set of tutorials about WiX.

Enjoy.

Gr.
Martijn.