I have an input, which displays a value (Firstname) in a box on the page. On the server side, the input is escaped by following rule (vb.net):

Public Function UnescapeString(strValue As String) As String
    If (String.IsNullOrEmpty(strValue)) Then Return strValue
    strValue = Replace$(strValue, """", "")
    strValue = Replace$(strValue, "'", "")
    strValue = Replace$(strValue, "<", "")
    strValue = Replace$(strValue, ">", "")
    Return strValue
End Function

The output isn't validated at all.

I can't believe escaping input from <> could be this safe as it feels for me!?

Are there tricks to inject code or is the most major thing to prevent XSS here, to cut out or escape <> signs?

Question 2: I am planning a rewrite of this method like this:

   strValue = Replace$(strValue, """", "&quot;")
   strValue = Replace$(strValue, "<", "&lt;")
   strValue = Replace$(strValue, ">", "&gt;")
   strValue = Replace$(strValue, "&", "&amp;")
   strValue = Replace$(strValue, "'", "&#x27;")
   strValue = Replace$(strValue, "/", "&#x2F;")
   strValue = System.Web.HttpUtility.HtmlEncode(strValue) <- or only this

I'm planning not to cut out, but escape values properly, like in the example above. Or I just use .NET's HtmlEncode (last line), which even encodes special characters like German umlauts, as well as dangerous signs like <>"'/.

  • have a look at this article: owasp.org/index.php/…
    – sir_k
    Sep 7, 2018 at 13:33
  • there are a LOT of quetions here on XSS filters
    – schroeder
    Sep 7, 2018 at 13:36
  • The correct XSS protection depends a lot on the output context. Also, you should usually prefer methods provided by your language/framework over custom functions. In modern code there is rarely any need to spell out < in order to prevent XSS.
    – Arminius
    Sep 7, 2018 at 14:00
  • It seems like you didn't get the question. I know the OWASP pages, and there is no anwser. Though there is a lot about XSS in general, but the explicit question is how to bypass < > escaping.
    – Timbo
    Sep 10, 2018 at 6:33

1 Answer 1


The problem is you can use other encoding like base64 which may get processed by you browser to create a successful XSS, use HttpContext.Current.Server.HtmlEncode() instead.


$ echo '<script>' | base64 
$echo PHNjcmlwdD4K | base64 -D

Javascript example:

 var decodedData=window.atob('PGlmcmFtZSBzcmM9L3hzcy9iYXNlLmh0bWwgd2lkdGg9MTAwJSBoZWlnaHQ9MTAwJT48L2lmcmFtZT4K');

Iframe example:


Additional point, you may not be maintaining this code for the life of the code, a new exploit could possibly get around your filter, hopefully the maintainers of .NET would issue an update that addresses that and is applied by sys admins.

  • in what context is base64 data interpreted as html code?
    – dandavis
    Sep 7, 2018 at 15:20
  • I'll add two examples in a the answer above as it doesn't fit well in a comment.
    – Joe M
    Sep 7, 2018 at 20:09
  • the JS example is contrived, that data handling is never going to happen in the wild like attrib takeovers do. XSS implies not just evading filters, but also not having help from the site; you're suggesting user input is injected into a dynamic JS file, which is not common in the age of JSON APIs. The iframe example is much more feasible, but should also be harmless do to the SOP's restrictions of cross-protocol access.
    – dandavis
    Sep 7, 2018 at 21:20
  • Hey Dan - Anytime a user can insert data in to a form, assign to a variable, be printed out by code you have the chance for XSS. Alas we will have to agree to disagree. Cheers, -Joe
    – Joe M
    Sep 8, 2018 at 2:17
  • 1
    Thanks for your example, but it doesn't fit into this scenario. Just saying that you could use base64 encoding in src/href/value/... tags, doesn't fit to the question, I already knew this.
    – Timbo
    Sep 10, 2018 at 6:40

Not the answer you're looking for? Browse other questions tagged .