One particular area of concern is the new Remote Data Service technology that provides client-side data-binding for Web pages over HTTP. This is a very powerful new technique, and allows you to create Web pages that provide fast and responsive access to data on your server. These pages can be used to edit the data, and the updates are automatically made back on the server. We've used it to advantage in our Wrox Car Co sample application.
RDS Security Risks
RDS is completely unlike any previous technique for displaying and updating data over the Web. With CGI applications, Perl scripts and ASP, we are used to sending just an HTML page containing the results of a query to a data source, and not a 'real' recordset that could be manipulated on the client. RDS is more like the traditional client/server model, where actual recordsets are moved across the network to the client.
Preventing Remote Data Updates
In traditional Web applications, there was no way users could update the source data directly. This required an equivalent server-side component (application or script) that collected the information they submitted from a form in the page, and the component updated the data source. In RDS, however, the browser will quite happily update the data itself—so you need to make sure that you set appropriate permissions.
If the data is available for read-only purposes, use the database security methods to lock it against all updates by specifying Read permission. You can do this in the ODBC driver for some data sources (like Microsoft Access for example). If it's supposed to be read-only for some people but updateable to others, make sure you have separate accounts for the two groups with the correct permissions on all objects in the database.
Distributing Connection Information
As well as the danger of the client automatically being able to update data on your server, RDS also introduces a new area of risk. In order for the client-side page to connect to the data source and build a recordset on the client, it has to have the connection information. When you put the database name, username and password in the page, you are inviting them into your database as surely as if you gave them the keys to the building.
There's no easy way round this. When the user loads a page of data created by an ASP script they have no indication at all of where the data came from—it's just HTML code and text. If you use RDS, however, you have to tell the browser where to get the data from. No matter how you try to hide this (for example using a client-side ActiveX control that the user downloads to make the connection) you can’t stop them from modifying the HTML or copying the information to create their own query page.
RDS pages are usually simple HTML files with the
file extension. RDS works just as well when pages like this are loaded from a local hard disk as when loaded from your server over the Web..htm
This means that you must be even more vigilant about the permissions available to users for that database. You might like to consider creating a special account with no password, and using that in cases where RDS data access is required. Within each database allow this account only the minimum level of permissions, and always use read-only unless the users have to be able to update the tables.
Distributing Table Structure Information
As well as the connection information, RDS pages often contain SQL strings that are sent to the data source to create the recordset for the page. This is a prime example of where you should be using views, queries or stored procedures to create the relevant recordsets.
For example, if you want to provide a staff telephone list using fields from the main employees and departments tables, create a view that contains only the fields required for the list. Don't be tempted to give the user an SQL string in the page containing the real table names. They might just guess that the employees table contained a
column, and create their own RDS page to see what's in it. Even if the table is read-only, so that they can’t change the contents, you would probably want to prevent them seeing it at all. Salary
Remember that the SQL string and the HTML attributes within an RDS page provide the field names of the recordset. You can change the names of the fields within a query or stored procedure from those in the source tables, so that the user cannot apply them to the original table should they be able to get access to it.
RDS and MTS Impersonation
One real security hole with RDS at present occurs when it is used with Microsoft Transaction Server. This is an underlying issue with COM, which caches identities of components between process calls. What this means in practice is that, if you access a component through the RDS
object, MTS will cache the security context. If someone else then accesses the component in the same way, they will run in the security context of the first user. This problem is due to be fixed with Windows NT5, and at the time of writing there was no 'hotfix' or patch available.DataSpace