Sunday, April 25, 2010

XML Parsing and SOAP messages

For a recent project, I needed to create a Web Services Conversation Language (WSCL) document (actually, four of these) and then be able to use another Web Service acting as a conversation handler to parse this XML and verify the protocols contained in the WSCL doc. This proved to be a challenge and reminded me that I need to better learn XML parsing in Web Services.

When a Web Service is created in Visual Studio, the service can be launched in a browser window. This page will show you the service available as well as a link to the WSDL document, and comments on the namespace if it is set to the default URL of tempuri.org. The screenshot below shows an example of this page.


Clicking on a Service name will allow you test the functionality of the service. Here is where an important note is annotated. When testing the operation directly, the parameters used are sent using HTTP POST. However, when accessing the Web Service through another application/service, the parameters are passed using SOAP messages by default.


So why is this important you might ask? Something gets lost in translation with the differences between HTTP POST and SOAP messages. When attempting read an attribute from an XML element, one can use the XMLReader.GetAttribute() function. This function is overloaded to allow for example: an int parameter (the index value of the attribute) or a string value of the attribute's XName. So, when parsing an XML document, one way to do this (using Visual Studio 2008, C#) is with something similar to the following:

using (XmlReader reader = XmlReader.Create(url))
{
reader.Read();
reader.ReadToFollowing("DestinationInteraction");
reader.MoveToFirstAttribute();
StartOp = reader.GetAttribute("href");
reader.Close();
}

This block of code will create an XML reader object (reader) and will then move to first Element with a name value of "DestinationInteraction." The reader is then moved to the first attribute of the Element and then assigns to (string)StartOp the value of the "href" attribute. An example of the portion of the WSCL document that this is reading is:

Notice that this Element has no values, only an attribute of "href" that has the value "OPName." And this is where the fun begins.

Parsing the value of Elements in an XML document is generally very easy. A developer can code such that only the required Element(s) is accessed (reducing overhead), or can parse the entire document, storing needed values for the application. It's the parsing of attributes, specifically using an "int" as the parameter that presents a problem.

The bottom line is this:
When using HTTP POST the XMLReader.GetAttribute(int i) will work properly. However, when attempting to use the int parameter in a SOAP message, this failed for me every time, with either an out-of-bounds error message (attributes can be accessed like an array [0...n]) or an invalid parameter error message. Needless to say that this was very frustrating for me, especially since I spent a LOT of time on this only to realize that the easy answer was to use the string parameter.

Using XMLReader.GetAttribute(string s) function allows the operation to execute properly (as long as s is a valid XName of the attribute) in both HTTP POST actions and with SOAP messages.

Unfortunately, this was another thing on which I spent a LOT of time that I really didn't have. I was not able to determine the cause of the problem, although it is obviously something in the way the SOAP messages are being handled. I assume it's the way that the client side is parsing the SOAP message and believe that although the SOAP message passes the int parameter as an int, the client-side is most likely parsing the int and casting it to a string. I have finals this week and will be focused on that in my free time. However, as SOON as my finals are over, I plan to spend some time on this one as I really want to know what the failure mechanism was with this operation.

Making a Change and Who You Know

A few weeks ago(the week before the dreaded "Master's Week"), I received an odd email. This requires a little bit of back story, so I will do that before explaining the email and subsequent activites.

The back story:
When I was leaving the Army, I was contacted by a woman who works for the Georgia Department of Labor, Veterans Assistance. I was this woman's first client, and she really went the distance to help me find suitable employment in order to care for my family. It was obviously a stressful time (leaving the Army was medically forced due to a stupid surgeon, not by choice) and this woman really helped, and probably more than she even realizes. So with all of that said, I have still stayed in contact with her and have tried to pass on job information to her so that she may help other service members being medically discharged.

The email:
The woman I reference sent me an email asking if I was happy at my current job and if she could pass along my information to someone. Although I have been extrememly happy with my current job, I felt that out of respect for her, I would at least listen to what this other company was offering. This is where the "who you know" comes into play, in addition to being willing to take a chance.

The outcome:
I am starting a new job in a week. This new job is programming based, as opposed to network security. I am very, very excited about this new job as I have been wanting to be able to focus more on programming than just the occasional tool I build or the programs I write for school projects. Furthermore, since I AM working on my Master's in Software Engineering (from the University of Michigan!!!), I think that having more real-world experience is important and gives credence to my pending degree. The real dilema here is that I really do love my current job. If they could come close to what the new company has offered, I would stay. However, I don't think that that will happen.

In any event, it is a win-win for me. While I will miss my current job and the fun I have there, I am certain the new job will be just as fun, even though I KNOW it will be a huge challenge with a LOT of pressure to perform quickly.

My two biggest passions when comes to work are network security and programming. Now I will be changing focus to the programming and I know that the challenges this presents will be fun, if not a little stressful. :-)

HTTP 404.8 ERROR

While working on a recent project involving web services, I started to get HTTP 404.8 errors, which I will discuss in a minute. The odd thing about this error is that it "just started." The project I was working on did not involve any "new" technology that I haven't already used on this box.
My current environment consists of:
- Windows 7 Pro
- Visual Studio 2008 Pro
- IIS 7.5

The HTTP 404.8 ERROR:
- Hidden Namespace. The requested URL is denied becuase the directory is hidden.
What does this mean???

This error is apparently returned when a directory is listed in the RequestFiltering/HiddenSegments of the applicationHost.config file for IIS. The fix for this is partially found at (http://support.microsoft.com/kb/942047). I say partially becuase it is still up to the user to determine which directory is the problem. However, I will still post the fix instructions here, with the caveat that this "might" not be the solution to everyone else's problem with this error.

Steps:
- Open Notepad as an Administrator (right click on Notepad, select "Run as administrator")
- Open the file named "%windir%\System32\inetsrv\config\applicationHost.config.
- Find the element and then the child tag
- Here's the annoying part...at least for me.
- In the section, find the directory that is causing you the problem. For me, it was the "App_Code" directory that had somehow become a problem.

The unanswered question here is: "What caused this error in the first place?" What was I doing when the error was returned? I was trying to use a Web Service instance in a project I was working on. This Web Service instance has been used in multiple projects and this 404.8 had never been returned before. In fact, when I recieved this error, I attemped to see if other Web Services I had recently created returned the same error when I tried to access them through my main application; the same error was in fact returned by all Web Services when accessed through the application, but not when I used the "View in browser" option for each service in VS2008. As frustrating as this was, I was under a serious time crunch to get the application working, and as such I have still not had time to properly research why this error started happening.

I do strongly believe the error to have been caused by some update to either Windows 7, IIS 7.5, or (even less likely) Visual Studio 2008. The update had to have been applied since the middle of February, as that is the last known time that the Web Service in question was successfully used. I may post a question to the forums on these, but it depends on time. Maybe somebody reading this can tell me why this error just "magically appeared" one day.

Friday, April 2, 2010

Chunky Data (HTTP Headers, Part Deux)

The world of intrusion detection and analysis is constantly changing, intel comes in chunks, and the bad guys range from encryption geniuses to 14-yr old pimple-faced punks.
That all said, it is important sometimes to review the "basics." So, here is another bit of information on HTTP Header information.
Field: Transfer-Encoding ";" 1#transfer-coding
Where 1#transfer-coding is the token defining what transfer encoding is being used.
I have seen even the the best of analyst make mistakes on what "Transfer-Encoding:chunked" means, so here goes:

This type of Transfer-Encoding ("chunked") is a method of coding is used to transport HTTP messages. The RFC (link below) can be read for the full details, but the big thing that I see people getting confused about...it's those numbers that appear in the message stream:

HEADER
AAA
.......
......
.....

HEADER
BBB
......
....
..
0

Where AAA and BBB are (in HEX) giving the size of the chunked portion of the message. As in the picture below, a final chunk will (must) end with a zero.




Sometimes, when following a stream in Wireshark, these numbers will "appear" in the middle of the data like:
......
XXX
.....
0
Either way, this number is not part of the actual message. Chunked encoding does not encode the payload specifically, It is used, as the RFC states, to encode the full message.

What is the lesson here: be careful when analyzing HTTP stream data. Do not include the chunk size values as part of the actual message when you are trying to decode.