JSP JSTL

Status
Finished 3/11/08 - in need of review.

Brief Overview of JSP Architecture
JSPs are delivered to a container that provides services like life-cycle management and runtime support. A JSP gets translated to a servlet class which is instantiated at runtime. A request headed for a particular JSP will be directed by the container to its corresponding servlet class (aka jsp implementation object). It then handles requests and generates responses. The default request response objects are HttpServletRequest and HttpServletResponse. JSP makes use of implicit objects that can be considered taint sources, sinks and propagators. I won't discuss further details since that is outside the scope of this project. For further information try this reference guide.

JSP In Light of Security
There’s not much to say here except that JSPs can act as both a model and view. It can operate fairly well without a distinct service or business layer because it doesn’t quite enforce separation of logic and concerns (hence the advent of development frameworks).

I won’t discuss details of web app design here, but one should understand that lack of separation can have negative effects on web-app stability and security. But even so, lack of input validation can lead to easy security vulns in JSP, namely XSS.

Commonly, JavaBeans are used in conjunction with JSP to store parameters and implement business logic. Most of my examples will use beans to demonstrate taint propagation and proper cleansing.

For more data on design with JSP and servlets, see this best practices article

Propagators
  <%=user.getStrParam%>
 * Makes a Java Bean available to the rest of the page by instantiating the object and binding it to a variable.
 * Once you have that you can modify and access it using the jsp setProperty and getProperty tags.
 * You can also call methods on it in scriptlets.

 Different ways to set bean properties with request parameters and supplied values <%--set all bean properties with matching request parameters--%> 
 * Sets one or more bean property values in a bean defined by .

<%--set one property with matching request parameter--%> 

<%--set one property with supplied value--%> 

Sinks

 * Gets a value from a bean object and writes to the page.

 Displays contents of another page within current. Only a problem if included page contains xss.

Example: Using standard actions to produce xss.
Set the bean properties with request parameters on one page.   Later on another page...  

JSP Implicit Objects
There are a handful of objects made available in JSPs which are susceptible to security flaws. Their corresponding java class functions are used as is in scriptlets. All the same security rules should apply. Examples: saveinfo.jsp <%    String name = request.getParameter("username"); session.setAttribute("taintedAttribute", name); %> displayinfo.jsp my xss varible: <%=session.getAttribute(name)%>

Unified EL
Unified EL is a feature of JSP 2.1 it is a union of JSP 2.0 and JSF expression languages. Expressions enclosed in ${…} are immediately evaluated and printed to the page. Expressions consist of EL implicit objects and bean names defined with jsp:usebean. All EL implicit objects are propagators that can be sunk for XSS as an expression.
 * param
 * paramValues
 * header
 * headerValues
 * cookie?

The examples for each implicit object demonstrates xss.

param Welcome ${param.userName}!
 * References a request parameter by name.
 * Equivalent to request.getParameter(“asdf”);

paramValues Using JSTL tags for this example.   =  <c:out value='${value}' escapeXml="false"/> </c:forEach> </c:forEach>
 * A String[] of parameter values.
 * Equivalent to request.getParameterValues.

header ${header.cookie}
 * Maps a request header name to a single value.
 * Equivalent to request.getHeader.

headerValues <c:forEach var="head" items="${headerValues}"> <c:out value="${head.key}" /> = <c:forEach var="val" items="${head.value}"> <c:out escapeXml="false" value="${val}" /> </c:forEach> </c:forEach>
 * A String[] array of header values.
 * The following example is the same as above.

cookie

Not sure if there's anything juicy here...

pageScope The following example uses the JSTL <c:set> tag so you know where the tainted variable comes from, I’ll cover c:set details in JSTL core section. <c:set var="PageScopeVar" value="${param.fwd_last}" scope="page"/> ${pageScope.PageScopeVar}
 * Maps page-scoped variable names to their values.

requestScope <c:set var="ReqScopeVar" value="${param.fwd_last}" scope="request"/> ${requestScope.ReqScopeVar}
 * Maps request-scoped variable names to their values.
 * Looks exactly the same as pageScope.

sessionScope <%session.setAttribute("sa_first", request.getParameter("first")); %> ${sessionScope.sa_first }
 * Maps session-scoped variable names to their values.
 * You can create a session variable with c:set as above OR you can use session.setAttribute.

applicationScope <c:set var="scopeVar" value="${param.addr}" scope="application"/> ${applicationScope.scopeVar }
 * Maps application-scoped variable names to their values.

See also [J2EE Bad Practices: JSP Expressions]

JSTL Tags

 * There are 5 tag libraries in JSTL: core, sql, fmt, xml.
 * This section will cover core and sql tags.

Sinks
<c:out> <c:out escapeXml="false" value="${param.first}"/> <c:redirect> Possibly susceptible to splitting? <c:redirect url="/include.jsp?lang=${param.first}"/>
 * Like <%= ... >, but for expressions.
 * Has a boolean attribute escapeXml that converts <,>,&,'," to their corresponding entities. Defaults to true so it's really not an issue unless explicitly set to be false.

Propagators
<c:url> A contrived example. <c:url var="url2" value="/account.jsp?lang=${param.username}"/> <a href='${url2}'>yes this is dumb</a>
 * Used to construct a string url.

<c:import> <c:import url="/include.jsp"/> <c:param> <c:url var="url1" value="/include.jsp?lang="> <c:param name="someParameter" value="${param.last}"/> </c:url> <a href='<c:out value="${url1}"/>'>Link back to some page (<c:out value="${url}"/>)</a> <c:set > <c:set var="appScopeVar" value="${param.addr}" scope="application"/> ${appScopeVar}
 * Imports the contents of a page, only a vuln if included page has a vuln. (only tested with xss)
 * Sets a variable to a value.
 * Can have page, application, request, or session scope.
 * Can be retrieved through use of scope objects or just by referencing the “var” in an expression.

Cleansers
<sql:param > Cleanser sort of? Works like prepared statements. <sql:query var="deejay"> SELECT * FROM mytable WHERE name= ? <sql:param value="<%=request.getParameter("taintme")%>"/> </sql:query>
 * Parameterized SQL statements – replace each ‘?’ with a parameter.

Cleansers
fn:escapeXml ${fn:escapeXml(taint) }
 * & < > “ ‘  &amp &lt &gt &#034 &#039

fn:replace ${fn:replace(taint,"<","HAH") }
 * Potential cleanser if used correctly
 * ${fn:replace(taint, "<", "&lt")} replaces all “<” with “&lt”