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
db.connect
case "dictionary"
dim d as Dictionary
if d.HasKey("FOO") THEN
end if
case "array"
dim a(0) as string
a(5)="foo"
case "raise"
raise new CryptoException("foo",1)
case "sqlite"
dim db as new SQLiteDatabase
db.connect
db.ExecuteSQL("select password from password_table where password = ?","")
end select
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"
Try
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
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
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.
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.
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.
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.
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
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.