How to pull Domain portion of Url from incoming HttpRequest - asp.net

I looked up the various request urls that you can grab from an HttpRequest. But I can't find how you can grab just the domain. Also would you call that portion of the string the domain or what? What's the formal term to call a string such as http://yourdomain.com? I want the http:// included without me having to prefix the yourdomain.com. I'm not sure what property I'm looking for.
Anyone know how grab that portion of the incoming HttpRequest? What do you call it?

http:// is the protocol; yourdomain.com is the host.
You can get either of them from the Request.Url property.

//your httprequest is called req you could do this.
Uri requesturi = req.Url;
string domain = requesturi.Host;

Related

How to redirect in nginx based on cookie header with alias?

I have a webserver that i want to configure like, using cookie.lua by cloudfare.
local key = "123"
local accessKey, err = cookie:get("access-key")
if accessKey == key then
ngx.var.proxy = "my_remote_server"
else
alias a static location
end
My problem is that i think there is a lua variable that support proxy_pass which means ngx.var.proxy, but there is no equivalent in alias to a static location.
So is there an example config that can solve my problem? thank you for reading this.
I'm not sure if I've understood your question correctly.
If you want to redirect to another route based on a cookie (or any Lua condition, really) you can use ngx.exec, which does an internal redirect; meaning the client will receive a reply as if they navigated to that new URI, but it all happens server-side so the client doesn't get redirected and still sees the old URI in the browser.
I don't know if this is 100% equivalent to using alias, but you can always combine it with ngx.var.VARIABLE and another route that has an actual alias directive making use of a $VARIABLE.

Web servlet url pattern

How would I express a url like:
<context>/{id}/email in the #WebServlet("...") syntax?
the default/context is users
Answering my own question. It does not appear like dynamic URL patterns are allowed in the #WebServlet("...").
I had to create a URL filter that would parse an incoming URL, extract {id} from it and set it as an attribute in the Session, and forward the request to the appropriate Servlet.

Get the current URL

I'm trying to set a variable to the current URL using:
Dim url As String = HttpContext.Current.Request.url.AbsoluteUri
Which is returning:
http://localhost/xxxxx2015/xxxx.asmx/xxxx
This seems to be the file name followed by the web function name.
What it's supposed to return/what it's displaying in IE is:
http://localhost/xxxxx2015/Default.aspx?form=xxxx
Why is this?
You are apparently in a WebRequest, so the current request is the request for that method. However, it is sent from some page, so possibly a "referrer" is set with the URL you are looking for.
See Getting the HTTP Referrer in ASP.NET for more details on how to get it. Basically: use Request.UrlReferrer

Security of passing GET parameters in URL through login page

Background: In my ASP.NET application, I occasionally need to pass the user through an intermediate page, which then must relink to the original requested page. I would like to maintain as many GET parameters as is feasible.
For example, if the user lands on:
store.aspx?storeId=34&myHours=12
But I now realize the user needs to go to the intermediate page, so the user is redirected:
siteAd.aspx?returnTo=store.aspx&params=storeId%3D34%26myHours%3D12
siteAd.aspx.vb will then have code to return the user to the original page (pseudocode):
Dim sReturnTo = Request.QueryString("returnTo")
' <insert code to protect against open-redirection attack on sReturnTo>
lnkContinue.HRef = sReturnTo & "?" & Request.QueryString("params")
Question: Are there any security concerns with the above scenario, as long as I make sure to protected against an open-redirection vulnerability in the returnTo parameter?
The solution I came up with was to URLEncode the entire string (per #SamGreenhalgh), then to use the built-in .NET function IsWellFormedUriString as such:
Private Shared Function isLocalUrl(ByVal sUrl As String) As Boolean
If String.IsNullOrWhiteSpace(sUrl) Then
Return False
End If
sUrl = sUrl.Trim
Return Uri.IsWellFormedUriString(sUrl, UriKind.Relative)
End Function
As #Sam Greenhalgh said why not pass the whole path and query string as one parameter rather than splitting. If it is correctly URL encoded, then this will be OK.
As well as the Open Redirection Vulnerability, you should secure your code against XSS by checking that lnkContinue.HRef can only be set to a HTTP or HTTPS URL. This will prevent someone creating a link to your site where returnTo contains JavaScript. e.g. javascript:alert('xss')
The Uri obect can be used to validate that returnTo isn't an open redirect or XSS attack. The protocol can be checked to make sure it is HTTP or HTTPS and the Url itself can be checked to see whether it is a relative URL or if it is an absolute URL pointing to your domain. It is better to use the Url object that executing manual string comparison methods. Many open redirect checks can be fooled by the attacker setting up domains such as www.example.com.evil.com to fool the domain check for www.example.com or by including www.example.com elsewhere in the URL (e.g. http://www.evil.com/www.example.com/Page.aspx).
URL Encoding is not a security measure and it is trivial to defeat. The best way to protect against Man-in-the-Middle attacks is to use HTTPS with a reputable SSL certificate and switch from GET to POST. Anything else is tiptoeing around the issue (i.e security)
Also see https://stackoverflow.com/a/1008550/374075

Request.RawUrl vs. Request.Url

What is the difference between Request.RawUrl and Request.Url in ASP.NET?
No one seems to have mentioned that it shows the Raw URL actually received by IIS, before any manipulation may have happened sending it around IIS or your file system with URL rewriting for example.
Say you have set an error page at /error in an MVC app and you set your webconfig to replace error pages with your custom error page at that location. In this way when getting an error at /faultypage, the user will get the page at /error but the url in your browser's address bar will still say www.mysite.com/faultypage—this is a transfer, or a rewrite.
Now on your error controller if you are to take a peek at Request.Url, it will be something like www.mysite.com/error and Request.RawUrl would say (more usefully?) /faultypage which is the user's actual request not the page that is currently being executed.
From MSDN:
The raw URL is defined as the part of
the URL following the domain
information. In the URL string
http://www.contoso.com/articles/recent.aspx,
the raw URL is
/articles/recent.aspx.
This means, you can use rawurl and do not have to care about through which address the server was called (for instance http://yourserver/ or http://yourserver.yourdomain.com/ if you have multiple interfaces.)
However, the URL property of an HTTPRequest object returns a System.URI object, which also contains server name.
Request.RawUrl is very similar to Request.Url.PathAndQuery except that Request.Url.PathAndQuery includes the Default Document if one was used whereas Request.RawUrl does not. From my experience, this is true for ASP.Net 4.0 and higher.
The HttpRequest.RawUrl Property documentation describes the property value as:
The raw URL is defined as the part of the URL following the domain information. In the URL string http://www.contoso.com/articles/recent.aspx, the raw URL is /articles/recent.aspx. The raw URL includes the query string, if present.
The HttpRequest.Url Property documentation describes the property value as:
A Uri object that contains the URL of the current request.
See the Uri class documentation for its properties.
Request.RawUrl returns a string, it's everything after the domain information for the current url.
Eg, for: Request.RawUrl vs. Request.Url
Request.RawUrl would be /questions/2019735/request-rawurl-vs-request-url
Request.Url returns a Uri object, http://msdn.microsoft.com/en-us/library/system.uri_members.aspx

Resources