Page MenuHomePhabricator

RunQuery form makes Error 400 for sites with strict compliance to RFC7231
Open, Needs TriagePublicBUG REPORT


In an otherwise perfectly functioning wiki (1.34) with PF (5.1), using Special:RunQuery will regularly return a "400 Bad Request" response to the client. In trying to understand this behavior, we have confirmed that A) the "400 Bad Request" is generated from our Haproxy front-end, and B) Haproxy is notoriously strict [1] about the adherence to RFC7230 (section 4.3.6?) in terms of message parsing and (from the haproxy documentation):

This means that invalid characters in header names are not permitted and cause an error to be returned to the client. This is the desired behaviour as such forbidden characters are essentially used to build attacks exploiting server weaknesses, and bypass security filtering.

Sometimes, a buggy browser or server will emit invalid header names for whatever reason (configuration, implementation) and the issue will not be immediately fixed. In such a case, it is possible to relax HAProxy's header name parser to accept any character even if that does not make sense, by specifying this option.

Similarly, the list of characters allowed to appear in a URI is well defined by RFC3986, and chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92 ('\'), 94 ('^'), 96 ('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete) and anything above are not allowed at all. Haproxy always blocks a number of them (0..32, 127). The remaining ones are blocked by default unless this option is enabled. This option also relaxes the test on the HTTP version, it allows HTTP/0.9 requests to pass through (no version specified) and multiple digits for both the major and the minor version.

Is it possible that PF Special:RunQuery is constructing an http-request in some situations which is not in strict compliance with RFC7231 section 4.3.6? [1]

While I'm not 100% what the root cause is, we have been able to eliminate the problem by making the following modification to Page Forms


git status

# HEAD detached at 5.1

git diff

diff --git a/specials/PF_RunQuery.php b/specials/PF_RunQuery.php
index da03da4..a7636c4 100644
--- a/specials/PF_RunQuery.php
+++ b/specials/PF_RunQuery.php
@@ -147,6 +147,7 @@ class PFRunQuery extends IncludableSpecialPage {

                        foreach ( $queryStringValues as $key => $value ) {
+                               if ( $key == "MySearchPage" ) continue;
                                if ( is_array( $value ) ) {
                                        $value = wfArrayToCgi( $value );

where "MySearchPage" is the name of the wiki page which contains the RunQuery

(Note - the hack was proposed by Yaron on 5/24/2020)


See also:

Event Timeline

I was told that an issue we discovered during some security testing may be related to this, so I figured I should post it here.[discipline]=Mystic%20forge&Base_ingredients[id]=9150501&Base_ingredients[item]=Legendary%20Sigil&Base_ingredients[quantity]=%3Ca%20href=%22!--&title=Special:RunQuery/Base_ingredients_query#

We don't use haproxy like the OP does, nor does the proposed PageForms tweak help in our situation since the query involved is used within layers of templates that are used widely throughout our wikis, easily thousands of pages that ultimately call the query.

I don't know if there actually is one. Our security team reported this was discovered during some testing and wanted to know if this was normal behavior for the wikis or if it was some kind of exploitable bug.

HTML injection. The link I provided in our wiki shows an example of that, but the sec team (and me) weren't sure if this was in some way maliciously exploitable or if MW/SMW is more restrictive in e.g. the HTML tags it allows.

Oh, now I see it - yes, that is a problem. No, I don't know how severe it is either.

Ok, thanks for the confirmation. I'll keep a close eye on this issue and I have a dev environment in which I can do further testing if needed.

FWIW I've also been told that SQL injections may be possible with this issue, though I don't have an example query/URL yet to demonstrate that.

I'm glad to see some confirmation/recognition of the core security issue here. @Justin_C_Lloyd, do you think our two symptoms are related by the same underlying issue in PF_RunQuery? (i.e. where you are getting security flags and I am getting page errors due to haproxy blocking the request) .. do you think these are related?

@Revansx I don't know for sure that they're related, but IIRC the conversation in the MW Stakeholders channel suggested that they are, and I'm not really knowledgeable on the details of how the extension works and what it all does, as it's our editors that manage all of our wikis' contents.

Is there any work being done on this issue? Any idea of how significant of a risk it is?