Privacy and Integrity Overview

[Previous] [Next]

Privacy should be an incredibly important consideration for you; it is for your users. Just about all privacy breaches on the Web are jumped upon by the media to fuel the argument that commerce on the Internet is dangerous and should be avoided. It's an incredibly sensitive subject, and, to complicate matters, it's even difficult to reach a consensus on the definition of privacy! Quite fortunately, adding privacy technologies to your application is simple, and most privacy problems are easy to remedy.

Like privacy, integrity is also of paramount importance: changed or deleted data can lead to wasted time while data is rebuilt or restored from backups or, worse, the integrity attack might go unnoticed and decisions might be made based on incorrect data.

Privacy Statements

It's recommended that your Web site include a privacy statement to let users know what data you collect about them and how you intend to use it. For example, it's common to include a privacy policy link at the bottom of a Web site's home page.

You can get information on privacy policy and privacy statements at the TRUSTe Web site at www.truste.com or from the Better Business Bureau at www.bbbonline.com. The TRUSTe Web site includes an excellent wizard to help you form the basis of a privacy statement.

Note that a law was passed in April 2000 in the United States requiring all Web sites that ask for certain information about children under age 13 to receive permission from parents to gather the information. The rules are part of the 1998 Children's Online Privacy Protection Act, and there are stiff fines for violators. Refer to http://www.ftc.gov/bcp/conline/edcams/kidzprivacy for further details.

Finally, if you offer a privacy statement, it's crucial that you adhere to it!

Ensuring privacy is all about mitigating information disclosure threats (the I in the STRIDE model, first described in Chapter 2, "A Process for Building Secure Web Applications"); integrity issues involve tampering with data threats (the T in the STRIDE model). We discussed some of the approaches used to mitigate these threats in Chapter 2, including the following for mitigating information disclosure threats:

• Using strong access control mechanisms
• Performing correct file canonicalization
• Limiting specific file operations
• Employing end-to-end encrypted data transfer protocols
• Not storing secrets of any kind in configuration files, unless you're using secure encryption mechanisms

You can use the following methods to mitigate data-tampering threats:

• Using strong access control mechanisms
• Requiring hashes and digital signatures on resources
• Employing end-to-end tamper-resistant data transfer protocols

What Is Canonicalization?

Canonicalization is a way to reduce a name to its canonical—meaning, in this case, standard or recognized—form or forms. For example, in Microsoft Windows 2000, a username can appear in one of two forms: user principal name (for example, [e-mail]) or Security Account Manager (SAM) name (for example, EXAIR\Cheryl).

Other canonical name variations include those for server names: you can use a Domain Name System (DNS) name (for example, webserver.explorationair.com), a NetBIOS name (such as \\webserver), or an IP address (such as 172.0.0.42). In NTFS, a filename can take the long form, such as ThisIsALongFileName.doc, or the FAT 8.3 filename, such as ThisIs~1.doc. If you make decisions based on the name of something, it's important that you use a canonical representation of the name. You can choose which canonical form to use for each type of name, but you must be consistent.

You'll notice that privacy and integrity issues are often deeply intertwined. If an attacker has illicit access to data, he might also be able to modify the data. For example, compare the following access control lists (ACLs) used to protect a file. The first ACL allows every user to have read access:

• Administrators (Full Control)
• System (Full Control)
• Everyone (Read)

The next ACL allows every user to have read and write access to the file:

• Administrators (Full Control)
• System (Full Control)
• Everyone (Read & Write)

The first ACL could lead to an information disclosure threat if other security mechanisms fail—the last access control entry (ACE) in the ACL allows all users to have read access to the resource. The second ACL is much more troublesome; it could yield a data-tampering threat because the last ACE allows all users read and write access to the resource. As you can see, a single ACE can change the vulnerability from a privacy issue to a privacy and integrity issue.

You can mitigate this by replacing the Everyone ACE with a Windows 2000 group ACE and adding trusted users to the new group. If you do this, only users known to you will have access to the resource. The new ACL looks like this:

• Administrators (Full Control)
• System (Full Control)
• WebAuthors (Read & Write)

The moral of the story is to use appropriate ACLs on protected resources.