My question is, does it really matter? Does it really represent a security issue?
The structure of struts jsp's are generally that they read the values from the "Form" object. So if someone goes directly to a jsp, they get a jsp. The jsp will try to read the values from the "form" object that will either: a) Crash because the form doesn't exist so when it tries to get the values it gets a null pointer b) Sets all the values as null/empty strings if existence of form is checked, etc.. If they try to submit the form, the security logic in the action will kick out the request. In the case of a) they had nothing to look at except an error page. In the case of b) they see how beautiful the page would look but without any data/information. Am I missing something? Does viewing a page structure with no data represent a security issue? Regards...djsuarez -----Original Message----- From: Erik Weber [mailto:[EMAIL PROTECTED] Sent: Thursday, August 26, 2004 8:25 AM To: Struts Users Mailing List Subject: Re: Question about authentication If your JSPs are in a public document root, there is nothing (necessarily) preventing a user from accessing them without going through a controller servlet, via an unintended (shortcut) path. Use the blank auth-constraint element in web.xml to deny direct access to the *.jsp web resource collection. Then make your intended paths end without extensions or with some other extension other than ".jsp". Now the only way to view your JSPs is to go through the controller. Erik David Suarez wrote: >I may be mis-reading the question but... why hide your jsp's from >direct access? The actions should definitely check for security and it >makes sense there but if your jsp's populate information from the form, >wouldn't the jsp be empty/unusable anyway?.. > >The approach above is what I have used. Only protect the forms/actions. >Empty jsp's I don't care about. Let me know why you think that this is >bad security practice. > >Regards...djsuarez > >-----Original Message----- >From: Jim Barrows [mailto:[EMAIL PROTECTED] >Sent: Wednesday, August 25, 2004 4:49 PM >To: Struts Users Mailing List >Subject: RE: Question about authentication > > > > > >>-----Original Message----- >>From: Steven Leija [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, August 25, 2004 2:15 PM >>To: Struts Users Mailing List >>Subject: RE: Question about authentication >> >> >>I'm currently running into the same situation. If you added >>to your web-inf directory. Do you just create a dir called >>"jsp"? and treat that as your root? Is there any sort of >>special path or configuration needed for this? I'm using Tomcat 5.0. >> >> > >No special configuration needed you forward to >/WEB-INF/jsp/yourpage.jsp. Any Servlet or JSP can access anything in >WEB-INF. >The only thing to remember is you cannot type in the jsp from the >browser, you have to go through an action. Which is what ForwardAction >is for :) > >If you don't like this, you could incorporate container managed security >to restrict all *.jsp to a dummy role. > > > > >> >>Thanks, >> >>Steven >> >> >> >> >>>Hi >>>I am going to use custom tags for checking >>>access to Jsp, if no user/bean bean in session, >>>then direct to login page. >>> >>>And I am also going to check admin bean again >>>in Action before invoking life cycle methods >>>on business beans. >>> >>>Now am I over kill with authentication?? >>> >>> >> Way overkill. Put your jsps in WEB-INF, and no one can >>get at them. If your container is new enough to handle >>filters, use them instead. Otherwise, use a >>BaseSecurityAction that overrides execute, does the check and >>then calls whateverYouWantForYourActualExecutionCode( same >>params as execute). >> >> > >> > I mean, if all JSP pages that require user/admin >> > access has custom tag that check for access >> > at top, then i don't really need to check >> > for authentication in Action classess. >> >> You shouldn't allow access to your jsp pages. >> >> > >> > But it may also be good practice to double check >> > for whatever reason. >> > >> > Just curious what's the usual practice u ppl do. >> > >> > Thanks >> > >> > >>--------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >>--------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
