I was just wondering what the best practice is for passing a parameter into a URL that contains characters that you do not wish to pass to the URL. For example, I pass the string /LM/W3SVC/7/ROOT into the URL but I want to pass it without the backslashes, thus like LMW3SVC7ROOT
The way I currently do this is by using .Replace(). This is the full line of code that I currently use #Html.DisplayFor(modelItem => item.Application) which works fine but throws out a warning every now and again so I was just wondering if this is the correct way of implementing it.
'Possible unintended reference comparison; to get a value comparison, cast the right hand side to type 'string'
Thanks in advance.
The problem you're getting is from var queryString = RouteData.Values["id"];. If you look in Visual Studio and hover over var it will tell you the type of that particular var, which in this case is Object.
Try:
var queryString = RouteData.Values["id"].ToString();
In this case, you're finding yourself having to replace certain characters in your string, which probably means server side, you might be having to do some extra logic to cope without having these characters on the received string. In your View, just wrap the id in Url.Encode:
id = Url.Encode(item.Application)
You will receive this server side with the string decoded, i.e. /LM/W3SVC/7/ROOT
Related
This is a question that has been asked before, but I've not found the information I'm looking for or maybe I'm just missing the point so please bear with me. I can always adjust my question if I'm asking it the wrong way.
If for example, I have a POST endpoint that use a simply DTO object with 2 properties (i.e. companyRequestDto) and contains a script tag in one of its properties. When I call my endpoint from Postman I use the following:
{
"company": "My Company<script>alert(1);</script>",
"description": "This is a description"
}
When it is received by the action in my endpoint,
public void Post(CompanyRequestDto companyRequestDto)
my DTO object will automatically be set and its properties will be set to:
companyDto.Company = "My Brand<script>alert(1);</script>";
companyDto.Description = "This is a description";
I clearly don't want this information to be stored in our database as is, nor do I want it stored as an escaped string as displayed above.
1) Request: So my first question is how do I throw an error if the DTO posted contains some invalid content such as the tag?
I've looked at Microsoft AntiXss but I don't understand how to handle this as the data provided in the properties of a DTO object is not an html string but just a string, so What I am missing here as I don't understand how this is helping sanitizing or validating the passed data.
When I call
var test = AntiXss.AntiXssEncoder.HtmlEncode(companyRequestDto.Company, true);
It returns an encoded string, but then what??
Is there a way to remove disallowed keywords or just simply throw an error?
2) Response: Assuming 1) was not implemented or didn't work properly and it ended up being stored in our database, am I suppose to return encoded data as a json string, so instead of returning:
"My company"
Am I suppose to return:
"My Company<script>alert(1)</script>"
Is the browser (or whatever app) just supposed to display as below then?:
"My Company<script>alert(1)</script>"
3) Code: Assuming there is a way to sanitize or throw an error, should I use this at the property level using attribute on all the properties of my various DTO objects or is there a way to apply this at the class level using an attribute that will validate and/or sanitize all string properties of a DTO object for example?
I found interesting articles but none really answering my problems or I'm having other problems with some of the answers:
asp.net mvc What is the difference between AntiXss.HtmlEncode and HttpUtility.HtmlEncode?
Stopping XSS when using WebAPI (currently looking into this one but don't see how example is solving problem as property is always failing whether I use the script tag or not)
how to sanitize input data in web api using anti xss attack (also looking at this one but having a problem calling ReadFromStreamAsync from my project at work. Might be down to some of the settings in my web.config but haven't figured out why but it always seems to return an empty string)
Thanks.
UPDATE 1:
I've just finished going through the answer from Stopping XSS when using WebAPI
This is probably the closest one to what I am looking for. Except I don't want to encode the data, as I don't want to store it in my database, so I'll see if I can figure out how to throw an error but I'm not sure what the condition will be. Maybe I should just look for characters such as <, >, ; , etc... as these will not likely be used in any of our fields.
You need to consider where your data will be used when you think about encoding, so that data with in it is only a problem if it's rendered as HTML so if you are going to display data that has been provided by users anywhere, it's probably at the point you are going to display it that you would want to html encode it for display (you want to avoid repeatedly html encoding the same string when saving it for example).
Again, it depends what the response is going to be used for... you probably want to html encode it at the point it's going to be displayed... remember if you are encoding something in the response it may not match whats in data so if the calling code could do something like call your API to search for a company with that name that could cause problems. If the browser does display the html encoded version it might look ugly but it's better than users being compromised by XSS attacks.
It's quite difficult to sanitize text for things like tags if you allow most characters for normal use. It's easier if you can whitelist characters allowed and only allow, say, alphanumeric but that isn't often possible. This can be done using a regex validation attribute on the DTO object. The best approach I think is to encode values for display if you can't stop certain characters. It's really difficult to try to allow all characters but avoid things like as people can start using ascii characters etc.
Just a thought came in mind.
Why the first of these two tags does not work in asp.net?
To me both are string values whose final value is same. Which is value of attribute href of hyperlink.
Please make me understand it.
Test
Test
Note: I am not looking for solution to it. Only want to understand what's logically difference between these two case.
To me both are string values whose final value is same
Not really. Consider first if you just had a plain non-razor HTML form such as if you'd hard-coded the beginning of the path:
Test
Now, here "/SomeProject/Test/Index" is not a string. It's an attribute value in HTML. HTML has no concept of "string". Sure it happens to use the same delimiter as C# does for string, but this isn't C# here.
With Razor we have a few means to indicate we want something done by Razor to the otherwise plain HTML.
# is one of them, indicating that we want a C# expression evaluated and the result (if not void) output. And the result of (string.Format("~/Test/Index")) is ~/Test/Index so that is output.
~/ is, in certain contexts, another one, indicating that it should be replaced with the value of evaluating Href("~/") or Url.Content("~/"), which would be something like / or /SomeProject/ or whatever. It's not so much a string as something more like a keyword.
If you have an expression returning a string, you can still use strings similarly with:
Test
Which incidentally, was the only way this could be done in Razor 1.0. The direct parsing of "~/… was added as a convenience and it is indeed convenient.
I think you're misunderstanding what string.Format(string format, params Object[] args) does. It will only replace specified placeholders {0}, {1}, etc with provided paramters. Take a look at the docs in the link provided for more info.
In short it doesn't do any automatic replacement of environment variables or any other substitutions not already covered by the placeholders.
String.Format sits in the System namespace, therefore I wouldn't expect it to know anything about web sites, file systems or anything more complicated than simple placeholder substitution and formatting.
You should be using Url.Action i.e.
Test
or even easier
#Html.ActionLink("Test", "Index", "Test")
Also note that in ASP.Net MVC you don't use the full controller name, only the prefix i.e. Test instead of TestController
I have a literal string generated by my bussiness logic that I need to send out on my web api via my controller.
The end part of my controller function looks like this, where the text variable is a literal string, thus containing "\\" to indicate a single backslash:
var text = _transformation.ToTextFormula(new Formula("", formula, parts));
return Ok(text);
The problem this creates is that when I then consume my api the duble backslashes are still there and not just the single one intended. Surely there must be a way to correct what is sent out?
If I inspect the "text" variable to look at the value in real format there is just a single slash before leaving the method.
I have a situation where I need to put a url inside a GET variable.
for example:
'http://www.site.com/StepOne?b=1&afterUrl=http://www.site.com/StepTwo?someVar=text&b=1'
In this case, when I am at StepOne the b param value will be 1,1 and not 1 as expected.
the afterUrl param will be:
'http://www.site.com/StepTwo?someVar=text'
instead of this:
'http://www.site.com/StepTwo?someVar=text&b=1'
How do I isolate the afterUrl param so its own GET variables won't effect the entire URL.
When you are creating the afterUrl URL parameter, be sure to UrlEncode() the value.
e.g.
var url = String.Format("http://www.site.com/StepOne?b={0}&afterUrl={1}", b, Server.UrlEncode(afterUrl));
Consider using HttpUtility.UrlEncode() for the AfterURL
(EDIT or Server.URLEncode() as others have pointed out)
"http://www.site.com/StepOne?b=1&afterUrl=" +
HttpUtility.UrlEncode(http://www.site.com/StepTwo?someVar=text&b=1");
Then when you finally hit the "StepOne" page you can use HttpUtility.UrlDecode(AfterURL variable name). From there you can Response.redirect or whatever you want with the preserved after url.
Use Server.UrlEncode on someVar to escape out it's querystring values before putting it in the link. You may need to use Server.UrlDecode on the other side to convert it back to the original characters.
Quite simply, you need to URL encode the afterUrl param (actually, you should URL encode all parameters passed to a server), which will turn "http://www.site.com/StepTwo?someVar=text&b=1" into "http%3A%2F%2Fwww.site.com%2FStepTwo%3FsomeVar%3Dtext%26b%3D1", which won't affect the set of parameters. Almost any server framework on the market will automatically decode that back into the string "http://www.site.com/StepTwo?someVar=text&b=1", or at least give you a function to do so yourself.
EDIT:
As this SO question shows, it is possible to URL encode a string without using System.Web, using System.Net.Uri.EscapeDataString().
I searched SO and found similar questions, but none compared all three. That surprised me, so if someone knows of one, please point me to it.
There are a number of different ways to parse the query string of a request... the "correct" way (IMO) should handle null/missing values, but also decode parameter values as appropriate. Which of the following would be the best way to do both?
Method 1
string suffix = Request.QueryString.Get("suffix") ?? "DefaultSuffix";
Method2
string suffix = Request.QueryString["suffix"] ?? "DefaultSuffix";
Method 3
NameValueCollection params = HttpUtility.ParseQueryString(Request.RawUrl);
string suffix = params.Get("suffix") ?? "DefaultSuffix";
Method 4
NameValueCollection params = HttpUtility.ParseQueryString(Request.RawUrl);
string suffix = params["suffix"] ?? "DefaultSuffix";
Questions:
Would Request.QueryString["suffix"] return a null if no suffix was specified?
(Embarrassingly basic question, I know)
Does HttpUtility.ParseQueryString() provide any extra functionality over accessing Request.QueryString directly?
The MSDN documentation lists this warning:
The ParseQueryString method uses query strings that might contain user input, which is a potential security threat. By default, ASP.NET Web pages validate that user input does not include script or HTML elements. For more information, see Script Exploits Overview.
But it's not clear to me if that means ParseQueryString() should be used to handle that, or is exposed to security flaws because of it... Which is it?
ParseQueryString() uses UTF8 encoding by default... do all browsers encode the query string in UTF8 by default?
ParseQueryString() will comma-separate values if more than one is specified... does Request.QueryString() do that as well, or what happens if it doesn't?
Which of those methods would correctly decode "%2b" to be a "+"?
Showing my Windows development roots again... and I would be a much faster developer if I didn't wonder about these things so much... : P
Methods #1 and #2 are the same thing, really. (I think the .Get() method is provided for language compatibility.)
ParseQueryString returns you something that is the functional equivalent of Request.Querystring. You would usually use it when you have a raw URL and no other way to parse the query string parameters from it. Request.Querystring does that for you, so in this case, it's not needed.
You can't leave off "suffix". You either have to pass a string or an index number. If you leave off the [] entirely, you get the whole NameValueCollection. If you mean what if "suffix" was not one of the QueryString values then yes; you would get null if you called Request.QueryString["suffix"].
No. The most likely time you would use it is if you had an external URL and wanted to parse the query string parameters from it.
ParseQueryString does not handle it... neither does pulling the values straight from Request.QueryString. For ASP.NET, you usually handle form values as the values of controls, and that is where ASP.NET usually 'handles' these things for you. In other words: DON'T TRUST USER INPUT Ever. No matter what framework is doing what ever for you.
I have no clue (I think no). However, I think what you are reading is telling you that ParseQueryString is returning UTF-8 encoded text - regardless if it was so encoded when it came in.
Again: ParseQueryString returns basically the same thing you get from Request.QueryString. In fact, I think ParseQueryString is used internally to provide Request.QueryString.
They would produce the equivalent; they will all properly decode the values submitted. If you have URL: http://site.com/page.aspx?id=%20Hello then call Request.QueryString["id"] the return value will be " Hello", because it automatically decodes.
Example 1:
string itsMeString = string.IsNullOrEmpty(Request.QueryString["itsMe"]) ? string.Empty : HttpUtillity.UrlDecode(Request.QueryString["itsMe"]);
Stright to your questions:
Not quite sure what do you mean by suffix, if you are asking what happens if the key is not present(you don't have it in the QueryString) - yes it will return null.
My GUESS here is that when constructed, Request.QueryString internally calls HttpUtillity.ParseQueryString() method and caches the NameValueCollection for subsequential access. I think the first is only left so you can use it over a string that is not present in the Request, for example if you are scrapping a web page and need to get some arguments from a string you've found in the code of that page. This way you won't need to construct an Uri object but will be able to get just the query string as a NameValueCollection if you are sure you only need this. This is a wild guess ;).)
This is implemented on a page level so if you are accessing the QueryString let's say in Page_Load event handler, you are having a valid and safe string (ASP.NET will throw an exception otherwise and will not let the code flow enter the Page_Load so you are protected from storing XSS in your database, the exception will be: "A potentially dangerous Request.QueryString value was detected from the client, same as if a post variable contains any traces of XSS but instead Request.Form the exception says Request.QueryString."). This is so if you let the "validateRequest" switched on (by default it is). The ASP.NET pipeline will throw an exception earlier, so you don't have the chance to save any XSS things to your store (Database). Switching it off implies you know what you're doing so you will then need to implement the security yourself (by checking what's comming in).
Probably it will be safe to say yes. Anyway, since you will in most cases generating the QueryString on your own (via JavaScript or server side code - be sure to use HttpUtillity.UrlEncode for backend code and escape for JavaScript). This way the browser will be forced to turn "It's me!" to "It%27s%20me%21". You can refer to this article for more on Url Encoding in JavaScript: http://www.javascripter.net/faq/escape.htm.
Please elaborate on that, couldn't quite get what do you mean by "will comma-separate values if more than one is specified.".
As far as I remember, none of them will. You will probably need to call HttpUtillity.UrlDecode / HttpUtillity.HtmlDecode (based on what input do you have) to get the string correctly, in the above example with "It's me!" you will do something like (see Example 1 as something's wrong with the code formatting if I put it after the numbered list).