I encoded an html text property using javascript and pass it into my database as such. I mean the javascript for string like "Wales&PALS"

encodeURIComponent(e.value);

converted to "Wales%20PALS"

I want to convert it back to "Wales&PALS" from asp. Any idea on how to embed

decodeURIComponent(datatablevalues) 

in my asp function to return the desired text?

I encoded an html text property using javascript and pass it into my database as such. I mean the javascript for string like "Wales&PALS"

encodeURIComponent(e.value);

converted to "Wales%20PALS"

I want to convert it back to "Wales&PALS" from asp. Any idea on how to embed

decodeURIComponent(datatablevalues) 

in my asp function to return the desired text?

• javascript
• asp

• Care to share your logic behind this decision? What's the point in encoding a string like this? You're adding yourself an unnecessary work... Encoding is fine, but you should know WHY and WHEN to do it. In your case it's pletely useless... – walther Commented Apr 3, 2013 at 18:19
• I decide to encode to allow users add special characters to their inputs. But before I can pass that into my database, I need to encode it to prevent code injection. Do you know any better way? Please share. – Peter Commented Apr 3, 2013 at 18:25
• As a prevention for SQL injection we use parametrized queries or stored procedures. Encoding isn't really suitable for that. Html encoding is nice if you expect your users to add stuff to your website and you want to prevent them injecting malicious javascript for instance. By encoding the string the browser would just print out the contents. What you're doing is that you encode the string, add it to the database, but then you try to decode it back to the original state and display it for the clients. That way you're vulnerable to many kinds of javascript injections... – walther Commented Apr 3, 2013 at 18:30
• Great, I appreciate your response. I used parameterized queries in my insertion. The thing is, I want to display the string back to the user the same way he input it. I'm still more of newbie in web technology, if you think it will make the application vulnerable to javascript injections, I guess I'll just leave it without decoding it. Still I'll appreciate your take on that. – Peter Commented Apr 3, 2013 at 18:46
• See my answer, I've tried to elaborate on the topic a little bit more. I'm not perfect or all-knowing by any means, I'm just trying to make sure that if people do decisions like this that involve webs security, that they know "how, when and why" to do it. If you're sure it's perfectly safe this way, good, don't let others fool you :) But if not, I'd suggest you to do some research for your own good. Good luck. – walther Commented Apr 3, 2013 at 18:51

2 Answers 2

As a prevention for SQL injection we use parametrized queries or stored procedures. Encoding isn't really suitable for that. Html encoding is nice if you expect your users to add stuff to your website and you want to prevent them injecting malicious javascript for instance. By encoding the string the browser would just print out the contents. What you're doing is that you encode the string, add it to the database, but then you try to decode it back to the original state and display it for the clients. That way you're vulnerable to many kinds of javascript injections..

If that's what you intended, no problem, just be aware of the consequences. Know "why" and "how" every time you make a decision like this. It's kinda dangerous.

For instance, if you wanted to enable your users to add html tags as a means of enhancing the inserted content, a more secure alternative for this would be to create your own set of tags (or use an existing one like BBCode), so the input never contains any html markup and when you insert it into the database, simply parse it first to switch to real html tags. Asp engine will never allow malicious input during a request (unless you voluntarily force it do so) and because you already control parsing the input, you can be sure it's secure when you output it, so there's no need for some additional processing.

Just an idea for you :)

If you really insist on doing it your way (encode -> db -> decode -> output), we have some options how to do that. I'll show you one example:

For instance you could create a new get-only property, that would return your decoded data. (you will still maintain the original encoded data if you need to). Something like this:

public string DecodedData
{
   get
   {
       return HttpUtility.UrlDecode(originalData);
   }
}

http://msdn.microsoft./en-us/library/system.web.httputility.aspx

If you're trying to encode a html input, maybe you'd be better off with a different encoding mechanism. Not sure if javascripts encodeURIComponent can correctly parse out html.

Try UrlDecode in HttpServerUtility. API page for it