You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Berneburg, Cris J. - US" <cb...@caci.com> on 2018/08/16 17:19:51 UTC
how to prevent user access to JSP pages?
Due to security concerns and general fussiness on my part, I'd like to prevent users from requesting JSP pages directly, except for the login page. I want all requests to be handled by servlets. That way I can legitimately claim that all requests are being validated, input scrubbed, JSP's cannot be taken advantage of w/o their servlet chaperones being present, etc.
a. One way I read is by adding a <security-constraint> for each folder. One use case is for JSP include files. That looks possible but makes it seem like these are exceptions and not the rule. I want "deny, deny, deny" to be the default and the one or 2 allowable JSP pages to be the exception.
b. Another way mentioned is by having most of the JSP files under the WEB-INF folder. That way the users don't have access to the JSP's but the servlets do. My understanding is a little wobbly here, because I can't conceptualize the virtual path for files under WEB-INF when sending a response. (See line of code below.) Also, that would require moving most of the JSP files.
> request.getRequestDispatcher("folder/file.jsp"); // what about WEB-INF?
Is there a "smart" way of doing this? Perhaps it would have been prudent to organize the JSP folders "properly" in the first place, but we're way beyond that now.
Got any comments, suggestions, advice?
Thanks. :-)
--
Cris Berneburg
CACI Lead Software Engineer
RE: how to prevent user access to JSP pages?
Posted by "Berneburg, Cris J. - US" <cb...@caci.com>.
Hi Chris
Thanks for your insight and reply.
cjb> I'd like to prevent users from requesting JSP pages directly,
cjb> except for the login page.
cs> Why except for the login page? I would include the login page
cs> as something that should be fronted with a (non-JSP) servlet,
cs> even if that servlet doesn't do anything right now. It gives
cs> you great flexibility in the future.
OK, that sounds reasonable.
cjb> I want all requests to be handled by servlets. That way I can
cjb> legitimately claim that all requests are being validated, input
cjb> scrubbed, JSP's cannot be taken advantage of w/o their servlet
cs> it's easy to put a servlet in front of everything that does
cs> *not* provide everything above, but... let's just assume that's
cs> all being competently done.
Well, it is still a work in progress.
cjb> a. One way I read is by adding a <security-constraint> for each
cjb> folder. One use case is for JSP include files. That looks
cjb> possible but makes it seem like these are exceptions and not
cjb> the rule. I want "deny, deny, deny" to be the default and the
cjb> one or 2 allowable JSP pages to be the exception.
cs> This is certainly doable, but it's a lot of work, and you have
cs> to maintain those blacklists as your application grows.
Agreed, and yuck.
cjb> b. Another way mentioned is by having most of the JSP files under
cjb> the WEB-INF folder. That way the users don't have access to the
cjb> JSP's but the servlets do. [...] Also, that would require moving
cjb> most of the JSP files.
cs> This is the way I've always seen it done, and the way I would
cs> recommend that you do it.
OK, gotcha.
cs> It *does* require that you move all your JSPs, but that's a one-time
cs> headache and it sets a precedent for the future of your project(s):
cs> put all your JSPs under /WEB-INF.
cs> You will of course also have to fix every include/forward that you
cs> have in your application
I was afraid of that. :-/ Looks like yet another round of refactoring. :-)
cs> fix every include/forward that you have in your application to
cs> include/forward to /WEB-INF/foo.jsp instead of just /foo.jsp.
OK, thanks for letting me know how to do that. Will it work for both scriptlet <%@ include file="abc.jsp" %> and JSP <jsp:include page="abc.jsp" /> includes?
--
Cris Berneburg
CACI Lead Software Engineer
Re: how to prevent user access to JSP pages?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Cris,
On 8/16/18 1:19 PM, Berneburg, Cris J. - US wrote:
> Due to security concerns and general fussiness on my part, I'd
> like to prevent users from requesting JSP pages directly, except
> for the login page.
Why except for the login page? I would include the login page as
something that should be fronted with a (non-JSP) servlet, even if
that servlet doesn't do anything right now. It gives you great
flexibility in the future.
> I want all requests to be handled by servlets. That way I can
> legitimately claim that all requests are being validated, input
> scrubbed, JSP's cannot be taken advantage of w/o their servlet
> chaperones being present, etc.
Well... it's easy to put a servlet in front of everything that doe
s*not* provide everything above, but... let's just assume that's all
being competently done.
> a. One way I read is by adding a <security-constraint> for each
> folder. One use case is for JSP include files. That looks
> possible but makes it seem like these are exceptions and not the
> rule. I want "deny, deny, deny" to be the default and the one or 2
> allowable JSP pages to be the exception.
This is certainly doable, but it's a lot of work, and you have to
maintain those blacklists as your application grows.
> b. Another way mentioned is by having most of the JSP files under
> the WEB-INF folder. That way the users don't have access to the
> JSP's but the servlets do. My understanding is a little wobbly
> here, because I can't conceptualize the virtual path for files
> under WEB-INF when sending a response. (See line of code below.)
> Also, that would require moving most of the JSP files.
This is the way I've always seen it done, and the way I would
recommend that you do it. It *does* require that you move all your
JSPs, but that's a one-time headache and it sets a precedent for the
future of your project(s): put all your JSPs under /WEB-INF.
You will of course also have to fix every include/forward that you
have in your application to include/forward to /WEB-INF/foo.jsp
instead of just /foo.jsp.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt1yk4ACgkQHPApP6U8
pFiG5A//S7R1d3GmxX2dMDFGDwq7TM8wdwNoBLBl23ROrHbRFg+5gN/2rIQoU4Km
f7wLVQxKNjVslSEss1ARcCjmP7MsxgZyL2gXcYaqV6u2EC5EgS+NIyK5PL1hgp3J
3h+RgcaJIjJoohMz2WlLYqPPVzTBuUqHjSxLx+bv0OFPIwSLcsRS2lO58sXVW6s8
r0v4wotyslAQYCC43Zc8w9o0QSYIuqO2v3V1ef/aSN0yJzMZSSyr9ldVONLr3Qg3
fC0VSqbHPf2h9Shbk7APiCm/P8pxBx2Rxz/c5LNAIpgcLjp+q+g0V8B+a1sUICT2
EEZt68pR9RQr+d48/O+HCz+R1qRtPSqxtj3mAc4jrbDGjmdSobuiqTBMe7eAsFhU
++133rHdTuCr0q7DMGSRl1v92tSX/8l8BI/BRstreXyY2fkFbUA3e1byS/7whUdO
y3P7xxflwwIKUWRTteHbQ6fzOUshKW4oxQB6tkhWJKM+KKArv59vHZlBhl1d5tli
GmX4jf1Ioo7Ghsw50ESc1mOXOpalm7U9NkonInRimDqegBclWXu3QMG8ze/xCF2U
JAKsF0/2sUjhKtZde3MKn4xlHGkvLKGs0qONbyDfXTRx0fvvsA0Cpg+X2LH6T2OP
Prbcn22i0dk+6zraaUI7UL+Kd3L6qfHSF/2wL654xFV71Yi5ggs=
=k+i4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Terrence,
On 8/18/18 10:39 PM, Terence M. Bandoian wrote:
> On 8/17/2018 8:52 AM, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Mark,
>>
>> On 8/17/18 3:54 AM, Mark Thomas wrote:
>>> On 16/08/18 18:19, Berneburg, Cris J. - US wrote:
>>>> Due to security concerns and general fussiness on my part,
>>>> I'd like to prevent users from requesting JSP pages directly,
>>>> except for the login page. I want all requests to be handled
>>>> by servlets. That way I can legitimately claim that all
>>>> requests are being validated, input scrubbed, JSP's cannot be
>>>> taken advantage of w/o their servlet chaperones being
>>>> present, etc.
>>> I'm struggling to understand what risks exists with JSPs that
>>> don't with Servlets. After all, a JSP is just an alternative
>>> way to write a Servlet. Tomcat translates the .jsp file to the
>>> .java source for a servlet, compiles it and runs it.
>>>
>>> Can you elaborate?
>> JSP support for input validation, etc. is basically non-existent.
>> I'm sure someone has a crappy library that can do it, and yes,
>> you can implement everything in JSP using miles of tag libraries
>> and stuff like that, but in the application world, that's a
>> serious no-no.
>>
>> MVC (or some version of it, under various names) is the "proper"
>> way to build software, and JSPs are relegated to the "V" portion
>> of that paradigm.
>>
>> Once you have decided that JSPs are squarely in the "V" category,
>> it's no longer appropriate for them to be treated as "C"
>> components and therefore they should not be accessed directly.
>> Protecting them from direct-access is a reasonable decision for a
>> number of reasons, including security if you have pages that
>> cough-up sensitive information under the assumption that
>> authentication and authorization requirements have previously
>> been satisfied.
>>
>> Sure, the container's authentication and authorization should be
>> able to protect those JSPs just fine, but the application may
>> have other controls in place that also need to sanity-check
>> things before the JSP takes over.
>>
>> So, while there isn't anything particularly "dangerous" about
>> direct-access to JSPs, there are a number of "best practices"
>> that suggest that hiding them is a good idea.
>>
>> I hope that helps explain Cris's (likely) reasoning a little
>> more.
>>
>> - -chris
>
>
> As far as I know, there is no input validation that can be
> performed in servlets that can't also be performed in JSP pages
> using the same Java code. Also, I'm not aware of any functional
> limitation that prevents JSP pages (classes) from being used as
> controllers. As I understand them, JSPs can do anything that can
> be done in servlets and offer additional facilities and
> ease-of-use. They may be thought of as view-generators only but I
> don't think that's a functional limitation.
>
> Could a servlet filter be used to reject external requests for JSP
> pages?
You are absolutely correct that (modulo a few edge cases), JSPs can do
anything servlets can do.
The issue is that they really should not do all of those things, and
if you don't agree, that's all well and good: you can put your JSP
files anywhere you want and allow direct-access.
But for those who wish to implement a separation-of-concerns in their
applications, hiding JSPs behind a standard mechanism (i.e. /META-INF)
is a reasonable course of action.
My post was intended to give background for why anyone would want to
do this, not that everyone should do this because of some fundamental
problem with JSPs.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt7BFQACgkQHPApP6U8
pFjEVBAAgOOuo7K0nBZsiCNLy4QbNlDiUUeubz0h1lF5ECbMWcamB9Kd9n5k/qzx
VKDcLVuL46Sb6AJ/4wxomx4DIzOq2umhqLLxugo55ZZmD1w0HPT8+iQjq9wHUl9t
tHX56E9oGFzJP+mYdBVDMpYrXFE5j9AXVw00LiwRDCqwMqdctqftkFudYcEYIte9
nm87gCbbUgcBWs2MqEZFEBUWURUFYOpYBCCY9Hwmwt/ijmOkkO9OK2VCBNGFZtnG
6xH8VKuQARip+dkS3+DeyGFerJVW05REi1nq2ZSwn7JbOSXd60PcalJo57MRyE6u
6b98b3UEQEUaUopCSmY5LaqfAMmlKu8Yl4da8Z1PVgwVBZZh+rKKUE+M9M/Kb//l
DmgfrPs/G4tQcZr2jpMkXs63CvcWlyYHH3pvO/bf+ZcWq6w0yCl6JPK7/I1J1+zl
z8+AO8tCgvFXuy6c6KH5zABV2tlpLmKb1jbcd3hRGDExZQ+agZUHWqsAGYi7P17K
ToULyRrwKjdIm3PS7ljbJYo0gJ9FTqk1ChKl/Gy0KvzElY5KAt2ry19AGl8snT2w
goMihDcVKD7b448HEEqPmNle7SRRPJH/yvNeUMumFskTIChKwNOqU5LavwdwZJ4g
atGbrg1W+HeF600Ex/9VZ6hS6CbNdxmjgQ3FBBiALIiPdTv45S4=
=Zj+o
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Posted by "Mekkelsen Madden, Steve" <St...@pega.com>.
If it helps, I also needed to do something very similar where if the user connected to the right server running Tomcat and has the right port but wrong context or servlet, they would see a default Tomcat page not found revealing the application server used (Tomcat) and its version which for us was a security concern. Reading over previous emails here, I used the filter option:
<Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false" />
In the conf/context.xml file and now if the user connects to the wrong url, all they'll get is:
HTTP Status 404 -- Not Found
With nothing else revealed so this was perfect for us. There were other changes I needed to make in each servlet to also customize the response screens, it was only the invalid ones that were more difficult to figure out how to do.
Kind Regards,
Steve Mekkelsen Madden
-----Original Message-----
From: Terence M. Bandoian <te...@tmbsw.com>
Sent: Saturday, August 18, 2018 10:39 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: how to prevent user access to JSP pages?
On 8/17/2018 8:52 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 8/17/18 3:54 AM, Mark Thomas wrote:
>> On 16/08/18 18:19, Berneburg, Cris J. - US wrote:
>>> Due to security concerns and general fussiness on my part, I'd like
>>> to prevent users from requesting JSP pages directly, except for the
>>> login page. I want all requests to be handled by servlets. That
>>> way I can legitimately claim that all requests are being validated,
>>> input scrubbed, JSP's cannot be taken advantage of w/o their servlet
>>> chaperones being present, etc.
>> I'm struggling to understand what risks exists with JSPs that don't
>> with Servlets. After all, a JSP is just an alternative way to write a
>> Servlet. Tomcat translates the .jsp file to the .java source for a
>> servlet, compiles it and runs it.
>>
>> Can you elaborate?
> JSP support for input validation, etc. is basically non-existent. I'm
> sure someone has a crappy library that can do it, and yes, you can
> implement everything in JSP using miles of tag libraries and stuff
> like that, but in the application world, that's a serious no-no.
>
> MVC (or some version of it, under various names) is the "proper" way
> to build software, and JSPs are relegated to the "V" portion of that
> paradigm.
>
> Once you have decided that JSPs are squarely in the "V" category, it's
> no longer appropriate for them to be treated as "C" components and
> therefore they should not be accessed directly. Protecting them from
> direct-access is a reasonable decision for a number of reasons,
> including security if you have pages that cough-up sensitive
> information under the assumption that authentication and authorization
> requirements have previously been satisfied.
>
> Sure, the container's authentication and authorization should be able
> to protect those JSPs just fine, but the application may have other
> controls in place that also need to sanity-check things before the JSP
> takes over.
>
> So, while there isn't anything particularly "dangerous" about
> direct-access to JSPs, there are a number of "best practices" that
> suggest that hiding them is a good idea.
>
> I hope that helps explain Cris's (likely) reasoning a little more.
>
> - -chris
As far as I know, there is no input validation that can be performed in servlets that can't also be performed in JSP pages using the same Java code. Also, I'm not aware of any functional limitation that prevents JSP pages (classes) from being used as controllers. As I understand them, JSPs can do anything that can be done in servlets and offer additional facilities and ease-of-use. They may be thought of as view-generators only but I don't think that's a functional limitation.
Could a servlet filter be used to reject external requests for JSP pages?
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 8/17/2018 8:52 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 8/17/18 3:54 AM, Mark Thomas wrote:
>> On 16/08/18 18:19, Berneburg, Cris J. - US wrote:
>>> Due to security concerns and general fussiness on my part, I'd
>>> like to prevent users from requesting JSP pages directly, except
>>> for the login page. I want all requests to be handled by
>>> servlets. That way I can legitimately claim that all requests
>>> are being validated, input scrubbed, JSP's cannot be taken
>>> advantage of w/o their servlet chaperones being present, etc.
>> I'm struggling to understand what risks exists with JSPs that don't
>> with Servlets. After all, a JSP is just an alternative way to write
>> a Servlet. Tomcat translates the .jsp file to the .java source for
>> a servlet, compiles it and runs it.
>>
>> Can you elaborate?
> JSP support for input validation, etc. is basically non-existent. I'm
> sure someone has a crappy library that can do it, and yes, you can
> implement everything in JSP using miles of tag libraries and stuff
> like that, but in the application world, that's a serious no-no.
>
> MVC (or some version of it, under various names) is the "proper" way
> to build software, and JSPs are relegated to the "V" portion of that
> paradigm.
>
> Once you have decided that JSPs are squarely in the "V" category, it's
> no longer appropriate for them to be treated as "C" components and
> therefore they should not be accessed directly. Protecting them from
> direct-access is a reasonable decision for a number of reasons,
> including security if you have pages that cough-up sensitive
> information under the assumption that authentication and authorization
> requirements have previously been satisfied.
>
> Sure, the container's authentication and authorization should be able
> to protect those JSPs just fine, but the application may have other
> controls in place that also need to sanity-check things before the JSP
> takes over.
>
> So, while there isn't anything particularly "dangerous" about
> direct-access to JSPs, there are a number of "best practices" that
> suggest that hiding them is a good idea.
>
> I hope that helps explain Cris's (likely) reasoning a little more.
>
> - -chris
As far as I know, there is no input validation that can be performed in
servlets that can't also be performed in JSP pages using the same Java
code. Also, I'm not aware of any functional limitation that prevents
JSP pages (classes) from being used as controllers. As I understand
them, JSPs can do anything that can be done in servlets and offer
additional facilities and ease-of-use. They may be thought of as
view-generators only but I don't think that's a functional limitation.
Could a servlet filter be used to reject external requests for JSP pages?
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Cris,
On 8/20/18 2:10 PM, Berneburg, Cris J. - US wrote:
> cs> So, while there isn't anything particularly "dangerous" about
> direct- cs> access to JSPs, there are a number of "best practices"
> that suggest cs> that hiding them is a good idea.
>
> If some authenticated user can directly access a JSP page and
> manipulate the parameters, they can keep reloading the page while
> varying conjured arguments to find and exploit potential
> weaknesses. Am I mistaken, but does vulnerability scanning
> software seem to feed on that sort of thing?
Most vulnerability scanners just try to detect your server's version
and look-up any publicly-reported vulnerabilities in e.g. NVD. They
are really stupid tools for the most part.
If you hired a real pen tester, they would probably run one of those
scanners first just to get some intel and then dive-into attacking
your application e.g. with request-parameter munging.
> Maybe it's just an illusion, but I feel like there is more security
> control if a user must access a servlet first.
It's an illusion from a purely technical perspective, but there are
*many* reasons why it's easier (and, therefore, better!) to handle
many of those sanity-checks, etc. in a non-JSP-based controller servlet.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt8QF0ACgkQHPApP6U8
pFhFzRAAx1CVIGHgEk4+BT/RcWiWsRitdoYXrbsby2wULdwdUB421U/mirq5Rhq0
HZhkFYrAzV5nFKf5UWblLqtrrIHg3AfIsDCrj/3a2OLrFVWGNuLIasItmWQrrLKK
g3nEvyOUpxm5fuxqr/80q5FlI/tmxXnkK6lIIgOe+QM2HzCI1awuC9Epx85R/X3y
0eUt+mqlpkRQlIYRdUNDFWaZsX1WYv9hZqr29jGMte/mTLkt/P591YFgjwWICSDa
tgGBIhF53rRfUYdwmnj9UnUz1CAo1FqEkV9CD64IXQQ020dWOsQvEjNsGTBwK2xt
N9zSPX4V0ETABum+PgU3FyKGPRLrK+x523YDruvduPFZF7Kndk+Bw5hu/gm3jUA7
f628NqV/RhyhW5ObisftGr9jNU1pdOuui4zhmTmRSuWWmcq35Tfc4x4JNn14kIPt
YpH0rkSqbVS7bVqJjfjp1BAvBgdrVC18w+9CbKsm0oMTcRnT/r9HG33oQ060Rzel
JUEFCGmS1avzKaWdDR03i3KMAqFyPWp7YlZyd+iugUNgeh7gLJtvh6eyZaQ5dIKJ
xOpevejDgPJLy9CSXiY829rXi/NEVMO1XKJ12T9olzGFliFohWJwruk107FQhR3X
HkP1PzyuaXmCBl86t/Cj0J2iDVFrkTB532xZHNpF0FqZ+oyqECE=
=M1QB
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Posted by "Berneburg, Cris J. - US" <cb...@caci.com>.
Chris (and Mark)
Bingo!
cjb> Due to security concerns and general fussiness on my part, I'd like
cjb> to prevent users from requesting JSP pages directly [...]. That
cjb> way I can legitimately claim that all requests are being validated,
cjb> input scrubbed, JSP's cannot be taken advantage of w/o their
cjb> servlet chaperones being present, etc.
mt> I'm struggling to understand what risks exists with JSPs that don't
mt> with Servlets. After all, a JSP is just an alternative way to write
mt> a Servlet. Tomcat translates the .jsp file to the .java source for a
mt> servlet, compiles it and runs it.
mt> Can you elaborate?
cs> JSP support for input validation, etc. is basically non-existent. I'm
cs> sure someone has a crappy library that can do it, and yes, you can
cs> implement everything in JSP using miles of tag libraries and stuff
cs> like that, but in the application world, that's a serious no-no.
+1
Yeah, messy.
cs> MVC (or some version of it, under various names) is the "proper" way
cs> to build software, and JSPs are relegated to the "V" portion of that
cs> paradigm.
cs> Once you have decided that JSPs are squarely in the "V" category,
cs> it's no longer appropriate for them to be treated as "C" components
cs> and therefore they should not be accessed directly.
+1
Yup, separation of responsibilities.
cs> Protecting them from direct-access is a reasonable decision for a number
cs> of reasons, including security if you have pages that cough-up sensitive
cs> information under the assumption that authentication and authorization
cs> requirements have previously been satisfied.
cs> Sure, the container's authentication and authorization should be able
cs> to protect those JSPs just fine, but the application may have other
cs> controls in place that also need to sanity-check things before the JSP
cs> takes over.
+1
Beyond merely having the bouncer allowing the person into the club, there are other validation and sanity-checks that need to happen, which I would prefer to be centralized, not in both the JSP's *and* non-JSP servlets.
cs> So, while there isn't anything particularly "dangerous" about direct-
cs> access to JSPs, there are a number of "best practices" that suggest
cs> that hiding them is a good idea.
If some authenticated user can directly access a JSP page and manipulate the parameters, they can keep reloading the page while varying conjured arguments to find and exploit potential weaknesses. Am I mistaken, but does vulnerability scanning software seem to feed on that sort of thing? Maybe it's just an illusion, but I feel like there is more security control if a user must access a servlet first.
cs> I hope that helps explain Cris's (likely) reasoning a little more.
Exact-ically.
--
Cris Berneburg
CACI Lead Software Engineer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 8/17/18 3:54 AM, Mark Thomas wrote:
> On 16/08/18 18:19, Berneburg, Cris J. - US wrote:
>> Due to security concerns and general fussiness on my part, I'd
>> like to prevent users from requesting JSP pages directly, except
>> for the login page. I want all requests to be handled by
>> servlets. That way I can legitimately claim that all requests
>> are being validated, input scrubbed, JSP's cannot be taken
>> advantage of w/o their servlet chaperones being present, etc.
>
> I'm struggling to understand what risks exists with JSPs that don't
> with Servlets. After all, a JSP is just an alternative way to write
> a Servlet. Tomcat translates the .jsp file to the .java source for
> a servlet, compiles it and runs it.
>
> Can you elaborate?
JSP support for input validation, etc. is basically non-existent. I'm
sure someone has a crappy library that can do it, and yes, you can
implement everything in JSP using miles of tag libraries and stuff
like that, but in the application world, that's a serious no-no.
MVC (or some version of it, under various names) is the "proper" way
to build software, and JSPs are relegated to the "V" portion of that
paradigm.
Once you have decided that JSPs are squarely in the "V" category, it's
no longer appropriate for them to be treated as "C" components and
therefore they should not be accessed directly. Protecting them from
direct-access is a reasonable decision for a number of reasons,
including security if you have pages that cough-up sensitive
information under the assumption that authentication and authorization
requirements have previously been satisfied.
Sure, the container's authentication and authorization should be able
to protect those JSPs just fine, but the application may have other
controls in place that also need to sanity-check things before the JSP
takes over.
So, while there isn't anything particularly "dangerous" about
direct-access to JSPs, there are a number of "best practices" that
suggest that hiding them is a good idea.
I hope that helps explain Cris's (likely) reasoning a little more.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt20yEACgkQHPApP6U8
pFj6uxAAxyAHmZgiPBNFXRQvbfmr7Su7WKfXeIuu2/VNdWluUBjmxqnNCbO7dgyh
F/emljDwMhU+PG/5Q8CDyi7+owPcRL0ix5l0ywQ+cm+nJk1YsohN52INUJ9uod4F
Uo+/Lty1/sro2coJYtDCeXTJzocgagSdef5Uw3jYnL64Zeaa1D/FwOffcGNbAG9g
mHY07JN3AsDDM3+ehNCK/MKSe+CYK+MSWPhb+ALYKXkRfhltWJu1ojNo5O4jy4SS
G1w2ZZaSZ1ISb52VXbN0+MOsHquNNFrm1UH7fDrrSazwSNMq998qeuUPzdljtEVa
aM8H4Zf3ERLUbEXIL4pbhd1wU7hkjdSzTzxvQlqyI1F1dtmHV9t3F0YITdCaFmfU
lepJhrHq6NHwt9peHs1DCSsb72kOv3bAR7F/rHVZNi3I0PL+MsxkoGgMQt74Xi1a
du9gHdsWMLIs0ZouLjAFVRLihbqKKXvZ7ATzgrFmFPNR3yIoIZn+iLT8LqiNqMBq
NsTQnktWTYKCs7uE7HUOyYwoqLOnEmjMqG9wjhTAETPQzp2PP3v2RJKfjI5WHMN8
H8PohSj7SxYxN5KWFR/JmO7eksetVVLw0q+NvuDj6L8grhBatVskIWV3FpFPzyI1
Qd2QxabNjNBgH+CXP57q7iYtYAdxkIOlH2q2JnkFbP1S1aWKWXY=
=DEMc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Cris,
On 8/22/18 11:22 AM, Berneburg, Cris J. - US wrote:
> Chris
>
> [combining messages]
>
> cjb> Am I mistaken, but does vulnerability scanning software cjb>
> seem to feed on that sort of thing?
>
> cs> Most vulnerability scanners just try to detect your server's
> cs> version and look-up any publicly-reported vulnerabilities in
> cs> e.g. NVD. They are really stupid tools for the most part.
>
> cs> If you hired a real pen tester, they would probably run one cs>
> of those scanners first just to get some intel and then cs>
> dive-into attacking your application e.g. with request- cs>
> parameter munging.
>
> I failed to mention that a vulnerability scanner being used
> actually follows paths in the source code. I inferred that a
> clever hacker could figure out how to discover and exploit the
> vulnerabilities, that the scanner revealed, by reloading pages and
> varying parameters.
You mean the source-code of the web page, right?
Yeah, these used to be called "web spiders". They are still really dumb.
What happens when it hits a login page? Can it authenticate and scan
the application internally?
> cs> One of the ways I have kept my code as maintainable as
> possible cs> is by not using JSPs :)
>
> OK, I'll bite. What do you use instead of JSP?
>
> [Chris S. replies, "Yes, folks - hook, line, AND sinker!"] :-)
$ find web -type f | sed -e "s/.*\.//" | sort | uniq -c | sort -nr
413 vm
182 png
65 jpg
63 xsl
37 gif
25 css
22 js
21 jsp
6 svg
6 html
3 xml
2 htc
1 zip
1 woff
1 txt
1 ttf
1 php (umm...)
1 dtd
Velocity WTF
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt9yvAACgkQHPApP6U8
pFiTUBAAr3v9St0NSBfJJQgJOZ/XsP0LjZBj5LWmRzv8ZEdEFqQH1AnIpSLsMCa6
Vy32tTJL5baY9aEZB3ahjt+8ifmhG8PEVs4ci+l0ATNLZXSSpg2ptuy1CrVfIm3c
tuszDxGo4aQ/h+O6DLGKEuBDX97uQ6cOzKZIaIRI8a7Ze2GCght7CuU4e3qe5RhU
vrv2sqCLAsFrzT1oic+4VZIux5xy3MV85LKLf34GSgbnakDJGn1Cr+8oLZ3ypXJp
rPfoyNbaqVskwzUITqfBQl+16bSkvu3WNTo8HhcP3Q5lChM5yHkPmlFGqCD90kqK
O6/8L9m9mUxQEvtOXR9N83pndpCNMNiziauz2WY9DaV348lM604ISvU+Lb84ptul
1akBmVEZitMBJkddyECte1c/0shhEYS/Gd49PvP1TzjkuChz6Vif7/wRaSariGKL
BOdlpnsDOJarqkFaeb2GH/zHzcHgPICjnOCGJ/JuC3YwLZu0uEIj5FIKmlGjMarb
OnqbyKv8sx1rbYq2/sVS0LfKj1JMlCGM6hzBld+qDf2ve831qIuA68sxS/tPFSas
Sq7+9NME1ZngzgaxlE+4U2rgvQ4mLUnzzzTY2bY4jJtdggYqcekdGVQ2jmPw7euO
KEmWrLZE3bsVRrOyMdhuNlq4sc++J30fvGFxLj/d39a3zkDxsP8=
=bHED
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Posted by "Berneburg, Cris J. - US" <cb...@caci.com>.
Chris
[combining messages]
cjb> Am I mistaken, but does vulnerability scanning software
cjb> seem to feed on that sort of thing?
cs> Most vulnerability scanners just try to detect your server's
cs> version and look-up any publicly-reported vulnerabilities in
cs> e.g. NVD. They are really stupid tools for the most part.
cs> If you hired a real pen tester, they would probably run one
cs> of those scanners first just to get some intel and then
cs> dive-into attacking your application e.g. with request-
cs> parameter munging.
I failed to mention that a vulnerability scanner being used actually follows paths in the source code. I inferred that a clever hacker could figure out how to discover and exploit the vulnerabilities, that the scanner revealed, by reloading pages and varying parameters.
cjb> For me, it's a twofold combination of (a) security
cjb> concerns and (b) separation of responsibilities.
cjb> a. Security - shrink the attack surface.
cs> It's worth pointing-out that what's shrinking is the attack
cs> surface *of the application*, not necessarily of JSP (as a
cs> technology) itself. While I agree 100% with (a), here, it's
cs> not because there is anything inherently risky about JSPs.
cs> It's that most people end up writing really awful JSPs that
cs> are full of holes.
Good point. I was not faulting the JSP technology itself, but rather the contents of the JSP files. While the JSP's have been refactored a few times already, I think the next strategic step would be to move them to a safe(r) place.
cjb> b. Separation of duties - I want the JSP's to simply render
cjb> pages and the non-JSP servlets to do all the heavy lifting.
cs> "separation of concerns" allows you to focus on one task in
cs> one piece of code, instead of having a JSP that needs to enforce
cs> security, sanitize inputs, query a database, manage the result
cs> set, etc. all while providing error-handling, etc. Anything that
cs> makes code more maintainable is a big +1 in my book.
+1
cs> One of the ways I have kept my code as maintainable as possible
cs> is by not using JSPs :)
OK, I'll bite. What do you use instead of JSP?
[Chris S. replies, "Yes, folks - hook, line, AND sinker!"] :-)
--
Cris Berneburg
CACI Lead Software Engineer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 8/23/2018 4:26 AM, Mark Thomas wrote:
> On 22/08/18 19:48, Terence M. Bandoian wrote:
>
> <snip/>
>
>> Back on topic, do JSPs have to be registered with the container using
>> servlet mappings in web.xml or some other mechanism in order to serve as
>> targets of forwards by servlets? Further, does doing so make those JSPs
>> accessible via external requests? I suspect the answer to both
>> questions is yes which means an additional mechanism will have to be
>> introduced to block that access which I believe was the original
>> question. Servlet filter?
> What makes JSPs accessible is the mapping of *.jsp to the JSP servlet.
> Any file outside of WEB-INF with a .jsp extension will be passed to the
> JSP servlet for processing:
> - .jsp -> .java
> - .java -> .class (servlet)
> - send request to servlet from previous step
>
> JSPs (or any other files) located under WEB-INF are never directly
> accessible.
>
> Forwards and includes can reference JSP files (actually any files)
> located under WEB-INF and the file is processed the same way it would be
> if it were located outside of WEB-INF. The idea of locating files under
> WEB-INF is so you can use them in forwards and includes without them
> being directly accessible.
>
> Mark
>
> P.S. It is actually WEB-INF or META_INF everywhere I write WEB-INF above
> but I only used WEB-INF to try and keep it clearer.
>
Thanks for clearing that up. It's surprisingly simple. The only
complication I found is that a "NamedDispatcher" is required to forward
to pre-compiled JSPs in WEB-INF that don't have servlet mappings.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by Mark Thomas <ma...@apache.org>.
On 22/08/18 19:48, Terence M. Bandoian wrote:
<snip/>
> Back on topic, do JSPs have to be registered with the container using
> servlet mappings in web.xml or some other mechanism in order to serve as
> targets of forwards by servlets? Further, does doing so make those JSPs
> accessible via external requests? I suspect the answer to both
> questions is yes which means an additional mechanism will have to be
> introduced to block that access which I believe was the original
> question. Servlet filter?
What makes JSPs accessible is the mapping of *.jsp to the JSP servlet.
Any file outside of WEB-INF with a .jsp extension will be passed to the
JSP servlet for processing:
- .jsp -> .java
- .java -> .class (servlet)
- send request to servlet from previous step
JSPs (or any other files) located under WEB-INF are never directly
accessible.
Forwards and includes can reference JSP files (actually any files)
located under WEB-INF and the file is processed the same way it would be
if it were located outside of WEB-INF. The idea of locating files under
WEB-INF is so you can use them in forwards and includes without them
being directly accessible.
Mark
P.S. It is actually WEB-INF or META_INF everywhere I write WEB-INF above
but I only used WEB-INF to try and keep it clearer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by David Wall <d....@computer.org>.
Has any decision been made on how the original poster will do this?
As I read through the various responses, while you can always argue
certain structures are better, it's simply not true that if you create
messy/insecure JSPs, you'll somehow create clean/secure servlets. Any
error you would make in a JSP you'd make for sure in a servlet. Again,
JSPs are servlets. You either protect requests coming in or not. You
can play with or hack parameters being sent to a servlet just as you can
to a JSP.
For sure, if you go through a servlet controller that does the user
login checks first before forwarding, that can make sense to concentrate
the requests, and JSPs would just be coded to stop processing (or
redirect to a login page, or return an error status) if it doesn't have
a session/request parameter added by the servlet that did the
authorization.
You can put all parameter checking into such a servlet, but that seems
not much better than having each servlet/JSP do parameter checking for
those it makes use of (if this were a known good, then we'd have just
one big servlet that does everything rather than dividing the work among
lots of them). It seems that if you have JSPs, you'll want those to be
checking params they expect (and safely ignore those you don't expect,
or report them, or produce an error, whatever it is you expect to do
when you see bad params come in).
It's unclear how direct access to a JSP is less secure than a servlet
that will route requests to all of those same JSPs, other than your JSPs
can somehow progress without caring who the authenticated user is. In
the end, a JSP typically doesn't just care that you are authenticated,
but who exactly you are as your user account is sure to have permissions
associated with it and will vary its processing based on the user.
Are there known exploits of direct JSP access that is shown to be solved
by putting all JSPs under WEB-INF?
Also, if server identification is so bad (it does seem to make it a bit
easier to look for known exploits), why does Tomcat not block reporting
anything about itself as the default? I can't imagine there are many
deployments that prefer to be insecure so that they can provide Tomcat
versioning info or the like. I mean, how many deployments need the
Tomcat version info returned as they would know what version they are
because they installed it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 8/21/2018 11:44 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Cris,
>
> On 8/20/18 1:31 PM, Berneburg, Cris J. - US wrote:
>> Hi Mark
>>
>> Thanks for taking the time to reply. :-)
>>
>> cjb> Due to security concerns and general fussiness on my part, I'd
>> like cjb> to prevent users from requesting JSP pages directly
>> [...]. That cjb> way I can legitimately claim that all requests
>> are being validated, cjb> input scrubbed, JSP's cannot be taken
>> advantage of w/o their cjb> servlet chaperones being present, etc.
>>
>> mt> I'm struggling to understand what risks exists with JSPs that
>> don't mt> with Servlets. After all, a JSP is just an alternative
>> way to write mt> a Servlet. Tomcat translates the .jsp file to the
>> .java source for a mt> servlet, compiles it and runs it. mt> Can
>> you elaborate?
>>
>> See Chris Shultz's reply about MVC. He pretty much nailed it.
>>
>> For me, it's a twofold combination of (a) security concerns and (b)
>> separation of responsibilities.
>>
>> a. Security - shrink the attack surface.
> It's worth pointing-out that what's shrinking is the attack surface
> *of the application*, not necessarily of JSP (as a technology) itself.
> While I agree 100% with (a), here, it's not because there is anything
> inherently risky about JSPs. It's that most people end up writing
> really awful JSPs that are full of holes.
>
>> b. Separation of duties - I want the JSP's to simply render pages
>> and the non-JSP servlets to do all the heavy lifting.
> This item (b) allows you to more effectively achieve (a) IMHO. Also,
> "separation of concerns" allows you to focus on one task in one piece
> of code, instead of having a JSP that needs to enforce security,
> sanitize inputs, query a database, manage the result set, etc. all
> while providing error-handling, etc. Anything that makes code more
> maintainable is a big +1 in my book.
>
> One of the ways I have kept my code as maintainable as possible is by
> not using JSPs :)
>
> - -chris
So, you don't like JSPs. Okay by me. Others have found them useful.
Back on topic, do JSPs have to be registered with the container using
servlet mappings in web.xml or some other mechanism in order to serve as
targets of forwards by servlets? Further, does doing so make those JSPs
accessible via external requests? I suspect the answer to both
questions is yes which means an additional mechanism will have to be
introduced to block that access which I believe was the original
question. Servlet filter?
In some cases (e.g. GET requests), it may be simpler to perform any
required validation in the JSP.
Also, shouldn't all JSPs be located in WEB-INF? If I remember
correctly, built-in protection is provided to prevent access to the
source code of JSPs within WEB-INF. In addition, I'd recommend
pre-compiling JSPs when possible.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Cris,
On 8/20/18 1:31 PM, Berneburg, Cris J. - US wrote:
> Hi Mark
>
> Thanks for taking the time to reply. :-)
>
> cjb> Due to security concerns and general fussiness on my part, I'd
> like cjb> to prevent users from requesting JSP pages directly
> [...]. That cjb> way I can legitimately claim that all requests
> are being validated, cjb> input scrubbed, JSP's cannot be taken
> advantage of w/o their cjb> servlet chaperones being present, etc.
>
> mt> I'm struggling to understand what risks exists with JSPs that
> don't mt> with Servlets. After all, a JSP is just an alternative
> way to write mt> a Servlet. Tomcat translates the .jsp file to the
> .java source for a mt> servlet, compiles it and runs it. mt> Can
> you elaborate?
>
> See Chris Shultz's reply about MVC. He pretty much nailed it.
>
> For me, it's a twofold combination of (a) security concerns and (b)
> separation of responsibilities.
>
> a. Security - shrink the attack surface.
It's worth pointing-out that what's shrinking is the attack surface
*of the application*, not necessarily of JSP (as a technology) itself.
While I agree 100% with (a), here, it's not because there is anything
inherently risky about JSPs. It's that most people end up writing
really awful JSPs that are full of holes.
> b. Separation of duties - I want the JSP's to simply render pages
> and the non-JSP servlets to do all the heavy lifting.
This item (b) allows you to more effectively achieve (a) IMHO. Also,
"separation of concerns" allows you to focus on one task in one piece
of code, instead of having a JSP that needs to enforce security,
sanitize inputs, query a database, manage the result set, etc. all
while providing error-handling, etc. Anything that makes code more
maintainable is a big +1 in my book.
One of the ways I have kept my code as maintainable as possible is by
not using JSPs :)
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt8QVIACgkQHPApP6U8
pFjgbA/6A74ruIlQ02cuGmRBegk4zqyUEKaEWJCJEC8SvudvUgHAiRhOnnR2Yscr
RWK0wQYzpAxd37/Us1D1jQeWkG4QjCXKNLxOkPMpOE/Qb9922XhLyn3aDI4wzjdi
RYkiR/KD4sbsbqwsBKLcFxoK/72goqNHGBYBMgNVrnmy3fp0bmavgW+gBXvH3Ucs
zMqJz5oTGeevBYrfnvUqqLhYQ7M5Vl3YhBXgDjXW+4HWL2shF4rFgpxrRfJg93tm
UsKMVRPatbKsRqdDS5nuI0CreYAsV2mybcrf8aGiNKrokLOZJlCZluC5lc4n5Nlw
DFEFUpzFnoxFo8bV2gHnAJL8EfbhOI/i/5kty3AmBwUsioTjf1XPJFPrNGOXOojJ
W0e/3cecsOJHyNsJozH/D2pSyT/XLhCWjwsBAl+h3sDVLX7hpXIrmNZm98u5kGWw
UvYjgiGRNbJOPsonlZcgRzRecZfELAU48z9fbHrhsScWQiJvJbHrDhMc9XfXlvjv
bcgLvu54ubDuMFMozTPGlA70HSmUk/FnMmWKd/238UVD8Xmx/xjVqp4hYRXtj6ap
UvPgisG6Ly/noRCkhKTILLvpcRPl3SJcNVuNYYj2WItbV1xEl3T4wifg3BRxynXl
opuFeT+5+h0kEsNuaD89kFiK0e4W/rrSNvEzMS1PEuH7lAM09h0=
=2PQp
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Posted by "Berneburg, Cris J. - US" <cb...@caci.com>.
Hi Mark
Thanks for taking the time to reply. :-)
cjb> Due to security concerns and general fussiness on my part, I'd like
cjb> to prevent users from requesting JSP pages directly [...]. That
cjb> way I can legitimately claim that all requests are being validated,
cjb> input scrubbed, JSP's cannot be taken advantage of w/o their
cjb> servlet chaperones being present, etc.
mt> I'm struggling to understand what risks exists with JSPs that don't
mt> with Servlets. After all, a JSP is just an alternative way to write
mt> a Servlet. Tomcat translates the .jsp file to the .java source for a
mt> servlet, compiles it and runs it.
mt> Can you elaborate?
See Chris Shultz's reply about MVC. He pretty much nailed it.
For me, it's a twofold combination of (a) security concerns and (b) separation of responsibilities.
a. Security - shrink the attack surface.
b. Separation of duties - I want the JSP's to simply render pages and the non-JSP servlets to do all the heavy lifting.
--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project
phone: 703-679-5313
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by Mark Thomas <ma...@apache.org>.
On 16/08/18 18:19, Berneburg, Cris J. - US wrote:
> Due to security concerns and general fussiness on my part, I'd like to prevent users from requesting JSP pages directly, except for the login page. I want all requests to be handled by servlets. That way I can legitimately claim that all requests are being validated, input scrubbed, JSP's cannot be taken advantage of w/o their servlet chaperones being present, etc.
I'm struggling to understand what risks exists with JSPs that don't with
Servlets. After all, a JSP is just an alternative way to write a
Servlet. Tomcat translates the .jsp file to the .java source for a
servlet, compiles it and runs it.
Can you elaborate?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by Woonsan Ko <wo...@apache.org>.
On Wed, Aug 22, 2018 at 11:44 AM, Berneburg, Cris J. - US
<cb...@caci.com> wrote:
> Hi Woonsan
>
> cjb> I'd like to prevent users from requesting JSP pages directly
>
> cjb> a. [...] adding a <security-constraint> for each folder.
>
> cjb> b. [...] JSP files under the WEB-INF folder.
>
> wk> c. Implement a servlet filter which is mapped to /* with
> wk> dispatcher options: REQUEST, INCLUDE, FORWARD. The filter may
> wk> check the request URI or include/forward URI (through request
> wk> attributes).
>
> wk> The chapter 6 of the servlet spec [1] describes what Filter is,
> wk> when/how it can be used, its lifecycle, etc. Dispatcher options
> wk> are explained in 6.2.5. Your servlet filter implementation may
> wk> be invoked as pre-processing component before other resources
> wk> or servlets. When .jsp is accessed directly, your filter may
> wk> be invoked as REQUEST dispatcher option (the default unless
> wk> configured manually), you can check the resource path info
> wk> through HttpRequestServlet#getRequestURI(). e.g,
> wk> /examples/hello.jsp. If you want to check the cases where the
> wk> JSP is included or forwarded through RequestDispatcher, you may
> wk> check servlet request attributes described in the section 9.3.1
> wk> (for inclusion) or 9.4.2 (for forwarding). So, you might want to
> wk> check include/forward path first and find requestURI afterward
> wk> to check everything and modify the response as a result. For
> wk> example, you can choose to send a 4xx response if the condition
> wk> doesn't meet your requirement. All of those are based on
> wk> servlet standards.
>
> I'm afraid this is a bit more advanced than where I currently am ATM and possibly what my project requires.
It was just an option. ;-) Feel free to ignore. It's you to judge your
case best.
Woonsan
>
> Also, I am reminded of the textbook phrase, "the rest is left as an exercise to the reader". :-) Or a presenter...
>
> --
> Cris Berneburg
> CACI Lead Software Engineer
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Posted by "Berneburg, Cris J. - US" <cb...@caci.com>.
Hi Woonsan
cjb> I'd like to prevent users from requesting JSP pages directly
cjb> a. [...] adding a <security-constraint> for each folder.
cjb> b. [...] JSP files under the WEB-INF folder.
wk> c. Implement a servlet filter which is mapped to /* with
wk> dispatcher options: REQUEST, INCLUDE, FORWARD. The filter may
wk> check the request URI or include/forward URI (through request
wk> attributes).
wk> The chapter 6 of the servlet spec [1] describes what Filter is,
wk> when/how it can be used, its lifecycle, etc. Dispatcher options
wk> are explained in 6.2.5. Your servlet filter implementation may
wk> be invoked as pre-processing component before other resources
wk> or servlets. When .jsp is accessed directly, your filter may
wk> be invoked as REQUEST dispatcher option (the default unless
wk> configured manually), you can check the resource path info
wk> through HttpRequestServlet#getRequestURI(). e.g,
wk> /examples/hello.jsp. If you want to check the cases where the
wk> JSP is included or forwarded through RequestDispatcher, you may
wk> check servlet request attributes described in the section 9.3.1
wk> (for inclusion) or 9.4.2 (for forwarding). So, you might want to
wk> check include/forward path first and find requestURI afterward
wk> to check everything and modify the response as a result. For
wk> example, you can choose to send a 4xx response if the condition
wk> doesn't meet your requirement. All of those are based on
wk> servlet standards.
I'm afraid this is a bit more advanced than where I currently am ATM and possibly what my project requires.
Also, I am reminded of the textbook phrase, "the rest is left as an exercise to the reader". :-) Or a presenter...
--
Cris Berneburg
CACI Lead Software Engineer
Re: how to prevent user access to JSP pages?
Posted by Woonsan Ko <wo...@apache.org>.
On Mon, Aug 20, 2018 at 1:19 PM, Berneburg, Cris J. - US
<cb...@caci.com> wrote:
> Hi Woonsan
>
> Thanks for providing an "option C". :-) There is still much for me to learn.
You're welcome. :-)
>
> cjb> Due to security concerns and general fussiness on my part, I'd like
> cjb> to prevent users from requesting JSP pages directly [...]. That
> cjb> way I can legitimately claim that all requests are being validated,
> cjb> input scrubbed, JSP's cannot be taken advantage of w/o their
> cjb> servlet chaperones being present, etc.
>
> cjb> a. [...] adding a <security-constraint> for each folder.
>
> cjb> b. [...] JSP files under the WEB-INF folder.
>
> wk> c. Implement a servlet filter which is mapped to /* with dispatcher
> wk> options: REQUEST, INCLUDE, FORWARD. The filter may check the request
> wk> URI or include/forward URI (through request attributes).
>
> While I have a general idea of what you mean, I don't know how to implement that. Is that a standard practice?
I think the option uses standards and doesn't depart from standard practices.
The chapter 6 of the servlet spec [1] describes what Filter is,
when/how it can be used, its lifecycle, etc. Dispatcher options are
explained in 6.2.5.
Your servlet filter implementation may be invoked as pre-processing
component before other resources or servlets.
When .jsp is accessed directly, your filter may be invoked as REQUEST
dispatcher option (the default unless configured manually), you can
check the resource path info through
HttpRequestServlet#getRequestURI(). e.g, /examples/hello.jsp. If you
want to check the cases where the JSP is included or forwarded through
RequestDispatcher, you may check servlet request attributes described
in the section 9.3.1 (for inclusion) or 9.4.2 (for forwarding). So,
you might want to check include/forward path first and find requestURI
afterward to check everything and modify the response as a result. For
example, you can choose to send a 4xx response if the condition
doesn't meet your requirement.
All of those are based on servlet standards.
HTH,
Woonsan
[1] https://javaee.github.io/servlet-spec/downloads/servlet-3.1/Final/servlet-3_1-final.pdf
>
> --
> Cris Berneburg
> CACI Lead Software Engineer
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Posted by "Berneburg, Cris J. - US" <cb...@caci.com>.
Hi Woonsan
Thanks for providing an "option C". :-) There is still much for me to learn.
cjb> Due to security concerns and general fussiness on my part, I'd like
cjb> to prevent users from requesting JSP pages directly [...]. That
cjb> way I can legitimately claim that all requests are being validated,
cjb> input scrubbed, JSP's cannot be taken advantage of w/o their
cjb> servlet chaperones being present, etc.
cjb> a. [...] adding a <security-constraint> for each folder.
cjb> b. [...] JSP files under the WEB-INF folder.
wk> c. Implement a servlet filter which is mapped to /* with dispatcher
wk> options: REQUEST, INCLUDE, FORWARD. The filter may check the request
wk> URI or include/forward URI (through request attributes).
While I have a general idea of what you mean, I don't know how to implement that. Is that a standard practice?
--
Cris Berneburg
CACI Lead Software Engineer
Re: how to prevent user access to JSP pages?
Posted by Woonsan Ko <wo...@apache.org>.
There's another considerable option:
c. Implement a servlet filter which is mapped to /* with dispatcher
options: REQUEST, INCLUDE, FORWARD. The filter may check the request
URI or include/forward URI (through request attributes).
Regards,
Woonsan
On Thu, Aug 16, 2018 at 1:19 PM, Berneburg, Cris J. - US
<cb...@caci.com> wrote:
> Due to security concerns and general fussiness on my part, I'd like to prevent users from requesting JSP pages directly, except for the login page. I want all requests to be handled by servlets. That way I can legitimately claim that all requests are being validated, input scrubbed, JSP's cannot be taken advantage of w/o their servlet chaperones being present, etc.
>
> a. One way I read is by adding a <security-constraint> for each folder. One use case is for JSP include files. That looks possible but makes it seem like these are exceptions and not the rule. I want "deny, deny, deny" to be the default and the one or 2 allowable JSP pages to be the exception.
>
> b. Another way mentioned is by having most of the JSP files under the WEB-INF folder. That way the users don't have access to the JSP's but the servlets do. My understanding is a little wobbly here, because I can't conceptualize the virtual path for files under WEB-INF when sending a response. (See line of code below.) Also, that would require moving most of the JSP files.
>
>> request.getRequestDispatcher("folder/file.jsp"); // what about WEB-INF?
>
> Is there a "smart" way of doing this? Perhaps it would have been prudent to organize the JSP folders "properly" in the first place, but we're way beyond that now.
>
> Got any comments, suggestions, advice?
>
> Thanks. :-)
>
> --
> Cris Berneburg
> CACI Lead Software Engineer
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Posted by "Berneburg, Cris J. - US" <cb...@caci.com>.
David
Thanks for taking the time to reply. :-)
cjb> Due to security concerns and general fussiness on my part, I'd like to
cjb> prevent users from requesting JSP pages directly [...]. That way I can
cjb> legitimately claim that all requests are being validated, input scrubbed,
cjb> JSP's cannot be taken advantage of w/o their servlet chaperones being
cjb> present, etc.
dw> JSPs are servlets.
dw> For us, the common way would be for your non-JSP servlets to authenticate
dw> the request (and save the results in the request), and then your JSPs can
dw> check if the request has been authenticated before progressing further.
dw> Of course, if it's just a login check, you can save the results of the
dw> authentication in the session, and when missing, redirect to your login.
It's more than just initial authentication, which the application does perform. I want to:
1. Prevent users from requesting pages directly to:
a. Prevent errors due to missing query data from bypassed process.
b. Reduce the application's attack surface size.
2. Hide JSP's from security scanning software. Again, shrinking the app's attack surface.
See Chris Shultz's reply about MVC, which captures my concerns most eloquently.
--
Cris Berneburg
CACI Lead Software Engineer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Posted by "Berneburg, Cris J. - US" <cb...@caci.com>.
Hi Louis
Thanks for replying to my request for help. :-)
cjb> Due to security concerns and general fussiness on my part, I'd like
cjb> to prevent users from requesting JSP pages directly [...]. That
cjb> way I can legitimately claim that all requests are being validated,
cjb> input scrubbed, JSP's cannot be taken advantage of w/o their
cjb> servlet chaperones being present, etc.
cjb> a. One way I read is by adding a <security-constraint> for each
cjb> folder. One use case is for JSP include files. That looks possible
cjb> but makes it seem like these are exceptions and not the rule. I
cjb> want "deny, deny, deny" to be the default and the one or 2 allowable
cjb> JSP pages to be the exception.
lz> can't you create a Security Folder and list out only the JSPs
lz> that you want to allow the users access to? My application is
lz> a third party application so I didn't develop it but they use
lz> a folder that has a list of .jsps that I can access so I assume
lz> they have set it up in the code.
It sounds like you're suggesting something like option (a), using security constraints linked to folders.
lz> Or am I just telling you the end state that you want to achieve
lz> without actually coding suggesting any coding for you?
Yeah, that's an end-state, and the security folder would be one possible method of getting there.
--
Cris Berneburg
CACI Lead Software Engineer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to prevent user access to JSP pages?
Posted by Louis Zipes <Lo...@gmcr.com>.
Maybe I'm not fully understanding the request but can't you create a Security Folder and list out only the JSPs that you want to allow the users access to? My application is a third party application so I didn't develop it but they use a folder that has a list of .jsps that I can access so I assume they have set it up in the code.
Or am I just telling you the end state that you want to achieve without actually coding suggesting any coding for you?
Thanks, Louis
-----Original Message-----
From: David Wall [mailto:d.wall@computer.org]
Sent: Thursday, August 16, 2018 2:27 PM
To: users@tomcat.apache.org
Subject: Re: how to prevent user access to JSP pages?
- - - external message, proceed with caution - - -
I'll be curious to see the answers.
JSPs are servlets.
For us, the common way would be for your non-JSP servlets to
authenticate the request (and save the results in the request), and then
your JSPs can check if the request has been authenticated before
progressing further. Of course, if it's just a login check, you can
save the results of the authentication in the session, and when missing,
redirect to your login.
On 8/16/18 10:19 AM, Berneburg, Cris J. - US wrote:
> Due to security concerns and general fussiness on my part, I'd like to prevent users from requesting JSP pages directly, except for the login page. I want all requests to be handled by servlets. That way I can legitimately claim that all requests are being validated, input scrubbed, JSP's cannot be taken advantage of w/o their servlet chaperones being present, etc.
>
> a. One way I read is by adding a <security-constraint> for each folder. One use case is for JSP include files. That looks possible but makes it seem like these are exceptions and not the rule. I want "deny, deny, deny" to be the default and the one or 2 allowable JSP pages to be the exception.
>
> b. Another way mentioned is by having most of the JSP files under the WEB-INF folder. That way the users don't have access to the JSP's but the servlets do. My understanding is a little wobbly here, because I can't conceptualize the virtual path for files under WEB-INF when sending a response. (See line of code below.) Also, that would require moving most of the JSP files.
>
>> request.getRequestDispatcher("folder/file.jsp"); // what about WEB-INF?
> Is there a "smart" way of doing this? Perhaps it would have been prudent to organize the JSP folders "properly" in the first place, but we're way beyond that now.
>
> Got any comments, suggestions, advice?
>
> Thanks. :-)
>
> --
> Cris Berneburg
> CACI Lead Software Engineer
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may contain information that is confidential, proprietary or exempt from disclosure. If you are not the intended recipient, please contact the sender immediately. Unauthorized use or distribution is prohibited and may be unlawful.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to prevent user access to JSP pages?
Posted by David Wall <d....@computer.org>.
I'll be curious to see the answers.
JSPs are servlets.
For us, the common way would be for your non-JSP servlets to
authenticate the request (and save the results in the request), and then
your JSPs can check if the request has been authenticated before
progressing further. Of course, if it's just a login check, you can
save the results of the authentication in the session, and when missing,
redirect to your login.
On 8/16/18 10:19 AM, Berneburg, Cris J. - US wrote:
> Due to security concerns and general fussiness on my part, I'd like to prevent users from requesting JSP pages directly, except for the login page. I want all requests to be handled by servlets. That way I can legitimately claim that all requests are being validated, input scrubbed, JSP's cannot be taken advantage of w/o their servlet chaperones being present, etc.
>
> a. One way I read is by adding a <security-constraint> for each folder. One use case is for JSP include files. That looks possible but makes it seem like these are exceptions and not the rule. I want "deny, deny, deny" to be the default and the one or 2 allowable JSP pages to be the exception.
>
> b. Another way mentioned is by having most of the JSP files under the WEB-INF folder. That way the users don't have access to the JSP's but the servlets do. My understanding is a little wobbly here, because I can't conceptualize the virtual path for files under WEB-INF when sending a response. (See line of code below.) Also, that would require moving most of the JSP files.
>
>> request.getRequestDispatcher("folder/file.jsp"); // what about WEB-INF?
> Is there a "smart" way of doing this? Perhaps it would have been prudent to organize the JSP folders "properly" in the first place, but we're way beyond that now.
>
> Got any comments, suggestions, advice?
>
> Thanks. :-)
>
> --
> Cris Berneburg
> CACI Lead Software Engineer
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org