As any developer will tell you, writing code is the easy part--finding the mistakes in the code is what keeps programmers...
awake at night. Reading code over and over again, looking for one missing semi-colon, can cause programmers to call into question their choice of profession. So any tool that helps with troubleshooting should be utilized to its fullest potential.
One such tool is the call tracing feature of Microsoft's recent ODBC 3.0 software release. Call tracing was introduced in ODBC 2.0 at the behest of developers and support organizations as a means of logging troubleshooting information.
ODBC stands for Open Database Connectivity, and is an open standard API for accessing databases. ODBC can access information in a variety of different databases by converting the request to a form of SQL that the respective databases can understand.
Call tracing is disabled by default, but can be enabled in the Control Panel of ODBC Driver Manager. Call tracing's designers intended it to be a controlled way to test an application's ODBC calls on a client. Once call tracing is enabled and the application is run, a text log is created. The trace entries include parameters such as the connect string and, in the case of some drivers, userIDs and passwords for server authentication. This is where concerns arise about the security of call tracing.
You may have read in the computer press that a security hole existed in ODBC 3.0--well, this is it. If a malicious user were to have access to a machine and be able to enable call tracing on said machine, then wait for a legitimate user to log on, they could theoretically gain access to the userIDs and passwords for that legitimate user in the tracing log. This also assumes that the legitimate user does not notice the enormous drop in the application's performance as it is attempting to write what can be a very large trace log.
Of course if the userID and the password were encrypted by the application before making the ODBC call then there wouldn't be any security risk and the overall security of the application would be increased.
Microsoft also encourages programmers to prevent tracing in their applications:
"Applications should prevent tracing of any sensitive commands by setting the connection attribute SQL_ATTR_TRACE to SQL_OPT_TRACE_OFF, and then re-enable tracing by setting SQL_ATTR_TRACE to SQL_OPT_TRACE_ON afterwards. Tracing can be completely disabled by leaving SQL_ATTR_TRACE off."
Read more about Microsoft's feelings about the security of ODBC and numerous other ways to prevent call tracing from being exploited in this white paper.
About the Author
Benjamin Vigil is a technical editor for TechTarget.
For More Information
- What do you think about this tip? E-mail us at editor@searchDatabase.com with your feedback.
- The Best ODBC Links: tips, tutorials, and more.
- Have an ODBC tip to offer your fellow DBA's and developers? The best tips submitted will receive a cool prize--submit your tip today!
- Ask your technical ODBC questions--or help out your peers by answering them--in our live discussion forums.
- Check out our new Ask the Experts feature: Our SQL, Database Design, Oracle, DB2, and SQL Server gurus are waiting to answer your toughest questions.