Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How to best accomplish this
#1
We have several ISAPI IW apps (15.2) that we link by each calling the others using TerminateAndRedirect.
This has worked great. Now we find Bad actors try to scrape our application and we have added an encrypted time string parameter will now pass when each app calls the other apps.
we decode and check the time string in the server controller's IWServerControllerBaseNewSession event.

  If not checkTS(asession) then
    begin
      Asession.terminate;
      exit;
    end;


ASession.Data := TIWUserSession.Create(nil, ASession);


The result of this change is we find iwcache folders are not being cleaned up.
We are also seeing Reply is already set errors.

If we use IWServerControllerBaseBeforeNewSession, how do we send back an dynamic HTLM response as the function does not provide a response object only a request object
Reply
#2
Not sure if this is what you are looking for but I use something like the code below to terminate a session and display a dynamic message:

Code:
WebApplication->Terminate(
"<head>"
"<title>"+IWServerController()->DisplayName+":  Registered</title>"
"</head>"
"<body>"
"<h3>"+IWServerController()->DisplayName+":  Registered - Please restart.<br/></h3>"
"</body>"
);
Reply
#3
Can't you use the OnBeforeNewSession event?


Code:
procedure TIWServerController.IWServerControllerBaseBeforeNewSession(
  const aUrlPath: string; aRequest: THttpRequest; out vCanCreate: Boolean);
begin
  vCanCreate := checkTS(aRequest);
end;


You probably need to change your CheckTS method to inspect the aRequest.Params object (a TStringList that contains all request parameters), because the seesion hasn't been created yet.

If you set vCanCreate to false within this event IW will skip the session creation code completely and respond with a 404 status, which is exactly what we want for any kind of unauthorized access attempt...
Reply
#4
@MJS

Your code is correct but maybe you want to try using a valid HTML including the <!DOCTYPE > document type declaration tag. The IWApplication code looks for this '<!DOCTYPE' string to find out if the provided code is a full HTML content or just a string that needs to be concatenated with other HTML entities...
Reply
#5
A final note:

I tested this scenario using IWServerControllerBaseNewSession event, like you did, and everything also "works" correctly, meaning that the session is destroyed and the session cache dir is deleted as expected. I find it weird that you got a different result.

Anyway, the most optimized way to deal with this is my suggestion above.
Reply
#6
I believe the problem is that I am using an older version (15.2.50) of Intraweb 
I am going to update but have a number of TMS IWcomponents that are a bitch to install.
Is there another work around for my Version?

Code:
//This access Violates on the  webapplication.Terminate('hello');
procedure TIWServerController.IWServerControllerBaseBeforeNewSession(
  const aUrlPath: string; aRequest: THttpRequest; out vCanCreate: Boolean);
begin
    webapplication.Terminate('hello');
    VCanCreate:=False;
end;

// this works
procedure TIWForm14.IWButton1Click(Sender: TObject);
begin
  webapplication.terminate('test 123');
end;
Reply
#7
Count this be a cause of "Reply type already set."

(where SecHtml=my html captcha code)

In my CheckTS function

Trace('Set Response');
webapp.Response.WriteString(secHtml);
// close session and terminate
Trace('Terminate');
WebApp.Terminate;


Is the problem that I use the webapp.Response.WriteString() then after I do a WebApp.Terminate; which is sending another response?

When I test locally on our IIS server, I do not get the error, but on the customers machine I see this error happening.
Reply
#8
(12-20-2023, 02:25 AM)PDSBILL Wrote: I believe the problem is that I am using an older version (15.2.50) of Intraweb 
I am going to update but have a number of TMS IWcomponents that are a bitch to install.
Is there another work around for my Version?

Code:
//This access Violates on the  webapplication.Terminate('hello');
procedure TIWServerController.IWServerControllerBaseBeforeNewSession(
  const aUrlPath: string; aRequest: THttpRequest; out vCanCreate: Boolean);
begin
    webapplication.Terminate('hello');
    VCanCreate:=False;
end;

// this works
procedure TIWForm14.IWButton1Click(Sender: TObject);
begin
  webapplication.terminate('test 123');
end;

The AV happens because there is no session yet and you are trying to reference an object that hasn't been created. Your code is not correct.

Besides that you should reconsider this custom response message: 
If you are blocking the access then you are certain that this is an unauthorized access. So why are you sending a "nice" response back?? It's like a burglar trying to enter into your home and you are asking him gently to go away...
The standard procedure in any web framework or application out there is to respond with either 404 (what IW does by default) or something even more specific as 401 (Unauthorized). You can use the property SessionOptions.HttpStatusForDeniedSessions and change it to whatever you want (I recommend leaving it the way it is or changing it to 401).
Reply
#9
The Checkts performs multiple checks. If the calling browser sends no parameters then I build the custom html that presents a landing page with Captcha code. If the calling browser passes in a encoded time string parameter then I decode and verify that the decoded time is no more that 5 seconds past current time (I use the to naviate between multiple IW ISAPI app.) then the CheckTS returns true and the session is allowed if not then I want to return a 403 error which is what webapplication.terminate does.

I was hoping to use the BeforeNewSession to do this, so that sessions are not created by bots trying to screen scape or other bad actors hitting our url

I have fixed the "Reply type already set" errors, by not calling terminate after i already sent the custom html.

I am getting a few errors on my password field OnAsyncChange on my login page. It does not show up as an error to the user but is written out to the exception log file. I am still investigating this, but if you have any advice on issues using OnAsyncChange, I would be grateful.

Again, that your for your help.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)