Dangerous request???

  • Thread starter Thread starter John
  • Start date Start date
J

John

I've beed trying to add the following MD5 hash to my webform as a hidden
field, but it comes up as a security error:

< input type="hidden" name="tester" value="Omoo/W0Yr6nBOGq9oNfvpw==" / >

Any ideas why? the '==' seems to be the issue.

John
 
try setting validateRequest to false in machine.config

-- bruce (sqlwork.com)


| I've beed trying to add the following MD5 hash to my webform as a hidden
| field, but it comes up as a security error:
|
| < input type="hidden" name="tester" value="Omoo/W0Yr6nBOGq9oNfvpw==" / >
|
| Any ideas why? the '==' seems to be the issue.
|
| John
|
|
 
Thanks Bruce (and Peter),

Yep it was a server side error, thrown by HttpRequest.ValidateInput I
guess.

I'm more interested in *why* the hidden field was considered
dangerous!! It was just an MD5 hash converted to base64.

Using Server.HtmlEncode made no difference.

As a work-around I did

s = s.Replace('/','-').Replace('=','.');

Was ValidateInput assuming '==' was javascript??? Seems like a bug if
so.

John
 
John said:
I've beed trying to add the following MD5 hash to my webform as a hidden
field, but it comes up as a security error:

< input type="hidden" name="tester" value="Omoo/W0Yr6nBOGq9oNfvpw==" / >

Any ideas why? the '==' seems to be the issue.

John
This bit from SDK explains the security issue.

ValidateRequest
Indicates whether request validation should occur. If true, request
validation checks all input data against a hard-coded list of potentially
dangerous values. If a match occurs, an HttpRequestValidationException Class
is thrown. The default is true.
This feature is enabled in the machine configuration file (Machine.config).
You can disable it in your application configuration file (Web.config) or on
the page by setting this attribute to false.

Note This functionality helps reduce the risk of cross-site scripting
attacks for straightforward pages and ASP.NET applications. An application
that does not properly validate user input can suffer from many types of
malformed input attacks, including cross-site scripting and SQL Server
injection attacks. There is no substitute for carefully evaluating all forms
of input in an application and making sure that they are either properly
validated or encoded, or that the application is escaped prior to
manipulating data or sending information back to the client. For more
information about cross-site scripting, see
http://www.cert.org/advisories/CA-2000-02.html.
 
The server does not know that something is hidden or not. Also, just
because a field is hidden in HTML, does not mean that someone could not
create a clone of the page where they could spoof the field value. The
server just protects against any form fields because the server has no way
of knowing where the data came from.
 
Ok, but shouldn't HtmlEncode() fix this??

I would expect any potentially dangerous content, when htmlencoded, to be
rendered harmless.

John
 
Back
Top