About protecting a data access page

  • Article

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

This topic provides reference information about:

Protecting a data access page shortcut and its corresponding HTML file

Protecting and controlling database access from a data access page

Preventing unauthorized access from a malicious script

Protecting a data access page shortcut and its corresponding HTML file

A data access page is the combination of a shortcut stored in the Microsoft Access database (.mdb) or Microsoft Access project (.adp) file and a corresponding Hypertext Markup Language (HTML) file located in your computer's file system. To protect a page's shortcut and its corresponding HTML file from being renamed, deleted, or changed, use the file system's security of the computer where you have stored these files. For example, on your computer, you can make the Access database or Access project file that contains the page's shortcut read-only. Or on the Web server where the page's corresponding HTML file is located (after you have published the page), make the file and the folder where the HTML file is located read-only. For more information about file and folder security, see Microsoft Windows Help.

Return to top

Protecting and controlling database access from a data access page

Consider the following when you want to ensure secure access to the Access database or Microsoft SQL Server database that the page is connected to:

Protect the database You can connect a page to either an Access database or SQL Server database. You should provide adequate security to either database as a foundation for protecting access to the database through a page. As with any application, you need to prevent unauthorized users from accessing the database, and control the level of access once a user has logged in.

  • For an Access database, if it is protected with user-level security and you want to enable user-level security through a page, you need to make sure that the connection information for a page specifies the correct workgroup information file and that this file is in a public network share accessible to all users. in the Data Link Properties dialog box by clicking the All tab, double-clicking Jet OLEDB:System database, and then specifying the UNC path to the correct workgroup information file in the Property Value box. Learn about protecting an Access database.

    If you have set a database password on an Access database that is connected to a page, you will be prompted for the password the first time you view the page.

  • For an SQL Server database, if you want to use Windows NT integrated security to connect from a page, in the Data Link Properties dialog box by clicking Connection, and then clicking Use Windows NT Integrated security. Learn about .

Don't save the user name and password with the page   If the username and password to the database are saved with the page, any user can log in to the database. If you want the page to prompt the user to log in to the database, in the Data Link Properties dialog box by clicking the Connection tab, and then clearing the Allow saving of password check box.

Return records based on a user name   You might want to create a page that doesn't require entering a username and password through a page but can automatically detect who the user is, and display records based on that user. For example, you could create a page that allows users to change their personnel file. The general steps for doing this are:

  • Create a page in an Access project connected to an SQL Server database protected by Microsoft Windows NT integrated security.

  • Add a column to the employee table that has each employee's Windows NT log in user name.

  • Create a view that uses the suser_sname() function to detect the current user logged in, and make that view the page's record source.

For a detailed example of this, see the .

Return to top

Preventing unauthorized access from a malicious script

A page uses the Microsoft Office Data Source Control (MSODSC) to connect to its data source. When a user opens a page, the MSODSC on the page may use the user name of the user to log on to the database. A malicious page author could exploit this by using Microsoft Visual Basic, Scripting Edition or JScript running against the MSODSC to attempt access to databases on servers accessible to the user, but not the page author. The mode of data access used by the MSODSC determines whether a page is considered inherently safe, or if cross-domain data access is possible from the page. You can configure the MSODSC to use two modes of data access: two-tier or three-tier data access.

Two-tier data access is a direct connection to a data source in a traditional client/server fashion  the client (first tier) makes a direct connection to the database server (second tier). To perform two-tier data access, the MSODSC makes a direct connection to its data source through an OLE DB provider that is registered on the users computer. For an Access database, two-tier data access uses the local computers Microsoft Jet 4.0 OLE DB provider to connect to an .mdb file located on a network share. For an SQL Server database, two-tier data access uses the local computers Microsoft OLE DB provider for SQL Server to connect to a database server available on your local network.

Three-tier data access refers to using a third, remote component between the client and database components. Three-tier data access is typically used to access data across the Internet. For three-tier data access that uses the MSODSC, this third component is the ActiveX Data Objects (ADO) Remote Data Service (RDS) component (also called Data Factory) running on Microsoft Internet Information Server (IIS).

Any page that uses two-tier data access is considered by Microsoft Internet Explorer to be making a cross-domain access attempt. Depending on the security settings in Internet Explorer, when a user opens a page by using two-tier data access, one of three things occurs: the page is automatically disabled, the user is asked whether to allow data access, or the page is automatically enabled.

Internet Explorer security settings also define different security zones. If a page is on a Web server in a trusted zone, the cross-domain attempt can be enabled automatically. In a controlled environment, such as a corporate intranet, your pages will perform better if you use two-tier data access, and make sure that they are published from a server located in a trusted security zone. This is the simplest way to provide security against unauthorized access from malicious scripts. For more information about security settings, see Internet Explorer Help.

A page that uses three-tier data access to connect to a database is considered to be inherently safe regardless of what Internet Explorer security zone it is published from, and will not warn the user about cross-domain data access attempts when it is opened if authentication settings have been left to their default configuration.

For information about implementing two-tier or three-tier access, see the .

Return to top