Controller is the frontend js so it makes the request on behalf of the user (and not internally server-side) so basically there is no way to distinguish between a request coming from browser and an attacker. Technically, you could block any browser-like UA but that can be easily spoofed.
On Wed, Aug 23, 2023 at 10:16 PM Amir Sarabadani <ladsgroup@gmail.com> wrote:
>
> You could technically decline access in apache (or whatever software you're using).
>
> But I need to warn: Many functionalities of mediawiki are done by calling the API in the backend, e.g. when you log out, it calls an API, when you watch a page, it calls another API, and all of those would break if you disable the api.php or rest.php
If I am understanding things correctly, it sounds like we should
disable the APIs on external interfaces, but allow them on internal
interfaces. For example, when a user clicks "logout", the controller
will invoke an API call. We want the controller to be able to call an
API. We don't want users to be able to call them.
How do we accomplish that?
Jeff
> Am Mi., 23. Aug. 2023 um 23:14 Uhr schrieb Jeffrey Walton <noloader@gmail.com>:
>>
>> I was looking at our Special:Version page, and got to thinking about
>> api.php [1] and rest.php.[2] I don't believe anyone on our team is
>> using the APIs, and I would like to disable them to reduce attack
>> surface. Or disable them on external interfaces (or maybe allow on
>> localhost/127.0.0.1).
>>
>> I see api.php can be disabled via $wgEnableAPI.[1] But I don't see a
>> similar option for rest.php.[2]
>>
>> I have two questions. First, is it possible to disable api.php and
>> rest.php in practice? Or restrict them to internal interfaces only?
>>
>> Second, what option controls rest.php?
>>
>> And maybe a third question, can we rename api.php and rest.php tosay,
>> api.php.unused and rest.php.unused? Will that produce ill effects?
>>
>> Thanks in advance.
>>
>> [1] https://www.mediawiki.org/wiki/Manual:Api.php
>> [2] https://www.mediawiki.org/wiki/Manual:Rest.php
--