Re: Storage of html markup code in database
From: Nicole Calinoiu (calinoiu)
Date: 10/08/04
- Next message: Nicole Calinoiu: "Re: Permissions"
- Previous message: Trevor Barry: "Encrypt with .Net, decrypt with Crypto API?"
- In reply to: Shabam: "Storage of html markup code in database"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 8 Oct 2004 08:01:19 -0400
This is not usually a particularly good idea for a few reasons. The biggest
problems are the following:
1. The web UI may not be (now or at some time in the future) the only
interface via which the data is read. The stored HTML-encoding will lead to
rendering annoyances when the data is displayed elsewhere. These alternate
UIs may include reports and database management tools, not just other
applications created for end-users.
2. Modifying the stored string representations will interfere with
searching the database. Of course, you could also HTML-encode all search
terms, but that gets even uglier if you consider the possibility of
alternate consumers of the data.
3. This only works if all data is entered via a UI that HTML-encodes the
data prior to saving. However, regardless of any additional protections you
might want to put into place (aside from some that are even more work than
the render-time encoding you are trying to avoid), the dba is going to be
able to edit the data directly, thereby bypassing your protection.
4. The details of your desired HTML-encoding may change over time. They
may also differ between display locations within your application. (e.g.: A
given string may be displayed with line breaks replaced by "<br>" tags on a
given page where there is a lot of vertical room for the text, but line
breaks might be suppressed when the same text is displayed as a single item
in a long list on another page.) If you store the pre-encoded text,
changing it either over time or space will be more difficult.
That said, ASP.NET provides a relatively convenient environment (at least as
compared to standard ASP <g>) in which to ensure that you use render-time
HTML-encoding. While it's unfortunate that the built-in controls are not
more consistent with respect to applying encoding during rendering, it's
relatively trivial to inherit from these controls in order to create new
controls that behave the way you might prefer. If you then want to ensure
that you consistently use your modified controls rather than the built-in
controls, it might be worth considering running FxCop with a custom rule
that screens for use of the built-in controls.
HTH,
Nicole
"Shabam" <blislecp@hotmail.com> wrote in message
news:A8KdnTmQHcIJ_PjcRVn-qA@adelphia.com...
>I have an application that needs to fetch client data from the database and
> show them on a web page. However, I don't want clients to inject html
> into
> any web pages so I've decided to change all instances of "<" to "<" and
> ">" to ">".
>
> However, having to convert those strings dynamically every time a page is
> to
> be displayed is rather tedious, and I may miss something down the line.
>
> So, I'm thinking that every time user data is received, the html markup
> tags
> are translated and stored in the database that way. That way when it
> comes
> time to display, no dynamic code is needed to translate them.
>
> What are your thoughts on this?
>
>
- Next message: Nicole Calinoiu: "Re: Permissions"
- Previous message: Trevor Barry: "Encrypt with .Net, decrypt with Crypto API?"
- In reply to: Shabam: "Storage of html markup code in database"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
