You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Peter Rader <p....@gmx.net.INVALID> on 2023/12/29 12:56:53 UTC
Servlet-Mapping having %-sign
Hey,
having a URL like this:
https://localhost:8443/index.html works perfect. This is my mapping:
<servlet-mapping>
<servlet-name>Nano-Nano-Servlet</servlet-name>
<url-pattern>/index.html</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Nano-Nano-Servlet</servlet-name>
<url-pattern>*.ts</url-pattern>
</servlet-mapping>
Unfortunately this URI does not load (because of the %-sign):
https://localhost:8443/@rm%2fmodel.ts
It gives a http-status:400 having the message "Invalid URI: [noSlash]"
Any ideas?
Kind regards / Happy new year
Peter Rader
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Aw: Re: Servlet-Mapping having %-sign
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Peter,
On 12/30/23 01:41, Peter Rader wrote:
>> Peter,
>>
>> On 12/29/23 07:56, Peter Rader wrote:
>>> having a URL like this:
>>>
>>> https://localhost:8443/index.html works perfect. This is my mapping:
>>>
>>> <servlet-mapping>
>>> <servlet-name>Nano-Nano-Servlet</servlet-name>
>>> <url-pattern>/index.html</url-pattern>
>>> </servlet-mapping>
>>> <servlet-mapping>
>>> <servlet-name>Nano-Nano-Servlet</servlet-name>
>>> <url-pattern>*.ts</url-pattern>
>>> </servlet-mapping>
>>>
>>> Unfortunately this URI does not load (because of the %-sign):
>>>
>>> https://localhost:8443/@rm%2fmodel.ts
>>>
>>> It gives a http-status:400 having the message "Invalid URI: [noSlash]"
>>
>> What's the use-case for having a client use a %-encoded / in your URL?
>> That kind of thing is usually evidence of a hacking attempt, which is
>> why Tomcat returns a 400 response.
>
> I generate TypeScript dynamically. In order to use it in Node: I register a servlet to create npm-packages at run-time. On Node-side I use this command:
>
> 1. Register servlet as npm source: 'npm config set @myapp:registry=https://nonofyourbusiness.mydomain.com:8443/'
> 2. Start the download: 'npm install @myapp/model --loglevel verbose' (hint: @myapp is the tomcat)
>
> This is the output of the second command:
>
> npm info it worked if it ends with ok
> npm verb cli [
> npm verb cli '/home/grim/.nvm/versions/node/v14.18.1/bin/node',
> npm verb cli '/home/grim/.nvm/versions/node/v14.18.1/bin/npm',
> npm verb cli 'install',
> npm verb cli '@myapp/model@1.0.0',
> npm verb cli '--loglevel',
> npm verb cli 'verbose'
> npm verb cli ]
> npm info using npm@6.14.15
> npm info using node@v14.18.1
> npm verb config Skipping project config: /home/grim/.npmrc. (matches userconfig)
> npm verb npm-session 778f7308eede99d8
> npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/@myapp%2fmodel 28ms
> npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/index.tgz.ts 14ms
> npm timing stage:loadCurrentTree Completed in 71ms
> npm timing stage:loadIdealTree:cloneCurrentTree Completed in 0ms
> npm timing stage:loadIdealTree:loadShrinkwrap Completed in 3ms
> npm timing stage:loadIdealTree:loadAllDepsIntoIdealTree Completed in 1ms
> npm timing stage:loadIdealTree Completed in 5ms
> npm timing stage:generateActionsToTake Completed in 1ms
> npm verb correctMkdir /home/grim/.npm/_locks correctMkdir not in flight; initializing
> npm verb lock using /home/grim/.npm/_locks/staging-b24acfc1530c2325.lock for /home/grim/node_modules/.staging
> npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/index.tgz.ts 7ms
> npm timing action:extract Completed in 10ms
> npm timing action:finalize Completed in 1ms
> npm timing action:refresh-package-json Completed in 1ms
> npm info lifecycle model@1.0.0~preinstall: model@1.0.0
> npm timing action:preinstall Completed in 1ms
> npm info linkStuff model@1.0.0
> npm timing action:build Completed in 0ms
> npm info lifecycle model@1.0.0~install: model@1.0.0
> npm timing action:install Completed in 1ms
> npm info lifecycle model@1.0.0~postinstall: model@1.0.0
> npm timing action:postinstall Completed in 0ms
> npm verb unlock done using /home/grim/.npm/_locks/staging-b24acfc1530c2325.lock for /home/grim/node_modules/.staging
> npm timing stage:executeActions Completed in 18ms
> npm timing stage:rollbackFailedOptional Completed in 1ms
> npm timing stage:runTopLevelLifecycles Completed in 97ms
> npm WARN saveError ENOENT: no such file or directory, open '/home/grim/package.json'
> npm info lifecycle undefined~preshrinkwrap: undefined
> npm info lifecycle undefined~shrinkwrap: undefined
> npm info lifecycle undefined~postshrinkwrap: undefined
> npm WARN enoent ENOENT: no such file or directory, open '/home/grim/package.json'
> npm verb enoent This is related to npm not being able to find a file.
> npm verb enoent
> npm WARN grim No description
> npm WARN grim No repository field.
> npm WARN grim No README data
> npm WARN grim No license field.
>
> npm http fetch POST 400 https://registry.npmjs.org/-/npm/v1/security/audits/quick 266ms
> + model@1.0.0 (as @myapp/model)
> added 1 package in 0.347s
> npm verb exit [ 0, true ]
> npm timing npm Completed in 463ms
> npm info ok
>
> --- end of console output
>
> As you might have noticed, this time the URL responded successfully. This is because I modified catalina.properties (org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true).
>
>>
>> https://stackoverflow.com/questions/19576777/why-does-apache-tomcat-handle-encoded-slashes-2f-as-path-separators
>
> I agree that this might become a security risk. Since the mentioned mod_jk-bug is not affected in this particular case, I could exoticize the tomcat-config to undo tomcats built-in-workaround throu the catalina.properties.
>
> It does not feel like an elegant solution, but it works for now. If however npm might be the future for some developers, a redesign of tomcat may a more desirable solution. It might be hard to tell the npm people to change their "way of downloading npm-packages" because "mod_jk have a bug" might not be concidered as a convincing argument. :-D
This is not just a "mod_jk had a bug one time" issue, but more of a
design decision in Tomcat of where to perform the decoding and
normalization of the URL. Changing the way Tomcat behaves could have
lots of downstream consequences that are difficult to predict with very
little in the way of positives.
I tend to agree with markt that changing things is unlikely to bring
significant improvement to the world, while greatly increasing risk to
... well, everybody.
Allowing slashes in URLs is only risky if you don't understand the
consequences of doing so. Since you are being mindful of the risks,
enabling that feature is appropriate in your environment.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Aw: Re: Servlet-Mapping having %-sign
Posted by Peter Rader <p....@gmx.net.INVALID>.
> Peter,
>
> On 12/29/23 07:56, Peter Rader wrote:
> > having a URL like this:
> >
> > https://localhost:8443/index.html works perfect. This is my mapping:
> >
> > <servlet-mapping>
> > <servlet-name>Nano-Nano-Servlet</servlet-name>
> > <url-pattern>/index.html</url-pattern>
> > </servlet-mapping>
> > <servlet-mapping>
> > <servlet-name>Nano-Nano-Servlet</servlet-name>
> > <url-pattern>*.ts</url-pattern>
> > </servlet-mapping>
> >
> > Unfortunately this URI does not load (because of the %-sign):
> >
> > https://localhost:8443/@rm%2fmodel.ts
> >
> > It gives a http-status:400 having the message "Invalid URI: [noSlash]"
>
> What's the use-case for having a client use a %-encoded / in your URL?
> That kind of thing is usually evidence of a hacking attempt, which is
> why Tomcat returns a 400 response.
I generate TypeScript dynamically. In order to use it in Node: I register a servlet to create npm-packages at run-time. On Node-side I use this command:
1. Register servlet as npm source: 'npm config set @myapp:registry=https://nonofyourbusiness.mydomain.com:8443/'
2. Start the download: 'npm install @myapp/model --loglevel verbose' (hint: @myapp is the tomcat)
This is the output of the second command:
npm info it worked if it ends with ok
npm verb cli [
npm verb cli '/home/grim/.nvm/versions/node/v14.18.1/bin/node',
npm verb cli '/home/grim/.nvm/versions/node/v14.18.1/bin/npm',
npm verb cli 'install',
npm verb cli '@myapp/model@1.0.0',
npm verb cli '--loglevel',
npm verb cli 'verbose'
npm verb cli ]
npm info using npm@6.14.15
npm info using node@v14.18.1
npm verb config Skipping project config: /home/grim/.npmrc. (matches userconfig)
npm verb npm-session 778f7308eede99d8
npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/@myapp%2fmodel 28ms
npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/index.tgz.ts 14ms
npm timing stage:loadCurrentTree Completed in 71ms
npm timing stage:loadIdealTree:cloneCurrentTree Completed in 0ms
npm timing stage:loadIdealTree:loadShrinkwrap Completed in 3ms
npm timing stage:loadIdealTree:loadAllDepsIntoIdealTree Completed in 1ms
npm timing stage:loadIdealTree Completed in 5ms
npm timing stage:generateActionsToTake Completed in 1ms
npm verb correctMkdir /home/grim/.npm/_locks correctMkdir not in flight; initializing
npm verb lock using /home/grim/.npm/_locks/staging-b24acfc1530c2325.lock for /home/grim/node_modules/.staging
npm http fetch GET 200 https://nonofyourbusiness.mydomain.com:8443/index.tgz.ts 7ms
npm timing action:extract Completed in 10ms
npm timing action:finalize Completed in 1ms
npm timing action:refresh-package-json Completed in 1ms
npm info lifecycle model@1.0.0~preinstall: model@1.0.0
npm timing action:preinstall Completed in 1ms
npm info linkStuff model@1.0.0
npm timing action:build Completed in 0ms
npm info lifecycle model@1.0.0~install: model@1.0.0
npm timing action:install Completed in 1ms
npm info lifecycle model@1.0.0~postinstall: model@1.0.0
npm timing action:postinstall Completed in 0ms
npm verb unlock done using /home/grim/.npm/_locks/staging-b24acfc1530c2325.lock for /home/grim/node_modules/.staging
npm timing stage:executeActions Completed in 18ms
npm timing stage:rollbackFailedOptional Completed in 1ms
npm timing stage:runTopLevelLifecycles Completed in 97ms
npm WARN saveError ENOENT: no such file or directory, open '/home/grim/package.json'
npm info lifecycle undefined~preshrinkwrap: undefined
npm info lifecycle undefined~shrinkwrap: undefined
npm info lifecycle undefined~postshrinkwrap: undefined
npm WARN enoent ENOENT: no such file or directory, open '/home/grim/package.json'
npm verb enoent This is related to npm not being able to find a file.
npm verb enoent
npm WARN grim No description
npm WARN grim No repository field.
npm WARN grim No README data
npm WARN grim No license field.
npm http fetch POST 400 https://registry.npmjs.org/-/npm/v1/security/audits/quick 266ms
+ model@1.0.0 (as @myapp/model)
added 1 package in 0.347s
npm verb exit [ 0, true ]
npm timing npm Completed in 463ms
npm info ok
--- end of console output
As you might have noticed, this time the URL responded successfully. This is because I modified catalina.properties (org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true).
>
> https://stackoverflow.com/questions/19576777/why-does-apache-tomcat-handle-encoded-slashes-2f-as-path-separators
I agree that this might become a security risk. Since the mentioned mod_jk-bug is not affected in this particular case, I could exoticize the tomcat-config to undo tomcats built-in-workaround throu the catalina.properties.
It does not feel like an elegant solution, but it works for now. If however npm might be the future for some developers, a redesign of tomcat may a more desirable solution. It might be hard to tell the npm people to change their "way of downloading npm-packages" because "mod_jk have a bug" might not be concidered as a convincing argument. :-D
>
> -chris
>
--
peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Servlet-Mapping having %-sign
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Peter,
On 12/29/23 07:56, Peter Rader wrote:
> having a URL like this:
>
> https://localhost:8443/index.html works perfect. This is my mapping:
>
> <servlet-mapping>
> <servlet-name>Nano-Nano-Servlet</servlet-name>
> <url-pattern>/index.html</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Nano-Nano-Servlet</servlet-name>
> <url-pattern>*.ts</url-pattern>
> </servlet-mapping>
>
> Unfortunately this URI does not load (because of the %-sign):
>
> https://localhost:8443/@rm%2fmodel.ts
>
> It gives a http-status:400 having the message "Invalid URI: [noSlash]"
What's the use-case for having a client use a %-encoded / in your URL?
That kind of thing is usually evidence of a hacking attempt, which is
why Tomcat returns a 400 response.
https://stackoverflow.com/questions/19576777/why-does-apache-tomcat-handle-encoded-slashes-2f-as-path-separators
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Servlet-Mapping having %-sign
Posted by Aryeh Friedman <ar...@gmail.com>.
No idea on the original question but the URL above mightiest well read:
http://dear.hacker.please/hack-me.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Fwd: Servlet-Mapping having %-sign
Posted by Aryeh Friedman <ar...@gmail.com>.
---------- Forwarded message ---------
From: Aryeh Friedman <ar...@gmail.com>
Date: Fri, Dec 29, 2023 at 8:08 AM
Subject: Re: Servlet-Mapping having %-sign
To: <p....@gmx.net.invalid>
On Fri, Dec 29, 2023 at 7:57 AM Peter Rader <p....@gmx.net.invalid> wrote:
> https://localhost:8443/@rm%2fmodel.ts
No idea on the original question but the URL above mightiest well read:
http://dear.hacker.please/hack-me.jsp
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org