Does escaping/cutting of <> prevents you from XSS [duplicate]

Question

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, """", """)
   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 <>"'/.

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.

Example:

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

Javascript example:

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

Iframe example:

src=data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4K

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.