?
Solved

Hidden Input Field causes potentially dangerous Request.Form value error

Posted on 2008-11-07
5
Medium Priority
?
1,087 Views
Last Modified: 2012-05-05
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 as shown in the code snippet. Pressing the submit button causes the error. The page works fine if I change the value to "".

Can someone explain why this is happening and suggest a solution? I do not want to remove page validation. During my testing, I tried using HTMLEncode but that doesn't change the test value in the snippet and still generates an error.
<%@ 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>

Open in new window

0
Comment
Question by:ZekeLA
  • 3
  • 2
5 Comments
 
LVL 5

Expert Comment

by:varungd
ID: 22911400
Add ValidateRequest="false" in the page directive like
 <%@ Page Theme="SkyHigh" Language="C#" AutoEventWireup="true" CodeBehind="Test.aspx.cs" Inherits="Log.Test" ValidateRequest="false"  %>

Open in new window

0
 
LVL 5

Expert Comment

by:varungd
ID: 22911404
<%@ Page Language="vb" AutoEventWireup="false" Codebehind="Dangerous.aspx.vb" Inherits="Dynalabs.Dangerous" ValidateRequest="false" %>
0
 
LVL 1

Author Comment

by:ZekeLA
ID: 22912059
I appreciate the responses but that doesn't really address the problem for two reasons:

1) Removing the request validation means users could enter truly dangerous requests (such as scripts and tags) which I would have to trap throughout the entire application and hope I did as good a job as .NET has already has built in.

2) This isn't a case where I want to allow the user to enter formatted text and I need to allow html tags. My input value is just "Onw=" which has no dangerous values as far as I can determine. From my viewpoint, this shouldn't be any worse than if the value was "abcd".

My only thought at the moment is that .NET is concerned about the variable itself somehow because I named it with a double underscore or because I duplicated some internal name. I'll try to test that but I'm still looking for a solution.

Thank you.
0
 
LVL 1

Author Comment

by:ZekeLA
ID: 22916939
Changing the field's name makes no difference. I tried id="MyHiddenWT" and still got the error. Removing the runat="server" does prevent 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?
0
 
LVL 1

Accepted Solution

by:
ZekeLA earned 0 total points
ID: 22917765
Per another site, the reason is cross site scripting: http://groups.google.com/group/microsoft.public.dotnet.framework.aspnet.security/browse_thread/thread/d91d89511401e979

It's being evaluated as a potential "onSomeEvent = doSomething()" script. Per Mike Kozlowski (http://www.klio.org/mlk/), for easy reference for some future person looking at this thread because they're having the same problem, the XSS validator blocks any string matching (in effect) the following regexes:

script\s*=
[^a-zA-Z]on[a-zA-Z]*\s*=
expression
&#
<[a-zA-Z!]

The last two are impossible with Base64 encoding (which only allows letters, digits, +, /, and =), the first two are impossible if you just do UrlEncode twice in a row (to prevent equal signs from occuring), and the third is vanishingly unlikely in random characters, but if you're concerned about it, you can just replace all "x" characters with "," after the Base64 encoding.
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The object model of .Net can be overwhelming at times – so overwhelming that quite trivial tasks often take hours of research. In this case, the task at hand was to populate the datagrid from SQL Server database in Visual Studio 2008 Windows applica…
Today I had a very interesting conundrum that had to get solved quickly. Needless to say, it wasn't resolved quickly because when we needed it we were very rushed, but as soon as the conference call was over and I took a step back I saw the correct …
Exchange organizations may use the Journaling Agent of the Transport Service to archive messages going through Exchange. However, if the Transport Service is integrated with some email content management application (such as an anti-spam), the admin…
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…
Suggested Courses

864 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question