Never use an http XML-RPC endpoint for https sites - #25869
Open
crazytonyli wants to merge 4 commits into
Open
Conversation
When the entered site address is https, WordPressOrgXMLRPCValidator no longer probes an http variant of the same host, and any endpoint that discovery resolves to (via redirects or RSD links) is rejected unless it is also https. Previously the username and application password were sent to the http endpoint whenever the https xmlrpc.php probe failed, and the plaintext endpoint was persisted (GHSA-qxpr-7v78-mh5g).
Older app versions could silently downgrade a site's discovered XML-RPC endpoint to http and persist it, so later XML-RPC traffic and the credentials it carries crossed plaintext (GHSA-qxpr-7v78-mh5g). Blog.xmlrpcURL returns the https-upgraded endpoint for an https site, and every credential bearing XML-RPC client is now built from it (Blog.xmlrpcApi, the Zendesk profile fetch, and the site settings credential check) instead of the raw stored value. The persisted xmlrpc and the Keychain keyed by it are left unchanged, so credential lookups still resolve; only the request endpoint is upgraded, at the point the client is constructed. This closes the downgrade regardless of launch timing or store restoration, with no migration pass.
Contributor
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 33628 | |
| Version | PR #25869 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 8cf3c89 | |
| Installation URL | 5nqfa590981e0 |
Contributor
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 33628 | |
| Version | PR #25869 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | 8cf3c89 | |
| Installation URL | 5ddenpfpae8po |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
The issue (GHSA-qxpr-7v78-mh5g) would only occur if
httpsXML-RPC request fails buthttpXML-RPC request succeeds. It's probably not very likely. But I think it's still good to patch it.Description
When a self-hosted site was added with an
https://address, the app could silently fall back to anhttp://XML-RPC endpoint and persist it, so the username and application password were then sent in plaintext on every XML-RPC call.WordPressOrgXMLRPCValidatorno longer resolves anhttp://endpoint for anhttps://site: it stops probing an http variant of the host, and rejects any endpoint that discovery resolves to unless it is also https. This prevents new downgraded endpoints.For records already downgraded by older versions,
Blog.xmlrpcURLreturns the https-upgraded endpoint for an https site, and every XML-RPC client is now built from it (Blog.xmlrpcApi, the Zendesk profile fetch, and the site settings credential check). The persistedxmlrpcvalue and the Keychain entry keyed by it are left untouched, so credential lookups is not affected.