Security Concerns for Message Logging
This topic describes how you can protect sensitive data from being exposed in message logs, as well as events generated by message logging.
Logging Sensitive Information
Windows Communication Foundation (WCF) does not modify any data in application-specific headers and body. WCF also does not track personal information in application-specific headers or body data.
When message logging is enabled, personal information in application-specific headers, such as, a query string; and body information, such as, a credit card number, can become visible in the logs. The application deployer is responsible for enforcing access control on the configuration and log files. If you do not want this kind of information to be visible, you should disable logging, or filter out part of the data if you want to share the logs.
The following tips can help you to prevent the content of a log file from being exposed unintentionally:
Ensure that the log files are protected by Access Control Lists (ACL) both in Web-host and self-host scenarios.
Choose a file extension that cannot be easily served using a Web request. For example, the .xml file extension is not a safe choice. You can check the Internet Information Services (IIS) administration guide to see a list of extensions that can be served.
Specify an absolute path for the log file location, which should be outside of the Web host vroot public directory to prevent it from being accessed by an external party using a Web browser.
By default, keys and personally identifiable information (PII) such as username and password are not logged in traces and logged messages. A machine administrator, however, can use the enableLoggingKnownPII attribute in the machineSettings element of the Machine.config file to permit applications running on the machine to log known personally identifiable information (PII). The following configuration demonstrates how to do this:
<configuration> <system.serviceModel> <machineSettings enableLoggingKnownPii="true"/> </system.serviceModel> </configuration>
An application deployer can then use the logKnownPii attribute in either the App.config or Web.config file to enable PII logging as follows:
<system.diagnostics> <sources> <source name="System.ServiceModel.MessageLogging" logKnownPii="true"> <listeners> <add name="messages" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\messages.svclog" /> </listeners> </source> </sources> </system.diagnostics>
Only when both settings are true is PII logging enabled. The combination of two switches allows the flexibility to log known PII for each application.
In .NET Framework version 4 the |
You should be aware that if you specify two or more custom sources in a configuration file, only the attributes of the first source are read. The others are ignored. This means that, for the following App.config, file, PII is not logged for both sources even though PII logging is explicitly enabled for the second source.
<system.diagnostics> <sources> <source name="System.ServiceModel.MessageLogging" logKnownPii="false"> <listeners> <add name="messages" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\messages.svclog" /> </listeners> </source> <source name="System.ServiceModel" logKnownPii="true"> <listeners> <add name="traces" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\traces.svclog" /> </listeners> </source> </sources> </system.diagnostics>
If the <machineSettings enableLoggingKnownPii="Boolean"/> element exists outside the Machine.config file, the system throws a ConfigurationErrorsException.
The changes are effective only when the application starts or restarts. An event is logged at startup when both attributes are set to true. An event is also logged if logKnownPii is set to true but enableLoggingKnownPii is false.
The machine administrator and application deployer should exercise extreme caution when using these two switches. If PII logging is enabled, security keys and PII are logged. If it is disabled, sensitive and application-specific data is still logged in message headers and bodies. For a more thorough discussion about privacy and protecting PII from being exposed, see User Privacy.
|PII is not hidden in malformed messages. Such messaged are logged as-is without any modification. Attributes mentioned previously have no effect on this.|
Custom Trace Listener
Adding a custom trace listener on the Message Logging trace source is a privilege that should be restricted to the administrator. This is because malicious custom listeners can be configured to send messages remotely, which leads to sensitive information disclosure. In addition, if you configure a custom listener to send messages on the wire, such as, to a remote database, you should enforce proper access control on the message logs in the remote machine.
Events Triggered by Message Logging
The following lists all the events emitted by message logging.
Message logging on: This event is emitted when message logging is enabled in configuration, or through WMI. The content of the event is "Message logging has been turned on. Sensitive information may be logged in clear text, even if they were encrypted on the wire, for example, message bodies."
Message logging off: This event is emitted when message logging is disabled through WMI. The content of the event is "Message logging has been turned off."
Log Known PII On: This event is emitted when logging of known PII is enabled. This happens when the enableLoggingKnownPii attribute in the machineSettings element of the Machine.config file is set to true, and the logKnownPii attribute of the source element in either the App.config or Web.config file is set to true.
Log Known PII Not Allowed: This event is emitted when logging of known PII is not allowed. This happens when the logKnownPii attribute of the source element in either the App.config or Web.config file is set to true, but the enableLoggingKnownPii attribute in the machineSettings element of the Machine.config file is set to false. No exception is thrown.
These events can be viewed in the Event Viewer tool that comes with Windows. For more information on this, see Event Logging.