TMI Syndrome in Web Applications
By design, Web applications are set up to process and present information, generally without the installation of any custom software on the user’s system. All the user needs to view information is a browser such as Microsoft Internet Explorer or Mozilla Firefox. With the current generation of Web application technologies (Web 2.0), Web pages no longer are plain vanilla and static but instead are rich user interfaces that are dynamic. Information is no longer merely presented but can now be interacted with per the user’s personal interests.
Herein lies the problem. If presenting the information is not properly protected, Web applications can suffer from TMI Syndrome (TMIS). TMI, an abbreviation for Too Much Information, according to Wikipedia is a slang expression indicating that someone has divulged too much personal information and made the listener uncomfortable. When Web applications suffer from TMI Syndrome, they divulge more information than is necessary, unsolicited or otherwise.
TMI Syndromes in Web applications can be categorized into two types: passive and active.
Passive TMIS: Web sites with Passive TMI Syndrome are those that divulge more information than is necessary, unsolicited or without any effort. Non-private MySpace and YouTube profile Web pages are a few classic examples of this.
Active TMIS: Web sites with Active TMI Syndrome are those that require additional efforts to glean out information that are meant to be private or protected. Just use your favorite search engine and search for “data breaches in Web sites” for a plethora of examples of Web sites that have suffered from Active TMI Syndrome. A Chronology of Data Breaches maintained by Privacy Rights Clearinghouse states, as of date, there has been more than 218 million data records of U.S. residents exposed due to security breaches since January 2005. A significant portion of this has been due to Web site mistakes.
So what are some of the sources for information leakage in Web applications? Recon efforts in which an attacker seeks to gather information about the Web application generally are comprised of, but are not limited to, the following sources:
- Unsolicited and non-private personal Web sites.
- See aforementioned section on Passive TMI Syndrome.
- Browser history and cache.
URI (Uniform Resource Identifier) is essentially a Web address with syntax rules. URIs of Web sites you visit using a browser are cached and recorded in history unless explicitly set not to. This is mainly to enhance performance. If users’ browsers record Web site URIs, and they visit your Web site, chances are that your Web site’s URI is cached and recorded in their browser history. This information can be stolen; URIs may pass sensitive information such as session IDs, log-in information and, in one case, even pricing and quantity ordered. When the browser’s cache and history is stolen and sensitive information is disclosed, the attacker has the ability to replay the session, find out the log-in information and possible submit orders, changing the price. TMI!
HTML Comments and Client Side Scripts
Using your browser and viewing the source can reveal a lot of information about the Web page. Developers that tend to instrument their code sometimes inadvertently put in comments that have sensitive information such as validation checks, connection strings to databases, production data for test purposes and steps to debug the business logic the Web page processes. Any sensitive information in client side scripts also is readable upon viewing source. Again, TMI.
Backup and Unreferenced Files
Due to versioning of Web applications, more often than not, older version of a Web page are renamed with extensions like .bak or .old and deployed in production environments without reference, along with the newer updated versions. Source control solutions have significantly reduced this; however, it is still prevalent in legacy applications. An attacker can guess these file names and request the files, and without proper access controls and handling of file types in place, TMI can potentially be revealed.
Include and Configuration Files
Include and Configuration files are used to support a “Write Once, Use Anywhere” mode of programming, wherein the developer would write common logic or settings that are to be used in various pages of the Web application in a file and then included in all the pages that need to use it. While this is good from a modular programming perspective, if these files contain sensitive information such as database connection strings and cryptographic routines in clear text (humanly readable form), it poses a serious threat of complete compromise by TMI disclosure.
Error messages are one of the first sources attackers will look at to determine vulnerabilities in a Web application because this requires little effort. For example, if a Web page requires you to specify the quantity of an item ordered in the shopping cart, the attacker can pass in a text string to see how the Web application handles the text input when expecting a numeric value. Without proper handling of the invalid input and the error message that is returned to the user, business logic flaws and underlying architecture of the Web application and back-end systems can be revealed. Clearly TMI.
The Risk of TMIS
So, you may ask, should I be concerned about this? On a personal front, Web applications that suffer from TMI Syndrome can result in serious maladies such as identity theft and cyberstalking.
On the corporate front, revelation of TMI in Web application could be disastrous, with results ranging from financial loss, levied fines, imposed regulations, auditors on-site, loss of the corporate brand and, more seriously, loss of customer trust.
It is critically important that precautionary measures are taken to prevent TMI Syndrome. Due diligence and secure coding practices help mitigate it. Some due diligence measures include divulging only need-to-know, publicly available information on personal Web communities and clearing browser cache and history upon closing of the browser window (manually or automatically).
Some secure coding measures include commenting HTML code and client side scripts wisely without revealing too much information, removing any old backup or unreferenced files from production environments, using include-and-configuration files only as needed and when used, encrypting sensitive information, handling error messages generically — instead of reporting “Password does not match” in the case of a failed log-in attempt, simply state “Log-in Invalid.” Do not allow the system to handle the error.
Avoiding Root From Recon
Failing to take necessary due diligence and secure coding control measures can lead to TMI being revealed and could lead to an attacker on a simple recon session gaining root access to your system, your company and maybe even your life.
Mano Paul is a founder and president of Express Certifications. He can be reached at editor (at) certmag (dot) com.