Monday, February 11, 2008

Using Subwebs Strategically to Increase Security

If you want to publish a restricted web that contains sensitive data, be sure to publish it as a subweb and not as a root web. An unauthorized person who knows how information about a FrontPage-based web is stored on the Web server can find certain information - such as the version of the FrontPage server extensions, the server type, and URLs for scripts - that always exists at the root web level. Someone could potentially use this information as a starting point for intrusion. Creating secure subwebs for sensitive information puts a level of security between your data and the root web.
A feature of subwebs in FrontPage is that you can set the subweb to use permissions that are different from the parent web. If you create subwebs to store sensitive data, remember that the security of a subweb can never be greater than that of its parent web.
For example, if you create a restricted subweb under an unrestricted root web, the subweb is potentially visible to anyone who accesses the root web. Someone knowledgeable about remote procedure calls used by FrontPage could discover the folder that contains the subweb and use the folder name as a starting point for intrusion. Additionally, an intruder who knows the full URL of a page within the restricted subweb could possibly bypass the subweb's security by typing the URL in their browser.
To restrict access to a subweb, you must first restrict access to its parent web. In FrontPage, select the Only registered users have browse access option in the parent web. If your Web server is Internet Information Server running on a Windows NT server, set the parent web with the following security settings:
For authentication methods, disable anonymous access.
In the Microsoft Management Console for Internet Information Server, right-click the web, and then click Properties on the shortcut menu.
On the Directory Security tab, click Edit in the Anonymous Access and Authentication Control section, and then clear the Allow Anonymous Access option.
Make sure the Everyone group is not granted explicit access.
In FrontPage, on the Groups tab of the Permissions dialog box, remove the Everyone group, and then click Apply.
On the Users tab, click Everyone has browse access.
Make sure the IUSR_computername account is not granted explicit access.
In FrontPage, on the Users tab of the Permissions dialog box, remove the IUSR_computername user, and then click Apply.
On the Users tab, click Everyone has browse access.

No comments: