Improving Web Application Security: Threats and - CGISecurity

166 Part III: Building Secure Web ApplicationsRegistryTo prevent the disclosure of sensitive data, do not log it in the first place. Forexample, do not log account credentials. Also, your code cannot be exploited to readexisting records or to delete event logs if all it does is write new records usingEventLog.WriteEvent. The main threat to address in this instance is how to prevent amalicious caller from calling your code a million or so times in an attempt to force alog file cycle to overwrite previous log entries to cover tracks. The best way ofapproaching this problem is to use an out-of-band mechanism, for example, by usingWindows instrumentation to alert operators as soon as the event log approaches itsthreshold.Finally, you can use code access security and the EventLogPermission to put specificconstraints on what your code can do when it accesses the event log. For example,if you write code that only needs to read records from the event log it should beconstrained with an EventLogPermissin that only supports browse access. Formore information about how to constrain event logging code, see “Event Log” inChapter 8, “Code Access Security in Practice.”The registry can provide a secure location for storing sensitive applicationconfiguration data, such as encrypted database connection strings. You can storeconfiguration data under the single, local machine key (HKEY_LOCAL_MACHINE)or under the current user key (HKEY_CURRENT_USER). Either way, make sure youencrypt the data using DPAPI and store the encrypted data, not the clear text.HKEY_LOCAL_MACHINEIf you store configuration data under HKEY_LOCAL_MACHINE, remember thatany process on the local computer can potentially access the data. To restrict access,apply a restrictive access control list (ACL) to the specific registry key to limit accessto administrators and your specific process or thread token. If you useHKEY_LOCAL_MACHINE, it does make it easier at installation time to storeconfiguration data and also to maintain it later on.HKEY_CURRENT_USERIf your security requirements dictate an even less accessible storage solution, use akey under HKEY_CURRENT_USER. This approach means that you do not have toexplicitly configure ACLs because access to the current user key is automaticallyrestricted based on process identity.HKEY_CURRENT_USER allows more restrictive access because a process can onlyaccess the current user key, if the user profile associated with the current thread orprocess token is loaded.