i think what we all now need is an extensive library of validating routines.
use allvalidationcode; ... ... ($new->validate($tn, phonenumber)) ? true : false ... arguments = varilable, variable type i wish... ----- Original Message ----- From: 'lesleyb' <lesl...@herlug.org.uk> To: beginners@perl.org Cc: Sent: Sunday, October 2, 2011 1:44 PM Subject: Re: Validating input On Sun, Oct 02, 2011 at 07:14:00PM +0300, Octavian Rasnita wrote: > From: "Shlomi Fish" <shlo...@shlomifish.org> > > On Sun, 2 Oct 2011 00:07:34 +0300 > "Octavian Rasnita" <orasn...@gmail.com> wrote: > > > Hi, > > > > Does anyone have some suggestions for what restrictions should be used on a > > site to be secure? > > Do you know some sites where I can get information about this subject? > > Most of the text I read said that the variables should be filtered before > > inserting them in DB, but never gave details for what should be filtered. > > > > Well, the SQL injections that you mention are one vector of attack against > web-sites, but are not the only one. See: > > * http://shlomif-tech.livejournal.com/35301.html - my post about Code/Markup > injection and its prevention. > > * http://en.wikipedia.org/wiki/Cross-site_scripting > > * http://en.wikipedia.org/wiki/Cross-site_request_forgery > > > > Hi Shlomi, > > Thanks for those links. I already read some of them, but on others I found > links to other interesting pages. > > Unfortunately I found what I already knew... the fact that there are very > many opinions, that the placeholders are good, but not enough because the SQL > code could contain variable elements which can't be inserted using > placeholders, that it is good to use regular expressions to filter the input > data, but regexp cannot be very helpful for some fields that should allow any > data from user... > > I thought I will find a kind of cookbook with all the receipts for avoiding > all the possible security issues. For example > 1. For simple variables, integers or strings, using placeholders is enough. > 2. For the variables used in SQL code like where name in( ... ) or "where > name like "..." the variables should be always escaped using... > 3. For creating SQL identifiers like the name of the tables, the "asc" or > "desc" order directions or other identifiers which are not enclosed in single > quotes should be used the method... > ... and so on. > > And it would be helpful if there would be examples for Perl, DBI and > DBIx::Class and not just general ideas about SQL injections with PHP code as > example. > > I guess that the variable $direction won't be escaped in DBIx::Class if I use: > order_by => { "-$direction" => 'column_name', > > but I am not sure if the variable $foo will be escaped in the following > example: > order_by => {-desc => $foo, > > Octavian Hi Octavian, I always HTML-escape data and then 'SQL-escape' it too - which in theory reduces the risk of SQL/HTML injection methods. I also use taint mode but Scalar::Util provides a tainted function. Not sure which of these is recommended. http://martin-evans.me.uk/node/72 indicates a possible speed issue with tainting data. Regards Lesley -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/ -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/