ALP ALP Security
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.

The security features implemented by ALP engine itself.

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.

ALPFrame browsing restrictions

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. 

Design considerations

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.

Conclusion

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.

newObjects Copyright 2001-2006 newObjects [ ]