Talk:Declarative Access Control in Java - Revision history

Owaspdavef at 01:21, 25 March 2008

2008-03-25T01:21:11Z

Jeff Williams: /* General Discussion */

2008-03-19T19:56:09Z

‎General Discussion

Owaspdavef at 16:35, 19 March 2008

2008-03-19T16:35:48Z

Owaspdavef at 20:55, 17 March 2008

2008-03-17T20:55:46Z

Stephendv: /* Status */

2008-01-14T11:04:14Z

‎Status

Stephendv: /* Status */

2008-01-14T11:02:00Z

‎Status

Frank.nimphius: /* General Discussion */

2007-01-23T08:24:54Z

‎General Discussion

Stephendv at 08:43, 14 November 2006

2006-11-14T08:43:58Z

Stephendv: /* General Discussion */

2006-11-14T08:42:07Z

‎General Discussion

Stephendv at 08:39, 14 November 2006

2006-11-14T08:39:53Z

← Older revision		Revision as of 01:21, 25 March 2008
Line 40:		Line 40:

	''Jeff Williams'' - This is really critical to understand. In some applications, the JSPs are intended to be accessed directly, and they contain some business logic and some presentation layer. But in most modern frameworks, there is a controller servlet that handles all the http request, invokes business logic, and '''forwards''' the request to the appropriate JSP. The JSP relies on information in the request or session attributes to be properly set. If you invoke the JSP directly, you are likely to get null pointer exceptions (because the attributes aren't there). But many times you can figure out what parameters the JSP code is expecting and you can make it do something. And occasionally, what you can force it to do is unauthorized and very damaging.		''Jeff Williams'' - This is really critical to understand. In some applications, the JSPs are intended to be accessed directly, and they contain some business logic and some presentation layer. But in most modern frameworks, there is a controller servlet that handles all the http request, invokes business logic, and '''forwards''' the request to the appropriate JSP. The JSP relies on information in the request or session attributes to be properly set. If you invoke the JSP directly, you are likely to get null pointer exceptions (because the attributes aren't there). But many times you can figure out what parameters the JSP code is expecting and you can make it do something. And occasionally, what you can force it to do is unauthorized and very damaging.
		+
		+	''DFerguson'' - Agreed, but if you know what you're doing you can prevent that from happening, such as having an include at the top of every JSP to check that the session state is valid. I guess the key is that developers have to understand the issue. I don't necessarily agree with an absolute rule about not accessing JSPs directly. As we know a JSP is really just a servlet. If you access a controller servlet directly, you can take steps to be able to safely access a JSP directly. If you're using a framework where that is out of the ordinary, then certainly I would not do it. I doubt someone using a framework would be using declarative access control anyway.

← Older revision		Revision as of 19:56, 19 March 2008
Line 38:		Line 38:

	''DFerguson - I don't understand why that would improve security. What threat is mitigated by having the JSPs inaccessible from the browser?''		''DFerguson - I don't understand why that would improve security. What threat is mitigated by having the JSPs inaccessible from the browser?''
		+
		+	''Jeff Williams'' - This is really critical to understand. In some applications, the JSPs are intended to be accessed directly, and they contain some business logic and some presentation layer. But in most modern frameworks, there is a controller servlet that handles all the http request, invokes business logic, and '''forwards''' the request to the appropriate JSP. The JSP relies on information in the request or session attributes to be properly set. If you invoke the JSP directly, you are likely to get null pointer exceptions (because the attributes aren't there). But many times you can figure out what parameters the JSP code is expecting and you can make it do something. And occasionally, what you can force it to do is unauthorized and very damaging.

@@ Line 20: / Line 20: @@
 * authentication methods 'Digest' ad 'Client cert' are evoked. How can they be implemented, i.e what is required on the client side (algorithm, certificate with proper issuer) and on the server side (algorithm for digest and certificate control, access to a trusted certificate database)
 * 2 different 'transport guarantees' are evoked, 'integral' and 'confidential'. What specific protocols, algorithms, and data, are required ?
 * SSL is evoked. a pointer toward a SSL page could be useful
-''DFerguson - I added a link to the OWASP SSL page, which is a stub and not very helpful.  Any other idea where the link should point to?''
+''DFerguson - I added a link to the OWASP SSL page, but it is just a stub and not very helpful.  Any other suggestions where the link should point to?''
 * no extra link is given. Is it deliberate from the Owasp editor ? Where can I go and look if I need further information ?
@@ Line 32: / Line 36: @@
 * I usually recommend storing the JSP files used for form based authentication in the WEB-INF directory. This way they cannot be accessed directly from the browser

@@ Line 12: / Line 12: @@
 * Introduction: a remainder of the technical context could be useful - what piece of code do one needs for executing this declarative access control: a servlet container ? a J2EE platform ?
 * first XML excerpt: no global tag is shown. If I have a real Web App descriptor without security, in which tag should I put the given xml code ?
 * authentication methods 'Digest' ad 'Client cert' are evoked. How can they be implemented, i.e what is required on the client side (algorithm, certificate with proper issuer) and on the server side (algorithm for digest and certificate control, access to a trusted certificate database)
@@ Line 20: / Line 24: @@
 * SSL is evoked. a pointer toward a SSL page could be useful
 * no extra link is given. Is it deliberate from the Owasp editor ? Where can I go and look if I need further information ?
 * I usually recommend storing the JSP files used for form based authentication in the WEB-INF directory. This way they cannot be accessed directly from the browser

@@ Line 1: / Line 1: @@
 ==Status==
-Released 14/1/2008
+Under review
 ==Authors==

← Older revision		Revision as of 08:24, 23 January 2007
Line 21:		Line 21:

	* no extra link is given. Is it deliberate from the Owasp editor ? Where can I go and look if I need further information ?		* no extra link is given. Is it deliberate from the Owasp editor ? Where can I go and look if I need further information ?
		+
		+	* I usually recommend storing the JSP files used for form based authentication in the WEB-INF directory. This way they cannot be accessed directly from the browser

@@ Line 1: / Line 1: @@
 ==Status==
-Needs review
+Reviewed.  Author to act on comments.
 ==Reviewers==
-* ?
+* Pierre Parrend
 ==General Discussion==