Note there is another reason: GET request should be idempotent, but in this case it is not.

See also: {T112428} and T255881: Enable wgBreakFrames across all projects

The argument would be that GET requests cause log entries to be added via event logging, debug logging, etc. The IPInfo log is different in that it's viewable via the wiki, but this is deliberately to allow very trusted community members to perform oversighting. (Related discussion on T307164; request for wider access on T309318.)

The logging we're planning for access to temporary account IP addresses would have the same concern - see T325238.

I'm interested to hear from @sbassett or @Reedy or others whether the status quo is acceptable, and from @Niharika what would be acceptable from a product perspective:

• Are we ok to keep the IPInfo log as is, and implement another, similar log for access to IPs for temporary accounts?
• Do we need to restrict access to these logs even further, or put some safeguards in place to reduce the risk of access being widened (eg documentation)?
• Do we need to do something more drastic, like move these logs away from the wikis (only allowing staff oversight rather than community oversight)?

@Tchanders - I think the above questions are probably best for Privacy Engineering to take a first pass. I've subbed them here which should get this into their review queue. My personal instinct here is that hoping on-wiki data eventually gets oversighted (even if it does most of the time) is not a strong enough mitigation for these specific issues.

I don't have wider context so do consider a reasonable chance that I'm wrong and what I'm saying makes no sense...

@Tchanders If this REST endpoint still exists today in the same form as described, and if such request unconditonally results in an "action" being performed on currently logged-in user's behalf, that's probably good reason to require a CSRF token for that API in question.

Separate from whether the log entry is publicly visible or not, the fact that an action is performed on my account without my knowledge, and then attributed to me in an on-wiki log (whether public or restricted/peer/admin-only log), that's a significant security bug in my opinion.

What we do in api.php to prevent this, is that cross-origin contexts do not initialise the session by default. Instead, they are in an anonymous unauthenticated context by default. If this REST end point is exposing a way to perform actions based on session cookies but without authentication to confirm the caller has access to those session cookies, that's a security problem — separate and on top of the potentially deanonymizing impact through correlating the public logs.

I think there might be a few issues going on (or not going on) here:

1. Both the IPinfo revision REST endpoint and Special:Contributions page mentioned within the task description are framable. So are a few other MediaWiki pages and endpoints, mostly due to historical access issues and the low-risk we generally apply to clickjacking non-writable MediaWiki pages and endpoints. But this isn't really the relevant issue IMO.
2. Sensitive IPInfo data isn't really being leaked via the iframe methods mentioned within the task description, since a user would still need to be authenticated on the relevant project and be in the checkuser group to view any sensitive IPinfo data. Both the IPInfo revision REST endpoint and IPInfo's InfoboxHandler (used for SpecialContributionsBeforeMainOutput) check for the appropriate ipinfo right and either throw an exception or return early, thus preventing any display of sensitive data and the creation of a log entry that said data was displayed to a given user. And Same Origin prevents any access to framed Wikimedia wiki content from external domains. So for sensitive IPInfo data to leak, a scenario would have to involve a compromised or extremely careless checkuser, which there's not much else we can do to prevent, outside of such functionaries following basic security best practices and volunteers and staff learning of and reacting quickly to such a situation by revoking user rights, disabling accounts, etc. I suppose the IPInfo log write might count as an "action", and could be further secured by requiring a token, but that's the only other operation that appears to be happening aside from the return or display of the IPInfo data itself.
3. Finally, there's the potential disclosure of details around a user accessing IPInfo data, where the IPInfo log is appended whenever a user successfully views IPInfo data via the REST endpoint, Special:Contributions and a few other ways. Viewing IPinfo log data still requires a right assigned only to checkusers on Wikimedia wikis. So again, we'd need to have either a compromised or extremely careless checkuser involved for this exploit to be feasible, who was intentionally leaking the IPInfo log data in some capacity.

This should be fixed by T356183: CVE-2024-34504: IPInfo REST APIs are not safe from CSRF attacks