ServerController.ShowLoadingAnimation := false

If you are using IntraWeb’s PageMode then there is problem though: PageModus has no explicit ServerController.  Instead, an instance of TIWServerControllerBase is created when TWebModule is created. Inother words to change an option such as ShowLoadingAnimation you have to do that in your PageMode’s TWebModule:

uses

IWGlobal ...

procedure TWebModule1.WebModuleCreate(Sender: TObject);
begin
GServerController.ShowLoadingAnimation := false;
end;

Interestingly many IntraWeb users don’t know that there is a Compression option in the ServerController:

just set ServerController.Compression.Enabled = true and IntraWeb will compress all pages sent to the web browser. If the Web browser doesn’t support compression, then IntraWeb will of course detect that and send uncompressed.

The only requirement is to put a zlib.dll into the application’s directory. A working version can be downloaded here. No changes/settings on the client side are necessary.

There is one trade-off though which you should keep in mind: compression takes CPU cycles. Thats no problem for the client, but if your server machine is already close to its limit, then compression might not be a so good idea ..

Running IntraWeb applications right off your desktop is simple and fast. Just compile and run, and you have a working HTTP server. For production we recommend installing as service or as ISAPI application though.

Running a Web server on a Windows desktop – where you need to be logged in – is not what you want typically.

However, for product demonstrations, long testing sessions etc. it might make sense to use an IntraWeb Standlone application that way. You could even run an IntraWeb application right off a CD. For that purpose
we offer a way to customize the more or less ugly default Standalone form. This can be done by just dropping a TIWStandaloneServer component onto a standard Windows VCL form. For more details see the
CustomStandAlone demo, which can be found in the “demos” folder where you installed IntraWeb.

We just got a customer inquiry, where a customized IntraWeb standalone application raises an Integer overflow after “lots of traffic”. The customer is implementing an online game with many graphics transfered.

The source of that problem is a LogBytes rountine which counts the transfered data using an Integer variable. In other words, after 2GB of data transfered the application will show an error.

Note: This error only applies to Desktop Standalone Applications.
ISAPI and Service type Standalone applications are not affected!

The next minor IntraWeb release (9.0.40) correctly handles that situation, and the next major release (9.1 or 10.0) will upgrade the variable in question to In64.

If you are using IntraWeb desktop applications in the described way, then add the following to your custom Standalone form:

private
  FTotalBytes := Int64;
  ...

procedure TFormCustom.LogBytes(const ABytes: Integer);
begin
FTotalBytes := FTotalBytes + ABytes;
//If you want to display the bytes transfered, then call your update routine here
//Or more resource friendly add a TTimer that updates your Byte counter
end;

procedure TFormCustom.FormCreate(Sender: TObject);
begin
memoLog.Lines.Add('Server started');
memoLog.Lines.Add('Listening on port: ' + IntToStr(GServerController.Port));
memoLog.Lines.Add('');
GLogBytesProcedure := LogBytes;
end;

We have just noticed, that the “VCL for the Web Application Wizard” fails to create an important file if you chose Application Type “ISAPI”.

Interestingly, if you create a new “WebBroker” ISAPI application (i.e. using CodeGear’s wizard ), that project will miss the same file. We did not look yet what the exact reason for this is, but for now just use the template project provided below as starting point for ISAPI IntraWeb applications.

ISAPITemplate.zip

Note: Only C++ Builder 2007 is affected. Do not download the file above if you are a Delphi 2007 user.

As sidenote, it appears that importing old C++ IntraWeb ISAPI projects from BDS2006 into BCB 2007 does not work smoothly either. The application type somehow gets mixed up. The result looks like a library project (as expected), but the linker apparently treats it as executable, resulting in errors. My current advice is to start from the template above too, and then add your forms, servercontroller and usersession files  from your old project.

If you are transferring sensible data between your IntraWeb server and your clients web browsers, then you should think about using SSL / HTTPS to encrypt the transmitted data. Unfortunately there are SSL exploits for SSL Version 2, which simply put make SSL V2 useless (in terms of security). SSL Version 3 does not suffer from these exploits, and it’s highly recommended to use SSLV3 only.

There are efforts by Web browser vendors to accept SSLV3 connections only, but as you can not control what the user is using, you should restrict your server to SSLV3 only.

If you are using SSL/HTTPS with your IntraWeb application, then there are two cases to consider:

1. IntraWeb application deployed as ISAPI dll (or DSO).
   In ISAPI/DSO mode IntraWeb does not handle SSL/HTTP communication, this is the responsibility of the hosting Web server. In other words you have to read the manual of your Web server, how to make sure that SSLV3 is used only. Information for IIS is found here.
2. IntraWeb application deployed as standalone executable.
   By default IntraWeb offers SSLV2 and SSLV3 to client web browsers. To restrict to SSL V3 you have to follow the steps at the bottom of this article.

The next version of IntraWeb will use restrict to SSLV3 by default.

Restricting an IntraWeb Standalone to SSL V3

A while ago I already blogged about how to restrict to SSL V3. Due to a change in IntraWeb 9.0, you have to apply the code a bit differently, as advised in my old post. Please add the lines marked in blue to your DPR file, as shown in the example below.

program StandAloneSSL;

uses  Forms,  IWMain,  IWHTTPServer,
  InSSLOpenSSL,  ServerController in 'ServerController.pas' {IWServerController: TIWServerController},  Main in 'Main.pas' {IWForm1: TIWFormModuleBase},  SecureForm in 'SecureForm.pas' {IWForm2: TIWAppForm},  NonSecureForm in 'NonSecureForm.pas' {IWForm3: TIWAppForm};

{$R *.res}

begin  Application.Initialize;  Application.CreateForm(TformIWMain, formIWMain);

  if assigned(GHTTPServer) and assigned(GHTTPServer.HTTPS) then begin
    GHTTPServer.HTTPS.Active := false;
    TInServerIOHandlerSSLOpenSSL(GHTTPServer.HTTPS.IOHandler).SSLOptions.Method := sslvSSLv3;
    GHTTPServer.HTTPS.Active := true;
  end;

  Application.Run;end. 

The first hotfix for the possible DOS attack may cause unexpected side effects under certain conditions.

The DOS (Denial-Of-Service) attack is based on manipulated HTTP requests. Certain manipulations – which are not explained here – may lead to unexpected behaviour of certain Delphi string routines. This caused an infinite loop in IntraWeb’s request processing. The internal fix in IntraWeb 9.0.12 was to use a “stable” variant of this string handling routine.

However, for older IntraWeb versions you have to manually apply a workaround in your application’s source code, because you don’t have access to IntraWeb’s internal request processing. The first approach of this work around was to try “healing” these manipulations. After some more research we found it to be much safer to completely ignore such manipulated requests though. The attack is based on an explicit HTTP manipulation. If manipulation occurs, then ignoring such a manipulation is “harmless”.

To protect your application against this DOS attack please follow these steps:

1. If you have IntraWeb 9.0.12 or higher then no action is needed
2. IntraWeb 9.0.11 an all versions below follow these steps
1. Open your ServerController.pas unit and add an OnBeforeDispatch event handler.
1. Add the following bold line to the event handler created in step one
1. If you already have an OnBeforeDispatch handler then add these lines above your own code

uses HTTPApp;
…
procedure TIWServerController.IWServerControllerBaseBeforeDispatch(Sender:
    TObject; Request: TWebRequest; Response: TWebResponse; var Handled:
    Boolean);
begin
    if (pos(‘multipart’, Request.ContentType) = 0)
      and (pos(#$26#$26, Request.Content) > 0) then
        Request.ContentFields.Text := ”;
end;

On Bugtraq there is a report about a possible denial of service (DOS) attack of IntraWeb applications:

http://www.securityfocus.com/archive/1/457758

Do not panic! See this article for a hotfix.

We have never been contacted by the author of this report – in contrast to what is said in this report. Also the suggested workaround is technically invalid:

Description
———–

DoS conditions occurs, when a specially crafted HTTP request is sent to the webapplication.
After the request, the affected thread enters into an infinte loop, and hangs.

Of course, due to the nature of software, we can not gurantee that such a vulnerability does not exist. We have contacted the author to send us the exact description to prove that statement.

WorkAround

———-



There is no vendor supplied workaround for the problem at this time.



A possible workaround can be, to filter the request body for the special request, and repair it.

It can be achieved, by overriding the function called “OnBeforeDispatch” of the TIWServerController object, and repair the request, by changing the “Request.Content” field.

Request.Content is a read-only property of TWebRequest (which is not an IntraWeb class, but is introduced by Delphi’s WebBroker architecture), thus can not be changed as the author suggests.

Both, not having informed us and supplying an invalid/incomplete workarround makes this report look like a fake, published to blame IntraWeb.

In the meantime I was able to contact the original author  (who still did not unveil his real name – I only know his nick mane “Core Impact”), and he finally provided the necessary steps how to reproduce the issue he observed.

To set the indetification string “Server: Indy/10.0.52″ with something else,
just add the follwoing to your ServerController’s create event:

Note: This applies to IntraWeb’s StandAlone mode only. You can
not change the string which is sent by IIS if you are using ISAPI
mode.

uses  IWInit, IWGlobal, IWHTTPServer;

[...]

procedure TIWServerController.IWServerControllerBaseCreate(Sender: TObject);begin  if assigned(GHTTPServer) and assigned(GHTTPServer.HTTP) then begin    GHTTPServer.HTTP.Active := false;    GHTTPServer.HTTP.ServerSoftware := 'fake';    GHTTPServer.HTTP.Active := true;  end;end;

If your server uses HTTPS/SSL then apply the same to GHTTPServer.HTTPS as well.

By default HTTPS enabled IntraWeb servers accept any SSL client
version from 1.0. To allow SSL 3.0 only with your HTTPS
enabled IntraWeb application, just add the following lines of code to your
ServerController’s OnCreate event:

Note: This only applies to IntraWeb StandAlone applications. If
you are using IIS or any other Web server (ISAPI, DSO or .NET assembly mode),
then please see the manual of your Web server how to set the available SSL
modes. HTTPS is not available with IntraWeb evaluation versions.

uses
  IWInit, IWGlobal,
IWHTTPServer;

procedure
TIWServerController.IWServerControllerBaseCreate(Sender:
TObject);
begin
  if assigned(GHTTPServer) and
assigned(GHTTPServer.HTTPS) then begin
   
GHTTPServer.HTTPS.Active := false;
   
TInServerIOHandlerSSLOpenSSL(GHTTPServer.HTTPS.IOHandler).
     
SSLOptions.Method :=
sslvSSLv3;
    GHTTPServer.HTTPS.Active := true;
 
end;
end;