3

I have been reading these two functions and am considering to pick up the one which is much more secure. I want to use Server.Transfer because it executes at the server side in a sense. Is it better to use?

Server.Transfer("myUrl.aspx?id=1");

or

Response.Redirect("myUrl.aspx?id=2");

Update:

My question is based on the client-side data security which comes from a previous page rather than a URL change.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Rajan Mishra
  • 1,178
  • 2
  • 14
  • 30
  • 1
    Why are you asking about security? What has security got to do with this? If you want to hide the ID, then think of a different solution than merely hiding it from the user. You need authorization, not obfuscation. – CodeCaster Aug 20 '17 at 07:32
  • @CodeCaster great advice, that is exactly what the OP's attempt here is, obfuscation and, in this case, some perceived illusion of improved security between one choice or the other – Brian Ogden Aug 20 '17 at 07:36

3 Answers3

2

tl;dr:

Neither Server.Transfer or Response.Redirect offers security advantages over the other. Strongly recommend not using Server.Transfer at all, as it is an anti-pattern of modern HTTP/web resource base paradigms, further explanation on that below. Use Response.Redirect and focus on authorization/identity for security concerns.


Neither offers more security than the other. The server/endpoint still allows HTTP/HTTPS requests, any request can be sent to the server by a malicious client.

You should prefer Response.Redirect over Server.Transfer. Server.Transfer is ASP.NET Web Forms "code smell". ASP.NET Web Forms has never respected HTTP, Restful, Stateless, resource request web paradigms, which is what the web is built on, obviously.

Server.Transfer is a very old method. Server.Transfer maintains the original URL in the browser. This can help streamline data entry for wizards, but it will also make for confusion when debugging.

Maintaining the original URL is also a perfect example of ASP.NET Web Forms doing what it wants, making life easier in the short term but impacting maintainability of the software in the long term. Maintaining the original URL is also a perfect example of going against the grain of HTTP/web protocols. It prevents the user from sharing the resource URL. And, even if you plan on that URL never being shared, there is always one use case where it is still always very helpful for the user/system/exception handling to be able to share the URL and it is to provide the correct place/resource the user is on, at a time of error or issue or even user question, for customer service/troubleshooting/debugging to better serve the user/customer/client.

Server.Transfer is an example of a shortcut. It has no security advantages, as the server/endpoints are exposed on port 80 to client requests whether responding with a different resource (Server.Transfer) or telling the client to redirect (Response.Redirect) and request another resource.

Regarding the "skipping" round trip advantage of Server.Transfer over Response.Redirect, it is a very small benefit considering that Server.Transfer is a web anti-pattern as I explained above. It guides developers to less elegant web systems architecture rather quickly as well.

Regarding the second parameter of Server.Transfer, perserveForm, setting perserveForm to True will maintain the form and query string and will still be available to the next page you are sending the user to but it is not advantageous enough to warrant use because it impacts long term maintainability of the web application.

perserveForm is also an anti-pattern to stateless, RESTful, resource based modern web applications/paradigms as I have been discussing above. If you need to maintain form state, across requests, it should be done on the client with local storage, it is not the responsibility of the server to maintain state for each client. perserveForm is yet another example of ASP.NET Web Forms, trying to make things easier for the developer in the short term but making code overly complex and difficult to maintain and debug in the long term.

HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
Brian Ogden
  • 18,439
  • 10
  • 97
  • 176
1

Using Response.Redirect would be more secure if you use it like this:

if (!Request.IsLocal && !Request.IsSecureConnection)
{
    if (Request.Url.Scheme.Equals(Uri.UriSchemeHttp, StringComparison.InvariantCultureIgnoreCase))
    {
        string sNonSchemeUrl = Request.Url.AbsoluteUri.Substring(Uri.UriSchemeHttp.Length);
        // Ensure www. is prepended if it is missing
        if (!sNonSchemeUrl.StartsWith("www", StringComparison.InvariantCultureIgnoreCase)) {
            sNonSchemeUrl = "www." + sNonSchemeUrl;
        }
        string redirectUrl = Uri.UriSchemeHttps + sNonSchemeUrl;
        Response.Redirect(redirectUrl);
    }
}

As it converts an HTTP request to a secure HTTP request (HTTPS).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
0

Both are equal to a security question...

Server.Transfer("myUrl.aspx?id=1");

Server.Transfer redirects from the server back end.

Response.Redirect("myUrl.aspx?id=2");

Response.Redirect comes to the front end, goes back to the back end, and redirects.

You can observe it if you debug both from the front and back end.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Shafikul Islam
  • 359
  • 1
  • 10