I had web site I launched it on server and it worked well internal but when it being online this error appear in registration form
<error>
Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%# Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.
That error is being displayed because you've entered something in the form that isn't deemed as safe by the validator. This is used in order to stop injection attacks, such as typing malicious javascript in the form.
If you type in the same things locally and "online" and still get that error, check to see if you have it turned off locally and turned on in your production environment.
It is recommended however to have enableEventValidation="true" since it gives you a lot of security for free.
Related
Asp.Net MVC application
When user tries to submit HTML or JavaScript code in query string of action method , getting Internal server error(500) with below exception..
A potentially dangerous Request.QueryString value was detected from the client (userid="'"-->..script..").
I have enabled the custom error mode so that end user is redirecting the custom error page for any XSS attacks.
But when I run NETSPARKER ENTERPRISE SCAN against action method with javascript code in query string , report coming as Internal server error - The server responded with an HTTP status 500.
What is the best practice to handle this internal server issue.
Suggestion: Custom Error handler
I am not sure about best practice, but what I use is <customErrors> in the web.config to redirect the user to a "nice" web page. The page it redirects to can be a plain HTML, ASPX etc. The nice thing is that you can setup a default custom error page, plus individual ones based on HTTP Status Code.
Follows is a snippet from my web.config for a default error code handler, plus one for HTTP 500 (Internal Server Error) which is what you are getting for the A potentially dangerous Request.QueryString value was detected error:
<customErrors mode="On" redirectMode="ResponseRedirect" defaultRedirect="~/dangitall.html">
<error statusCode="500" redirect="~/dangitall500.html" />
</customErrors>
dangitall.html is a standard HTML page for all error. Its overridden by dangitall500.html which will display for HTTP 500 errors. The contents of these HTML pages can be whatever you want: warn the user, abuse the user etc :)
Follows is a link to the Microsoft tech article regarding custom errors and all of the possible attribute settings etc:
https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.customerror?view=netframework-4.8
So I am implementing a payment system with 2co on my website. I am using their 'Header Redirect' which returns the customer to an ASPX page on my website with a bunch of querystrings after a successful payment.
Anyway, I was wondering. What is the proper way to secure this? What If a customer typed the parameters him/herself such as `Payment.aspx?params-here' and added credits as they wish to their account.
How can I make sure that this is 100% authentic?
Suggestions? Thanks!
A solution approach to parameter tampering is usually mapping the query parameters to something that cannot be easily manipulated, e.g. by using a one-way hash function to create a digest to send along with the original parameter and limiting the duration during which a particular mapping/digest is valid. If the digest matches the query parameter you know the request has not been tampered with.
E.g. your URL
Payment.aspx?Amount=100
could become
Payment.aspx?Amount=100&Digest=53e5e07397f7f01c2b276af813901c2
Here's an old but still relevant, detailed article on the topic: Passing Tamper-Proof QueryString Parameters
In ASP.NET you can use Page.EnableEventValidation which uses a hidden textbox as part of a form to validate that a request was issued from the form:
When the EnableEventValidation property is set to true, ASP.NET
validates that a control event originated from the user interface that
was rendered by that control. A control registers its events during
rendering and then validates the events during postback or callback
handling. For example, if a list control includes options numbered 1,
2, or 3 when the page is rendered, and if a postback request is
received specifying option number 4, ASP.NET raises an exception. All
event-driven controls in ASP.NET use this feature by default.
When I try and run a forum page:
System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client
In my web.config I have:
<pages validateRequest="false" smartNavigation="false">
And on the actual page I also have:
<%# Page Language="C#" AutoEventWireup="true" ValidateRequest="false" MasterPageFile="~/MasterPages/Main.master" %>
But it keeps throwing this error!
Edit
I fixed it with:
<httpRuntime requestValidationMode="2.0" />
But what's that do and why does it work?
This error occurs because something in the submitted form, or in the querystring, looked dangerous to the validation in ASP.NET.
By adding
<httpRuntime requestValidationMode="2.0" />
you are relaxing the validation that is applied back to the standards of ASP.NET 2.
I would say you are far better off trying to work out exactly what it objects to in your form/querystring than just relaxing the validation. This tightened validation is there to protect you and your users, and shouldn't be relaxed lightly.
I have recently hit this on a project I am working on when we upgraded to ASP.NET MVC3 (from version 2). In our case it actually highlighted an issue whereby we were urlencoding our querystring when we didn't mean to (i.e. the entire quertstring including the question mark and the ampersands was all getting url encoded when it shouldn't be).
Whatever your reason, look for the root cause rather than relax the validation if it is at all possible.
There was probably markup in the submitted text. http://www.asp.net/learn/whitepapers/aspnet4/breaking-changes
The request validation feature in
ASP.NET provides a certain level of
default protection against cross-site
scripting (XSS) attacks. In previous
versions of ASP.NET, request
validation was enabled by default.
However, it applied only to ASP.NET
pages (.aspx files and their class
files) and only when those pages were
executing.
In ASP.NET 4, by default, request
validation is enabled for all
requests, because it is enabled before
the BeginRequest phase of an HTTP
request. As a result, request
validation applies to requests for all
ASP.NET resources, not just .aspx page
requests. This includes requests such
as Web service calls and custom HTTP
handlers. Request validation is also
active when custom HTTP modules are
reading the contents of an HTTP
request.
As a result, request validation errors
might now occur for requests that
previously did not trigger errors. To
revert to the behavior of the ASP.NET
2.0 request validation feature, add the following setting in the
Web.config file:
<httpRuntime requestValidationMode="2.0" />
I have written a custom error page that displays an error message. Its an aspx page (and it needs to be).
The problem is that I tested the custom errors with a disabled database and the page just won't load. This is due (I think) to the fact that I have httphandlers and global.asax code trying to access the database so the app can never get to the error.aspx page if the db is down.
Anybody know how to disable all httphandlers and global.asax events from a page within an app?
Why don't you handle your error in Global_Asax and redirect the user to Error.aspx from Application_Error with a proper error message?
I get the following exceptions every couple of days:
System.Web.HttpException (0x80004005): Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. ---> System.Web.UI.ViewStateException: Invalid viewstate.
The thing is that I have a machine key set, and I also use only a single server (ie no cluster). So why is this exception happening? The only thing I can think of is that I keep reseting the IIS server, but I can't quite work out why that's a problem. Do you guys see this exception on a regular basis?
For reference, the following exists under my 'system.web':
<machineKey validationKey="Blah1" decryptionKey="Blah2" validation="SHA1" decryption="AES" />
To elaborate a little on Brian's point, the reason pages which are 'pretty large' experience problems is that those pages are sometimes rendered so slowly that you press the 'submit' button before the ViewState has finished downloading, which causes it to appear corrupted and generates the error.
The only solutions to this are:
disable viewstate completely
use a script to only enable submit after the page is fully loaded
make sure ViewState is as near the top of the page as possible (which I think is bad for SEO if your site is public).
You could try and prove this were the case by seeing if there were any correlation between the speed pages were being loaded and the timing of the exception. Using a tool like LogParser could help with this.