The following query string results in Request.QueryString being empty:
http://intranetsite/form.apsx?InstanceID=123&Form=App.SomeForm
As soon as I change it to
http://intranetsite/form.apsx?InstanceID=123&Forms=App.SomeForm
Request.QueryString is populated with two key value pairs (InstanceID - 123 and Forms - App.SomeForm).
I am using IIS 8 on a win2k12 server. I think that this worked under IIS 7 but can't be sure. I have scoured the interweb for a list of key names that are blacklisted in Request.QueryString but no joy. Does anyone know of such a list and/or have a suggestion on why this is happening? My guess that it is because the key name is 'Form' could be wrong...
Wrong diagnosis - QueryString was empty because the page was redirecting when Form=<any value> was in the URL. Thanks for everyone's help though!
Are you using MVC or some other technique that applies routing to your URL?
It's just a long shot guess, but seing that your page name is also "form"(.aspx) it could be a routing issue...
EDIT: I have never heard of such a thing as blacklisted querystring parameter names. For sure certain characters won't work, but whole words - no, I've never encountered that.
Related
I am using the asp.net routing in a webforms application and I need to map the new url's and the legacy url's to the same route.
localhost/blog/?financial-literacy-efficacy
localhost/blog/financial-literacy-efficacy
The legacy url's have a question mark in front of the query string and the routing /{slug} is not picking it up.
i have tried something like this with no luck
routes.MapPageRoute("blog-slug", _
"blog/?{slug}", _
"~/blogArticles/Default.aspx")
Is this possible?
Thanks in advance.
By default, the routes will not accept anything after the ? as part of the page being routed to since by definition the ? separates the query string from the resource in the URL. One way that might work is
routes.MapPageRoute("blog-slug", _
"blog/", _
"~/blogArticles/Default.aspx")
But the "financial-literacy-efficacy" value will instead be a key since it is ?x not ?slug=x. However, since that is the legacy url, there might already exist some portion of your code that checks keys in query strings as opposed to values since most dynamic webforms legacy urls look soemthing like
blog/?slug=x
And then they check Request.Querystring["slug"]. You would need to provide more information in your question if that causes you trouble.
On my site i have used cookie to store few details in browser.
The issue is, it doesn't store value which ends with ampersand. i.e. HiAll655& loads back as HiAll655
I found that cookie creates issue with few characters like ampersand but it stores & loads value like HiAll655&HiAll properly.
Any help would be appreciated.
Thank you
You can use HttpUtility.UrlEncode(string) when storing the value, and HttpUtility.UrlDecode(string) when reading the value.
UrlEncode transforms & to %26 which is safe to use in cookies.
2nd in an occasional series:
Here's the first one
Is CAT.NET correct that the following is a genuine vulnerability in ASP.NET or is it a false positive?
var myInt = Int32.Parse(txtUserInput.Text);
Response.Redirect(string.Format("myPage.aspx?myId={0}", myInt);
CAT.NET is reporting this as a redirect vulnerability needing remediation via encoding myInt.
I wouldn't call that dangerous but its not how I would write it myself
int myInt;
if(Int32.TryParse(txtUserInput.Text,out myInt)){
Response.Redirect(string.Format("myPage.aspx?myId={0}", myInt);
}
Is to my mind cleaner as it wont throw an exception if the parse fails due to bad user input and we are explicitly typing the int.
Any error handling code can be bundled into an else statement on the end.
I don't believe so, it could cause an exception so TryParse might be a better approach. It's just yelling because you are taking user input and redirecting based on it. It's possibly being a little too aggressive which isn't exactly bad.
There is no exploitable vulnerability as a result of this code. Any vulnerability would be a result of what myPage.aspx does with the value of myId, not how your url is built. Anyone could just as easily directly hit myPage.aspx with anything they want in the querystring.
However this is bad practice, assuming that you haven't left anything out of the code between those two lines. You should verify that txtUserInput.Text contains only numeric characters, and falls within allowable values.
Exploits happen because of improper parsing of user-supplied data by the page it's posted to -- not improper generating of URLs. While it's a good idea to try to make sure your web site won't write a broken URL because of something that's put in a form, input validation at the front-end is irrelevant to security. All that matters is what the code that accepts the input does with it, since any post or query string can be forged.
In ASP.NET, is there any way to get the real raw URL?
For example, if a user browse to "http://example.com/mypage.aspx/%2F", I would like to be able to get "http://example.com/mypage.aspx/%2F" rather than "http://example.com/mypage.aspx//".
I would of course like a clean way to do it, but I can live with a hacky approach using reflection or accessing obscure properties.
At the moment, I try to use the uri in the Authorization-header (which works), but I cannot rely on that always being there.
EDIT:
What I really want to do is to be able to distinguish between "http://example.com/mypage.aspx/%2F" and "http://example.com/mypage.aspx/%2F%2F".
It looks like ASP.NET first converts "%2F%2F" into "//" and then converts the slashes into a single slash.
So just re-encoding it is not going to work.
I wasn't able to test this because it only works in IIS and not the ASP.NET Development Server that is part of Visual Studio, but try:
Request.ServerVariables[ "HTTP_URL" ]
The following code works for me:
IServiceProvider serviceProvider = (IServiceProvider)HttpContext.Current;
HttpWorkerRequest workerRequest = (HttpWorkerRequest)serviceProvider.GetService(typeof(HttpWorkerRequest));
string realUrl = workerRequest.GetServerVariable("HTTP_URL");
Note that this only works when running on the IIS and not under f.x. ASP.NET Development Server!
Thanks to Lucero for the answer in another thread and Zhaph for pointing me to the thread.
See also:
Get the exact url the user typed into the browser
Server.HtmlEncode(Request.RawUrl);
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.
see also:link text
I can't test here, but this might be what you need:
Request.Url.AbsoluteUri
Request.RawUrl will return the application relative path(including querystring info) while Request.Url will return the complete path(including querystring info).
For more information, see "Making sense of ASP.NET paths".
Well, you could just encode it back to the url-encoded version.
Get the url from the request and urlencode only the query string part and then concatenate them
I have a query string parameter value that contains an ampersand. For example, a valid value for the parameter may be:
a & b
When I generate the URL that contains the parameter, I'm using System.Web.HTTPUtility.UrlEncode() to make each element URL-friendly. It's (correctly) giving me a URL like:
http://example.com/foo?bar=a+%26b
The problem is that ASP.NET's Request object is interpreting the (encoded) ampersand as a Query String parameter delimiter, and is thus splitting my value into 2 parts (the first has "bar" as the parameter name; the second has a null name).
It appears that ASP.NET is URL-decoding the URL first and then using that when parsing the query string.
What's the best way to work around this?
UPDATE: The problem hinges on URLRewriter (a third-party plugin) and not ASP.NET itself. I've changed the title to reflect this, but I'll leave the rest of the question text as-is until I find out more about the problem.
man,
i am with you in the same boat, i have spent like hours and hours trying to figure out what is the problem, and as you said it is a bug in both, as normal links that contain weird characters or UTF-8 code characters are parsed fine by asp.net.
i think we have to switch to MVC.routing
Update: man you wont believe it, i have found the problem it is so strange, it is with IIS,
try to launch your page from visual studio Dev server and Unicode characters will be parsed just fine, but if you launch the page from IIS 7 it will give you the ???? characters.
hope some body will shade some light here
I would have thought that %26 and '&' mean exactly the same thing to the web server, so its the expected behavior. Urlencode is for encoding URLs, not encoding query strings.
... hang on ...
Try searching for abc&def in google, you'll get:
http://www.google.com.au/search?q=abc%26def
So your query string is correct, %26 is a literal ampersand. Hmm you're right, sounds like a bug. How do you go with an & instead of the %26 ?
Interesting reading:
http://www.stylusstudio.com/xsllist/200104/post11060.html
Switching to UrlRewritingNet.UrlRewrite did not help, as it apparently has the same bug. I'm thinking it might have something to do with ASP.NET after all.
I think URLRewriter has a problem with nameless parameters (null name).
I had a similar problem. When I gave my nameless parameter a (dummy) name, everything worked as expected.