Error Handling, Auditing and Logging - Revision history

Adedov: /* Error Handling */ PHP is not "functional" language

2015-07-17T12:32:26Z

‎Error Handling: PHP is not "functional" language

Shady: Further Reading

2013-05-12T17:12:01Z

Schattenbaum: "protocol led" replaced by "protocolled"

2012-05-14T13:46:43Z

"protocol led" replaced by "protocolled"

KirstenS: /* Error Handling and Logging */

2009-05-02T11:04:08Z

‎Error Handling and Logging

KirstenS: /* Objective */

2009-05-02T10:40:15Z

‎Objective

KirstenS: /* Further Reading */

2009-03-04T02:41:51Z

‎Further Reading

KirstenS: /* Proof of validity */

2009-03-04T02:33:53Z

‎Proof of validity

KirstenS: /* Proof of validity */

2009-03-04T02:32:58Z

‎Proof of validity

KirstenS: /* How to protect yourself */

2009-03-04T02:29:29Z

‎How to protect yourself

KirstenS: /* Error Handling and Logging */

2008-08-27T22:26:00Z

‎Error Handling and Logging

@@ Line 43: / Line 43: @@
 ==Error Handling ==
-Error handling takes two forms: structured exception handling and functional error checking. Structured exception handling is always preferred as it is easier to cover 100% of code. Functional languages, such as PHP 4, that do not have exceptions are very hard to cover 100% of all errors. Code that covers 100% of errors is extraordinarily verbose and difficult to read, and can contain subtle bugs and errors in the error handling code itself.
+Error handling takes two forms: structured exception handling and functional error checking. Structured exception handling is always preferred as it is easier to cover 100% of code. On the other hand it is very hard to cover 100% of all errors in languages that do not have exceptions, such as PHP 4. Code that covers 100% of errors is extraordinarily verbose and difficult to read, and can contain subtle bugs and errors in the error handling code itself.
 Motivated attackers like to see error messages as they might leak information that leads to further attacks, or may leak privacy related information. Web application error handling is rarely robust enough to survive a penetration test.

@@ Line 285: / Line 285: @@
 * Oracle Auditing
-<u>http://www.sans.org/atwork/description.php?cid=738</u>   [[category:FIXME|broken link]]
+<u>http://www.dba-oracle.com/t_audit_table_command.htm</u>
 * Sarbanes Oxley for IT security

@@ Line 151: / Line 151: @@
 ===Quality of service ===
-Repetitive polls can be protocol led so that network outages or server shutdowns get protocolled and the behavior can either be analyzed later on or a responsible person can take immediate actions.
+Repetitive polls can be protocolled so that network outages or server shutdowns get protocolled and the behavior can either be analyzed later on or a responsible person can take immediate actions.
 ===Proof of validity ===

← Older revision		Revision as of 11:04, 2 May 2009
Line 426:		Line 426:


−	The cflog and cftrace tags allow ~~developer~~ to create customized logging. <cflog> can write custom messages to the Application.log, Scheduler.log, or a custom log file. The custom log file must be in the default log directory – if it does not exist ColdFusion will create it. <cftrace> tracks execution times, logic flow, and variable at the time the tag executes. It records the data in the cftrace.log (in the default logs directory) and can display this info either inline or in the debugging output of the current page request. Use <cflog> to write custom error messages, track user logins, and record user activity to a custom log file. Use <cftrace> to track variables and application state within running requests.	+	The cflog and cftrace tags allow developers to create customized logging. <cflog> can write custom messages to the Application.log, Scheduler.log, or a custom log file. The custom log file must be in the default log directory – if it does not exist ColdFusion will create it. <cftrace> tracks execution times, logic flow, and variable at the time the tag executes. It records the data in the cftrace.log (in the default logs directory) and can display this info either inline or in the debugging output of the current page request. Use <cflog> to write custom error messages, track user logins, and record user activity to a custom log file. Use <cftrace> to track variables and application state within running requests.

@@ Line 9: / Line 9: @@
 * Traceable – it’s possible to determine where an activity occurs in all tiers of the application
-* High integrity – logs cannot be overwritten or tampered by local or remote users
+* High integrity – logs cannot be overwritten or tampered with by local or remote users
 Well-written applications will dual-purpose logs and activity traces for audit and monitoring, and make it easy to track a transaction without excessive effort or access to the system. They should possess the ability to easily track or identify potential fraud or anomalies end-to-end.
 ==Environments Affected ==

@@ Line 165: / Line 165: @@
 The points from above show all different motivations and result in different requirements and strategies. This means, that before we can implement a logging mechanism into an application or system, we have to know the requirements and their later usage. If we fail in doing so this can lead to unintentional results.
-Failure to enable or design the proper event logging mechanisms in the web application may undermine an organization's ability to detect unauthorized access attempts, and the extent to which these attempts may or may not have succeeded. We will look into the most common attack methods, design and implementation errors as well as the mitigation strategies later on in this chapter.
+Failure to enable or design the proper event logging mechanisms in the web application may undermine an organization's ability to detect unauthorized access attempts, and the extent to which these attempts may or may not have succeeded. We will look into the most common attack methods, design and implementation errors, as well as the mitigation strategies later on in this chapter.
 There is another reason why the logging mechanism must be planned before implementation. In some countries, laws define what kind of personal information is allowed to be not only logged but also analyzed. For example, in Switzerland, companies are not allowed to log personal information of their employees (like what they do on the internet or what they write in their emails). So if a company wants to log a worker's surfing habits, the corporation needs to inform her of their plans in advance.

@@ Line 157: / Line 157: @@
 Application developers sometimes write logs to prove to customers that their applications are behaving as expected.
-* Required by law or corporate policies
+* Required by law or corporate policies.
 * Logs can provide individual accountability in the web application system universe by tracking a user's actions.
-It can be corporate policy or local law to be required to (as example) save header information of all application transactions. These logs must then be kept safe and confidential for six months before they can be deleted.
+It can be corporate policy or local law to be required to (for example) save header information of all application transactions. These logs must then be kept safe and confidential for six months before they can be deleted.
 The points from above show all different motivations and result in different requirements and strategies. This means, that before we can implement a logging mechanism into an application or system, we have to know the requirements and their later usage. If we fail in doing so this can lead to unintentional results.

@@ Line 109: / Line 109: @@
 Production code should not be capable of producing debug messages. If it does, debug mode should be triggered by editing a file or configuration option on the server. In particular, debug should not enabled be an option in the application itself.
-If the framework or language has a structured exception handler (ie try {} catch {}), it should be used in preference to functional error handling.
+If the framework or language has a structured exception handler (i.e. try {} catch {}), it should be used in preference to functional error handling.
 If the application uses functional error handling, its use must be comprehensive and thorough.
-Detailed error messages, such as stack traces or leaking privacy related information, should never be presented to the user. Instead a generic error message should be used. This includes HTTP status response codes (ie 404 or 500 Internal Server error).
+Detailed error messages, such as stack traces or leaking privacy related information, should never be presented to the user. Instead a generic error message should be used. This includes HTTP status response codes (i.e. 404 or 500 Internal Server error).
 ==Logging ==

@@ Line 467: / Line 467: @@
-{| border=1
+<pre>
 <cffunction name="dblogin" access="private" output="false" returntype="struct">
@@ Line 691: / Line 689: @@
 </cffunction>
-|-
+</pre>
 [[Guide Table of Contents|Development Guide Table of Contents]]