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
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/
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
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
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@lists.wikimedia.org