Re: regex challenged

What Moritz says about using a placeholder is definitely the way to go vis. avoiding SQL injection.

If you want a simple way to make it HTML safe, you can do that before you put it in the DB or after, when you take it out and want to use it in a page (depending what else is done with the data). There are lots of modules, etc, for doing this but the major issue is the < and >, and ' if you use javascript:

$string =~ s/</&lt;/g;
$string =~ s/>/&gt;/g;
$string =~ s/'/&#39;/g;
[download]

Hopefully you recognize what that is for. There is a chart of all HTML "escape" codes at http://www.lookuptables.com/

Comment on Re: regex challenged Download Code

Replies are listed 'Best First'.
Re^2: regex challenged by dsheroh (Monsignor) on Oct 08, 2009 at 07:25 UTC
How is your advice regarding HTML safety poor? Let me count the ways: It's best to clean up your data both before and after. Before storing the data, you need to clean it up enough to make it safe to store. (In many cases, this can be skipped in favor of using parametrized queries (placeholders).) Cleanup for display needs to be done immediately prior to display because, if you only clean up the HTML before storing it and a new exploit is discovered next week, the data already in your database may still contain that exploit. Doing this cleanup on display is the only way to ensure that all current cleanup will be performed on older data. (Pre-cleaning before storage isn't a bad thing, but it is not sufficient by itself.) `<` and `>` are major issues even if you don't use javascript. `<iframe src='http://rogue.com/path/to/exploit.html'></iframe>`, for example. Your set of suggested regexes take a blacklisting approach ("block these three specific characters") which, by its very nature, is susceptible to letting potential dangers slip through. It's much better to go with whitelisting ("this set of characters are known (or at least believed) to be safe; block everything else") in the general case or to use a proper HTML escaping function in the specific case of handling HTML output.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: regex challenged
by dsheroh (Monsignor) on Oct 08, 2009 at 07:25 UTC

It's best to clean up your data both before and after. Before storing the data, you need to clean it up enough to make it safe to store. (In many cases, this can be skipped in favor of using parametrized queries (placeholders).)
Cleanup for display needs to be done immediately prior to display because, if you only clean up the HTML before storing it and a new exploit is discovered next week, the data already in your database may still contain that exploit. Doing this cleanup on display is the only way to ensure that all current cleanup will be performed on older data. (Pre-cleaning before storage isn't a bad thing, but it is not sufficient by itself.)
< and > are major issues even if you don't use javascript. <iframe src='http://rogue.com/path/to/exploit.html'></iframe>, for example.
Your set of suggested regexes take a blacklisting approach ("block these three specific characters") which, by its very nature, is susceptible to letting potential dangers slip through. It's much better to go with whitelisting ("this set of characters are known (or at least believed) to be safe; block everything else") in the general case or to use a proper HTML escaping function in the specific case of handling HTML output.

[reply]
[d/l]
[select]