Brilliant comment!
- Michael
Anil John <[EMAIL PROTECTED]> wrote: The only
comment I will add to this particular thread is that as you go
about implementing this, please consider incorporating the "Exception
Shielding" Security Pattern as part of the design.
Info on the Pattern:
Context
=========
A client is accessing a Web service. The Web service is designed
according to the principals of service orientation, which ensures that
the boundaries of the service are explicit, and requires that exception
information related to the internal implementation of the service is
managed within the service.
Problem
=========
How do you prevent a Web service from disclosing information about the
internal implementation of the service when an exception occurs?
Forces
========
Any of the following conditions justifies using the solution described
in this pattern:
* Exception details may contain clues that an attacker can use to
exploit resources used by the system. Detailed fault messages can
disclose information about the Web service or resources accessed by the
Web service code that threw the exception. An attacker may deliberately
cause the Web service to throw an unhandled exception in an attempt to
obtain sensitive information, such as connection strings, server names,
SQL queries, XPath commands, stack traces, and data schemas. The
attacker can then use this information to exploit the Web service or the
resources that it accesses.
* Information related to anticipated exceptions needs to be returned
to the client. In cases where an exception is expected, an error message
that does not contain sensitive internal information can be returned to
the client. A service may provide information about the cause of the
fault, where the information is not considered a security risk. In some
cases (for example, data validation errors), the potential savings in
administrative support may outweigh the risk of providing the requestor
with more detailed information about an exception.
The following condition is not resolved by the base pattern, but it is
resolved by Extension 1 - Logging Exceptions:
* Exceptions that occur within a Web service should be logged to
support troubleshooting. Information within an exception can be used by
monitoring tools to automatically notify system administrators when an
exception occurs. The same information can also be used by application
developers to diagnose exceptions that occur within the logic of the
service or with resources that the service is dependent on. In some
cases, you may require that an error message that is returned to the
client contains an ID that helpdesk staff can use to troubleshoot user
problems.
Full details @ http://msdn2.microsoft.com/en-us/library/aa480591.aspx
Regards,
- Anil
:-
:- Anil John
:- http://www.aniltj.com/blog/
:-
---------------------------------
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
