If an organization's firewall(s) were to be breached or circumvented, sensitive information stored in obviously named files or database tables (as depicted in Figure 6.3 as a means of improving design readability) may allow an intruder to locate desirable information much more easily. This is especially true if the information is conveniently located on a Web server (a practice not recommended).
To mitigate this threat, many organizations have been known to implement one or more datacentric defenses, such as the examples in the following sections.
Data Filenames
If sensitive application data (such as userIDs and passwords) is to be stored in a database accessible via the Web site, the database design may have called for such fields and files to be named in a manner that does not give away their true usage. If such a strategy is employed, the database design should be reviewed at an early stage to ensure that sensitive information is not stored in such obviously named files as users, userIDs, passwords, security, accounts, and so on.
Unfortunately, if blatantly obvious names do make it into production, the cost of reworking (and testing) the application code just to use alternate filenames may be unjustifiably expensive, hence the need to decide early on in the application's design whether or not this security by obscurity approach should be adopted by the application's developers.
Data Tripwires
An exception to this security by obscurity rule would be when these easily identifiable files are used to store bogus userIDs and passwords. An attempt to log in with a userID from one of these bogus files may then be used as a tripwire to alert support staff to the fact that someone has already gained unauthorized access to the application's database and is attempting to penetrate further. (Tripwires are discussed in more detail in Chapter 8.) Unfortunately, tripwires are generally only effective if someone takes notice of their alerts. Therefore, if a database tripwire is deployed, when it is triggered, the on-duty staff should monitor and react appropriately if triggered.
Data Vaults
Vulnerable data may be placed inside a data vault for further protection. A data vault is a database (or data repository) that has had additional security measures applied to it to ensure that the data is protected from unauthorized access. Such controls improve the security around the data but add to the administrative workload and may impact data I/O speeds. If a data vault is implemented, the testing team should check that all the sensitive data that should be placed inside the vault does actually reside there, and that no performance-enhancing copies have been replicated outside the vault. Examples of data vaults are listed in Table 6.17.
Table 6.17: Sample Data Vaults
NAME ASSOCIATED WEB SITE
BorderWare www.borderware.com Cyber-Ark www.cyber-ark.com
WORMs
Write-once read-many (WORM) devices may impact performance, but using devices such as CD writers to store transaction logs or network audit trails would most likely thwart any attempt by an intruder to cover their tracks by deleting or modifying these logs.
In the case of read-only data files and executables, fast CD readers (with no writing capabilities) and ample memory may make for a more secure storage solution than storing
these files on hard drives that could be compromised. The amount of memory needed should be sufficient to keep the read-only files in memory long enough to avoid the considerable performance hit that repeatedly reading this data from the CD would cause. If a Web application's design calls for hardware-based write restrictions, a quick visual inspection of the hardware may not be able to detect the difference between a write-once CD writer and a CD writer with rewriting capabilities. In such cases, a software-based test may be warranted to see if files on the CD can be altered or deleted. To ensure that any restriction is due to the hardware device, as opposed to a security setting, the file access request should be done with an administrative account, which is not limited by any software-based security restriction.
Data Encryption
Although stringent precautions may be taken to protect data files used to permanently store data, less attention may be paid to transient data files such as temporary files, Web logs, database logs, application logs, third-party data files, .ini files, and obscure storage locations such as Window's registry entries. Unfortunately, these files are often used to temporarily store sensitive data (credit card numbers, social security numbers, and so on). They should therefore be checked to ensure that if such data is stored, it is only stored in an encrypted format, lest an intruder stumble across these forgotten nuggets of information. In addition, or as an alternative to any file encryption capabilities that the host operating system may provide (for instance, Windows 2000's Encrypting File System [EFS]), products such as those listed in Table 6.18 can be used to encrypt data stored on a server.
Table 6.18: Sample File Encryption Tools
NAME ASSOCIATED WEB SITE
AgProtect www.hallogram.com Blowfish and Crypto www.gregorybraun.com
CipherPack www.cipherpack.com
Data Vault www.reflex-magnetics.com
DataSAFE www.data-encryption.com EasyCrypt www.easycrypt.co.uk
Encryption Plus www.pcguardian.com
FileCrypto www.f-secure.com
GNU Privacy Guard www.gnupg.org
Kryptel www.bestcrypto.com
may never suspect that the data has been encrypted and therefore not even attempt to decipher it, thereby protecting the data ad infinitum. For example, instead of encrypting a client's PIN into a 128-bit binary format (which would make the resulting data longer), a hashing algorithm could be used that creates in another value that is the same length. Unsuspecting intruders may never figure out that the data is actually encrypted, and when they try using these values, they'll become frustrated because none of these stolen numbers work.
A fundamental weakness of a deception strategy is that for it to be effective, the deception must be kept secret. If such a strategy is to be employed, knowledge of its use should be restricted to a need-to-know basis, and certainly not documented in a requirements specification that any employee of the organization could easily gain access to. (Chapter 8 discusses the implications of testing defenses based on deception in more detail.)
Data Islands
Many organizations choose not to expose their master database to the Internet. One strategy for doing so is to replicate the master data on a database server that is part of the Web application and then to remove all physical network connections between the Web application and this master database, effectively creating a data island.
If a Web application's design calls for a data island implementation, then the testing team should determine if the implementation has left open any network path from the Web site to the master database. For instance, via an internal firewall that has not been tested, or via a temporary unsecured network connection that only exists while the two databases are being synchronized.
Distributed Copies
In an effort to improve scalability, some Web sites use a distributed database design to store data across multiple servers. In addition to any capacity flexibility that this design enables, such an approach may make a Web application harder for an intruder to corrupt, as the intruder would need to gain access to several servers before being able to corrupt every single copy of a data file.
Where feasible, these distributed copies should ideally have different security permissions, meaning that if an intruder is able to crack a userID and password protecting one copy, the same combination could not be used to access the others. Therefore, the testing team should check that as few accounts as possible are granted access to more than one copy of the data.
Fragmented Data
In contrast to storing multiple copies of the same data, extremely sensitive data may be broken up and distributed across multiple geographic locations, making the information useless unless the intruder is able to compromise all the storage sites and reassemble this fragmented data. For instance, some credit-card-processing Web sites store a client's userID, password, and account information in three separate databases, each residing at a different physical location.
One danger with this approach is that in order to improve database performance, a developer may reassemble the fragmented data into a single temporary file, which, if discovered by an intruder, would circumvent the need to attack all the dispersed locations. This situation is more likely to be discovered via design reviews than through test execution.
Database Management System (DBMS) Enforced Constraints
Most Database Management Systems (DBMSs) offer several different ways in which the data inside a DBMS can be protected from unauthorized access. The following are some of the more common approaches:
User groups. Rather than assigning security privileges to individual userIDs, most DBMSs enable the DBA to assign users to user groups, and then grant access to the group, which in turn is passed on to all the members of the group. Because user groups typically make security administration easier and therefore less prone to human error, they are generally considered a more secure approach than assigning privileges directly to individual users.
Views. Instead of assigning access directly to the data, many DBAs create an intermediate database object-a view. Instead of accessing a table (or group of tables) directly, users reference the data indirectly via a view. This extra level of indirection can allow a DBA to hide some of the database's physical attributes, such as the table's real name and location, or limit the user to only viewing some of the table's columns and/or rows.
Stored procedures. Rather than actually assigning read and write access to users (or user groups), some DBAs will only grant direct access to a database's tables (or views) to a program stored within the database itself (a stored procedure). Users are then limited to executing these predefined programs, thereby removing the data manipulation flexibility intruders would have if they were able to gain direct access to the tables (or even views) themselves.
Referential integrity (RI). Features such as foreign keys, triggers, user-defined data types, rules, and constraints that are intended to ensure that the data stored within the database remains consistent may also frustrate an intruder that is trying to insert, update, or delete illicit data in an ad hoc fashion. For instance, trying to delete a customer account may first necessitate purging all the client's transactions, which in itself may require tampering with the application's audit trail. Or as another example, trying to add a fictitious stock purchase transaction could require the intruder to simultaneously add an associated stock sale transaction. However, many DBAs disable RI on production databases in order to improve database performance (if no RI exists for the DBMS to enforce, then these resource-consuming operations will not be performed). Therefore, a tradeoff takes place between performance and security/data integrity priorities.
Whichever approach the database design calls for, the database schema that has actually been created in the production environment should be reviewed to ensure that all the intended methods of protection have been implemented correctly. In addition, tools such as AppDetective from Application Security (www.appsecinc.com) and Database Scanner from Internet Security Systems (www.iss.net) can be used to scan database implementations looking for DBMS-specific security vulnerabilities. Castano et al. (1994), Dustin et al. (2001), and Heney et al. (1998) provide additional information on database security measures.
engines enable a Webmaster to list words that should not be indexed. Either way, the internal search engine should be tested to ensure that it doesn't provide any sensitive information.
The defenses designed to protect an application's data are often an application's last line of defense. They should therefore be thoroughly exercised by the testing team, especially when you consider that unlike some defenses that are under constant attack (such as a perimeter firewall), an organization may never have had this final line of defense put to the test by a real attacker. Table 6.19 summarizes the checks that a testing team may want to consider performing as a means of determining if the data residing on the server-side portion of a Web application is adequately protected.
Table 6.19: Server-Side Data Checklist YES NO DESCRIPTION
□ □ Does the Web application's design specify which defensives should be put in place to protect data stored on the server side (with the possible exception of a deception-based defense)?
□ □ Have sensitive data files been given names that do not indicate their true purpose?
□ □ If the application has a database tripwire, does the on-duty support staff react to an alert appropriately, or are the alerts ignored?
□ □ Are any devices (or media) that are intended to be read-only or write- once actually write inhibited?
□ □ Are all data files protected from being corrupted, altered, or prematurely destroyed by an intruder using data vaults, WORM devices, data islands, distributed copies, DBMS-enforced constraints, and so on?
□ □ Are all sensitive data files protected from being read by an intruder using data vaults, encryption, deception, fragmented copies, and so on?
□ □ Has the desired database schema been implemented correctly in the production environment?
□ □ Has any internal search engine been checked to ensure that it does not return any confidential information?