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
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 written some code from what I can gather from online sources to submit some text from a form into a text file, now I do not know what I am missing but nothing is coming through to the text file, I am guessing it might be something to do with maybe folder paths but I am not sure, just looking for some direction on this.
My ASP Form Code is:
<form method="get" action="simpleform.asp">
<br/>
<i>Please include your initials and date with the bug report</i>
<br/>
<br/>
<b>Bug</b> <input type="text" name="bug">
<input type="submit" value="Submit Bug Report">
</form>
<br/>
ASP Code to comit the text to the file is this:
<html>
<body>
Thanks for the report! To report another bug click here.
<%
Dim idea
dim fs,f
set fs=Server.CreateObject("Scripting.FileSystemObject")
set f=fs.OpenTextFile("G:\General\EM_Wiki\WikiBug\bugreport.txt",8,true)
idea= Request.QueryString("bug")
f.WriteLine(bug)
f.Close
set f=nothing
set fs=nothing
%>
</body>
</html>
Hope that makes sense to someone and that you can point me in the right direction, thanks!
You aren't writing the correct variable to the file.
f.WriteLine(bug) should be f.WriteLine(idea)
If you turn on "Option Explicit", it is easier to diagnose these kinds of problems. Here's the page that shows you how to do this: http://msdn.microsoft.com/en-us/library/ms524870(v=vs.90).aspx
your actual content is in variable idea, not in bug. bug is just an index of query string. Also you may need to flush your stream.
Use the flush method before closing file , e f.flush()
f.WriteLine(idea)
//your more writing
f.flush()
f.Close
here's the msdn link
http://msdn.microsoft.com/en-us/library/system.io.streamwriter.flush.aspx
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.
I have some weirdness occurring while trying to switch from webrat to capybara. The error is this:
And I press "Create floob"
# features/step_definitions/web_steps.rb:27
no button with value or id or text 'Create floob' found (Capybara::ElementNotFound)
The html in my app looks like this:
<fieldset class="buttons">
<ol>
<input id="floob_submit" name="commit" type="submit" value="Create floob" />
</ol>
</fieldset>
I would have thought that capybara would look at the value of the buttons on the page, and reading the documentation this does seem to be the case, but it's not working! If I change the line in my cuke file to And I press "floob_submit" everything works, but I'd rather not change all my features...
Does anyone have any thoughts on why this might be happening and if there's a fix? Thanks friends!
The only thing I can see is that you aren't wrapping your input in an <li></li>. This might be confusing enough for the DOM to cause your problem.