Handling of reload pwd check

[adamcameron]

G'day again:
This code here in onRequestStart:

(StructKeyExists(url, "password") && url.password == application.wheels.reloadPassword)

If that check fails, shouldn't one get a 403 response, not just "ah well, we'll ignore all that".

If a request has asked to do something, but the conditions for the request have not been met, it should not ignore things, it should respond with the appropriate 4xx status, right?

--
Adam

[dbelanger]

I agree that a RESTful approach should always have a response but I feel there is a security concern here. In a lot of cases, especially for larger Wheels apps, reloading the framework is resource intensive and may take a few minutes. My concern is that Bot attacks could use a 403 return to keep guessing whereas returning the 200 lets them think it worked.

Now, I see your point that it also keeps the user guessing which isn't good.

I only raise this point because of all the attacks we've dealt with, the 3 patterns of attack we see are:

1. the login page
2. the admin login (although every bot seems to be shooting for wp-admin) and
3. application reload attempts (reload, fwreload, reinit, reboot, restart....)

I guess the correct way to deal with that would be to return a 403 and block the attacker after so many attempts but should that be a default for anyone who uses the framework?

[neokoenig]

As a side note, we use allowEnvironmentSwitchViaUrl=false in production, as the app should never get reloaded (just destroyed and recreated in containers).

[adamcameron]

Ooh you got me all excited until I remembered we are still on 1.4.x... :-/

[adamcameron]

@dbelanger yeah good point. TBH, having the reload mechanism just as a query rather than a route is perhaps less than ideal to start with. If it was handled by like /system/reload?password=whatevs then one could only expose /system/reload on an internal network, or behind other security measures. Exposing it anywhere probably seemed like a good idea at the time, but not sure that it is.

A case in point we had an "issue" today (which got me onto this in the first place) and my first reaction was "right, I'm blocking that URL from the outside world completely", only to then firmly declare [I can't repeat it, but you know me and what it probably sounded like and how long it went on for] as I remembered it's a query parameter not a URL :-|

Then I went to just override the method that dealt with it and... well... you saw my other thread... :-/

[neokoenig]

TBH, alongside a dedicated URL, it really should be a POST request in production, as otherwise the query string can potentially end up in server logs (depending on the configuration of the server).