MWhitby (Community Member) asked a question.
I'm moving an XML tag into a simple asp.net text box.
<Name> Dog & Sud's </Name>
I want to display as "Merchant Name: Dog & Sud's" in a simple asp.net label.
I have to call HtmlEncode to avoid CWE 80, but then it displays as the XML tag..
Not a professional way to display out to your customers.
So I have a bunch of replace statements after the call to HtmlEncode:
string v0 = queryXmlMessage("Name"); // our own function
string v1 = WebUtility.HtmlEncode(v0);
v1 = v1.Replace("&", "&");
v1 = v1.Replace("'", "'");
return v1;
But then I get again, 365 CWE 80's again as we have to call this...365 times...go figure.
I do NOT want to purchase some veracode class to sanitize this as I should be able to do this with simple C# code and MS functions.
This is not rocket science. How do you move a simple XML field into an asp.net label or textbox without CWE 80?
.png){kind=logo}
Hi @MWhitby (Community Member) ,
The primary defence against CWE 80 Basic XSS is HTML encoding any data that is placed in an ASP label as this control does not do any automatic encoding. Veracode Static Analysis will detect use of Supported Cleansing Functions ( https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/IiF_rOE79ANbwnZwreSPGA ) and will automatically close flaws where this is used appropriately. Unfortunately, doing string replacements after encoding may weaken the encoding so we will not consider this remediated.
In your example, if you're fetching data from an XML document that is already encoded, you should decode it first, ideally with an XML decode function.
Modified example:
string xmlEncoded = queryXmlMessage("Name"); // our own function
string unencoded = WebUtility.HtmlDecode(xmlEncoded); // decode XML data to turn & back into &
string htmlEncoded = WebUtility.HtmlEncode(unencoded); // encode for HTML to turn & back into &
return v2;
Well, you might think, this is silly, I need to decode and then encode?
Strictly speaking if the input document is guaranteed to be in encoded format, the input would be the same as the output.
But it's much better to not rely on that guarantee and assume the input document could contain anything.
This way, even the system changes in the future, you will still be safe.
Thank you,
Boy Baukema