According to old AntiXss article on MSDN AntiXss.UrlEncode is used to encode link href (Untrusted-input in the following example):
Click Here!
My understanding was, that UrlEncode should be used only when setting something to URL, like when setting document.location with JS. So why don't I use HtmlAttributeEncode in the previous example to encode [Untrusted-input]? On the other hand is there a security flaw if I use UrlEncode to encode HTML attributes like in the above sample?
Url Encode encodes URL parameters for use in anchor tags.
Html Attribute encode encodes things for use in general HTML attributes.
Both encoding types vary - unsafe characters in HTML attribute encoding will be turned into a &xxx; form, in URL encoding they'll turn into %xxx. Whilst it's probably unlikely getting it wrong would cause a security problem your data wouldn't be properly rendered in the browser, or understood in a request.
(Indeed Url encoding is probably going to change because of an incompatibility with older browsers, and HTML Encoding will change in the next CTP drop to allow for safe listing of particular Unicode ranges).
Related
In ASP having this URL:
http://www.example.com?foo=1&bar=2
Request.QueryString["bar"] returns NULL
The URL is a map area "href" link which I have assigned like so:
PolygonHotSpot p = new PolygonHotSpot();
p.NavigateUrl = http://www.example.com?foo=1&bar=2
ASP automatically HTML encodes the URL for the href, but it is not HTML decoding it again in the request therefore query string "bar" is not found.
Now I am using IIS URL Rewrite 2 module. Maybe this module is causing the problem? What can I do to solve it? I have tried using URL rewrite rules but couldn't figure our how or if it is the proper way.
It's probably not a good idea, but you could use Request.ServerVariables("QUERY_STRING") (or Request.ServerVariables["QUERY_STRING"] - your tags say ASP classic but your code looks like C#?) to get at the entire thing and then process it yourself.
I think there must be something deeper wrong though. A link can be encoded to be sent to the browser - the browser does the work of decoding it before navigating to the link. You can demonstrate this with a simple <a href="/test?a=1&b=2"> in a test script - the browser ends up correctly at /test?a=1&b=2. Testing it with a polygonal image map shows the same behaviour.
If you can show me what is in your actual HTML output for the image map I might be able to help more.
Such as:
<img style="width:500px;height:150px;background:url(data:image/png;base64,BLAH)" />
The application I have displays an authorization letter, and then displays a canvas. The canvas allows touch/mouse events and the user is able to sign their name to it. Then the HTML and the signature are saved. The customer is requesting that these be saved to one single file so that they don't get mismatched signature PNG files and HTML text files in the future.
So, while I don't like the look of this approach, it seems to work fine in Chrome and even IE, and it solves the customers request of only having to store one single file with the signed authorization.
My question is - Is this legal HTML or is Chrome being nice to me?
Quote OP:
<img style="width:500px;height:150px;background:url(data:image/png;base64,BLAH)" />
"My question is - Is this legal HTML?"
No. According to the W3C HTML spec, the src attribute "must be present".
Why not change your img into a div?
<div style="width:500px;height:150px;background:url(data:image/png;base64,BLAH)"></div>
In general, any question regarding HTML validity should be put through the online validator before coming to SO: http://validator.w3.org/
The HTML is not valid. But if you dig a bit you'll find references to the Data URI scheme in the HTML4 spec:
<OBJECT id="clock1"
classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502"
data="data:application/x-oleobject;base64, ...base64 data...">
A clock.
</OBJECT>
... so the problem is not the data: uri. As for whether this is a chrome-only thing, the Wikipedia article on the Data URI Scheme contains a section devoted to browser support.
It looks like the CSS is not valid either. The following fails validation on the w3c CSS validator:
.wtv {
background:url(data:image/png;base64,BLAH);
color:red;
}
The validator gives the following error:
Value Error : background url(data:image/png;base64,BLAH) is an incorrect URL url(data:image/png;base64,BLAH)
So what you're doing works, but according to the letter of the law, it is not valid.
It is fine in my opinion. Having actual base64 image data in a CSS declaration is fine. Interesting approach if the output of the process is just an HTML file.
In this case the question would be if this is valid CSS. However, it can be used in both and should be valid. But be careful, not all browsers support it.
Wikipedia: Data URI scheme
When I put this word "Bibliothèque" in a .aspx page, I see it correctly "Bibliothèque".
If I put the same word in a .html file, I see "Bibliothèque"
How can this be possible? Must be an IIS issue but I can't find the setting.
How can a .aspx file show the right word but not a .html file.
Open the file named web.config in the ASP.NET project. The value of requestEncoding attribute in globalization element is "utf-8". It means the requested texts were encoded as UTF-8 character set.
check your browser what it is support. you can change it using character encoding. So your HTML is giving you the result according to browser character encoding.
To ensure it will always work, for this specific example, you can replace the non ASCII characters using Html entities, like this: Bibliothèque. But this is not always practical in general.
Otherwise, there are other various ways to make it work:
use byte order mark encoding (sometimes called 'signature', or BOM, by editors) and save the file as UTF-8
add a META character encoding to your html file.
define what HTTP headers will be sent to the client using the globalization element in the application web.config (responseEncoding, etc.)
define what HTTP headers will be sent to the client using the ASP.NET #page directive
The best is to make sure all this is consistent in your application. UTF-8 support is now widespread, so it's a good choice as the encoding.
An interesting article on the encoding subject :The Definitive Guide to Web Character Encoding
I have the problem that my installed FCKEditor 3.3.1 changes all & to &.
I am posting lots of links in my posts and this makes them invalid. Where can I define that & ist NOT replaced with &?
Thanks :-)
No, you can't. FCKEditor does the right thing.
There is no situation where a standalone & in HTML is not an error. The ampersand always has to be encoded as & - unless it is the start of an escape sequence itself (like in <).
It is a misconception that the & in the HTML source code would make a link invalid. It does not. For HTML to be valid, all data in it must be HTML-escaped. "Data" means both text (in-between tags) and attribute values (like href). When the HTML source is then parsed, the parser will automatically HTML-unescape all data and & will become & again in the DOM. Do not let the fact that many browsers accept an unescaped ampersand deceive you. It is wrong nevertheless (and FCKEditor just tries to deliver valid HTML).
See the custom setting in the fckconfig.js file for FCKeditor.
FCKConfig.ForceSimpleAmpersand = true ;
Tomalak is correct about how it should be presented but I'm just pointing out that there is a configuration option in FCKeditor, in case you need to "break the rules". There are situations where this is necessary. Rendering the ampersand as a true HTML entity (&) does not work in some HTML mail clients, which rarely adhere to HTML standards properly anyway. And you may need to force the plain ampersand if you have an additional filter that will convert it to an HTML entity further along your process.
On our site, I use the category (in Russian) in the querystring.
E.g.: http://www.odinklik.ru/kategoriya.aspx?cat=люди
If you paste this link in IE8, it is translated to cat=???? and it does not work
If I paste it in FireFox, it works.
It gets even more weird: the same URL is reachable from the homepage, and if I click the same URL in IE8 from the homepage it works fine (unless I click open in a new tab, that it is back to ????).
I am using ASP.NET 3.5(C#)
Did you try to do encoding on first page and decode from Cyrillic to Unicode and back?
Little bit a headache but surly will work.
You should URL-encode the category name before adding it to the querystring, rather than relying on the browser to do that for you.
The method HttpServerUtility.UrlEncode should be able to handle this encoding for you.
HttpServerUtility.UrlEncode should give you the link http://www.odinklik.ru/kategoriya.aspx?cat=%D0%BB%D1%8E%D0%B4%D0%B8, which should give you the correct result.
(Note that %D0%BB corresponds to л, %D1%8E to ю, %D0%B4 to д and %D0%B8 to и. As the Unicode values for Cyrillic characters are over U+ff, you will require two URL-encoding bytes for each character.)