| This page will give you
information on how to implement security for your applications and
gives you pointers to the chapters in which you can find the full
description of the mentioned features.
The page contents:
What kind of protection is needed for the ALP applications.
The ALP applications are virtual ALP sites running on the local
machine. They are accessed through requests that are characterized by
URL. This means that a locally running ALP application may be invoked
in-place in a browser window used by the user to browse the Internet
if the user enters an ALP URL in the address bar or if the user clicks
a link, submits a form that uses an ALP URL. Also a redirection to an
ALP URL may occur if it is invoked by a script on the WEB page shown
in the browser. This opportunity can be useful when you want to create
with ALP an application that tightly integrates with an online WEB
site and transfer the control back and forth from the WEB site to the
local application and reverse, but this is also a potential security
hole as it allows a malicious user to create a WEB page that will
invoke a page from your application with parameters that may cause it
to perform harmful operation. Thus the major risk you should be aware
of is protection from unattended execution - page from your
application invoked without user intention.
ALP provides security features that allow the developer protect the
application from malicious attacks without need to change the
application code. The ALP security features are split in two areas:
- Security features implemented by ALP
engine itself. They apply to any browser (i.e. can
be used in both Internet Explorer and ALPFrame) and have general
effects.
- Security features in the ALPFrame browser.
These are called also Browsing restrictions and allow the
developer restrict each particular instance of ALPFrame browser to
certain virtual ALP sites, WEB sites and other locations. These
features are also useful even without ALP application running in
the ALPFrame browser, because they allow administrators of
corporate intranets to configure special ALPFrame browser
instances that would allow the users to access only the sites
considered safe by the administrators. For example an ALPFrame
instance can be created that allows access to the intranet sites
and a few Internet sites needed by the employees to perform their
tasks, but denies any browsing action outside these boundaries.
Thus the employee would need to open separate (another browser)
browser if he/she wants to browse other Internet sites - which can
be also forbidden by the administrators, thus eliminating even the
possibility that the user will expose him/her-self to a phishing
site for instance.
Additionally the ALP applications can specify their browser
requirements. For example an ALP application may be configured to
refuse to run in Internet Explorer and require ALPFrame because of its
advanced features (this has also non-security oriented benefits - for
example the application may need some ALPFrame features and informing
the user that he/she started the application incorrectly may be of
some use, no matter that usually the installation creates appropriate
shortcuts - every developer knows that there are users who like to dig
into the file system for fun). Additionally each ALPFrame instance can
be marked with APPID signature which allows the ALP applications
require even more - not just ALPFrame as browser, but ALPFrame
configured especially for them.
Together these two series of features allow the developer tighten
the security of the application up to the level that will prevent any
security risk for the user's machine.
These features are controlled by a few options in the ALP
directory settings. You can open the ALP Settings
shell extension in the directory that contains potentially
vulnerable parts of your application and go to the Directory
settings to configure them. These settings are:
Main options
Prevent unattended execution - The corresponding option in
the alp.directory file is (int)SafeEntrtance
in the Access section.
When set this option enables ALP to maintain locked/unlocked
state for the application. When the application is in locked state
only the default documents which are listed in the directory
settings (configured in the same dialog box) can be executed. When
in unlocked state - any URL that points into the application will
be processed.
The state is maintained on directory level - i.e. it applies to
all the directories that use these ALP directory settings.
Initially ALP starts in locked state, thus allowing only the
default documents to be executed/served. Once a default document
is executed/served the state changes to unlocked automatically.
The effect: Usually noone would implement potentially
dangerous code in a default (start up) page. Potentially dangerous
code is a code that performs system operations - writes to file or
databse, edits system settings and so on. Even if you have such
code in your default page everything you need to do is to create
an entrance page without any risky code in it and configure it as
default document.
Advanced: ALP supports also a special header that can be
sent by the applications to turn on the locked state over the
directory at any time. The header is: ALPHeader-ResetSafeEntrance.
In ASP page you can use:
Response.AddHeader "ALPHeader-ResetSafeEntrance",""
In CGI application this should be sent as regular header with
empty content.
This allows the application to turn on the lock each time it
completes certain task. In regular applications there is no reason
to use it, but certain applications types may need additional
security protection. For example this is relevant for browsing
companions - for example ALP application running combined with the
newObjects IE ScriptBar.
Such an application would stay active while the user browses the
Internet and process certain requests (such as record favorite,
index page etc) and if the user reuses the browser this may
continue even days. Thus for such an application it is a must to
disallow any unsafe requests when there is nothing to be done. In
such an application each task usually needs that the user would
pass through a few pages to specify the details about the task and
completes. Then the last page should send the header to turn on
the locked state and disallow unattended requests that may pose
security risks.
Security URL - When non-empty this allows the developer
specify an URL that will impersonate all the content served from the
directories affected by the ALP directory settings in which it is
specified. Thus it means that the content will be treated by the
browser as if it comes from the URL specified and not from the local
file system. The corresponding alp.directory
file option is (string)SecurityURL in the Access section.
By default this is empty and the content is treated by the
browser as local content (from the Local Machine zone). When it is
non-empty it should specify a WEB site (or directory in a WEB
site) and the content will be treated as coming from there and
will fall into the same security zone as the WEB site specified.
The effect: This is especially useful for applications
that integrate tightly with an online site. The setting concerns
mostly the DHTML content served and most importantly the client
side scripts in it (JavaScript for example). Thus the cross-frame
scripting will be disallowed by the browser if you use a frameset
that shows local ALP content in some frames and online
content from your WEB site in others unless the security URL for
the local ALP content matches the online site URL. In other
scenarios where the ALP application has nothing to do with a
particular online site it is recommended to leave this field
empty.
Advanced: You may need to declare also the content
secure if the online site uses https (SSL).
Troubleshooting: When the Security URL is not
empty problems may occur if the application runs from a removable
media. This concerns mostly applications that use a frameset page
is their start page. If the frameset page contains/loads scripts
(for example by using <SCRIPT SRC= ...>) it may get loaded
incorrectly or not load at all. This is caused by the cross-frame
security initialization in the Internet Explorer and ALPFrame. If
you need non-empty security URL in such an application you can
avoid the problem by putting a simple entrance page (non-frameset
page without scripts in it) where the user would click a link to
enter the actual application.
Advanced options
- Declare content secure and Declare content safe - The
corresponding options in the alp.directory
file are: (int)ContentIsSecure and (int)ContentIsSafe. Only the
first option has substantial effect (see the advanced section about
the SecurityURL above) while the other option is disregarded by the
browser in almost any practical scenario.
The detailed description of ALPFRame configuration settings that
control these features can be found in the ALPFrame
configuration page. Here we will describe only the concepts. ALPFrame
browser is based over the Internet Explorer core and thus only
extends the IE functionality. IE allows certain browsing
restrictions, but these settings are applied to the machine as whole
and there is no way to prepare several different IE instances that
have different restriction settings on the same machine. On the
other hand ALPFrame supports cascaded configurations and the
developer/administrator may create several different configurations
and for example several different shortcuts that invoke ALPFrame
with one of them each. Effectively this would look as like the user
has several different browsers each of them configured for certain
purpose. While this is rarely useful for general WEB browsing it is
something many administrators look for when they need to prepare
browsing environments for certain WEB/ALP applications only. For
example this applies to networks in organizations that use ALP
and/or Intranet applications in their work. In such a scenario it is
often a good idea to have a separate browser for the production
applications and another (or none) for the random WEB browsing. Such
a practice minimizes the security risks - even such that were not
predicted and many administrators are forced to install different
WEB browser applications and instruct the users and define policies
that will force them to use each browser for certain work only. As
the ALP applications would play role similar to the intranet
applications having such a feature built-in is a plus that allows
the administrators implement the working environment without need to
look for 3-d party software. How it works: The ALPFrame
configuration may contain a BROWSING section that specify the
browsing restrictions. If the section does not exist no restrictions
apply, if it exists the settings in it are applied. The browsing
restriction settings consist of a default restriction level and
arbitrary number of profiles the developer/administrator may define
to specify restrictions to groups of URL/sites or protocols. None of
these settings affects the ALP application(s) located in the
directory (and its sub-directories) where the effective ALPFrame
configuration file is located. This application(s) is assumed
non-restricted and would always work even if everything else is
forbidden. Thus with a single option one can apply ultimate
protection in the most scenarios that concern ALP applications. In
more complex scenarios (where online sites are integrated for
example) the profiles allow the developer/administrator define
whatever level of restriction is required. The ALP Settings
shell extensions provide interface for the ALPFrame configuration
and include the browsing restrictions. Note that ALPFrame settings
are applied in a bit different manner than the other ALP settings.
They take effect only when an ALPFrame browser starts, this the
specific ALPFrame configuration you compose must be located in the
startup directory of your application. Further details about the
cascaded ALPFrame configurations you may learn in the ALPFrame
configuration. The reasons behind this behavior are simple - the
configuration effectively defines a specific ALP/WEB browser with
specific behavior. It is not suitable to allow this to change at
run-time because it would make the browser's behavior unpredictable
and the application that counts on a particular configuration may
experience problems if the configuration changes. What
kind of restrictions can be applied? There are 5
policies: Allowed - Access always allowed
Ask first time - The user is asked if he/she really wants to
go there the first time he/she attempts to browse an URL covered by
this policy.
Ask always - The user is asked each time he/she
attempts to browse an URL for which this policy applies.
Forbidden with message - The navigation is prevented with a
message.
Forbidden silent - The navigation is prevented without
indication why. On of these policies is specified as default
setting and if the developer needs something more complex he/she
creates profiles and lists in each of them the locations or
protocols he/she wants to treat as a single zone and specifies a
policy for them. For detailed information on how to configure this
see ALP Settings shell extensions
and the ALPFrame configuration. The
APPID of the ALPFrame configuration. The developer may
want to prevent a sensitive application from running by accident in
misconfigured ALPFrame browser or in Internet Explorer. To do so the
developer can specify in the ALP Application settings browser
requirements - see Browser in ALP
Application settings dialog and the corresponding configuration
entries in alp.application: (int)RequireALPFrame
and (string)RequireAppId. The developer specifies an APPID in the
ALPFrame configuration (see Configuration ID name in the ALPFrame
configuration dialog) and specifies the same APPID in the ALP
Application settings. If the application by accident is started in a
wrong browser that is not loaded with this ALPFrame configuration
the ALP Engine will generate an error message and prevent the
application from running.
While ALP itself can aid you in implementing application
protection with a few settings, the specific application
functionality is up to you. For instance using the NetStreams
components from the ALP
run-time library you can implement custom networking
functionality, you can even run server threads in the background of
your application. What you do there is your responsibility and you
should take care to evaluate the potential risks for your
application and implement them in a fashion that would not expose
the user's machine to attacks. When you implement functionality
that involves file/database writes, sending information to other
machines, system management or management of other sensitive data
you must consider the possible risks. Never forget that each page in
your application can be invoked directly unless you turn on the
unattended execution protection (see above). If the application you
are building is such that the user may want to keep it running for
long periods of time it is better to design it to run in ALPFrame
browser configured for it only. alpframe:// helper protocol.
As you may already learned from this documentation this helper
protocol allows links in IE invoke the ALPFrame browser with the
rest of the URL - for example: alpframe://alp://C:/myapp will
invoke ALPFrame with the alp://C:/myapp URL. This will invoke
a new instance of ALPFrame to be started. If the directory pointed
by the ALP URL contains ALPFrame settings they will apply to this
ALPFrame instance. Having configured both unattended execution
protection turned on and ALP Application requirement for ALPFrame
with marked configuration (See the discussion about the APPID above)
will make it absolutely impossible for any malicious user to attack
it. If the application is highly sensitive better forbid any
external browsing in the ALPFrame configuration for it (set the
default policy to "Forbidden (silent)" for example) to
disallow attackers to delude the user to do harmful operations. In
fact an ALP application running in ALPFrame with special
configuration and forbidden external browsing behaves just like a
regular desktop application which puts it in the same security
class. Most applications that do not integrate with an online site
tightly do not need to behave in a manner different from the typical
desktop applications. All they will gain with less restricted
security is the ability to execute them in-place in already running
browser used by the user to do something else. If such a feature
would not bring substantial benefits to your application you can
just employ all the protection mechanisms and make your
application's behavior equivalent to regular desktop application.
This may sound paranoid to some developers, but it is always a good
idea to tighten the security up to the point which would not disrupt
the application functionality even if it looks too much - noone
knows what may happen tomorrow and what you consider secure today
may pose a risk tomorrow. Therefore closing all the doors from which
an attack may come is a guarantee that your application will
continue to be safe in future, no matter if you have missed
something. Applications that need to remain partially
"opened" to serve certain purposes should be evaluated
more carefully and the developer should take care to employ every
security feature suitable to guarantee their correct usage no matter
how good the user understands the application functionality.
Consider the unattended execution protection and the ALPHeader-ResetSafeEntrance
header (see above) usage in a fashion that would not keep the
application opened when the user does not need it.
The security features ALP supplies are simple yet enough to allow
the developer protect the application from malicious attacks.
Usually no code changes are needed except in specific applications
that actually extend the WEB browser and thus need to pay more than
usual attention to the security. The applications that run in
ALPFrame may combine the both methods and thus make absolutely
impossible to attack the application by creating especially
configured instance of the browser and disallow any user action that
may lead to a risk even theoretically. If the application is
well-planned and correctly installed the security protection will be
transparent to the end user and will not cause any side effects. The
developer should provide the user with shortcuts (installed
distributions) or compose package where the user sees just one exe
(usually ALPFrame.exe) in autorun scenarios so that the user would
always start the application from in the appropriate environment for
it. If the user is tampering with the application and tries to run
it from incorrect places in incorrect browsers the configuration
will prevent him/her from running the application in potentially
risky conditions.
|
