Is it possible to rewrite URL on the fly, only when a part of the server code has already been processed for the "raw" URL and it becomes clear the parameters must not be revealed to the user? Like, I want to proccess all the GET parameters in my page code on the server and create a tracking record in the database, then serve the user the page but change URL to parameterless in the browser.
I guess all the web.config referred module techniques won't work as they offer URL rewriting before request is passed to the page code on the server. But it comes in my case that I receive an ugly URL from google adwords clicks and I do like it tracked 'as is' in my database, and I do certainly not like it show to user in her brower's bar.
At the same time I would like to keep URL unchanged without applying the URL rewrite most of the time unless some particular parameter shows up in it (like ref=adwords) so that any paramter written by hand or posted back would be displayed in the address bar.
Is it possible to do so by any means?
Have you considered writing an ActionFilter that would (if your controller or method is decorated with it) intersect your initial request, do all the necessary processiong and then redirect back to the requested page only indicating, that processing has been done?
This would be my first thought.
Related
We're reviewing some security findings and I'm trying to understand a finding about open redirects. Essentially the question is: Can a redirect to a hard-coded known-local path with user-supplied parameters in the query component be an open redirect?
Say you have the following in page1.aspx:
Response.Redirect("/page2.aspx?parm=" + Request["user-supplied-value"]);
Can page1.aspx, in and of itself, be an open redirect? Is there any value that can be supplied in the request to page1 that would cause a browser to ignore the "page2.aspx" path of the redirect and instead redirect to the user-supplied-value in the query part of the redirect url?
Please note, I am NOT referring to the situation where page2.aspx then takes the value of the parm and mindlessly redirects to it, that is an open redirect. I'm referring more to something like how a semicolon in a SQL Injection might terminate leading text and allow you to inject a new statement inline. I cannot think of a value for a parm in the query part that would essentially override the path part.
To be explicit, if you think the answer is "Yes, open redirects happen when you redirect to user-supplied inputs" go read the question again. I am not referring to the situation where page2 blindly redirects to the value supplied in the parameter. Rather can the redirect in page1 where the path component is hard-coded but has user-supplied parms be an open redirect?
It is not possible to make a modern browser go to a different page than page2.aspx just by manipulating the parameter. Therefore I wouldn't call this an open redirect, but it still might be a weakness, depending on what exactly page2.aspx does. It might become an actual open redirect as well in somewhat unexpected ways, like for example if there is header injection in page2.aspx and the attacker can inject a whole new Location header. Or this might be used to circumvent weak referrer-based csrf protection. Or it might just provide a way for an attacker to perform phishing by providing a link in a trusted application screen that does something the user didn't want to do.
So in short this might just be a building block in a more complex attack - but it might be an important one, or not even a weakness, it all depends on page2.aspx.
Asp.net, when it sees an unauthenticated request, typically send the request to the login page.
An example is below:
http://localhost:9001/?a=x&b=y&c=z
Request to the login page:
http://localhost:9001/Account/Login.aspx?ReturnUrl=%2f%3fa%3dx%26b%3dy%26c%3dz&a=x&b=y&c=z
Notice how Asp.net creates a new parameter ReturnUrl but still retains the original parameters while redirecting to the login page.
I have a situation where the initial url length is around 1000+ characters and after this redirection, it becomes 2000+ which is kind of going beyond some browser limits.
Is there a quick way (configuration/httpmodule etc) to prevent the automatic parameters forwarding to the login page? (I can manage the login page needing these parameters to be extracted from ReturnUrl.)
For anyone who is wondering about this issue, the issue happens even in a default asp.net application but I was able to implement a fix for it.
Following is the fix:
Implement an HttpModule; handle the EndRequest event and check for 302/unauthenticated request
We have to use Response.RedirectLocation for most steps below
Using HttpUtility.ParseQueryString, get collection of all parameters
Using HttpUtility.ParseQueryString, get collection of all parameters within ReturnUrl value
Except ReturnUrl, strip out all other parameters which exist in ReturnUrl value
Update Response.RedirectLocation with ReturnUrl and remaining parameters (none in most cases), Url encoding as necessary
This will ensure the Url now has only ReturnUrl and other parameters which aren't copied in ReturnUrl.
You need to ensure that the login page (Account/Login in above e.g.) does not use any of these parameters or if they do, you have code to pull those out from value of ReturnUrl.
Hope this solution helps anyone with similar situation.
In the current HTTP spec, the URL fragment (the part of the URL including and following the #) is not sent to the server in any way. However with the increased spread of AJAX, which uses the fragment to maintain some form of state, there are a lot of situations where it would be useful for the server to have knowledge of the URL fragment at request time.
For example, if you go to http://facebook.com, then click a user name in your stream, the URL will become http://faceboook.com/#!/username - to allow FB to update your page without reloading all of its bootstrap JS and HTML. However, if you were to reload this with your browser, the server would have no way of seeing the "#/!username" part of the URL, and therefore could not pre-render the content for you. This forces your browser to make an extra request once the client Javascript has loaded and parsed the fragment.
I am wondering if there have been any efforts or proposals towards creating a standard mechanism to achieve this.
For example, there could be a standard HTTP header, which would be sent with the value of the URL fragment - any server which cared about such things could then have access to it.
It seems like this would be a very useful thing for the web-application community as a whole, so I am surprised to not have heard anything proposed. Perhaps I missed it though.
Imho, the fragment identifier really is not a good place to store the state, it has been designed for something else.
That being said, http://www.jenitennison.com/blog/node/154 has a good discussion of the whole subject.
I found this proposal by Google to make Ajax pages crawlable, but it addresses a more constrained set of use cases. Specifically, it creates a way to replace the URL fragment with a URL parameter to obtain the same HTML output from the server as would be generated by a client visiting the equivalent URL with the fragment. However, such URLs are useless for actually running the Ajax apps, since they would necessitate a page reload every time.
Webkit Bug 24175 - URL Redirect Loses Fragment refers to Handling of fragment identifiers in redirected URLs which may be of interest.
A suggestion for a future version of HTTP may be to add an (optional)
Fragment header to the request, which holds the fragment identifier.
Even simpler may be to allow an HTTP request to contain a fragment
identifier.
is there a way from a asp.net-page code behind with "Request.Redirect()" or another method to redirect to the last page (like Javascript history back)?
You can check the Request.UrlReferrer property, which will be set if the user has navigated to the given page from another one. This is nothing more than the HTTP Referrer header that a browser will set. This will be null if the user navigates to your page directly.
HTTP is stateless, so theres no way of being able to read the browsers history (on the server) in the same way that Javascript can (its client side).
However there are a couple of tricks you can use:
Javascript could write the URL into a textbox which gets submitted to the server
The last URL visited could be stored in session - which can be retreived on a later visit
If using the URL in session method, you'll probably want to code this into a HTTP handler (not module) and this will fire automatically on every request.
Obviously these will only work if the user has previously visited a page, and not directly.
I'm replacing an old web application with a new one, with different structure.
I can not change the virtual directory path for the new app, as I have users which have bookmarked different links to the old app.
Lets say I have a user, who has this bookmark:
http://server/webapp/oldpage.aspx?data=somedata
My new app is going to reside in the same virtual directory, replacing the old one, but it has no longer oldpage.aspx, instead it has different layout, but it still needs the parameter from the old url.
So, I have set to redirect 404 errors to redirectfrombookmark.aspx, where I decide how to process the request.
The problem is, that the only parameter I receive is "aspxerrorpath=/webapp/oldpage.aspx", but not the "data" parameter, and I need it to correctly process the request.
Any idea how I can get the full "original" url in the 404 handler?
EDIT: reading the answers, looks like I did not make the question clear enough:
The users have bookmarked many different pages (oldpage1, oldpage2, etc.) and I should handle them equally.
The parameters for each old page are almost the same, and I need a specific ones only.
I want to re-use the "old" virtual directory name for the "new" application.
The search bots, etc., are not a concern, this is internal application with dynamic content, which expires very often.
The question is - can I do this w/o creating a bunch of empty pages in my "new" application with the old names, and Request.Redirect in their OnLoad. I.e. can this be done using the 404 mechanism, or some event handling in Global.asax, etc.
For the purposes of SEO, you should never redirect on a 404 error. A 404 should be a dead-end, with some helpful information of how to locate the page you're looking for, such a site map.
You should be using a 301, moved permanently. This allows the search bots to update their index without losing the page rank assigned to the original page,
See: http://www.webconfs.com/how-to-redirect-a-webpage.php on how to code this type of response.
You could look into the UrlRewritingNet component.
You should also look into using some of the events in your Global.ascx(?extention) file to check for errors and redirect intelligently. The OnError event is what you want to work with. You will have the variables from the request at that point in time (under the HttpContext object) and you can have your code work there instead of a 404. If you go this route, be sure you redirect the 404 correctly for anything other than oldpage.aspx.
I am sorry I don't have any explicit examples or information right now, hopefully this will point you in the right direction.
POST and GET parameters are only available per request. If you already know the name of the old page (OldPage.aspx) why not just add there a custom redirect in it?