HandleURL returns to client Exception message and data

HandleURL returns to client Exception message and data. This includes Database errors etc. This could be an attack vector, and I believe is behaving contrary to the documentation by adding this data to the response. I first got this “working” with a bad query, that returned database info the user should not know about.

Tested with 2022R1

How to Reproduce:

Create a new Web project and add the following into HandleURL. Visit the webpage with /mysql etc as per case statements.

select case request.path
case "mysql"
  dim db as MySQLCommunityServer
case "dictionary"
  dim d as Dictionary
  if d.HasKey("FOO") THEN 
  end if
case "array"
  dim a(0) as string
case "raise"
  raise new CryptoException("foo",1)
case "sqlite"
  dim db as new SQLiteDatabase
  db.ExecuteSQL("select password from password_table where password = ?","")
end select

Screenshots of errors:







This was the original error that prompted me to investigate, because the client was receiving unexpected data.

Your missing “New”
Dim ... As New .....

You can just dim a class without new and expect it to work.

This only happens because you happen to “Return” nothing. If you return true with status 404 or so, nobody knows what has happened and so you created the attack vector yourself…

You need to try it before you comment because you are misunderstanding. It returns error data to the webresponse and sets the webresponse status to 200. The not specifying new was on purpose to make it raise an exception. Any exception raised in HandleURL will do this

What @DerkJ is saying is that this can (and should) be handled. Just a simple example:

select case Request.Path
case "array"
    dim a(0) as String
    a(5) = "foo"
  catch e as OutOfBoundsException
    Response.Status = 500
    Response.Write( "An error has occurred." )
  End Try
  Return True
end select
1 Like

Obviously. But showing that if you miss an error in HandleURL it will return data to the user sending the API call. It should not return data and have a status of 404

Yeah, it definitely shouldn’t return 200 and sharing database info can be a real bad thing.


I’ve opened a case for this issue. Please add any relevant information or points you wish to make, and upvote if you feel so inclined.


You created a problem that does not exist in well written code. So the only answer is for people that don’t know how to do this the right way (since it’s a public forum) was to say your return value wrong or missing.

Errors should be handled by logging them or another way. But never hand them directly over to the end-user.

So youre saying youve never made a mistake. Once again youre misunderstanding. Try the example and see what it does. As you can see from the sample code nothing is printing to the webresponse or setting status.

1 Like

Thanks Anthony! Will do

No i’m not saying that, i’ve made alot otherwise i wouldn’t have known this probably…
But i may hope one does test the output before deploying a production build.

This was my main worry, that I was not touching the response, yet it was sharing the exception data with the user.

A try … Catch fixes the error and returns a 404, but it should have returned a 404 either way.


Liam/Daniel, check and see if this happens when you’re not in debug mode.

Ah, so the problem with the code above is that you’re not returning True to indicate that you’ve handled the request.

Remember, HandleUrl let’s you intercept the first request from a browser to the app and it is that Return True that tells the app that you don’t want a session created and that your code is going to do everything (including setting the response code). If you return False, the default response is a 200 OK because the web app created a session and everything was OK with that process.

1 Like

Thank you everyone.

The framework is supposed to be displaying a “500 Internal Server Error” page in this case, but there is an issue preventing to show it (that fortunately is easy to fix)

Unhandled exceptions can be received using the UnhandledException event from the App class, so they can be logged without being shown to the end user.


Glad its an easy fix

The unhandled exception event on app fires when this error occurs. But it still returns the error information to the user that sent the api message regardless of what staus or data is set before this occurs

That won’t be shown in the next version. In the meantime, you can Return True in UnhandledException to display a blank page.


You can put a Return true at the end of the code and the unhandled exception skips it.

The original code was running from compiled and did have Return True.

I however was not handling the exception. I just thought that returning the exception details to the user was wrong. I will investigate a little more at work tomorrow.

Excellent. Thankyou.