Microsoft Web Protection Library

New Post: AntiXSS - validate JSON

nishithraval — Fri, 17 May 2013 09:33:53 GMT

hey,
Similar to this,I have a restful wcf service,where need to validate JSON and XML against the Xss.Is there anything in AntiXss ???

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

Reviewed: AntiXSS Library v4.2.1 (Apr 26, 2013)

pschrama72 — Fri, 26 Apr 2013 10:45:38 GMT

Rated 1 Stars (out of 5) - Sanitizer.GetSafeHtmlFragment is too agressive and strips perfectly safe html, rendering it pretty much useless.

Reviewed: AntiXSS Library v4.2.1 (Apr 26, 2013)

pschrama72 — Fri, 26 Apr 2013 10:45:10 GMT

Rated 1 Stars (out of 5) - Sanitizer.GetSafeHtmlFragment is too agressive and strips perfectly safe html

New Post: Where is the SecurityRuntimeEngine???

bdorrans — Thu, 18 Apr 2013 16:38:29 GMT

So if you want the SRE bits you need to compile them yourself - and they haven't been validated with Win8/2012.

Given that we helped port ModSecurity to IIS, and that's open source and has many more options available it's unlikely any further work will be done on the SRE.

New Post: Where is the SecurityRuntimeEngine???

jsp3536 — Thu, 18 Apr 2013 15:11:42 GMT

I am looking for this as well. Has this been removed?

New Post: Release Build Fails

ScottMacMaster — Fri, 12 Apr 2013 14:38:45 GMT

Everything is working fine when the configuration is set to debug. However, when I set the configuration to release the build fails. I get the following error.

SGEN : error : Could not load file or assembly 'file://\TeamFoundationServer\c$\Bin\MyDll.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

I thought maybe my dll needs to be built in release mode. So I changed that but that had no effect.

I then did a bunch as research and found 3 possible causes.

It requires full trust.

So I added '<trustLevel name="full" policyFile="internal" />' to my web.config file. This had no effect.

Maybe something in the version of IIS integrated into Visual Studio needs configured but I can't find any info on this approach.

The library is 32 bit and requires the program to be 32 bit.

I tried changing the project target for both the web app and the dll from 'Any CPU' to x86. This had no effect.

My OS is 64 bit maybe other settings need changed.

Don't use unsafe code.

The library has code that requires full trust and the new version has this in a separate assembly. I'm not sure if the unsafe code is in AntiXssLibrary.dll or HtmlSanitizationLibrary.dll but the Encode function I'm trying to use is in AntiXssLibrary.dll. So I don't know if I can exclude it by not including a dll.

Also, I briefly tried the approach of downloading the source code and removing the code but I got errors the project files couldn't be loaded when I tried opening the project.

Can someone help me get this to work?

Thanks

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.

New Post: Update on the sanitizer.

Tyrven — Wed, 30 Jan 2013 19:04:37 GMT

Reiterating programmerman's question. bdorrans, should AntiXss be considered abandoned? Obviously, .NET 4.5 covers some of the functionality, but (to my knowledge) doesn't have an equivalent to the GetSafeHtmlFragment() method. Would love to know where things stand, as we have a number of libraries that rely on MWPL.

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?)

Reviewed: AntiXSS Library v4.2.1 (Jan 28, 2013)

KalininAndrey — Mon, 28 Jan 2013 10:10:36 GMT

Rated 1 Stars (out of 5) - The only safe HTML is Plain Text! Guys, you are the best!

New Post: Update on the sanitizer.

Programmerman — Fri, 11 Jan 2013 17:31:58 GMT

It's been a year now since the WPL was patched. Do we have any further news on updating the sanitizer?

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