bleroy, maybe this is his reason:
Use Server.HTMLEncode for strings stored in a database
If your ASP pages display strings stored in database fields, you should always process the strings with the Server.HTMLEncode method, otherwise the string won't be displayed correctly in the user's browser if it contains characters that have a special meaning to HTML, such as the quote ("), the less-than (<) and greater-than (>) symbols, the ampersand symbol (&), and any character whose ANSI code is larger than 127.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q253119
recommends using Server.HTMLEncode from forms and querystrings:
HOWTO: Review ASP Code for CSSI Vulnerability
This article describes how to identify and correct Active Server Pages (ASP) applications that are susceptible to Cross-Site Scripting Security Issues (CSSI). Only input that is not correctly validated or formatted makes your application vulnerable to attack.
You both are beside the point here.
Encoding before sending TO the database and decoding what comes FROM the database is absolutely useless. The database won't suffer from any javascript injections, believe me. Sql injections, perhaps, but X-site scripting, no way.
These papers explain how you should encode any data FROM THE USER TO THE PAGE.
So if you're storing user data to the database, you may encode it at this point or when fetching it back from the database, but don't DECODE what comes from the database before sending it to the client.
It's the "and of course [?] I use Server.HTMLDecode before displaying it or presenting the data back to the user for editing" from the original post that is utterly wrong.
> Encoding before sending TO the database and decoding what comes FROM the database is absolutely useless.
> These papers explain how you should encode any data FROM THE USER TO THE PAGE.
What is stored in the database (from the user) will be displayed on the page. Is is still wrong?
0 comments:
Post a Comment