MORE INFORMATION
Active Server Page (ASP) Code Is Displayed Rather than Processed
Page
If you activate a component (for example, click
Start Search in a Search
Component) on a Web page that contains a browse-time FrontPage component
and
either Active Server Pages (ASP) or server-side scripting code, you see the ASP
code
rather than the result of the ASP. This behavior potentially can cause
problems
if a knowledgeable user exploits this behavior to gain access to sensitive
data
(such as a user name or password) embedded in the ASP source code.
When some FrontPage components are activated on a Web page, the Shtml.dll
file, a FrontPage Server Extensions browse-time file, is called. The calling
page
name is then passed as a value to the DLL. The DLL parses the Web page,
performs
whatever actions it should based on the components on that page, and then
returns the appropriate results. If the page that contains the activated
run-time component also contains ASP code, Shtml.dll parses the page and
returns a
Web page that contains the actual ASP code rather than the processed
results of
the ASP script. Normally when a Web page that contains ASP code is invoked
from
the browser, the Asp.dll file processes the ASP code and dynamically generates
a Web
page with the expected results. However, since a FrontPage component
invokes
Shtml.dll, passing the Web page name as a value for it to parse the page,
Shtml.dll, not Asp.dll, is responsible for processing the page. As a
result, the
page returned to the browser still contains the unprocessed ASP source
code.
This update does not remove any functionality that a Web developer might
be
using today. If a Web developer actually tries to combine these two
technologies
on a page, the developer will not achieve the intended result, because the ASP will
never
be processed. However, although it is unlikely anyone would design a page
that
combines these two technologies, there is a remote chance this combination
of
technologies could be exploited to gain read-only access to ASP source
code and
potentially sensitive information (such as user names and passwords). This
issue
was discovered internally, and to date we have had no reports from
customers
regarding this issue. However, with this update we have taken steps to
ensure
that no customer will encounter this.
The update addresses the issue by doing the following: If a page has
either ASP
code or server-side scripting, the update does not allow Shtml.dll to
process
that page. If a Web page or someone attempts to pass the ASP code through
Shtml.dll, a standard error appears, prompting the customer to contact
the
Web site administrator. The Web site administrator can check the event
log. This log contains an entry indicating that the attempt to fetch a non-HTML
page
was not completed. This update effectively eliminates the possibility of
exploiting Shtml.dll to view unprocessed ASP code or viewing ASP code in a
run-time component and ASP combination situation. Please note that this in no
way
limits or restricts the proper use of ASP code or server-side scripting on
your
Web site.
In this update, a setting has been added for the Frontpage.ini file called
"RunTimeFileExtensions." In addition to the above cases, if Shtml.dll is
invoked, it returns an error if the requested page has a file extension that does not match a file extension specified as the value of "RunTimeFileExtensions." By default, this value is .htm and .html. This new setting gives Web
administrators
who use custom file extensions for their Web pages to further enable
or
control which pages can be parsed by Shtml.dll. For more information about
this
setting and the update, please refer to the FrontPage Server Extensions
Resource
Kit.
Discussion Web Sorting
In the shipping version of FrontPage 98, you can create a discussion Web
using
the Discussion Web Wizard. In the wizard, you can sort your discussion Web
messages in chronological or reverse chronological order. Specifying
reverse
chronological order in the wizard has no effect on the actual, run-time
sorting
of the discussion Web messages, and the messages are actually sorted in
"forward" chronological order.
Discussion Web Table of Contents
Under some conditions, it is possible that a discussion Web table of
contents may
not list all messages that actually exist in the Web. When you recalculate
a
FrontPage extended Web, the pages are enumerated and their hyperlinks are
recalculated in the order dictated by file system date. The Writeto.cnf
file
(located in the _vti_pvt folder of the Web) contains a list of the Web
pages
that contain "backlinks" to files where a browsing user is authorized to
post
new data. The discussion Web table of contents file (<discussion
name>toc.htm in
the discussion Web) is one such file. At the beginning of the
recalculation,
Writeto.cnf is cleared. As the recalculation processes each file, it adds
the
names of the proper files to the Writeto.cnf file. If the discussion Web
table
of contents file is processed before all of the message files, the table
of
contents will not display entries for those message pages that have not
yet been
recalculated.
The update corrects this problem by recalculating the table of contents
page
last, ensuring that all message pages are listed.
Discussion Webs and Microsoft Index Server 2.0
If a FrontPage discussion Web is indexed and queried using Microsoft Index
Server 2.0, the search fails. This update corrects this issue by
ensuring
that Index Server 2.0 indexes those files that exist in the special
discussion Web folders on your FrontPage extended Web.
Nortbots.htm with Disk-Based Webs
When you create a disk-based Web with FrontPage, the run-time components,
such
as the Search Form and the Save Results Form Handler, do not function
properly
until the Web is published to a Web server on which the FrontPage Server
Extensions are installed. If you activate a browse-time component on a
page from
a disk-based Web, an end user receives a page that displays this
message:
No Run-Time Bots Available.
This page is called Nortbots.htm. This is meant to inform users that they
need
to install the FrontPage Server Extensions in order for the run-time
components
to function and that they are browsing against a Web on which the
FrontPage
Server Extensions have not been installed.
When you publish a disk-based Web to a Web server that has the FrontPage
Server
Extensions installed, this message is no longer necessary, because the "Run-Time
Bots" functionality is now available. However, the links to the
Nortbots.htm
page still exist in the Web pages that contain the run-time components.
This can
result in the following error message when you activate a run-time component:
HTTP/1.0 404 Object not found.
This update corrects the problem by removing the links to the Nortbots.htm
page
when you publish your content to a FrontPage extended Web site.