i create a web form with JSP, and for preventing attacks I do the following:
input.replace("<", "something else");
input.replace(">", "something else");
so a user cannot add HTML or other tags inside a form.
Is this enough to prevent attacks of this kind(Insertions of HTML or other tags inside
my website)??
Thanks you
JH. G.
In short, no. I recommend that you should checkout the ESAPI project for this. They have built in tools to HTML encode requests and responses as to prevent XSS attacks.
This is not entirely the right way. It's not only incomplete as ', " and & also needs to be escaped, but you should actually be using JSTL <c:out> or fn:escapeXml() to escape HTML/XML entities in the view side.
E.g.
<c:out value="${bean.value}" />
<input type="text" name="foo" value="${fn:escapeXml(param.foo)}" />
See also:
XSS prevention in JSP/Servlet web application
Related
How to prevent browser from remembering the password fields ... especially FireFox ( using jsf 2.0.9 ) I tried autocomplete= "off" ,still not working , Is there any possibility for this without migrating to jsf 2.2 ? Am using "h:inputSecret"
The autocomplete attribute is ignored and therefore not rendered in the output html. I had a similar problem, i wanted to use placeholder attribute. I ended up using jquery to accommodate the need
<script type="text/javascript">
jQuery(document).ready(function() {
document.getElementById("entityForm:searchField").setAttribute('placeholder','Search');
});
</script>
You can use this to set the autocomplete attribute
document.getElementById("passwordField").setAttribute('autocomplete','off');
You will never find a way to achieve this, cause the autocomplete in this case is happening on the client-side.
You can make it a little more difficult, but at the end of a day it's the users browser which decideds whether to store a password or not. If a user wants to store the password, he can always do it. (A Lot of Browsers are simply ignoring things like autocomplete="false", because its a user decision, nothing the website should decide.)
Hi all thanks fr yur solutions , Fixed the issue , just made some work around so that code is compatable with both Firefox and Chrome ,
Use "p:inputText"(Primefaces Component) instead of "h:inputSecret"
Code :
p:inputText onfocus="validate('Id')"
use javascript to change type to "password" upon focus :
function validate(Id){
document.getElementById(pwd).type = 'password'};
then comes the important workaround,adding tags before and after
<input type="text" name="faketext" id="faketext" style="display:none;"/>
<input type="password" value=" " name="fakepassword" id="fakepassword" style="display:none;" />
<!-- - After <p:inputText> -->
<input type="password" value=" " name="fakepassword1" id="fakepassword1" style="display:none;"/>
Thus issue Resolved.
We're using the StripFilter property in our production systems:
com.liferay.portal.servlet.filters.strip.StripFilter=true
but on the most pages the markup isn't properly stripped (some parts like navigation has massive whitespaces, others like head are fine) or worst case the whole markup is not stripped!
Those non stripped pages have up to 20k lines of source code (mostly blank), which causes poor performance in browsers.
Mostly appears when pages requested as guest user, but this is not reproducible.
Also when we undeploy all webapps, this problem occurs.
How we can investigate this problem?
Is this a common issue?
If some part of the beginning of your page is actually stripped and the rest is not, then the filter tripped over your html. Maybe you have an error in your html code. Or the strip was simply too stupid.
Remember that you must (because of the filter) close input tags with a /> If you do not, the filter looks up the next /> and does not strip anything between!
Example
<input name="bla">
<p> hello world,
<br />
<span> you are </span>
beautiful. </p>
This will lead to the following output, because the closes the
<input name="bla">
<p> hello world,
<br /><span>you are</span> beautiful. </p>
I have been using display.none, for the hid-whens for example, all the hidden fields were kept in a section and section was hidden from web by using Display.none.
This is working for Internet Explorer till IE 9, but for IE 10 all the hidden fields are shown.
Can anyone help in this matter. Any alternative or approach.
Without seeing the page it sis very difficult to guess.
Try validating the html through one of the many online html validators as something may not be closed or Notes might have given you an unwanted code addition .
Try adding a background color to the css #wrapper to make sure the css is being called.
Take a copy of the form and start removing all other elements one section at a time to see if something else is causing the issue.
Add {meta http-equiv="X-UA-Compatible" content="IE=10;IE=9; IE=8; IE=7; IE=EDGE" /} as the very top meta tag and see if that fixes it. Replace the curly braces obviously.
All the best in finding the issue.
It sounds like just the section element is getting hidden. Without seeing the code I can't tell why that changes between ie 9 and 10 but ie is famous for having varying behavior between versions.
One alternative that comes to mind: You could wrap the section and the fields in a DIV element using pass thru HTML and set that div's style to display:none. That is pretty standard and should work across browsers.
Update: To give you an idea what I'm talking about, check out this jsfiddle.
HTML:
<form>
<div class="wrapper">
<input type="text" name="Field 1" /><br />
<input type="text" name="Field 2" /><br />
<input type="text" name="Field 3" />
</div>
<span>Some text that won't be hidden.</span>
</form>
CSS:
.wrapper {
#display:none;
}
You can remove the # next to the display:none and see the difference, even in IE 10.
You'll need to look closely at the HTML being rendered by Domino and make sure that in fact all the fields you are trying to hide are surrounded by the DIV that is hidden.
What is the simplest way to replace quote characters with \" sequence inside string values?
That'll be the fn:replace() function.
<%#taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>
...
${fn:replace(foo, '"', '\\"')}
Unrelated to the concrete question, this is an often recurring requirement in order to prevent malformed HTML when redisplaying user controlled input as a HTML attribute. Normally, you should use <c:out> or fn:escapeXml() for this instead. E.g.
<input name="foo" value="<c:out value="${param.foo}" />" />
<input name="foo" value="${fn:escapeXml(param.foo)}" />
It not only takes quotes into account, but also all other XML special characters like <, >, &, etc.
See also:
XSS prevention in JSP/Servlet web application
Use javascript replace (with /g to replace all occurrences)
string.replace(/"/g, '\\"')
In my ASP.NET 1.1 application, I am compressing and replacing the hidden Viewstate variable with an alternate compressed value, stored in a hidden field called __VSTATE. This works well but on a few occasions, submitting a page causes the common "potentially dangerous Request.Form value ..." error.
I examined the __VSTATE value and nothing seems to be potentially dangerous. I was able to reproduce the error with a completely stripped down version of the page and __VSTATE value as shown below. Pressing the submit button causes the error. The page works fine if I change the value to "".
<%# Page Language="vb" AutoEventWireup="false" Codebehind="Dangerous.aspx.vb" Inherits="Dynalabs.Dangerous" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<body MS_POSITIONING="FlowLayout">
<form id="Form1" method="post" runat="server">
<input type="hidden" id="__VSTATE" runat="server" value="Onw=" />
<asp:Button ID="btnSubmit" Runat="server" Text="Submit" />
</form>
</body>
</html>
Changing the field name to "MyHiddenWT" made no difference. Removing the runat="server" did stop the error but that just means that .NET only examines server side controls. I also tried some additional values and found that of the following:
"Anw=", "Bnw=", "Cnw=", ... "Nnw=", "Onw=", "Pnw=", ... "Znw=",
"Onw=" is the only one that causes the problem. Is the captial O being seen as an octal value somehow?
Can someone explain why this value is triggering the error message? I'm also looking for a solution but, please, do not tell me to remove page validation. That's the same as saying a car with bad brakes can be fixed by not driving the car.
Thank you in advance.
My first guess is that it looks like a "OnSomething=" javascript event declaration.
It's a little weird that only the capital O triggers the error, did you test on the lowercase o as well?
Can you try these: "OnClick=", "abc OnClick=", "onclick=", "abc onclick=", "anw=", "bnw=", ...
If "OnSomething=x" javascript is a problem, then simply adding another character to your values should do the trick. Maybe a simple 'v' should do.
<input type="hidden" id="__VSTATE" runat="server" value="vOnw=" />
And then on submit, you remove the extra character before decoding.
Or better yet, upgrade to 2.0.
You've got the essence of the reason. Here's the best link in a response I got from another site:
http://groups.google.com/group/microsoft.public.dotnet.framework.aspnet.security/browse_thread/thread/d91d89511401e979