Cheap skate way to do exception shielding in ASP.NET web services

You read it right. There is a very cheap way to shield exception information from an ASP.NET web service. Mind you, this is available only from ASP.NET 2.0 (and upwards presumably).

So, what is exception shielding for web services? Preventing potentially valuable exception information from leaking to the calling client. It’s a good security practice to shield unhandled exceptions that occurred inside your web service from bubbling up to the ASP.NET HttpHandler for ASMX. Take this web service:

  [WebService(Namespace = http://tempuri.org/”)]

  [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

  [ToolboxItem(false)]

  public class FaultyTowers : System.Web.Services.WebService

  {

 

    [WebMethod]

    public string HelloFawlty()

    {

      throw new ArgumentException(“Stop right there, Basil!”);

      return “No way, Manuel”;

    }

  }

The handler will take over and return a SOAP fault to the client. The <soap:Fault> element will contain (wrapped inside a SoapException) the type and message of the exception that occurred, plus a stacktrace and references to the file location of the source file. It will look like this:

<?xml version=1.0 encoding=utf-16?>

<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:xsd=http://www.w3.org/2001/XMLSchema>

  <soap:Body>

    <soap:Fault>

      <faultcode>soap:Server</faultcode>

      <faultstring>

        System.Web.Services.Protocols.SoapException: Server was unable to process request. —&gt; System.ArgumentException: Stop right there, Basil!

        at WebApplication1.FaultyTowers.HelloFawlty() in C:tempWebApplication1FaultyTowers.asmx.cs:line 23

        — End of inner exception stack trace —

      </faultstring>

      <detail />

    </soap:Fault>

  </soap:Body>

</soap:Envelope>

You could jump through hoops to catch all unhandled exceptions that occur inside of your methods and throw your own SoapExceptions (in which case the exception isn’t altered). There is some guidance right here from the Patterns and Practices team.

Or you could set a new ASP.NET 2.0 diagnostics option in your web.config and let the ASP.NET runtime take care of not returning too much exception information.

<?xml version=1.0?>

<configuration>

  <system.web>

    <webServices>

      <diagnostics suppressReturningExceptions=true />

    </webServices>

Setting the suppressReturningExceptions attribute to true (the default is false) will result in no information being included in the returned SoapException. The <soap:Fault> will now contain the following:

<soap:Fault>

  <faultcode>soap:Server</faultcode>

  <faultstring>System.Web.Services.Protocols.SoapException: An error occurred on the server.</faultstring>

  <detail />

</soap:Fault>

I say: recommended for production environments.

For a full-blown and more robust implementation, check the Web Service Software Factory from P&P and read an intro by Eric here.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s