Proof Of Concept
In this proof of concept, it will be demonstrated that by viewing the configuration data on the endpoint (/api/v1/settings) with only the read-only token, the API write token can be displayed, as well as the encrypted administrator password The most forceful thing as such is the write API token, since although the administrator has a fairly strong password, with the writing power an attacker can edit the password hashed by another and access the administrative panel.
With read only token, an attacker could view the following data, including what was already mentioned (hashed password and Write API Token):
The vulnerability in this endpoint, is in api_settings function, where not controlled data exposured in the variable $data['site']
Since the /api/v1/settings endpoint is intended to display the system configuration but considering the fact that it exposes the API write token as the encrypted password of the administrator, I suggest modifying the code as follows manner:
function api_settings(): void {
global $App;
$data = $App->data();
$method = api_method();
if ( 'GET' === $method ) {
$clean_data = $data;
unset($clean_data['site']['password']);
unset($clean_data['site']['api']['write']);
api_response(
array(
'code' => 200,
'status' => true,
'message' => 'Settings',
'data' => api_field_selection(
$clean_data[ 'site' ]
)
)
);
}
The new changes reflected when a request is submitted:
And as noted, such compromising data will not be exposed.
Proof Of Concept
In this proof of concept, it will be demonstrated that by viewing the configuration data on the endpoint (/api/v1/settings) with only the read-only token, the API write token can be displayed, as well as the encrypted administrator password The most forceful thing as such is the write API token, since although the administrator has a fairly strong password, with the writing power an attacker can edit the password hashed by another and access the administrative panel.
With read only token, an attacker could view the following data, including what was already mentioned (hashed password and Write API Token):
The vulnerability in this endpoint, is in api_settings function, where not controlled data exposured in the variable $data['site']
Since the /api/v1/settings endpoint is intended to display the system configuration but considering the fact that it exposes the API write token as the encrypted password of the administrator, I suggest modifying the code as follows manner:
The new changes reflected when a request is submitted:
And as noted, such compromising data will not be exposed.