Article:		Web Services Security, Part 1
Subject:		false sense of insecurity: Author's response
Date:		2003-03-30 23:22:21
From:		Bilal Siddiqui
Response to: false sense of insecurity: Axis Developer's response
You can continue disagreeing without going sad. We can do it happily as it introdcues new ideas!!! However, I do not find much of a disagreement in your message. Your first message was about little security tricks (user tokens, IP addresses etc. for authentication) and I explained that we have to work with standards, without which we cannot ensure interoperability. For example, if we decide about user tokens, we need standards describing how to wrap and process security tokens in XML format. At the end of my last message, I just put up a question, in which I was trying to prove that user tokens inside SOAP messages (the XML layer) are necessary for web services security. We cannot use lower layers for web services security. After reading your latest message in which you want to celebrate further disagreement, without commenting anything on the main issue of the first message (interoperability), I think there is a basic confusion about two things. Please note that *interoperabiulity* and *deciding the level to implement web services security* are two distinct problems. You have chosen to disagree only about the level to implement web services security. So I think the interoperability debate is over, with a conclusion that we have to stick with standards. However, you can reopen the debate any time, happily :) Your answer to my question assumes that my question was specifically about SOAP over HTTP, while my question did not mention SOAP over HTTP. However, I do think I should have explicitlly mentioned in my question that I am talking about SOAP in general and not SOAP over HTTP. So, let's discuss BOTH cases: SOAP in general AND SOAP over HTTP. And you will see that using HTTP end points to implement web services security is inadequate in both cases. You mention "The rationale for WS-security is not that HTTP security is inadequate". Did I ever say that HTTP security is inadequate? My point is that HTTP security is not suitable for SOAP (and this is *partly* the rationale for WS-Security). Let's consider two of the popular models for moving beyond HTTP as a transport: Messaging middleware applications like JMS Virtual network overlay applications like JXTA In both these applications, there will be middleware modules working effectively as routers over HTTP or some other equivalent transport. Such middleware modules give rise to the concept of SOAP intermediaries. The simple result is that the SOAP requester and the ultimate recepient of the SOAP message (the SOAP server which is supposed to author the SOAP response) MAY not know the HTTP or IP addresses of each other. So you cannot rely on web service end points to implement security. And if you do rely on web service end points, I think here you are breaking the well established rules formed in the early days of OSI stack development, when people used to argue what functionality should be built into which layer. Resuability (abstraction and encapsulation) are proven techniques not just in OO, but also in protocol stack development. And if you trivialize this matter today, you will need to re-build systems as business logic grows. Another thing. If we do consider SOAP oever HTTP, how will you implement operation or method level authorization policies? These are the reasons, I don't consider HTTP for securing web services. And I think SOAP developers also appreciate these points. Please go through section 7.1.2 of SOAP Version 1.2 Part 2: Adjuncts specification. This section describes the *purpose* of SOAP HTTP binding. For your convenience, here is an extract from the official document: QUOTE: This binding is not intended to fully exploit the features of HTTP, but rather to use HTTP specifically for the purpose of communicating with other SOAP nodes implementing the same binding. Therefore.......... UNQUOTE: I think, if you rely on HTTP for anything other than "specifically for the purpose of communicating with other SOAP nodes", you are misusing the technological framework available. Your customers will pay the price later on for this over-trivialization. And you see, that's why it hurts! I mentioned in the begininng "I do not find much of a disagreement in your message". I think the only disagreement is in the "frame of minds". You solve a problem without considering what's coming next and say "Look this is so easy that it hurts". And I am trying to focus on what's coming next, and therefore don't think that your solution addresses the problem at all. Your further disagreement is most welcome. Bilal

Previous Message

Up

Next Message

• false sense of insecurity: Author's response
  2005-09-26 11:43:58 tony!
  
  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.