Hash character encoded into %23

Jan 16, 2012 at 5:06 PM

I've just started using AntiXss 4.2.1 and I'm finding that it's encoding hyperlinks that include the hash character in anchor tags.

i.e. http//www.website.com/page.htm#section1 gets encoded into http//www.website.com/page.htm%23section1, which obviously cannot be found. I've googled this issue but not found anything. I can't believe no-one has had this problem before! Or am I missing something?? Should the hash character not be treated as being safe?

I've added my reference to 4.2.1 and added the following to web.config

<httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" .... />

Jan 16, 2012 at 5:07 PM

Hmm, how are you outputting the anchors? WebForms? MVC? I need a bit more information to go on

Jan 16, 2012 at 5:40 PM


After a little more tinkering I found that it only occurs when I use relative urls using ~


<a runat="server" href="~/page.aspx#section" />

<asp:Hyperlink runat="server" NavigateUrl="~/page.aspx#section">link<asp:Hyperlink>

Both have the same result.... %23

Absolute URLs seem ok.

Jan 16, 2012 at 5:42 PM

Thanks - I'll go talk to the webforms folks. This may take a while.

Jan 16, 2012 at 6:16 PM

OK this is a bug. I'll co-ordinate a new release hopefully this week.

Jan 16, 2012 at 7:48 PM


Jan 22, 2012 at 10:29 PM

Same here. It killed all the links in my Web Forms app, replacing links with "%23" :(

This is a show stopper bug for me and I second getting this fixed fast.



Jan 22, 2012 at 10:42 PM

For now don't use web.config to swap out the encoder - or are you seeing this without configuring AntiXSS via web.config?

Feb 1, 2012 at 10:59 PM

This was in web.Config, so I just removed it for now.

Fingers crossed there's a quick and easy fix. Will be much appreciated :)



Jul 18, 2012 at 7:47 PM

I am also having same issue. Is there any resolutions or workaround for this?

Jul 19, 2012 at 7:08 PM

Soon. Kinda of.

The underlying problem lies within some asp.net controls using url encoding incorrectly. The ASP.NET folks have been trying to track them all down and that's still ongoing.

The fix actually syncs the url encode with the .NET framework version, and as such uses code from the .NET framework. However that code is not open source, and we've been working with the legal folks to address this. What with the VS2012 beta releases this hasn't been at the top of everyone's mind, but now that has shipped we're pushing forward again and hope to get signoff within a few weeks.

Once I have that you'll see a new version of the encoders up which will address the issue.

Sorry it's taken so long.