This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "J2EE Bad Practices: JSP Expressions"

From OWASP
Jump to: navigation, search
m
Line 1: Line 1:
==Overview==
+
{{Template:Vulnerability}}
 +
{{Template:Stub}}
 +
 
 +
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 +
 
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 
 +
[[ASDR Table of Contents]]
 +
__TOC__
 +
 
 +
 
 +
==Description==
 +
 
 
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]].
 
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]].
 
* 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]]
 
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
 
* 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.
 +
 
 +
 
 +
 
 +
==Risk Factors==
  
 +
TBD
  
==Severity ==
 
High
 
  
==Likelihood of exploit ==
+
==Examples==
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
 
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.
 
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 ==
+
 
 +
==Related [[Attacks]]==
 +
 
 +
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
Note: the contents of "Related Problems" sections should be placed here
 +
 
 +
 
 +
==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.
  
==Examples ==
+
==Related [[Technical Impacts]]==
See [[#Discussion]] above.
+
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:
 +
 
 +
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
 +
* http://www.link1.com
 +
* [http://www.link2.com Title for the link2]
 +
 
 +
[[Category:FIXME|add links
 +
 
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 
 +
Availability Vulnerability
 +
 
 +
Authorization Vulnerability
 +
 
 +
Authentication Vulnerability
 +
 
 +
Concurrency Vulnerability
 +
 
 +
Configuration Vulnerability
  
 +
Cryptographic Vulnerability
  
==Related problems ==
+
Encoding Vulnerability
  
 +
Error Handling Vulnerability
  
{{Template:Vulnerability}}
+
Input Validation Vulnerability
{{Template:Stub}}
+
 
 +
Logging and Auditing Vulnerability
 +
 
 +
Session Management Vulnerability]]
 +
 
 +
__NOTOC__
 +
 
 +
 
 +
[[Category:OWASP ASDR Project]]
 
[[Category:Vulnerability]]
 
[[Category:Vulnerability]]
 
[[Category:Implementation]]
 
[[Category:Implementation]]
 
[[Category:Java]]
 
[[Category:Java]]
 
[[Category:Use of Dangerous API]]
 
[[Category:Use of Dangerous API]]

Revision as of 17:13, 26 September 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.

Last revision (mm/dd/yy): 09/26/2008

Vulnerabilities Table of Contents

ASDR Table of Contents


Description

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 [JSP 2.0 standard]

Platform

  • Languages: Java/JSP

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.


Risk Factors

TBD


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

<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>

with this

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

As you can see, the syntax in the second example is more succinct. However, it may also expose a Cross Site Scripting XSS vulnerability. The problem that few tutorials (including 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.


Related Attacks


Related Vulnerabilities

Note: the contents of "Related Problems" sections should be placed here


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.”

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


References

Note: A reference to related CWE or CAPEC article should be added when exists. Eg: