Hello Octavian, please configure your mailer to quote messages properly. Currently, it seems like you have written my reply.
On Sun, 2 Oct 2011 19:14:00 +0300 "Octavian Rasnita" <orasn...@gmail.com> 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... What kind of “variable elements which can't be inserted using placeholders” are you referring to? > > 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. You're right about that. > 2. For the variables used in SQL code like where name in( ... ) or "where > name like "..." the variables should be always escaped using... Doesn't the SQL IN clause accepts a list? Therefore, can't you pass an array reference placeholder using DBI? Regarding the LIKE clause this is a complex problem. I think we coded a hacky solution for it in https://github.com/shlomif/catable/tree , but I'm not sure I can recommend it. > 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. For that case, the answer is that you shouldn't let the user directly dictate such things. You can let him indirectly pick from a few options, but never insert user input directly into the SQL like that. > > 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', No, it won't. This is dangerous. > > but I am not sure if the variable $foo will be escaped in the following > example: > order_by => {-desc => $foo, Well, make sure $foo contains a valid column name, and that the user does not affect it directly. Regards, Shlomi Fish -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ Best Introductory Programming Language - http://shlom.in/intro-lang Mastering ‘cat’ is almost as difficult as herding cats. — http://www.shlomifish.org/humour/bits/Mastering-Cat/ Please reply to list if it's a mailing list post - http://shlom.in/reply . -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
