none
Most secure way to accept confidential information using an http application? RRS feed

  • Question

  • Hi,

    I really don't know what forum to ask this in - so please guide me in the right direction if this is completely off (I was redirected to this forum).

    I have the need to accept a http-post. It can be in IIS using an aspx handler, asmx or wcf service it doesn't really matter. The post will be done using HTTPS. The post is not guaranteed to include a content-type, soap structure or anything. The only guarantee is that the data is valid XML. In other Words, if the data is XML I must accept it.

    The data is confidential and as such we can't have that this data is logged or anything.

    Since the requirement is that the protocol is HTTPS, I figure that the easiest way to do this is running the application under IIS. But I have to be sure that IIS doesn't log the request if some failure happens.

    I could use a WCF service that accept a Stream - but that would only Work if the sender specifies the content-type I think. I could use the aspx-handler and access the HTTPRequest stream. Or I could build a HTTPHandler. I guess that when talking about IIS, the best way would be to grab the byte-stream at the earliest stage possible.

    I could also ditch IIS and use a HTTPListener - but that would not be as easy to run under HTTPS as a simple IIS certificate.

    What would you recommend? Any idea, thought or redirection is more than welcome!

    --
    Werner


    Thursday, September 19, 2013 11:03 AM

All replies

  • 1.) Any data that is sent across a wire can be captured.  Luckily, your data will be SSL-encrypted, so even if it is logged or captured, it will be secure.

    2.) If you want the data to be more secure, it should be encrypted before being sent over SSL.  It should also be stored in an encrypted format in any database or other data store.

    3.) What version of .NET are you going to use for your application?  I'm not sure at exactly what version of the framework the features described below became supported, but it looks like they were available as of VS2008 (and later).  You can create an HTTP Handler or an HTTP Module to intercept requests to your application and perform whatever custom action you would like to do.  Here is an MSDN overview page describing these two options:

    http://msdn.microsoft.com/en-us/library/bb398986(v=vs.100).ASPX

    It sounds like one of these two options will be sufficient for your task.

    Thursday, September 19, 2013 12:23 PM
  • 1.) Any data that is sent across a wire can be captured.  Luckily, your data will be SSL-encrypted, so even if it is logged or captured, it will be secure.

    2.) If you want the data to be more secure, it should be encrypted before being sent over SSL.  It should also be stored in an encrypted format in any database or other data store.

    3.) What version of .NET are you going to use for your application?  I'm not sure at exactly what version of the framework the features described below became supported, but it looks like they were available as of VS2008 (and later).  You can create an HTTP Handler or an HTTP Module to intercept requests to your application and perform whatever custom action you would like to do.  Here is an MSDN overview page describing these two options:

    http://msdn.microsoft.com/en-us/library/bb398986(v=vs.100).ASPX

    It sounds like one of these two options will be sufficient for your task.

    Thanks.

    Well I'm not sure that I follow. HTTPS is the transport, so whenever my C# code inspects the request Stream (either from a HttpContext, Handler or Module), the data is not encrypted anymore. It is no longer in transport. So imagine that the process suffers a fatal exception just before the Stream is passed on to my Handler or whatever...can I be sure that the data isn't dumped somewhere (log files, event viewer etc)? The data sent is not under my control and is not encrypted.

    Next is the question about using a HttpHandler and/or module. Would that be better than to use the built-in handler for aspx for example? Where I could just grab the System.Web.UI.Page.Request.InputStream from "Page_Load"?

    --
    Werner

     

     

     



    Thursday, September 19, 2013 12:57 PM
  • 1.) If you are handling errors within your C# application, you can control what gets written to a log.  Millions of transactions involving secure and confidential data are handled by Microsoft applications running on IIS every day.  If the logging of this data were a problem, Microsoft would provide a solution.  Again, if the confidentiality of this data is truly a concern, it should be encrypted before being sent to the transport layer by the sending application.  It should never be exposed in an un-encrypted format to any part of the system where it is not necessary.  I would strongly advocate keeping this data encrypted through each part of the workflow if you are interested in maximum confidentiality.

    2.) If you do not trust IIS logging and you cannot convince the author of the application sending the data to encrypt the data internally before sending it to the transport layer, the next easiest solution is to build a custom application to receive HTTP requests.  This is not as easy as it sounds.  IIS hides away a lot of the difficulty in dealing with HTTP transactions, especially the portion involving SSL.  You would seriously have to consider whether this is worth the trouble, because you would effectively be writing an HTTP server again - and you would have to test that for security.

    3.) As far as using an HTTP Handler or an HTTP Module, this will allow you to implement any kind of action that you want.  To quote your initial posting:

    I guess that when talking about IIS, the best way would be to grab the byte-stream at the earliest stage possible.

    If that is what you are looking to accomplish, the HTTP Handler or HTTP Module solution would allow you to intercept the request at an earlier stage that relying on the ASP .NET page life cycle.

    Thursday, September 19, 2013 1:26 PM
  • Ad 1)
    Again: I do not control the data sent to me, and I can't change the data structure in any way.

    Ad 2)
    In fact, it is very easy using the HttpListener. The only thing easier in IIS is the HTTPS certificate. And it is not that I don't trust IIS but there are a number of Things that I don't know enough about. For example the LogRequest added in 3.5. What does that do by default? Etc, etc. 

    Ad 3)
    Yes, a module would make it possible for me to grab the data in HttpApplication.OnBeginRequest. This is my favourite this far. I just need a way to enforce that module. I can't have a mis-configured Web.Config result in these data being disclosed. But I might be closing in on a solution to that problem here.

    That said, the data I must receive can be large. And while I know that I must create a Stream implementation for the Request.Filter, I can't seem to grasp how to handle large data where the Stream.Read will be called several times.

    Also, I can't help the thought that I'm missing out on a WCF solution to this. The trouble with WCF is that I must accept any POST with no content type information.





    Friday, September 20, 2013 7:57 AM