java - ESAPI for XSS prevention not working -
i working on fixing cross site scripting issues in our code in jsps.
below original code
//scriplet code <% string userid = request.getparameter("sid"); ...%> and in same jsp have
<input type = hidden name = "userid" value = "<%= userid %>" /> i have made changes include esapi-2.1.0.jar in lib , esapi.properties, validation.properties in classpath. made below changes scriplet code fix above code
//scriplet code <% string userid = esapi.encoder().encodeforhtml(request.getparameter("sid")); ...%> i thought fix issue when scan code using fortify, these lines again highlighted having xss issue. please if guys have idea on how should handled. thanks.
------- update
thanks lot @avgvstvs. insightful.follwd guidelines, not sure if missng somethn. code -
string usersid=esapi.encoder().encodeforhtmlattribute(request.getheader("janus_sid")); session.setattribute("username",usersid);<input type=hidden name="username" value="<%= usersid %>" and varibale debug, below usage
string debugflag = esapi.encoder().encodeforjavascript(request.getparameter("debug"));var debugflag = "<%= debugflag%>";if(debugflag == "y"){ document.title= title + " (" + host + ")"; defaultapptitle = title + " (" + host + ")"; } latest fortify scan still lists them vulnerabilities :-(
the first question need ask should "what code interpreters handing value off to?"
preventing xss unfortunately isn't recipe-based task, , looks of it--your application using scriptlets, aside being bad java practice, makes more difficult static code-scanning tools fortify give accurate results. jsps compiled @ runtime, fortify scans source only. should note there should future tasks/stories filed refactor scriptlets jstl--you'll thank me later. can use esapi taglibs these use cases. fortify okay job of scanning pure java code, , taglibs give that.
esapi.encoder().encodeforhtml(userid)going protect xss in use case variable in question going placed between tags,<span><%= userid %></span>isn't case have.esapi.encoder().encodeforhtmlattribute(userid)want in particular, narrow use-case. because escaping rules different in html attributes data placed within tags. should fix immediate problem.if value going used exclusively javascript, want
esapi.encoder().encodeforjavascript(userid)if value going renderable html being sent javascript function render markup,
element.innerhtml = “<html> tags , markup”;want<%=encoder.encodeforjs(encoder.encodeforhtml(userid))%>
this few examples, here few more--but overriding gist of answer this: need know complete flow of data every variable in application , always encode appropriate output context. , in security world, "context" means "data being handed off new code interpreter." if implement understanding well, won't need fortify anymore! :-)
====added complexity====
in comment noted value later being used javascript. correct solution in case to fork 2 different variables, each 1 set proper encoding. html attribute case:
string escapedhtmluserid = esapi.encoder().encodeforhtmlattribute(userid);
for javascript case:
string escapedjsuserid = esapi.encoder().encodeforjavascript(userid);
then use values appropriately. if used jstl/taglibs, use right esapi taglib in right place instead of splitting 2 separate scriptlet variables.
===and 1 more thing===
from comment on op:
we have initial scriptlet declaration:
<% string userid = esapi.encoder().encodeforhtml(request.getparameter("sid")); ...%>
and used later in javascript function:
<%= esapi.encoder().encodeforjavascripl(userid)%>
just point out, presented, userid variable stops being raw text on initialization. effectively, encoding javascript becomes this:
<% esapi.encoder().encodeforjavascript(esapi.encoder().encodeforhtml(request.getparameter("sid"))); ...%> if javascript going rendering html using *.innerhtml() or *.outerhtml() fine. otherwise, note input has changed raw state.
also, watch fact javascript can undo you've done , ensure javascript isn't doing similar.
==========more added code, more questions========
so we've traced our data paths, we've double-checked our jsp in question isn't being included in different jsp introduces new contexts defend against, it's @ point i'd smell "false positive," if i'd contact hp support , raise issue false positive. don't know enough of specifics of application of more use here unless had access full source. because you're dealing scriptlets--its possible fortify can't trace full data path variable instantiation eventual output, failing fast can @ least warn found "so far."
Comments
Post a Comment