J2EE Bad Practices: JSP Expressions - Revision history

MediaWiki spam cleanup: Reverting to last version not containing links to www.textcooucalideln.com

2009-05-27T18:30:49Z

Reverting to last version not containing links to www.textcooucalideln.com

Deleted user at 19:34, 22 May 2009

2009-05-22T19:34:30Z

KirstenS at 23:37, 7 April 2009

2009-04-07T23:37:55Z

KirstenS at 14:02, 17 February 2009

2009-02-17T14:02:00Z

KirstenS at 14:01, 17 February 2009

2009-02-17T14:01:18Z

KirstenS at 20:33, 2 November 2008

2008-11-02T20:33:38Z

KirstenS at 12:59, 17 October 2008

2008-10-17T12:59:03Z

KirstenS at 17:13, 26 September 2008

2008-09-26T17:13:58Z

Kunklejr at 19:54, 24 February 2007

2007-02-24T19:54:22Z

Kunklejr: New page: ==Overview== JSP 2.0 introduced a new capability allowing one to use JSP Expressions directly within the template text (i.e. outside of tag libraries or tag files) of a web page. However, ...

2007-02-24T19:49:11Z

New page: ==Overview== JSP 2.0 introduced a new capability allowing one to use JSP Expressions directly within the template text (i.e. outside of tag libraries or tag files) of a web page. However, ...

New page

==Overview==
JSP 2.0 introduced a new capability allowing one to use JSP Expressions directly within the template text (i.e. outside of tag libraries or tag files) of a web page. However, improper use of the expressions will leave an application open to [[XSS Attacks]].

==Consequences ==
* Failing to use JSP Expressions properly will leave an application open to [[XSS Attacks]].

==Exposure period ==
This vulnerability has existed since servlet containers and application servers began implementing the [[http://jcp.org/en/jsr/detail?id=152| JSP 2.0 standard]]

==Platform ==
* Languages: Java/JSP

==Required resources ==

==Severity ==
High

==Likelihood of exploit ==
If a developer uses JSP Expressions to write unsanitized, user-entered data to a page, the likelihood of exploit is very high.

==Discussion ==
JSP 2.0 expressions allow developers to expose data and objects stored in application, session, request, or page scope using an Ant-style syntax. It allows you to replace this

<pre>
<table>
<c:forEach var="book" items="${books}">
<tr>
<td><c:out value="${book.title}"/></td>
<td><c:out value="${book.author}"/></td>
<td><c:out value="${book.isbn}"/></td>
</tr>
</c:forEach>
</table>
</pre>

with this

<pre>
<table>
<c:forEach var="book" items="${books}">
<tr>
<td>${book.title}</td>
<td>${book.author}</td>
<td>${book.isbn}</td>
</tr>
</c:forEach>
</table>
</pre>

As you can see, the syntax in the second example is more succinct. However, it may also expose a Cross Site Scripting [[XSS Attacks| XSS]] vulnerability. The problem that few tutorials (including [http://java.sun.com/javaee/5/docs/tutorial/doc| Sun's Java EE 5 Tutorial]) mention is that the expression syntax does not escape HTML characters. Therefore, any web application using JSP Expressions to output unsanitized, user-entered data will be vulnerable to Cross Site Scripting (XSS) attacks.

==Avoidance and mitigation ==
The safest cure for this XSS vulnerability leads one right back to the first example. As section 2.2.2 of the JSP 2.0 Specification reads, “In cases where escaping is desired (for example, to help prevent cross-site scripting attacks), the JSTL core tag c:out can be used.”

To be sure your code is not vulnerable to the potential XSS vulnerability described herein, use JSP Expressions only as tag library attribute values and stick to using JSTL‘s c:out tag for writing text to a page. Deciding which instances of template text expression usage are safe and which are not is error prone and the consequences of a mistake is dangerous.

==Examples ==
See [[#Discussion]] above.

==Related problems ==

{{Template:Vulnerability}}
{{Template:Stub}}
[[Category:Vulnerability]]
[[Category:Implementation]]
[[Category:Java]]
[[Category:Use of Dangerous API]]

@@ Line 1: / Line 1: @@
 {{template:CandidateForDeletion}}
@@ Line 80: / Line 79: @@
 ==Related [[Controls]]==
-The safest cure for this XSS vulnerability leads one right back to the first example. As section 2.2.2 of the JSP 2.0 Specification reads, âIn cases where escaping is desired (for example, to help prevent cross-site scripting attacks), the JSTL core tag c:out can be used.â
+The safest cure for this XSS vulnerability leads one right back to the first example. As section 2.2.2 of the JSP 2.0 Specification reads, “In cases where escaping is desired (for example, to help prevent cross-site scripting attacks), the JSTL core tag c:out can be used.”
-To be sure your code is not vulnerable to the potential XSS vulnerability described herein, use JSP Expressions only as tag library attribute values and stick to using JSTLâs c:out tag for writing text to a page. Deciding which instances of template text expression usage are safe and which are not is error prone and the consequences of a mistake are grave.
+To be sure your code is not vulnerable to the potential XSS vulnerability described herein, use JSP Expressions only as tag library attribute values and stick to using JSTL‘s c:out tag for writing text to a page. Deciding which instances of template text expression usage are safe and which are not is error prone and the consequences of a mistake are grave.
 ==Related [[Technical Impacts]]==

@@ Line 1: / Line 1: @@
 {{template:CandidateForDeletion}}
@@ Line 79: / Line 80: @@
 ==Related [[Controls]]==
-The safest cure for this XSS vulnerability leads one right back to the first example. As section 2.2.2 of the JSP 2.0 Specification reads, “In cases where escaping is desired (for example, to help prevent cross-site scripting attacks), the JSTL core tag c:out can be used.”
+The safest cure for this XSS vulnerability leads one right back to the first example. As section 2.2.2 of the JSP 2.0 Specification reads, âIn cases where escaping is desired (for example, to help prevent cross-site scripting attacks), the JSTL core tag c:out can be used.â
-To be sure your code is not vulnerable to the potential XSS vulnerability described herein, use JSP Expressions only as tag library attribute values and stick to using JSTL‘s c:out tag for writing text to a page. Deciding which instances of template text expression usage are safe and which are not is error prone and the consequences of a mistake are grave.
+To be sure your code is not vulnerable to the potential XSS vulnerability described herein, use JSP Expressions only as tag library attribute values and stick to using JSTLâs c:out tag for writing text to a page. Deciding which instances of template text expression usage are safe and which are not is error prone and the consequences of a mistake are grave.
 ==Related [[Technical Impacts]]==

← Older revision		Revision as of 23:37, 7 April 2009
Line 3:		Line 3:
	#REDIRECT [[Failure to follow guideline/specification]]		#REDIRECT [[Failure to follow guideline/specification]]

−
−	~~[[ASDR Table of Contents]]~~

	Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''		Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

← Older revision		Revision as of 14:02, 17 February 2009
Line 1:		Line 1:
		+	{{template:CandidateForDeletion}}
		+
		+	#REDIRECT [[Failure to follow guideline/specification]]

−	~~__TOC__~~

	[[ASDR Table of Contents]]		[[ASDR Table of Contents]]

@@ Line 1: / Line 1: @@
 __TOC__
@@ Line 8: / Line 6: @@
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==
@@ Line 100: / Line 95: @@
 * http://www.link1.com
 * [http://www.link2.com Title for the link2]

@@ Line 2: / Line 2: @@
 {{Template:Stub}}
-[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
+__TOC__
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 [[Category:FIXME|Stub article, needs review]]
 ==Description==
@@ Line 81: / Line 80: @@
 * [[Vulnerability 1]]
 * [[Vulnerabiltiy 2]]

@@ Line 1: / Line 1: @@
-==Overview==
+{{Template:Vulnerability}}
 JSP 2.0 introduced a new capability allowing one to use JSP Expressions directly within the template text (i.e. outside of tag libraries or tag files) of a web page. However, improper use of the expressions will leave an application open to [[XSS Attacks]].
-==Consequences ==
+'''Consequences'''
 * Failing to use JSP Expressions properly will leave an application open to [[XSS Attacks]].
-==Exposure period ==
+'''Exposure period'''
 This vulnerability has existed since servlet containers and application servers began implementing the [[http://jcp.org/en/jsr/detail?id=152| JSP 2.0 standard]]
-==Platform ==
+'''Platform'''
 * Languages: Java/JSP
-==Required resources ==
+'''Severity'''
-==Likelihood of exploit ==
+==Examples==
 JSP 2.0 expressions allow developers to expose data and objects stored in application, session, request, or page scope using an Ant-style syntax. It allows you to replace this
@@ Line 51: / Line 70: @@
 As you can see, the syntax in the second example is more succinct. However, it may also expose a Cross Site Scripting [[XSS Attacks| XSS]] vulnerability. The problem that few tutorials (including [http://java.sun.com/javaee/5/docs/tutorial/doc| Sun's Java EE 5 Tutorial]) mention is that the expression syntax does not escape HTML characters. Therefore, any web application using JSP Expressions to output unsanitized, user-entered data will be vulnerable to Cross Site Scripting (XSS) attacks.
-==Avoidance and mitigation ==
 The safest cure for this XSS vulnerability leads one right back to the first example. As section 2.2.2 of the JSP 2.0 Specification reads, “In cases where escaping is desired (for example, to help prevent cross-site scripting attacks), the JSTL core tag c:out can be used.”
 To be sure your code is not vulnerable to the potential XSS vulnerability described herein, use JSP Expressions only as tag library attribute values and stick to using JSTL‘s c:out tag for writing text to a page. Deciding which instances of template text expression usage are safe and which are not is error prone and the consequences of a mistake are grave.
-==Examples ==
+==Related [[Technical Impacts]]==
-See [[#Discussion]] above.
-==Related problems ==
+Encoding Vulnerability
-{{Template:Vulnerability}}
+Input Validation Vulnerability
-{{Template:Stub}}
 [[Category:Vulnerability]]
 [[Category:Implementation]]
 [[Category:Java]]
 [[Category:Use of Dangerous API]]