URL variables can be automatically parsed into a struct

Description

I believe this is identical to this issue: https://luceeserver.atlassian.net/browse/LDEV-1590, which has been closed, but I think something needs to be done about this for URL and Form scopes to prevent DOS attacks that would be initiated by generating a ton of errors.

When the following URL is interpreted by Lucee, the URL scope includes a struct as follows:

mysite.com?id=1&q...r

My feeling is that under no circumstances should any parameter in the URL or Form scopes be interpreted as anything other than a simple value. Otherwise it seems that it would be trivial to initiate a DOS on any Lucee site that uses variables in the URL scope (or the Form scope) because you could hit the site with expected URLs in the form of a struct, which might cause so many errors that the site could become unstable or stop responding.

I realize that you could obfuscate URL params or prevent Lucee from ever seeing this patter by using url rewrites, but that is not technically feasible for many apps, especially legacy apps.

I also don't think it's feasible to put the onus on the developer to validate a URL or Form scope after Lucee parses it.

Am I overthinking this, or would you agree that this could be a vector for DOS attacks on Lucee sites?

Environment

Windows

Attachments

5

Activity

Zac Spitzer 
27 July 2024 at 09:07

I have rewritten this test using internalRequest

[java] [script] test.tickets.LDEV2374 [java] [script] ts=10&res...temp=1 [java] [script] ["ts":"10","res":["temp":"1"],"res...temp":"1"] [java] [script] [java] [script] mt=10&test.temp=lucee [java] [script] ["mt":"10","test":["temp":"lucee"],"test.temp":"lucee"]

https://github.com/lucee/Lucee/commit/d36fc961585bec96894edceaf6010194424c5ff4

Adam Cameron 
2 June 2023 at 16:21

Oh blimey. Not cool.

The last para from JP’s comment is key here:

  • Ppl expect this behaviour about as much as they expect the Spanish Inquisition.

  • And yeah absolutely validation needs to take place before any action is taken on external values. This makes this behaviour even more inappropriate I think.

What might be useful here is a function called rehydrateFlattenedStruct , or some such, which does what is being done to the URL scope here, with a passed-in string. The functionality is useful. The implementation here is… not.

Ref: https://www.youtube.com/watch?v=HqF_nPbX_Ow

JP 
2 June 2023 at 01:33

Just ran into this again… the url string ?BwxS%3D5967%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27<script>alert%28"XSS"%29<%2Fscript>%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202>1--%2F%2A%2A%2F%3B%20EXEC%20xp_cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 which is obviously an injection attack, was parsed like this, which resulted in a bunch of errors.

I think this feature, which auto-parses URL strings into complex objects, needs to be turned off by default and enabled at the application level. In my 25 years of coding CFML, I’ve never seen code that expects URL params to be complex objects, and even if an app supported it, there would need to be additional validation code to ensure the expected data is correct.

Adam Cameron 
20 September 2022 at 14:10

Just got bitten by this.

One cannot pass a struct in a URL. There is no situation where this ought to be considered a “feature”. It’s a bug.

The very first sentence of the query section of the URI RFC (RFC-3986), starts with this:

3.4. Query

The query component contains non-hierarchical data

Non-hierarchical.

They specifically say this.

RFC-7320 (which is also referenced from RFC-3986) says:

Applications MUST NOT directly specify the syntax of queries

Which Lucee is doing here. Note, RFC-8820 supersedes RFC-7320, and the wording is now:

Applications can specify the syntax of queries

So you have some leeway there I suppose, but it’s caveated - both versions - with “However, doing so can cause operational difficulties”. Well… indeed. Here we are.

The latter two RFCs notwithstanding, RFC-3986 is very clear that the key is non-hierarchical. So by treating it otherwise, you are breaking the RFC. This is subpar. RFCs are there for a reason.

It’s also breaking compat with CF, as previously mentioned.

And it’s always been the understanding that the query key/value pairs are represented in the URL scope as the same key/value pairs.

Lucee just shouldn’t be doing this. If the functionality can’t simply be removed because of backwards compat concerns, it should be switched off by default, and switching it on should be documented along with observations that it is not recommended as it breaks the URI RFC etc etc.

Out of interest, where’s the original ticket where this feature was first floated?

Zac Spitzer 
28 October 2020 at 10:05

Details

Assignee

Reporter

Priority

Labels

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Affects versions

Created 15 July 2019 at 23:30
Updated 27 July 2024 at 09:07