Block URL's and Invalidate them - asp.net

This is a valid url
URL1:
http://www.itsmywebsite.com/showproduct.aspx?id=127
http://www.itsmywebsite.com/browseproduct.aspx?catid=35
but this is not
URL2:
http://www.itsmywebsite.com/showproduct.aspx?id=-1%27
http://www.itsmywebsite.com/browseproduct.aspx?catid=-1%27
How can I block URL2 and the ones containing a string of format "-1%27" and invalidate the request. It's an automated bot sending this request so basically I want to just block the request in probably Global.asax? Please advise.

Well, those are both perfectly valid URLs. Your "URL2" is simply percent-encoded. Since 0x27 is an ASCII apostrophe, your percent-encoded URL2s are exactly the same as
http://www.itsmywebsite.com/showproduct.aspx?id=-1'
http://www.itsmywebsite.com/browseproduct.aspx?catid=-1'
Perhaps your web page should be validating the data it receives on the query string and throwing an error.

Which version of iis are you using? If 7.0 or later use the URL rewrite module to reject invalid urls such as those ending in =-1
See an example blocking domains ( regex patterns ) here: http://www.hanselman.com/blog/BlockingImageHotlinkingLeechingAndEvilSploggersWithIISUrlRewrite.aspx

Related

Nginx Rewrite URL Rule having special character(#) for Page section

I need help in rewriting the URL in nginx configuration which should work as below :
/products/#details to /produce/#items
but it is not working as # is creating a problem.
Note : # in the URL denotes the page section
e.g. www.test.com/products/#details should get redirected to www.test.com/produce/#items
This is impossible using nginx because browsers don't send hashtags (#details) to servers. So you cannot rewrite in nginx or any other web servers.
In other words, hashtags is available to the browser only, so you have to deal it with Javascript. The server can not read it.
https://www.rfc-editor.org/rfc/rfc2396#section-4
When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI.
There is no way to do this rewrite. The # and everything that precedes it will not be sent to the server, it is completely handled on the client side.

Is an HTTP URL containing // valid?

I have a URL in the following form
https://abc.domain.com//xyz/test
and I'm fetching the contents via Volley (Android).
Is it a valid URL? Do I need to one / remove from //xyz
Basically it's still a valid URL.
Both server and search engine consider these two (with / or //) are separated URLs.
So be sure what URL is correct for fetching.

hashtags (#) in URL encoded parameters decoded on redirect

I have a two server system... one hosting the app and the other hosting the authentication/authorization. When the app detects the user isn't logged in yet, it redirects to the auth server and passes, as a parameter, the URL originally requested by the user so that after authentication, the user will be redirected back to the app server to the exact URL originally requested.
However, if that original URL contains a #, the whole routine is hosed. It appears that the browsers are decoding the url encoded parameter and, as a consequence, dropping anything after the # to the floor. I've tried this on Chrome, Safari and Firefox.
Example:
Original URL:
https://xxx.com/#/main/by-users?param1=53&param2=13&param3=39
Redirect URL:
https://yyy.com/signin/?returnURL=https%3A%2F%2Fxxx.com%3A80%2F%23%2Fmain%2Fby-users%3Fparam1%3D53%26param2%3D13%26param3%3D39
Browser shows:
https://yyy.com/signin/?returnURL=https%3A%2F%2Fxxx.com%2F#/main/by-users?param1=53&param2=13&param3=39
As you can see, everything including and after the # is decoded. Thus the server never gets the full 'returnURL' parameter value. It basically just gets
https://xxx.com/
This must be part of some spec someplace, though it seems insane that an encoded # should be decoded and dealt with as if it were never encoded in the first place. But how does one get around this?
Thanks.
Not sure if it is the best solution or even if you can control this, but it may work if you do double-encoding: for example, instead of "%23", make it use "%2523".
The unwanted decoding should then convert "%2523" to "%23", leaving the desired result in the redirect URL that the browser shows.
You need to URI-escape the "#" character.

Is it ok to use http:// inside an URL body?

As far as I understand, an URL consists of the folowing fields:
Protocol (http, https, ftp, etc.)
User name
User Password
Host address (an IP address or a DNS FQDN)
Port (which can be implied)
Path to a document inside the server documents root
Set of arguments and values
Document part (#)
as
protocol://user:password#host:port/path/document?arg1=val1&arg2=val2#part
But I've just met an example of using "http://" inside the path part: there is a redirection service (showing ads and paying money for traffic you route through it) which just adds a target URL (in full form, with "http://") to its own. Is it considered ok from standards point of view? Doesn't it break anything? Normally I'd never expect to meet "//" double slash, a colon or a "#" inside a valid URL but on the places they are in the example above.
No, it is not okay from a standards perspective.
Per Section 3.3 Path Component in RFC-2396, path cannot contain the following characters - "/", ";", "=", and "?"
Usually, browsers encode such malformed URIs before making the http request, which is why it works in practice.

Check malicious Redirect URL in ASP.NET

I heard of sites using other site to redirect users either to their own site or to hide behind another site. In my code i redirect in a few places such as post a comment (its easier to use a return url then figure out the page using data given).
How do i check if the return URL is my own url? I think i use absolute paths so i can easily check if the first character is '/' but then i will lose relative flexibility. This also disallows me from doing http://mysite.com/blah in the redirect url. I could patch the url by adding mysite + string but i'll need to figure out if string is a relative url or already a mysite.com url.
Whats the easiest way to ensure i am only redirecting to my site?
How about, if the redirectUrl contains "://" (which includes http://, https://, ftp://, etc.) then it must also start with "http://mysite.com". If it does not contain "://" then it is relative and should not be a problem. Something like this:
if (!(redirectUrl.Contains("://") ^ redirectUrl.IndexOf("http://mysite.com") == 0))
{
Response.Redirect(redirectUrl);
}
I hadn't thought of this before, but how about using an encrypted version of the URL in the query string parameter?
Alternatively, you could keep a list of the actual URLs in some persistent store (persistent for a couple of hours, maybe), and in the query string, just include the index into the persistent store of URLs. Since You'd be the only code manipulating this persistent, server-side store, the worst a malicious user could do would be to redirect to a different valid URL.
This seems to be an odd question, and it should not be a concern if you are in full control over the redirect process. If for some reason you are allowing input from the user to be actively involved in a redirect (as in the code below)
Response.Redirect(someUserInput);
Then, yes, a user could have your code send them off to who knows where. But if all you are ever doing is
Response.Redirect("/somepage.aspx")
Then those redirects will always be on your site.
Like I said, it seems to be an odd question. The more prominent concerns in terms of user input are typically SQL Injection attacks and cross-site scripting. I've not really heard about "malicious redirects."

Resources