wpl Issue Tracker Rss Feed

Closed Issue: SupressAntiXssEncoding Not working [10091]

Frankbr — Thu, 16 May 2013 11:29:59 GMT

In the AntiXSS Library Help, it says to to do the following to supress individual controls:

[Microsoft.Security.Application.SecurityRuntimeEngine.SupressAntiXssEncoding()]

protected global::System.Web.UI.WebControls.Label Label1;

For my web page, in the designer file, I have the following:

[Microsoft.Security.Application.SecurityRuntimeEngine.SupressAntiXssEncoding()]
protected global::System.Web.UI.WebControls.Literal litMainMenu;

And attached is my antixssmodule.config.

I'm wondering if I'm missing something or why it's not supressing the antixss encoding. I've also tried with label controls, and it does the same behavior.

Thanks for any help in advance.

Closed Issue: Medium Trust AntiXss.GetSafeHtmlFragment [13681]

bdorrans — Thu, 16 May 2013 11:29:58 GMT

It does not work in medium trust environments due to the code being Unsafe. Would it be possible to convert the code into safe code that can be used under medium trust? Maybe have an option to use the faster unsafe code for full trust or the slower safe code for medium trust?

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

dvdrom000 — Wed, 08 May 2013 21:57:07 GMT

When we updated our AntiXss library to 4.2.1 we noticed that our GetSafeHtmlFragment was no longer working. Is it required that we now whitelist any html attributes that we need with the newest release ?

GetSafeHtmlFragment("text") returns only "text".

The version we were running prior to release was 4.0.0 which did not seem to require any such white listing of needed html attributes.

Thank you in advance for reviewing this issue.
Comments: ** Comment from web user: dvdrom000 **

The problem is still there, crazy

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

timwilson — Wed, 30 Jan 2013 20:48:19 GMT

When we updated our AntiXss library to 4.2.1 we noticed that our GetSafeHtmlFragment was no longer working. Is it required that we now whitelist any html attributes that we need with the newest release ?
 
GetSafeHtmlFragment("text") returns only "text".
 
The version we were running prior to release was 4.0.0 which did not seem to require any such white listing of needed html attributes.
 
Thank you in advance for reviewing this issue.
Comments: ** Comment from web user: timwilson **

Tyrven, we had to go back to an older version... if you do have a different solution please post here. Thanks.

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

Tyrven — Wed, 30 Jan 2013 18:59:28 GMT

This issue has been open for over a year without acknowledgement from the contributors. I'm assuming it won't be addressed. Given this, I'm curious what approach folks are using to accomplish similar behavior? Has anyone implemented alternate libraries or approaches with much success?

(Still blows my mind that this hasn't been addressed - AntiXss, RIP?)

Commented Issue: Carriage return encoded as numeric character reference [19074]

sean986 — Thu, 20 Dec 2012 14:59:49 GMT

I have set the encoderType to "System.Web.Security.AntiXss.AntiXssEncoder,System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" for my project which is a simple ASP .NET 4.5 web forms project. When I include new lines in a text box the new line renders as the numeric character reference which is incorrect HTML5 according to http://validator.w3.org/ . See the attached file for the mark up.
Comments: ** Comment from web user: sean986 **

Great, thanks for talking to the ASP.NET folks.

Although this is a standards problem in HTML5 I think it could be fixed universally without any adverse effects. This would save having to pass an HTML version through a parameter.

If the encoder ever finds a carriage return followed by a new line could it remove the carriage return rather than encoding it? This would allow HTML5 to be correct but shouldn't change the meaning in other HTML versions.

Commented Issue: Carriage return encoded as numeric character reference [19074]

bdorrans — Wed, 19 Dec 2012 13:35:31 GMT

Ah got you. This is new for HTML5.

That complicates things, AntiXSS has no idea of HTML versions, so you'd have to pass it through via a parameter, which means changes in how it's called by the ASP.NET et al.

I'll go talk to the ASP.NET folks to see what ideas we can come up with

Commented Issue: Carriage return encoded as numeric character reference [19074]

sean986 — Wed, 19 Dec 2012 11:33:12 GMT

In the attached HtmlEncodeWithoutTextbox.PNG there is an example which doesn't use a text box, hopefully that will help clarify.

Reopened Issue: Carriage return encoded as numeric character reference in textbox [19074]

sean986 — Wed, 19 Dec 2012 11:30:43 GMT

Sorry to re-open this again but I think I may be confusing you with the text box example. I am certainly not asking for a special case for textbox values.

The problem is that HtmlEncode is encoding a new line as a numeric character refence of a carriage return and the numeric character refence of a new line. The carriage return is one of the space characters which is not allowed to be represented by a character reference in html5 according to http://www.w3.org/TR/html5/syntax.html#character-references . If HtmlEncode could be updated to never output the character reference of the carriage return that would mean when the text in my example was encoded html would be valid.

Closed Issue: Carriage return encoded as numeric character reference in textbox [19074]

bdorrans — Tue, 18 Dec 2012 19:24:34 GMT

It is still a web forms bug, rather than an AntiXSS bug. AntiXSS doesn't know who is calling it. It emits correct encoding for non-textbox value HTML encoding, so without adding another HtmlForTextBoxEncode, or adding a Boolean, and then changing web forms, any change would veer from the spec.

I've punted this over to the webforms folks, but I'm closing it as not a bug.

Reopened Issue: Carriage return encoded as numeric character reference in textbox [19074]

sean986 — Tue, 18 Dec 2012 11:31:12 GMT

Commented Issue: Carriage return encoded as numeric character reference in textbox [19074]

sean986 — Tue, 18 Dec 2012 10:40:16 GMT

Thank you for the swift reply. The page already had controlRenderingCompatibilityVersion set to 4.5. I tried reverting to controlRenderingCompatibilityVersion 4.0 and this added an extra line break to the mark up and encoded it which made the problem even worse (see attached file).

If the encoding type is not set to the AntiXssEncoder then the line breaks are not encoded so the page renders as valid HTML5 (see attached file).

Closed Issue: Carriage return encoded as numeric character reference in textbox [19074]

bdorrans — Mon, 17 Dec 2012 17:07:09 GMT

This is, I'm afraid, a known webforms bug.

You can get the correct behavior by reverting how webforms renders. You do this by setting the following web.config attribute on the pages element;

You can read more about this setting at http://msdn.microsoft.com/en-us/library/system.web.configuration.pagessection.controlrenderingcompatibilityversion.aspx

Created Issue: Carriage return encoded as numeric character reference in textbox [19074]

sean986 — Mon, 17 Dec 2012 16:00:23 GMT

I have set the encoderType to "System.Web.Security.AntiXss.AntiXssEncoder,System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" for my project which is a simple ASP .NET 4.5 web forms project. When I include new lines in a text box like this:

Line1
Line2

It renders as

<textarea rows=2 cols=20 id=MainContent_txt>

Line1
Line2
</textarea>

which is incorrect HTML5 according to http://validator.w3.org/

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

brentonw — Tue, 07 Aug 2012 08:00:26 GMT

I've reached out the the project coordinator several times with no response. I also reached out to ScottGu at Microsoft who put me in touch with some folks on his team. I exchanged a few emails with them, however, they did not have an update as to when this would be fixed. Perhaps if more people voice their concern directly to Microsoft someone will address this.

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

robstrange — Thu, 02 Aug 2012 00:04:28 GMT

This is unacceptable. The prior version has security vulnerabilities and the new version strips out all of the HTML. This thread is going on 8 months and there still isn't a resolution or updated patch.

version 3 and 4 vulnerabilities:
http://www.securityfocus.com/bid/51291/discuss

Created Issue: Ajax HtmlEditorExtender not working properly in IE-10. [18340]

saurav_kumar — Tue, 10 Jul 2012 02:35:33 GMT

Whenever i try to upload image in htmleditorextender in IE 10 it hangs up on 1% or stops working another issue is when i press enter for new line, new line goes too far from current cursor position.

Created Issue: AntiXSS Sanitizer removes html
and
tags from AjaxControlToolkit HtmlEditorExtender generated html. [18339]

saurav_kumar — Tue, 10 Jul 2012 02:28:21 GMT

I have added a Htmleditorextender ajax control to my asp.net web application with putting XSS sanitizer in it for XSS security but now when I retrieve the text from Htmleditorextender the sanitizer removes 
from it and all input comes in a single line. Now i am using htmleditorextender by making EnableSanitization="false". This issue appears only in firefox, not in safari and chrome, in both everything works fine because they use <div> for new paragraphs and line breaks but when i hit enter in htmleditor in firefox a tag is created and on submission of html text all tags gets removed by sanitizer and that's why new line break is not appearing in firefox.

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

i8beef — Wed, 06 Jun 2012 21:53:22 GMT

Can we change "Impact" on this item to high? This pretty much makes this part of the library completely unusable...

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

alexcheveau — Mon, 14 May 2012 10:50:31 GMT

Where are the validation before the release of the ToolKit? Very disappointing...

wpl Issue Tracker Rss Feed

Closed Issue: SupressAntiXssEncoding Not working [10091]

Closed Issue: Medium Trust AntiXss.GetSafeHtmlFragment [13681]

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

Commented Issue: Carriage return encoded as numeric character reference [19074]

Commented Issue: Carriage return encoded as numeric character reference [19074]

Commented Issue: Carriage return encoded as numeric character reference [19074]

Reopened Issue: Carriage return encoded as numeric character reference in textbox [19074]

Closed Issue: Carriage return encoded as numeric character reference in textbox [19074]

Reopened Issue: Carriage return encoded as numeric character reference in textbox [19074]

Commented Issue: Carriage return encoded as numeric character reference in textbox [19074]

Closed Issue: Carriage return encoded as numeric character reference in textbox [19074]

Created Issue: Carriage return encoded as numeric character reference in textbox [19074]

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

Created Issue: Ajax HtmlEditorExtender not working properly in IE-10. [18340]

Created Issue: AntiXSS Sanitizer removes html and tags from AjaxControlToolkit HtmlEditorExtender generated html. [18339]

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

Commented Issue: GetSafeHtmlFragment replacing all html tags [17246]

Created Issue: AntiXSS Sanitizer removes html
and
tags from AjaxControlToolkit HtmlEditorExtender generated html. [18339]