Runtime error when passing <b> in URL

dev support
1

I am trying to pass some info in a URL which contains <b> . I am using URLEncodedFormat, I have also tried replacing the <b> with&lt;b&gt; . When it executes the receiving page gives a runtime error A potentially dangerous Request.QueryString value was detected from the client (message="...dvertiser <b>Aspire Communicat...").

I have this running locally on a dev server with CF2016/IIS10 with no trouble. I’ve tried it on a production box using CF2016/IIS10 and it works fine. The Lucee server was a clone server from the original CF2016, therefore the IIS settings are the same. I’ve also double checked the web.config file for anything that is somehow different

I am wondering if Lucee is the cause of this, but I can’t find any setting that could impact it

Appreciate any help, thanks

Code

<CFLOCATION URL="review_2.cfm?checksendemail=1&nonverified=1&message=#URLEncodedFormat('Advertiser &lt;b&gt;#form_companyname#</b> declined')#" addtoken="no">

Stack:

Windows Server 2022
IIS 10
Java 11.0.21
Tomcat Version 9.0
Lucee 6.0.0.585
MS SQL 2022

2

Encoded it as ascii string characters using the CHR command.
See the following table

1 Like
3

It’s an IIS error, so it’s not Lucee.

To demonstrate to yerself, browse to that URL yerself, having typed in the URL, rather than worrying about Lucee building it. You’ll get the same error. From IIS.

I googled “A potentially dangerous Request.QueryString value was detected from the client” and there are plenty of results. I’d have a read of some of those.

The first match talks about ValidateRequest="false". You’ve checked that setting, and know it’s… false?

4

You’ve piqued my interest now.

Say what?

5

Do you by any chance have a web app firewall such as OWASP running on that server?

1 Like
6

Thanks for the input.

I tried using HTML name and HTML number from https://www.ascii-code.com/ neither worked.

Although I was unable to find the actual setting in the IIS administrator, I did manually add the following directly under CONFIGURATION in the web.config file

<system.web>
    <httpRuntime requestValidationMode="2.0" />
    <pages validateRequest="false" />
</system.web>

This fixed the problem. However I’ve read that it’s a bad idea and can leave the site open to scripting attacks.

Now the strange thing is that I ran the same tests on another site on a CF2016 server as a I mentioned above it was a clone, the settings were the same in IIS. I also checked the web.config for that site and it did not contain the code above to stop the validation, and it works. So I am a little perplexed as to why it’s happy on one server but not another, with the only difference being Lucee vs CF2016

I did have a chat with my good friend ChatGPT and it suggested that Lucee may have inherited a setting, although the visual output of the error is certainly an IIS one.

I can manage without it, so will likely go through the code to hunt down any times I passed a HTML tag in a URL and just remove it. Although ideally, I’d really like to get to the bottom of this one.

Btw There are no additional firewalls running short of the standard windows one and an external port block from the datacenter

1 Like
7

Have you considered not passing the error string on the url at all?

Generally speaking, the pattern I use is to pass some numeric value (e.g. ?msg=123) that I then detect in the page being loaded to generate text to display to the user.

cfswitch( url.msg ) {
    case 123:
         message = 'Advertiser <b>' & passedInOrLookedUpAdvertiserName & '</b> declined';
    break;
}

Passing URL encoded data like that, esp with any tags (encoded or otherwise) is insecure. I also don’t know how you’re displaying message now, but chances are high you’re exposing an XSS attack vector doing what you’re doing (indeed, to allow the <b> on the url is to allow <img onload=“javascript:alert( ‘you are vulnerable’ );”> as well).

HTH

– Denny

1 Like
8

ahh good idea. I would have thought urlencodedformat would have stopped the issue from throwing an error at least but that didn’t help.

It’s actually only for my own internal dashboard. I went through the code and I’d only used it a few times so I just removed it, it was easier as my to-do list is significant and I need to press on.

I’ve left it validating so it’s not vulnerable

1 Like
9

This is def what it looks like, but the error message string that Mark posted is from IIS (according to the googling I did). But it looks to me like IIS is fulfilling the role of the WAF here and going “that ain’t legit, not letting it through”.

1 Like
10

it does appear to be doing that. Why it’s not doing it on a server with CF with the same webconfig is beyond me.

On a completely different subject, as I’m new to Lucee, I was wondering, is there a directory of sites that are proud to state they are running on Lucee? I just launched the platform https://www.showtheoffer.com - Shameless plug :slight_smile: . I have to say the load times of the pages is very impressive.

11

You can use the CHR function to output or parse something in ColdFusion character by character.

I found it useful when dealing with proprietary file formats or building scripts in other languages so I can use cfexecute to fire off the script(s).

12

All I wanted to do was pass a <b> in a URL :slight_smile: I’m just going to avoid doing it on this server. I don’t know whether Lucee is playing a part or not, but I can’t make any sense of why it works on the other server.

13

This may not solve the problem, but I just remembered URLEncodedFormat() is deprecated. Looks like the Lucee doc for that function needs to be updated because both Adobe and cfdocs.org confirm it is deprecated and replaced with EncodeForURL().

14

It may be related to ESAPI encode quirks.
Check Lucee Server Admin - Extension - Applications - ESAPI Extension (OWASP). IF the version is 2.2.4.15 (latest) try to downgrade one step to 2.2.4.13.

15

Oh that is not good news, I have likely used URLEncodedFormat extensively. Right now I only have one site running on Lucee, but in the future intend to migrate more off the CF server to Lucee. Is there any indication as to when it might be deprecated in Lucee and what the impact on the code would be?

16

I tried a downgrade to 2.2.4.13 (including a reboot), same issue

17

Fellas.

The error is coming from IIS. It’s not a Lucee or a code issue.

Like I said earlier, this is easy to prove:

To demonstrate to yerself, browse to that URL yerself, having typed in the URL, rather than worrying about Lucee building it. You’ll get the same error. From IIS.

Also if you do that pay attn to the Lucee logs at the time of the in-browser error: there will be no activity in Lucee as the request will not be getting as far as Lucee.

Do that. See the error. Stop looking at Lucee as a means to solve this. You’re looking in the wrong place, and wasting your time. As is everyone else on this thread talking about anything to do with CFML code.

This one thing though is significant, although unrelated to the situation:

I have likely used URLEncodedFormat extensively. Right now I only have one site running on Lucee, but in the future intend to migrate more off the CF server to Lucee. Is there any indication as to when it might be deprecated in Lucee and what the impact on the code would be?

URLEncodedFormat has been actively not recommended on CF for over a decade now. It is an inomplete solution, and does not cover all theoretical (theoretical) pen vectors in a URL. Use encodeForUrl. It should be a drop-in replacement, and be safe to do a global search and replace, and smoke test of the functionality.

However as I have said twice now…this issue is not about the URL encoding. It’s about how IIS is treating URLs it feels are dubious. There is a chance there is a WAF or something in front of IIS stopping the request for the same reason; and if it’s a Microsoft product, it might stand to reason that it uses the same error message strings that IIS uses. On the other hand Lucee would NOT use the exact same error message string that IIS uses. The error is not coming from Lucee.

3 Likes
18

I did a search and although I have used URLEncodedFormat quite a few times, it’s manageable, as it’s directly replaceable, I’ll use a search and replace and give it a good test, looks like a simple fix, hopefully not famous last words.

As for the IIS issue, I did very simple test, just passed a <b> in a URL to a HTML file, presuming that would ensure it totally bypassed any potential interference from Lucee, and sure enough I got the error (I know, no shock there). I have removed the code but curiosity is getting the better of me so I’ll try and dig a little deeper, especially as I have what I believe are identical IIS setups, with identical web.config files

3 Likes