Say I have a form whose action target expects a value with spaces in it. If I were typing the request out manually as a URL, I'd use %20 to escape the spaces. If I use a hidden input for this parameter instead, should the value contain the spaces themselves, or the URL quoted %20 sequences?
Spaces! Let the browser HTML-escape the values for you on form submission.
Related
I want to put the value="name+asc" in hidden field. Http method is Get.
<input type="hidden" value="name+asc" name="sort" />
But I cannot put the name+asc in URL.
How can I handle that problem.
Values of form inputs will be automatically encoded correctly when a form is submitted. In application/x-www-form-urlencoded data, a + sign represents a space so the browser will encode it as %2B.
If you want to submit a form with + in the data: The code you have is fine.
If you want to submit a form with a space in the data: Use a literal space. The browser will encode it for you.
If you want to read form data with JavaScript and construct a URL (or post request) programatically when pass the data through the encodeURIComponent method.
var value = "123+456";
var encodedValue = encodeURIComponent(value);
var url = "http://example.com/?query=" + encodedValue;
If you want to construct a URI by hand (e.g. for pasting into an HREF attribute) then you will need to look up the encoded values … somewhere. I tend to run node.js in a terminal so I can quickly type encodeURIComponent('a string literal');.
As far as i know the + will automatically split your values unless encoded to special characters. You can use a - or a _ instead of the +.
I have a simple html page with a div element in it.
The innerHTML property of the div is set through query String.
In query string I pass html strings,i.e.
<p style='font-size:20px;color:green;'> Sun rises in the east </p> etc...
I get the appropriate output.
However, if I pass color code in style attribute say, #00990a, I am not displayed any content.
Can someone help me through this?
if theres a color code that contains a #, everything after that will be treated fragment identifier. to avoid this you have to url-encode your parameter-value (replacing # with %23 an d doing the same with other characters that have a special meaning (#&%=?#...)).
Finally your url should look like this:
PageUrl?Content=%3Cp+style%3D%27color%3A%23009900%27%3EContent%3C%2Fp%3E
Since you haven't shown us any code, I shall guess…
In a URI, # indicates the start of the fragment identifier (as ? indicates the start of the query string). Your colour is terminated the query string and starting the fragment identifier. You need to URL encode any character that has special meaning in URLs. (# is %23).
Do make sure that you sanitise the passed HTML and CSS on the server though. It is very easy to expose yourself to XSS attacks otherwise.
Say we have a form where the user types in various info. We validate the info, and find that something is wrong. A field is missing, invalid email, et cetera.
When displaying the form to the user again I of course don't want him to have to type in everything again so I want to populate the input fields. Is it safe to do this without sanitization? If not, what is the minimum sanitization that should be done first?
And to clearify: It would of course be sanitized before being for example added to a database or displayed elsewhere on the site.
No it isn't. The user might be directed to the form from a third party site, or simply enter data (innocently) that would break the HTML.
Convert any character with special meaning to its HTML entity.
i.e. & to &, < to <, > to > and " to " (assuming you delimit your attribute values using " and not '.
In Perl use HTML::Entities, in TT use the html filter, in PHP use htmlspecialchars. Otherwise look for something similar in the language you are using.
It is not safe, because, if someone can force the user to submit specific data to your form, you will output it and it will be "executed" by the browser. For instance, if the user is forced to submit '/><meta http-equiv="refresh" content="0;http://verybadsite.org" />, as a result an unwanted redirection will occur.
You cannot insert user-provided data into an HTML document without encoding it first. Your goal is to ensure that the structure of the document cannot be changed and that the data is always treated as data-values and never as HTML markup or Javascript code. Attacks against this mechanism are commonly known as "cross-site scripting", or simply "XSS".
If inserting into an HTML attribute value, then you must ensure that the string cannot cause the attribute value to end prematurely. You must also,of course, ensure that the tag itself cannot be ended. You can acheive this by HTML-encoding any chars that are not guaranteed to be safe.
If you write HTML so that the value of the tag's attribute appears inside a pair of double-quote or single-quote characters then you only need to ensure that you html-encode the quote character you chose to use. If you are not correctly quoting your attributes as described above, then you need to worry about many more characters including whitespace, symbols, punctuation and other ascii control chars. Although, to be honest, its arguably safest to encode these non-alphanumeric chars anyway.
Remember that an HTML attribute value may appear in 3 different syntactical contexts:
Double-quoted attribute value
<input type="text" value="**insert-here**" />
You only need to encode the double quote character to a suitable HTML-safe value such as "
Single-quoted attribute value
<input type='text' value='**insert-here**' />
You only need to encode the single quote character to a suitable HTML-safe value such as
Unquoted attribute value
<input type='text' value=**insert-here** />
You shouldn't ever have an html tag attribute value without quotes, but sometimes this is out of your control. In this case, we really need to worry about whitespace, punctuation and other control characters, as these will break us out of the attribute value.
Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of the attribute. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and | (and more). [para lifted from OWASP]
Please remember that the above rules only apply to control injection when inserting into an HTML attribute value. Within other areas of the page, other rules apply.
Please see the XSS prevention cheat sheet at OWASP for more information
Yes, it's safe, provided of course that you encode the value properly.
A value that is placed inside an attribute in an HTML needs to be HTML encoded. The server side platform that you are using should have methods for this. In ASP.NET for example there is a Server.HtmlEncode method, and the TextBox control will automatically HTML encode the value that you put in the Text property.
I found out that HTML form supports only two enctype types. They are application/x-www-form-urlencoded and multipart/form-data. I understand that I use multipart/form-data when I need to upload a file. When do I use application/x-www-form-urlencoded? Is it default form enctype?
Yes, it is. Here's a cite from the W3 HTML forms specification:
The default value for this attribute is "application/x-www-form-urlencoded". The value "multipart/form-data" should be used in combination with the INPUT element, type="file".
The webbrowser will take care about URL encoding automatically.
application/x-www-form-urlencoded
This is the default content type. Forms submitted with this content type must be encoded as follows:
1) Control names and values are escaped. Space characters are replaced by '+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by '%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
2) The control names/values are listed in the order they appear in the document. The name is separated from the value by '=' and name/value pairs are separated from each other by `&'.
Check out this link for more on form content types, or here for more information about file uploads and such.
Yes, the default enctype is application/x-www-form-urlencoded.
When should I HTML-escape data in my code and when should I URL-escape? I am confused about which one when to use...
For example, given a element which asks for an URL:
<input type="text" value="DATA" name="URL">
Should I HTML-Escape DATA here or URL-escape it here?
And what about an element:
NAME
Should URL be URL-escaped or HTML-escaped? What about NAME?
Thanks, Boda Cydo.
URL encoding ensures that special characters such as ? and & don't cause the URL to be misinterpreted on the receiving end. In practice, this means you'll need to URL encode any dynamic query string values that have a chance of containing such characters.
HTML encoding ensures that special characters such as > and " don't cause the browser the misinterpret the markup. Therefore you need to HTML encode any values outputted into the markup that might contain such characters.
So in your example:
DATA needs to be HTML encoded.
Any dynamic segments of URL will need to be URL encoded, then the whole string will need to be HTML encoded.
Name needs to be HTML encoded.
HTML Escape when you're writing anything to a HTML document.
URL Escape when you're constructing a URL to call in-code, or for a browser to call (i.e. in the href tag).
In your examples you'll want to 'Attribute' escape the attributes. (I can't remember the exact function name, but it's in HttpUtility).
In the examples you show, it should be first URL-escaped, then HTML-escaped:
<a href="http://www.example.com?arg1=this%2C+that&arg2=blah">