The WebShift Software Blog

Quick Start: Using MSBuild to re-target project output

2009-11-26T13:59:00.004-05:00

I often find it useful to build many .NET projects from one master build script and then copy their output to a central folder. It is then easier to perform additional processing on the DLLs. While the concept is straight forward, I haven't seen many examples for doing this, so I'm posting a complete MSBuild script that demonstrates the technique in action.


<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
    <PropertyGroup>
        <OutputTargetDir>Output</OutputTargetDir>
    </PropertyGroup>
    <ItemGroup>
        <ProjectFile Include="PathToProjectA\MyProjA.csproj"/>
        <ProjectFile Include="PathToProjectB\MyProjB.csproj"/>
    </ItemGroup>
    <Target Name="Build">
        <Message Text="Building: @(ProjectFile, ', ')" />

        <MakeDir Directories="$(OutputTargetDir)" Condition="!Exists($(OutputTargetDir))" />

        <!-- Build projects and copy output to target directory -->
        <MSBuild
            Projects="@(ProjectFile)"
            Targets="Build">
            <Output
                TaskParameter="TargetOutputs"
                ItemName="PrimaryBuildOutput" />
        </MSBuild>
        <Copy SourceFiles="@(PrimaryBuildOutput)" DestinationFolder="$(OutputTargetDir)" SkipUnchangedFiles="true" />

        <!-- Find built project dependencies and copy to target directory -->
        <ResolveAssemblyReference AssemblyFiles="@(PrimaryBuildOutput)" SearchPaths="{HintPathFromItem}">
            <Output TaskParameter="ResolvedDependencyFiles"
                ItemName="BuiltProjectDependencies" />
        </ResolveAssemblyReference>
        
        <Copy SourceFiles="@(BuiltProjectDependencies)" DestinationFolder="$(OutputTargetDir)" SkipUnchangedFiles="true" />
    </Target>

From Users to Developers - Avoiding Web-Based Computer Security Vulnerabilities

2009-11-23T11:52:00.006-05:00

The proliferation of browser platforms and technology available on the web has allowed not only rapid advances in what may be accomplished in web sites but it has also given malicious users new ways to carry out attacks. This article covers the most common attacks that are utilized in today's browser platforms and how you can protect yourself from these attacks as both a user of the web and as a web site developer.

The vulnerabilities discussed are

Cross-site scripting (or XSS) attacks

Cross-site Request Forgery (CSRF) attacks

Clickjacking attacks

Cross-site Scripting

Cross-site scripting (XSS) attacks have been by far the most prevalent exploit utilized on the web. However, in many cases they are also the easiest to avoid from a web site developer stand point. An XSS attack commonly occurs when a web page displays content either supplied by an end-user or from another site, and it does not perform any HTML encoding of the content. The end-user content commonly comes from a form input field, and it essentially allows a user to insert their own HTML or client-site script into a web page. If that content may viewed by another user (in a message forum, for example) then it could be used to carry out any number of attacks such as:

Read the content of the user's page and send it to another server.

Read the value of a user's cookie and send it to the attacker so that he may assume that user's identity.

Send the user to another site.

In versions of Internet Explorer prior to IE6 and Windows XP Service Pack 2, a script could target a vulnerable page on a user's local file system and run scripts with full access to that user's system.

From a user stand-point, obviously the most severe approach to defeating these attacks is to simply disable client-side scripts from running. This would protect you from 99% of the really nasty exploits, although you would still be vulnerable to purely HTML based attacks. However, disabling all scripts is somewhat drastic and really hampers your ability to take full advantage of the web. A better approach is discussed at the end of this article.

The real onus for defeating XSS attacks lies with web developers. The first and most important action that a web developer should take is to not trust any input that could be potentially tainted by an end-user. Any data that will be written into a web page needs to be HTML encoded. Any data that will be written as a client-script string literal needs to be properly escaped. Finally, do not give client scripts access to any cookies unless absolutely necessary. Instead, mark them as httpOnly so that only your user's browser and your web site have access to them, and nothing else.

Cross-site Request Forgery

Cross-site Request Forgery (or CSRF) is another attack that is becoming more common. It takes advantage of situations where a user remains logged into another site by means of a cookie (httpOnly or otherwise). For example, suppose there is a webmail application that a user is logged into. As long as an appropriate authentication cookie is sent to the site with a user's request, the site will allow actions to be performed. This kind of security is referred to as ambient authority. The authentication information is sent with each request to the server; however, the server doesn't really know if the user specifically performed the request with their browser, or if another page tricked the user into performing the request. This problem is often called the problem of the Confused Deputy, which refers back to an article written in 1988 by Norm Hardy. For example, a malicious third-party site could embed an IFRAME in their own page but the IFRAME's URL points to your web mail server, and sends it a command to delete all of your mail. Since you were already logged in to your mail server, the IFRAME request behaves exactly as if you had made that request yourself and sends all of the necessary authentication cookie information. These attacks may also be implemented with img tags.

From a user stand-point, there isn't a whole lot that you can do to protect yourself against CSRF attacks other than always logging out of sites when you are done using them. You can also protect yourself from attacks via IFRAME based attacks. See the last paragraph of this article for more information on that.

From a developer stand-piont, there are a number of ways that you can protect the users of your sites from these attacks. Obviously, you could not support persistent authentication via cookies, but most people find it convenient so it would be nice if there were a compromise. You could require an additional user confirmation before performing any action that could modify their data. However, that would become quickly cumbersome to users. A more transparent approach is to include a secret value or key that must be sent back in a form or URL. If the value is sent back in a cookie or some other means where a browser's same-origin policy applies (i.e. scripts can't access cross-domain data such as what comes back in an IFRAME), then the third-party site cannot successfully construct a valid request. Finally, you should also prevent any requests to modify data that are not POST requests. The HTTP protocol specifies that GET requests should never change data on the server.

Clickjacking

The final attack that we will examine is also one of the more recent to be classified, and it is called Clickjacking. It is also potentially the most dangerous as there isn't a 100% solution for it. Clickjacking is a derivative of a CSRF attack except that the user is fooled into clicking what appears to be a button on a third-party site, but in between the cursor and the button is a hidden layer positioned over a button on another web site (for example, a delete mail button from our example above). This invisible layer can even be made to follow a user's cursor around the page to ensure that the attack will succeed. A non-script based approach could simply tile the third-party site's page with these hidden layers.

Considering that this attack forces a user to unknowingly perform an action on a web site in a very real sense, it is indeed very dangerous and hard to detect. A user's only repercussion is to once again, disable client scripts (which would prevent the majority of these attacks from working), and also logout from any site once finished with it. A third approach is discussed below as well.

Developers have it much harder for prevent clickjacking attacks. A site could be setup to force user confirmation before performing an action, but once again, that becomes cumbersome to users and is not foolproof. In truth, prevention of these attacks will likely need to come from the browsers. A discussion of some of the
possible solutions can be found here.

Wrapping Things Up

As mentioned several times in this article, an alternative approach exists to dealing with all of these attacks, and that comes in the form of the NoScript plugin for Firefox 3+. NoScript essentially provides a "white-listing" approach to which sites you allow to execute client-side scripts. It can also be used to disable IFRAME in un-trusted sites. The NoScript plugin is highly recommended, and it can be used to prevent XSS, CSRF, and Clickjacking attacks. Simply put, as the technologies used to build the web and enable new applications of the web move forward, so will the number and severity of the exploits available to attackers. As both users and developers for the web, we must constantly think about how we can protect ourselves as well as our sites from being attacked. The attacks my take a very different form tomorrow. While the web opens up many doors of opportunity it will also continue to keep us all
on our toes.

Additional Links of Interest

Discussion of Clickjacking and NoScript

Wikipedia article on XSS

Dynamic Control of ASP.NET Session State Requirement

2009-11-23T09:31:00.004-05:00

The ASP.NET runtime provides the SessionStateModule, which automatically loads session state for any ASP.NET HTTP Handler implementing the IRequiresSessionState or IReadOnlySessionState interfaces. This approach is fine in most circumstances, but consider the case where you may wish to selectively load session state for the same HTTP Handler from one invocation to the next, and you need to make this determination at runtime. In this case, it is unclear what approach should be taken as the IRequiresSessionState and IReadOnlySessionState interfaces are static type information specified at compile time. When using the interfaces, the HTTP handler is effectively hard-wired to always cause session state to be loaded or to not be loaded. This article examines one approach to dealing with this restriction by implementing a custom HTTP module.

First of all, let’s examine what hooks exist in the ASP.NET pipeline for triggering the SessionStateModule to load session state for an HTTP request. Our eventual goal is to load the session state, only when it is needed, into the HttpContext object before the Http Handler’s ProcessRequest method executes. Examining the HttpApplication class, we can see the list of events that are fired by the ASP.NET runtime. The important one is the AcquireRequestState event as it is the event that the SessionStateModule utilizes to determine if session state needs to be loaded. Looking at the event list, we can see that shortly after AcquireRequestState finishes, the HTTP handler itself is invoked. During AcquireRequestState, the SessionStateModule examines the Handler property of the current HttpContext object to see if it implements one of the IRequiresSessionState or IReadOnlySessionState interfaces. If it does, then session state is loaded.

Example:

public void AcquireRequestStateHandler(object sender, EventArgs e)
{
    HttpContext context = ((HttpApplication)sender).Context;
    if (context.Handler is IRequiresSessionState)
    {
        // ...
    }
}

Conceivably, if we could change the interface of the HTTP handler at runtime before AcquireRequestState runs, then we could control whether the session state is loaded or not. Fortunately, the Handler property is a writable property. Therefore, by creating "wrapper" HTTP handlers we can wrap the current handler at runtime before the AcquireRequestState event runs. Each wrapper type implements an interface corresponding to a type of session state requirement.

Example wrappers:

/// 
/// Wraps another IHttpHandler and indicates to the SessionStateModule
/// that read-only session state is required for the request.
/// 

public class ReadStateHandlerWrapper : IHttpHandler, IReadOnlySessionState
{
    private IHttpHandler _wrappedHandler;

    public ReadStateHandlerWrapper(IHttpHandler wrappedHandler)
    {
        _wrappedHandler = wrappedHandler;
    }

    public bool IsReusable
    {
        get { return _wrappedHandler.IsReusable; }
    }

    public void ProcessRequest(HttpContext context)
    {
        _wrappedHandler.ProcessRequest(context);
    }
}

/// 
/// Wraps another IHttpHandler and indicates to the SessionStateModule
/// that read/write session state is required for the request.
/// 

public class ReadWriteStateHandlerWrapper : IHttpHandler, IRequiresSessionState
{
    private IHttpHandler _wrappedHandler;

    public ReadWriteStateHandlerWrapper(IHttpHandler wrappedHandler)
    {
        _wrappedHandler = wrappedHandler;
    }

    public bool IsReusable
    {
        get { return _wrappedHandler.IsReusable; }
    }

    public void ProcessRequest(HttpContext context)
    {
        _wrappedHandler.ProcessRequest(context);
    }
}

Looking again at the HttpApplication events, we can see that an event named PostMapRequestHandler runs before AcquireRequestState executes. All that remains is to create a custom HTTP module that hooks into PostMapRequestHandler, and implements runtime logic to determine if session state is required for the current request or not.

Example module:

public class StateInitModule : IHttpModule
{
    public void Dispose()
    {
    }

    public void Init(HttpApplication context)
    {
        context.PostMapRequestHandler += new EventHandler(PostMapRequestHandler);
    }

    void PostMapRequestHandler(object sender, EventArgs e)
    {
        HttpContext context = ((HttpApplication)sender).Context;
        // Step 1. Determine if a handler is executing that we care about
        // Example: check it by type name
        if (null != context.Handler
            && "MyHandlerTypeName" == context.Handler.GetType().Name)
        {
            // Step 2. Determine if the handler requires session state or not
            // This will be specific to your particular application.
            // For example, you may examine a query string parameter.
            if(/* ... Logic to determine read-only access requirement */) 
            {
                context.Handler = new ReadStateHandlerWrapper(context.Handler);
            } 
            else if(/* ... Logic to determine read/write access requirement */) 
            {
                context.Handler = new ReadWriteStateHandlerWrapper(context.Handler);
            } // else do not alter the Handler property and state will not be loaded
        }
    }
}

(See the Custom Module Walkthrough if needed, which describes the process of implementing and configuring an ASP.NET HTTP Module.)

Keep in mind that HTTP modules execute in front of all requests so you should try to keep your logic as light and efficient as possible. Obviously each particular application will need to define its own heuristic for determining if a given HTTP handler request requires session state or not, but the above pattern will provide the capability to implement the logic at runtime.