Security | Programming Microsoft Office 2000 Web Components (Microsoft Progamming Series)

[Previous] [Next]

As soon as I start describing how the Office Web Components access databases directly from a client's web browser, developers start asking tough questions about how the DSC enforces security and protects clients from malicious page developers.

The DSC's security model is largely dependent on the data components and providers below the DSC. However, this component does add some interesting twists to the security model that are unique to the world of web pages. This section will discuss how the DSC works with the data source's security and how it works with Internet Explorer's security mechanism to block malicious page developers.

Database Security

As shown in Figure 5-1, the DSC communicates with an in-memory OLE DB provider, which in turn communicates with the data source by a private protocol. The OLE DB provider is on the client machine and acts as the gateway to the data source, either enforcing security itself or delegating security enforcement to the data source. Therefore, the DSC is subject to all existing security mechanisms enforced by the data source; only authorized users can access the data or make changes to the data source.

Put the DSC in the <head> Section in HTML Pages

If you look at the HTML source generated by the Data Access Page Designer, you will see that the designer places the DSC's <object> tag inside the <head> section of the document instead of inside the <body> section. This is legal in HTML, and it is an easy way to ensure that the browser doesn't take the DSC into account when dynamically laying out the document. Although the control is invisible at runtime, you will notice that if you include the DSC in the <body> section, Internet Explorer will initially display a small square where the DSC's <object> tag resides, reserving room in the document's layout. A second later, Internet Explorer realizes that the control is invisible at runtime and removes the square, laying out the document accordingly. You can avoid this rather annoying behavior by putting the DSC's <object> tag in the <head> section instead of in the <body> section.

An alternative to this approach is to use the style attribute in the DSC's <object> tag. If you add style="display:none" in the DSC's <object> tag, Internet Explorer will not include the DSC in the layout calculations, and it will not show the square icon when it initially loads your document.

The key DSC property for specifying the database connection is the ConnectionString property. The connection string you pass to this property is like the connection strings discussed in Chapter 4 and is identical to the connection string used in the ADO Connection object's Open method. A connection string consists of a set of attribute/value pairs specifying various pieces of connection information, such as the name of the data source, the initial catalog (database) to use, and the authentication information. This last piece is what concerns us here.

Different data providers use different security schemes, but these providers essentially fall into two categories: those that use an integrated security scheme and those that require specific user names and passwords. Integrated security schemes combine database security with network security, using the client's network credentials for authentication within the database. This approach obviously works only when the client and data source exist on the same network domain, or when there are mechanisms for sharing authentication information between domains. The second type of provider requires an explicit user name and password in the connection string or in response to a prompt dialog box, often shown by the provider itself. The DSC can use either type of provider, but for providers that require a user name and password in the connection string, the DSC will supply the prompt dialog box itself when these values are not present in the connection string. Many providers' prompt dialog boxes allow you to do much more than simply specify a user name and password. In fact, they are often complex and visually unappealing. For these reasons, the DSC displays its own simple dialog box for specifying a user name and password.

Most providers support only one type of security scheme, which makes your choice rather simple. However, some providers (such as the one for Microsoft SQL Server) support both types of security scheme, so you can choose which approach to use. To use integrated security, include "Integrated Security=SSPI" in your connection string. To use an explicit user name and password (called standard security in SQL Server), include "User ID=user name;Password=password" in your connection string. Typically, you should use integrated security when you know that the client and server exist in the same domain and when you do not want to require users to log on to your application in addition to logging on to the network. You should use standard security when you know that the client and server are not on the same domain or when you want the user to have a different password for your application than his or her network password. Standard security is also the correct scheme to use when accessing your database from code executing on a web server, as the following sidebar discusses.

Use Standard Security for Code Running on a Web Server

I have spent many a stressful day preparing for a demo, wondering why code that worked fine in a web page on my machine no longer worked when run in a Microsoft Active Server Pages script. The answer makes perfect sense if you understand how Microsoft Internet Information Server works, but for most developers, this gets quite confusing.

The web server and the code executing your ASP page are running as a Microsoft Windows NT service. Each Windows NT service can run as a local system account or can log on to a domain as a specific user account. Depending on how the service is configured, it can have radically different permissions. By default, IIS is set up to run as a local system account, with few to no privileges on other network resources. This means any code attempting to connect to a SQL Server database generally will not have permissions to access SQL Server itself—much less, the data within it. It also doesn't help that the account is a local system account on the web server, which is not an account in the Windows NT domain. Therefore, you cannot grant the account access to SQL Server via integrated security.

You might think that if you used the Windows NT Challenge/Response security mechanism on your web site, you could work around this. Think again. If you disallow anonymous access to your web site and allow only clients that can get past the Windows NT Challenge/Response security mechanism, your ASP code will run using the client's security credentials. This process—called impersonation—applies only to resources on the current machine, which in this case, is the web server. As soon as you try to connect to a network resource on a different machine, the impersonation stops and you again begin running under the IIS service's credentials. This behavior is intentional; otherwise, a serious breach in security would be allowed, permitting people to "spoof" a client and perform tasks on other network resources using the client's security credentials. Windows 2000 promises to allow cross-machine impersonation in a secure manner, but until that release, the preceding information is correct.

Using SQL Server's standard security avoids this whole mess. You create a special user logon to your instance of SQL Server that represents a "web user" and grants permissions to that account accordingly. However, make sure that web clients cannot obtain the source code for your ASP scripts because that would reveal the password and user ID for the account.

You might also consider configuring the IIS service to log on using a domain user account. IIS will use this account when accessing any resource. However, this approach has one land mine. When you configure IIS to use a domain account, you must also enter the domain password for that account so that IIS can log on to the domain without prompting. The domain password is stored on the web server but does not automatically reset when that account's password is changed. I did this once with a web server I had in my office, and one day the entire web server stopped working. It took me a while to realize that I had changed my domain password that morning because it had expired, but the IIS service was still trying to log on to the domain using my old password.

Cross-Domain Data Access

All the information I have covered so far is applicable to any OLE DB client application and has nothing to do with the DSC or the rather unique environment of the Web. However, because our team designed the DSC to operate in a web browser as a signed control that is "safe" for initialization and scripting, we had to add functionality prohibiting malicious page developers from doing damage by using the client's security credentials.

There are primarily two features of the Web and data access that, when combined, offer a frightening potential for mischief. The first is that web pages raise an event when initially loaded (the Window object's onLoad event) in which a developer can execute any script he or she wants. The code is run without asking the browsing user, and without warning, this code can call any method or property of any object that is marked as safe for scripting. We already discussed the second feature: integrated security. When connecting to a data source using integrated security (which for some providers is the only way you can connect), all access to database objects is tied to the client's user credentials. If the client has access to a table, view, or stored procedure, any code running on the client's behalf can access these objects without showing the user any warning.

To illustrate the problem, let's put these two features into a hypothetical situation. Suppose Celeste is an employee in the HR department of your company. She has access to the HR database that contains your salary information and has the permission to change data when necessary (for example, when you get a raise). Now suppose that Brent, an employee you just fired and gave the afternoon to clear out his workspace, is quite disgruntled. Brent develops interactive pages using the Office Web Components. He knows that he can write script in the Window object's onLoad event handler to connect to and access a database, because he typically does this when building reports or data entry forms. Brent decides to get even with you by writing a page that will attempt to access the HR database using integrated security and delete your salary information. He can't run this page because he has no access to the HR database, so the code will generate an error when it attempts to connect using the DSC. But Brent knows that Celeste has access. So Brent sends the page to Celeste as an HTML e-mail message with an enticing title that tempts her to open it. The page opens, the onLoad event fires, and the code connects using Celeste's credentials, deleting your salary information. Celeste doesn't even know what happened until later when you've complained and her boss asks her why she deleted the salary information.

The good news is that this scenario cannot occur; we specifically designed the DSC to warn the user when the page attempts to access a data source that is not in the same domain as the one from which the page originates. In this case, the word "domain" refers to an Internet or intranet domain rather than a Windows NT domain. (A single Windows NT domain might contain many Internet or intranet domains.) So if our fictitious Brent tried to perform the sabotage just described, Celeste would see the warning message shown in Figure 5-2.

click to view at full size.

Figure 5-2. The cross-domain data access warning.

To understand how the cross-domain data access warning feature works, you need to understand the following:

What defines an Internet or intranet domain.

How to control this option so that the user can suppress the warning if he or she trusts the site from which the page originates.

An Internet or intranet domain is essentially the first part of a URL. For example, the domain for http://www.microsoft.com/office is www.microsoft.com, and the domain for http://MyServer/folder/page.htm is MyServer. In the latter case, any URL that starts with http://MyServer is considered to be in the same Internet or intranet domain. However, an instance of SQL Server running on the same machine as the web server is still considered to be in a different domain, as are any file shares exposed from the server. For this reason, most direct data access is inherently cross-domain unless you use RDS, as described in the next section.

So now you know why you must warn users before code in a page accesses data sources on a different domain than where the page originated. But what about when the user knows that the page came from a trusted source and wants to suppress this warning? For example, suppose Celeste regularly works with another web-based tool to view and manipulate employees' records. The easiest way for her to suppress this warning is to add the site from which this page originates to her trusted sites list in Internet Explorer. By doing so, Celeste declares that she trusts the site from which this page comes. This causes Internet Explorer to run the page in the trusted sites zone, which has lower security settings than the browser's Internet or local intranet zones. To add the site to her trusted sites list, Celeste uses Internet Explorer's Trusted Sites dialog box, shown in Figure 5-3.

click to view at full size.

Figure 5-3. Adding a site to the trusted sites list.

The trusted sites zone in Internet Explorer defaults the Access Data Sources Across Domains security setting to Enable. This security setting controls whether the current user sees the cross-domain data access warning. The user can set this option explicitly for a specific zone by clicking the Custom Level button on the Security tab of Internet Explorer's Internet Options dialog box and using the Security Settings dialog box that appears.

NOTE
If you are running Internet Explorer 4.01, you will not see this security setting in the Security Settings dialog box. Microsoft added this option to Internet Explorer 5.0 to make this security setting easier to set. In Internet Explorer 4.01, the DSC uses the setting titled Script ActiveX Controls Marked Safe For Scripting instead.
Since using the trusted sites zone works the same for versions 4.01 and 5.0, it is a better choice than adjusting the individual security settings.

Be aware that you can add a portion of a web site to the trusted sites list. For example, if you add http://MyServer to your trusted sites list, Internet Explorer will trust all pages from this site. If you add http://MyServer/MyFolder to the trusted sites list, Internet Explorer will trust all pages starting with this URL. However, Internet Explorer will not trust pages from http://MyServer/MyOtherFolder, and pages from this site will fall into the local intranet zone.

You might be wondering why we did not just mark the DSC as "unsafe" for initialization and scripting. The answer, I hope, is obvious. If we had done that, any page including the DSC would generate warning messages both when the control was initialized and when any code used its methods or properties. There would be no way to suppress the warnings and no way to build applications (that would automatically suppress warning messages) that users could trust. We designed the DSC so that you can create complex custom solutions that run in a web environment and produce no warnings when trusted by the user. However, the DSC also ensures that users are protected from malicious developers.

In What Zone Does HTML E-Mail Run?

When the Microsoft Access team first designed the data access pages feature, they were excited about the potential for sending one of these pages via HTML e-mail. Instead of e-mailing a routine report as an attachment, the report itself would be the message. Then our team hooked up the cross-domain warning. To our dismay, the warning displayed every time we opened an e-mailed report, and there seemed to be no way to suppress it. Microsoft Outlook always considers HTML e-mail to be from the Internet zone, even if it comes from within your organization; therefore, it is always suspect. You cannot add HTML e-mail to your trusted sites list because it isn't an actual site that has a URL. If you plan to send pages containing the DSC, they will always generate the cross-domain data access warning unless your users enable the security setting noted earlier for the Internet zone. (This is a bit risky though.) However, if you send a link to a page from a site on the user's trusted sites list, you will avert the warning.

Can I Add My Site to the Trusted Sites List Automatically?

A few developers have asked me whether any way exists to programmatically add their web site to a user's trusted sites list. To my knowledge, this is impossible—and for good reason. Such a capability would create a gaping security hole because it would enable a developer to add his or her site to the list and redirect the client's browser to a malicious page. However, the Internet Explorer Administrator's Kit does allow a corporation to prepopulate the trusted sites list in a network install setup. When a user installs from such a setup, his or her trusted sites list will automatically contain the sites from the prepopulated list.