Observations and insights from the Security PS Team.

My WCF Experience (Part 1)

Hello World

One of the core aspects of Security PS is the leadership’s emphasis and priority on continuing professional development. I have been afforded a great deal of research and development time to grow my security and application development knowledge. So, I've decided to blog a bit of what I'm learning in hopes that my "aha" moments may help and spur on others on a similar journey.

A New Target: WCF

In our team's application security testing projects, there are times where we encounter applications that use "Windows Communication Foundation" (WCF) to communicate between application components. I was new to WCF, so one of my teammates and mentors, Nick Coblentz, tossed me in the deep end of Windows WCF communication so I could get a good handle on how to test such applications for security concerns. Nick gave me a crash course and some exercises to understand WCF, their security implications, and how to test them. Essentially, I first had to build a service myself and implement different service configurations. Then I needed to figure out how to listen to the communication and identify the circumstances and methods that would enable me to manipulate the communication. Over the next few posts, I'm going to walk through me figuring out this process and share a few things I learned along the way.

WCF - What is it good for? (and what even is?)

Windows Communication Foundation (WCF) originally was code-named Indigo and was released with .NET 3.0 in 2006. According to Microsoft, WCF “is a framework for building service-oriented applications.” WCF was built to support a whole suite of features, including interoperability, data contracts, security, multiple transports and encodings, and reliable and queued messages (Source:

Today, it appears the general Internet consensus is that more and more enterprises are moving away from WCF towards WebAPI for its ease in supporting not only websites but also mobile devices and tablets. However, WCF has been a core part of service-oriented infrastructure over the Internet for over a decade, and so it still bears relevance today. Not only due to pervasiveness, WCF is likely to remain a core part of service-oriented architecture for the time being because WCF and WebAPI are complementary and not mutually exclusive. WCF by design supports a service-oriented architecture and implements Web Services (WS) protocols based on SOAP specifications for stateless applications, whereas WebAPI supports resource-oriented architecture and pairs much better with Restful frameworks where stateful applications are concerned.

Now that we have an understanding of what WCF is, I'll share how I implemented my first WCF service.

The Setup

First, I set out to build a basic WCF service. No fancy bells, no fancy whistles. Just a WCF service out of the box. Microsoft has done a good job with providing documentation on their website to assist with setting up an initial WCF service. As I mentioned previously, this is not a tutorial blog post, but I followed this walkthrough to help me get a basic service up and running along with a client. For me, my application was a simple Windows Form that:
Asked for a username and password
Checked the combination against an Excel “database”
Returned whether the credential pair was valid or not.

This simple application was designed to mimic an intranet login application, which you can see in the two screenshots below.

Login Form with Valid Response Message 

Login Form with Invalid Response Message
Now, the default WCF service generated by Visual Studio 2017 is a “basicHttpBinding” service. This is a very simple service with no default security mechanisms implemented - no TLS, no encryption, no message-level security. The returned message (either “Valid” or “Invalid”) told me the service and client was working properly, but I wanted to see how the mechanism underneath worked. Proxying the service through BurpSuite allowed me to inspect the transport mechanism.

WCF basicHttpBinding Observations

Intercepting POST Request with BurpSuite
Viewing raw response with BurpSuite
 The first observation one may make about the above screenshots is the presence of the SOAP envelope and body. As previously mentioned, WCF implements the SOAP framework. This point is proved by the request and response shown in the screenshots. 

The second observation one may make is that basicHttpBinding transmits everything via clear text with no predefined security implementations whatsoever. It does not support Web Services (WS) protocols or standards. By default, basicHttpBinding does not allow cookies, the encoding type is “Text”, and security is turned off.

Quick Conclusions

This was my introduction to WCF and playing with the out of the box basic configuration. Based on my initial observations, basicHttpBinding is simple to set up quickly, but it is not suitable for corporate solutions. However, most clients probably are not using basicHttpBinding. So, look for “My WCF Experience Part 2” where I set out to try to create a wsHttpBinding.

    Blogger Comment
    Facebook Comment


Post a Comment