Mailing List Archive

Disable api.php and rest.php?
Hi Everyone,

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
_______________________________________________
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/
Re: Disable api.php and rest.php? [ In reply to ]
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

HTH

Am Mi., 23. Aug. 2023 um 23:14 Uhr schrieb Jeffrey Walton <
noloader@gmail.com>:

> Hi Everyone,
>
> 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
> _______________________________________________
> MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
> To unsubscribe send an email to mediawiki-l-leave@lists.wikimedia.org
>
> https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/
>


--
Amir (he/him)
Re: Disable api.php and rest.php? [ In reply to ]
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
_______________________________________________
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/
Re: Disable api.php and rest.php? [ In reply to ]
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.

Am Do., 24. Aug. 2023 um 19:35 Uhr schrieb Jeffrey Walton <
noloader@gmail.com>:

> 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
>


--
Amir (he/him)
Re: Disable api.php and rest.php? [ In reply to ]
On 24/8/23 07:13, Jeffrey Walton wrote:
> Hi Everyone,
>
> 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,

People don't use them. Scripts use them, on behalf of people. The
people don't know they are using them.


> I see api.php can be disabled via $wgEnableAPI.[1]

$wgEnableAPI was removed in MW 1.32. (T115414)


> But I don't see a similar option for rest.php.[2]

$wgEnableRestAPI was removed in MW 1.36.


> I have two questions. First, is it possible to disable api.php and
> rest.php in practice?

You could patch isCompatible() to always return false. MediaWiki will
assume everyone's browser is too old for JavaScript and will not
attempt to make requests via api.php or rest.php. Most things should
still work in a degraded mode.

Then you could move api.php and rest.php away, or deny access in
Apache, or patch them, or whatever.

When I say "most things", I mean like 70% of things. You're using
SimpleMathJax which would be broken. RateChange would disappear. You
should reconsider your need for this change.


> Or restrict them to internal interfaces only?

That would not be useful.


> 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.

That's not a thing.

-- Tim Starling

_______________________________________________
MediaWiki-l mailing list -- mediawiki-l@lists.wikimedia.org
To unsubscribe send an email to mediawiki-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/