After running a security scan across our web application (WebInspect), it has reported several XSS vulnerabilities with some aspx pages.
The request URL seems to be able to change the form action.
Example,
/Website/somepage.aspx/'+alert(1234)+'
the form action is changed to
action="'+alert(1234)+'"
To rule out our application code, I tried this with the default new Visual Studio webform project and it allows the same.
How can this be prevented?
I've always been told that un-validated input being reflected into the page is bad news.
just put something in the action, something like this:
<form id="id_form" runat="server" action="Default.aspx">
When the action form is not specified asp fills this attribute with which you wrote in the URL next to the last slash. If you write something there asp doesn't rewrite this.
Please check your global.asax - Application_Start to see if any routes have been defined.
Related
I have a simple task but I don't know about this. When we run a page for the first time the extension will be hidden like Default.aspx run on the browser for the first time .aspx will hidden.
You can use the URL Rewrite IIS module to allow the URLs typed and seen by the user to be completely different form the URLs used by the application.
I have an MVC4 app, but I'm primarily using it for the WebAPI parts. I want to have a "plain old HTML" file sent back to the user (which will then use KnockoutJS or KendoUI to pull JSON from the webapi controllers).
I know I can do this:
routes.IgnoreRoute("{page}.html");
And then if I browse to "localhost/index.html" it does successfully just return my .html page.
However, I really want to map the "root" default path "localhost/" to return my index.html.
I tried this:
routes.MapPageRoute("root", "", "~/index.html");
but that throws the error:
There is no build provider registered for the extension '.html'. You can register one in the <compilation><buildProviders> section in machine.config or web.config. Make sure is has a BuildProviderAppliesToAttribute attribute which includes the value 'Web' or 'All'.
Anyone have any ideas on how I can make this work? I could just hit a default controller that returns a plain html page, but it seems like overkill to go through the entire ASP.NET stack once for the HTML page, which then just calls a WebAPI URL to go back through the ASP.NET stack to get some JSON data for the page's model.
I basically just want to "skip" all the MVC plumbing and have IIS send me back the html page, as if it wasn't an ASP.NET app, or at least do as little processing as possible.
Add the following to your routing config:
routes.IgnoreRoute("");
I am receiving an error that states: "The HTTP verb POST used to access path '[my path]' is not allowed.".
The error is being caused by the fact that I am implementing an HTML form element that uses the POST method and does not explicitly define an .aspx page in its ACTION parameter.
For example:
<form action="" method="post">
<input type="submit" />
</form>
The HTML above is on a file at "/foo/default.aspx".
Now, if the user points the URL to the root directory "foo" without specifying the aspx file (i.e. "http://localhost/foo") and then submits the form, the error "The HTTP verb POST used to access path '/foo' is not allowed." will be thrown.
However, if the user goes to "http://localhost/foo/default.aspx" and then submits the form, all goes well (even if the ACTION parameter is left empty).
Note: If I explicitly add the name of the .aspx (default.aspx) page to the ACTION parameter, no errors are thrown. So the example below works fine regardless if the user defines the name of the file in the URL or not.
<form action="default.aspx" method="post">
<input type="submit" />
</form>
I was curious as to why the error was being thrown, so I read a Microsoft KB that states
This problem occurs because a client
makes an HTTP request by sending the
POST method to a static HTML page.
Static HTML pages do not support the
POST method.
I suppose the core of the explanation makes sense, however in my case, my form is not being sent to a static html page - it's being sent to the same page that the html form lives on (default.aspx)... this is implicit to an ACTION param that is left empty.
Is it possible to configure IIS (or otherwise) that will allow us to do form POSTing and keep the ACTION param empty?
Check your default documents - without specifying the action, it might be stripping back to foo/. If you've got a default document (ie: Default.html, not Default.aspx) that is static it might cause this issue.
Try using "./" as your action.
It's been a year since initially experienced this error and thought I should add to this post that I am no longer receiving the error.
I don't know what fixed the problem, but my guess is that the error has gone away due to some Windows Update that has been implemented on my dev machine within the year.
One thing I noticed in the IIS 7 settings is that the "ISAPI.DLL" (in the "Handler Mappings" section) is disabled. I can't figure out how to "enable" it in order to try to reproduce the problem to show that the ISAPI.DLL is causing (or related) to the problem.
Anyway, the I am unable to reproduce this error that occurs when I leave the "action" attribute blank in an HTML Form tag. So, my guess is that there is an IIS and/or .NET Framework update that implicitly or explicitly fixes the error mentioned in the OP.
I had the same thing happen -- by having action = " " in the form tag. Don't know how it got in there. Sometimes when I edit a gridView it doesn't "sync" with the HTML. Maybe this is what happened. Weird. Took me a while to find, too!
The ASP.Net ISAPI DLL was plugged-in to translate all (*) URLs so had to follow these steps:
Click on the website
Choose Properties and on Virtual Directory tab click Configuration
Remove the ASP.Net ISAPI DLL (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll)
Restart IIS and try again.
I got this error when I was setting up a custom HTTP handler, not using forms.
You have to let IIS (or your WebDevServer in VisualStudio) know that you handling certain pages with your own handler. This is done by adding entries to the web.config file. I could type them out, but life is short and the sun is over the yard-arm, so here's a link - but scroll down to "Registering the Custom HTTP Handler in IIS ". Or read the whole thing, as it's all good, meaty tech-nuggets...
http://msdn.microsoft.com/en-us/library/ms227433%28v=vs.100%29.aspx
Hope that helps.
Add an index.htm with below re-direct lines
<html>
<head>
<meta http-equiv="Refresh" content="0; url=Default.aspx" />
</head>
</html>
I'm using the old 404-rewrite method on a certain site that is tied to IIS6 *.
So if I enter
http://example.com/non-existent/path
it calls my error page like so
http://example.com/catch.aspx?404;http://example.com/non-existent/path
Great.
Except if I call the page with a fragment, like
http://example.com/non-existent/path#with-fragment
I get the same result as above. I can't find the fragment anywhere:
Request.Url
Request.Url.OriginalString
Request.UrlReferrer
Request.RawUrl
headers, server variables, etc
This has come up because I want to resolve paths created by AJAX to their server-side versions.
Is there any way for me to retrieve the original path from my handler?
Thanks.
(*) Please don't suggest I change platform. Obviously I would if I could.
No, there isn't.
The portion of URL after # is never passed to the server per HTTP spec. Has nothing to do with platform.
To work with info after # in javascript you should look at Javascript History plugins/functionality. jQuery has history plugin, asp.net ajax and mvc ajax (partial views et al) have that. Mind you, it's not a very easy thing to implement, you have to get into undo/redo mindset.
It probably won't work if you are trying to handle 404's on the server - server doesn't know that there was something after #. Not sure what you want to do though, 404 handling, or "resolve paths created by AJAX"? What exactly is the goal?
I have a simple ASP.NET 3.5 SP1 Web Forms app... I've added the System.Web.Routing DLL, and I've made a simple route that returns a standard ASP.NET Page as the "IHttpHandler".
All is good... except that HttpContext.Current.User is null ???
So, I did a little more digging (I put breakpoints in all the events in the Global.asax file). Normally, these breakpoints get hit (when I navigate to a standard ".aspx" page):
Application_BeginRequest
Application_AuthenticateRequest
Application_EndRequest
But, when using ASP.NET Routing... none of those events are firing. Am I missing something?
Assuming you're using IIS6, the alternative is to define a "wild card" extension handler. Adding this simple "catch all" mapping to IIS6 will enable it to process your extensionless requests. By default, the .NET installer maps ".aspx" to the aspnet_isapi.dll- that's why the .aspx extension works. To map requests with no extension to the APS.NET engine, you must tell IIS to look at every request.
Here's a quick article that explains the process:
http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Hope that helps and reduces the "lame" factor of your URLs. :)
-Todd
Found the freakish and bizzare (and stupid) answer :)
If you don't add ".aspx" to the end of your route, nothing fires in the Global.asax, meaning you don't get any BeginRequest, AuthenticateRequest, EndRequest, etc... Also, you don't get SessionState or anything.
So, the "fix" was for me to just change my route from this:
RouteTable.Routes.Add("Blah", new Route("Blah/{reportName}", new MyHandler());
to this:
RouteTable.Routes.Add("Blah", new Route("Blah/{reportName}.aspx", new MyHandler());
How completely lame :) ... but it's a fix none-the-less!
When you say
"If you don't add ".aspx" to the end of your route, nothing fires in the Global.asax, meaning you don't get any BeginRequest, AuthenticateRequest, EndRequest, etc... Also, you don't get SessionState or anything."
Will IIS log such requests in the log files or they are just anonymous? what about Application variables and ViewState?
sorry i haven't tested it yet, but just asking if you might already know?
i have checked application variable and Viewstate, these two are obviously working.. not sure about server logs :S