|
First: I wanted to say I have really enjoyed this article and the banter at the bottom.
Second: I wanted to throw in my two cents.
I agree with both of you but I have found a recent need to not follow the standards when it comes to developing secure web services.
By monitoring the raw structure of a SOAP request and return message it is clear that SOAP is simply a hybrid of the HTTP message structure.
For example:
*HTTP*
---Standard HTTP header POST (non-soap post):
POST /ReportService/Publisher/createReport HTTP/1.1
Host: somehost.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Followed by standard HTTP post data
---Standard HTTP header RETURN
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
Followed by XML
*SOAP*
---Standard SOAP header POST:
POST /ReportService/Publisher HTTP/1.1
Host: somehost.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: http://somehost.com/ReportService/createReport
Followed by XML
---Standard SOAP header RETURN
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
Followed by XML
As you can see, in these examples, the posting/request headers are nearly identical and the return headers for HTTP and SOAP… ARE identical.
Beyond the header you either process XML or HTTP post data which is nothing more than “string” or “string encoded” data unless it has a binary attachment.
Any hacker will find this easy to strip apart and analyze then later mimic a valid consumer.
First habit: Always use SSL. You really don’t need another layer of encryption beyond this. Though in some cases I do anyway to provide an additional layer of security but it is really not needed other than to provide comfort to a customer.
Second habit: Minimize how often the client consumer has to send authentication. I only have a consumer send authentication once and authentication can only happen through a “connection” web service method. I then create a “session token” (or GUID) on the service side and return it to the client. The client then HAS to keep this “session token” and included it with all subsequent web services calls.
Yes… these habits require that I run my own “session” manager on the service.
I use this custom session manager to link to our roles and permissions settings to quickly determine if a calling user has access to the method AND/OR the CONTENT/DATA the method may return. In some instances the user will have access to a method but not the selected content that the method can request for. (This is key... security really goes beyond access to a web service method but also to the data that a method can return... just because a client has access to a method does not mean they have access to ALL data that method can return.)
The “session” manager monitors for these issues and modifies the returned XML to inform the consumer that they don’t have access to that data.
I try to never return a 404 error. I always try to return an XML result that provides some status like…
<STATUS>
<ERROR>FAIL<ERROR>
<MESSAGE>You are not authorized.</MESSAGE>
</STATUS>
To prevent a ‘stolen session’ you simply monitor the calling IP. If the calling IP does not match the IP originally associated with the “session token” when it was created then that call fails. If you don’t have access to the calling IP (or if you don’t have access to the protocol layer) you are in trouble and should resolve this issue first because you will not be able to properly monitor and/or provide secure web services.
The above methodology (beyond the SSL) allows for providing a “proprietary” token and XML authentication structure to and from our services to further prevent “most” hacker attacks. This also removes much of the “overhead” and reduces the size of the SOAP data to better support poor bandwidth environments. (Yes… poor bandwidth environments still exist… most of my experience with web services is in support of getting data to our troops in Iraq which include networks just vanishing and passing through 20 year old satellite technology. HTTP/SOAP does not guarantee message delivery (return stream) in these environments. (...another story for another time…))
This is all probably an over simplification and I look forward to holes and examples to problems with the above theory.
|
Previous Message
Up
