I am facing an XSS vulnerability in my ASP.Net Web application where the malicious code may be encrypted and html encoded
Bottomline: I am trying to prevent XSS via code obfuscation.

Question: I already know that I have to use HtmlDecode anyway.Is there a way to decrypt and then Html decode such data in ASP.Net?

  • 1
    What do you mean with Decoding plus decryption of a possible set of encodings? Encryption != Encoding (like Base64). Write a method that detects in what encoding is the payload sent and decode it, what's the problem?
    – TildalWave
    Jun 8 '14 at 2:12
  • 1
    "trying to prevent XSS via code obfuscation" doesn't work. It's too easy to make opaque predicates for you to be able to deobfuscate code and there are too many ways to reflectively designate powerful properties in web programming languages for to keep a determined attacker away from sources of authority. The only ways to protect against XSS are to statically white-list known-safe constructs or to sandbox so you can dynamically vet operators. Jun 8 '14 at 11:28

First: Base64 is NOT an encryption algorithm. It's an encoding mechanism i.e: Anybody can decode your encoded data.

Secondly: If you're facing XSS in your ASP app that means you're not sanitizing a user-influenced input properly. You will need to provide us with more details about the piece of code that is influenced by the user, but generally. you need to encode all input in html. That is:

" ----> "
' ----> '
< ----> &lt;
> ----> &gt;

In ASP you can simply use Server.HTMLEncode(string) to HTML-encode your user-influenced input.

Remember XSS can also be triggered from stored input, so you will need to sanitize those too!

  • I am encountering Reflected XSS when an attacker is intercepting a plain request xml. The only way for the attack to work is if the payload is decoded when injected. The only acceptable solution in my case is to decode the complete request before it is parsed. User input is already sanitized so no foul play there. Hope that makes sense.
    – KatariaA
    Jun 9 '14 at 5:51
  • 1
    @AsK It would appear you're severely misunderstanding how XSS protection should be implemented. User-supplied data should only be HTML escaped upon output, not input. That means you are not supposed to escape incoming data, but only escape it any time the server is outputting something to a client. This would fix your current problem and many other potential security and double-escaping problems. See: stackoverflow.com/a/13878047
    – Anorov
    Jun 9 '14 at 13:05

Obfuscation will only get you so far. You'll have people who'll give up because it's hard, and some will like the challenge. The problem with obfuscation is that you'll attract the latter, since you're actively trying to prevent it from happening without really fixing the issue.

Just to be really anal about it, you're not "preventing it", you're making it more difficult. It's like putting the key of a door under a mat instead of a fake rock.

Not the answer you're looking for? Browse other questions tagged or ask your own question.