Validating input

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.

I know a lot of theory but without practical examples.

Is it enough to use binding parameters in DBI for avoiding SQL =
injections? I mean, if I always use binding parameters, it is OK if I =
don't use any other kind of filtering? If it is not enough, what kind of =
SQL code can still damage the DB?

And if I need to filter, what kind of filter I need to apply?

I know that the code will be secure if I will allow only A-Za-z0-9 and =
spaces, but in some form fields I need to allow every character. If =
there are some well defined types of SQL injection codes, are there some =
patterns that can be used for filtering?

Thanks.

Octavian


--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: Validating input

On Sun, 2 Oct 2011 00:07:34 +0300
"Octavian Rasnita" wrote:

> Hi,
>=20
> 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.
>=20

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

> I know a lot of theory but without practical examples.
>=20
> Is it enough to use binding parameters in DBI for avoiding SQL injections=
? I mean, if I always use binding parameters, it is OK if I don't use any o=
ther kind of filtering? If it is not enough, what kind of SQL code can stil=
l damage the DB?

By binding parameters, you probably mean placeholders and that should be
enough in most cases (assuming you are careful enough):

http://bobby-tables.com/

One possible vector of problem is the SQL â€=9CLIKEâ€=9D operator w=
here people
can inject "%" in.

>=20
> And if I need to filter, what kind of filter I need to apply?
>=20

You don't need to filter if you're using placeholders.

> I know that the code will be secure if I will allow only A-Za-z0-9 and sp=
aces, but in some form fields I need to allow every character. If there are=
some well defined types of SQL injection codes, are there some patterns th=
at can be used for filtering?

Just use placeholders.

Regards,

Shlomi Fish

>=20
> Thanks.
>=20
> Octavian
>=20
>=20



--=20
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
"Humanity" - Parody of Modern Life - http://shlom.in/humanity

When Chuck Norris uses git, he takes a coffee break after initiating every =
git=20
commit. And then he waits for the commit to finish.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: Validating input

From: "Shlomi Fish"

On Sun, 2 Oct 2011 00:07:34 +0300
"Octavian Rasnita" wrote:

> Hi,
>=20
> 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.
>=20

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 =3D> { "-$direction" =3D> 'column_name',

but I am not sure if the variable $foo will be escaped in the following =
example:
order_by =3D> {-desc =3D> $foo,

Octavian


--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: Validating input

On Sun, Oct 02, 2011 at 07:14:00PM +0300, Octavian Rasnita wrote:
> From: "Shlomi Fish"
>
> On Sun, 2 Oct 2011 00:07:34 +0300
> "Octavian Rasnita" 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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: Validating input

On 11-10-02 02:44 PM, 'lesleyb' wrote:
> I also use taint mode but Scalar::Util provides a tainted function. Not sure
> which of these is recommended.

You have to run with -T or tainted() will always return false.


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

"Make something worthwhile." -- Dear Hunter

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: Validating input

i think what we all now need is an extensive library of validating routines=
.. use allvalidationcode; ... ... ($new->validate($tn, phonen=
umber)) ? true : false=0A...=A0 arguments =3D varilable, variable type=0A=
i wish... ----- Original Message -----=0AFrom: 'lesleyb' <=
lesleyb@herlug.org.uk>=0ATo: beginners@perl.org=0ACc: =0ASent: Sunday, Octo=
ber 2, 2011 1:44 PM=0ASubject: Re: Validating input On Sun, Oct 02, 20=
11 at 07:14:00PM +0300, Octavian Rasnita wrote:=0A> From: "Shlomi Fish" lomif@shlomifish.org>=0A> =0A> On Sun, 2 Oct 2011 00:07:34 +0300=0A> "Octav=
ian Rasnita" wrote:=0A> =0A> > Hi,=0A> > =0A> > Does a=
nyone have some suggestions for what restrictions should be used on a site =
to be secure?=0A> > Do you know some sites where I can get information abou=
t this subject?=0A> > Most of the text I read said that the variables shoul=
d be filtered before inserting them in DB, but never gave details for what =
should be filtered.=0A> > =0A> =0A> Well, the SQL injections that you menti=
on are one vector of attack against=0A> web-sites, but are not the only one=
.. See:=0A> =0A> * http://shlomif-tech.livejournal.com/35301.html - my post =
about Code/Markup=0A>=A0 injection and its prevention.=0A> =0A> * http://e=
n.wikipedia.org/wiki/Cross-site_scripting=0A> =0A> * http://en.wikipedia.or=
g/wiki/Cross-site_request_forgery=0A> =0A> =0A> =0A> Hi Shlomi,=0A> =0A> Th=
anks for those links. I already read some of them, but on others I found li=
nks to other interesting pages.=0A> =0A> Unfortunately I found what I alrea=
dy knew... the fact that there are very many opinions, that the placeholder=
s are good, but not enough because the SQL code could contain variable elem=
ents which can't be inserted using placeholders, that it is good to use reg=
ular expressions to filter the input data, but regexp cannot be very helpfu=
l for some fields that should allow any data from user...=0A> =0A> I though=
t I will find a kind of cookbook with all the receipts for avoiding all the=
possible security issues. For example=0A> 1. For simple variables, integer=
s or strings, using placeholders is enough.=0A> 2. For the variables used i=
n SQL code like where name in( ... ) or "where name like "..." the variable=
s should be always escaped using...=0A> 3. For creating SQL identifiers lik=
e the name of the tables, the "asc" or "desc" order directions or other ide=
ntifiers which are not enclosed in single quotes should be used the method.=
...=0A> ... and so on.=0A> =0A> And it would be helpful if there would be ex=
amples for Perl, DBI and DBIx::Class and not just general ideas about SQL i=
njections with PHP code as example.=0A> =0A> I guess that the variable $dir=
ection won't be escaped in DBIx::Class if I use:=0A> order_by =3D> { "-$dir=
ection" =3D> 'column_name',=0A> =0A> but I am not sure if the variable $foo=
will be escaped in the following example:=0A> order_by =3D> {-desc =3D> $f=
oo,=0A> =0A> Octavian Hi Octavian, I always HTML-escape data and =
then 'SQL-escape' it too - which in theory=0Areduces the risk of SQL/HTML i=
njection methods. I also use taint mode but Scalar::Util provides a ta=
inted function.=A0 Not sure=0Awhich of these is recommended.=A0 http://mart=
in-evans.me.uk/node/72 indicates a=0Apossible speed issue with tainting dat=
a. Regards Lesley =0A-- =0ATo unsubscribe, e-mail: beg=
inners-unsubscribe@perl.org=0AFor additional commands, e-mail: beginners-he=
lp@perl.org=0Ahttp://learn.perl.org/

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: Validating input

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" wrote:

> From: "Shlomi Fish"
>=20
> On Sun, 2 Oct 2011 00:07:34 +0300
> "Octavian Rasnita" wrote:
>=20
> > Hi,
> >=20
> > 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 befo=
re inserting them in DB, but never gave details for what should be filtered.
> >=20
>=20
> Well, the SQL injections that you mention are one vector of attack against
> web-sites, but are not the only one. See:
>=20
> * http://shlomif-tech.livejournal.com/35301.html - my post about Code/Mar=
kup
> injection and its prevention.
>=20
> * http://en.wikipedia.org/wiki/Cross-site_scripting
>=20
> * http://en.wikipedia.org/wiki/Cross-site_request_forgery
>=20
>=20
>=20
> Hi Shlomi,
>=20
> Thanks for those links. I already read some of them, but on others I foun=
d links to other interesting pages.
>=20
> 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 plac=
eholders, that it is good to use regular expressions to filter the input da=
ta, but regexp cannot be very helpful for some fields that should allow any=
data from user...

What kind of â€=9Cvariable elements which can't be inserted using place=
holdersâ€=9D
are you referring to?

>=20
> I thought I will find a kind of cookbook with all the receipts for avoidi=
ng all the possible security issues. For example
> 1. For simple variables, integers or strings, using placeholders is enoug=
h.

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 hac=
ky
solution for it in https://github.com/shlomif/catable/tree , but I'm not su=
re
I can recommend it.=20

> 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 sin=
gle quotes should be used the method...
> ... and so on.

For that case, the answer is that you shouldn't let the user directly dicta=
te
such things. You can let him indirectly pick from a few options, but never
insert user input directly into the SQL like that.

>=20
> 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 ex=
ample.
>=20
> I guess that the variable $direction won't be escaped in DBIx::Class if I=
use:
> order_by =3D> { "-$direction" =3D> 'column_name',

No, it won't. This is dangerous.

>=20
> but I am not sure if the variable $foo will be escaped in the following e=
xample:
> order_by =3D> {-desc =3D> $foo,

Well, make sure $foo contains a valid column name, and that the user does n=
ot
affect it directly.

Regards,

Shlomi Fish

--=20
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
Best Introductory Programming Language - http://shlom.in/intro-lang

Mastering â€=98catâ€=99 is almost as difficult as herding cats.
â€=94 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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: Validating input

On Sun, Oct 2, 2011 at 02:32, Shlomi Fish wrote:
> On Sun, 2 Oct 2011 00:07:34 +0300
> "Octavian Rasnita" wrote:
>
>> Hi,
>>
>> Does anyone have some suggestions for what restrictions should be used o=
n 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 befor=
e 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 agains=
t
> web-sites, but are not the only one. See:
>
> * http://shlomif-tech.livejournal.com/35301.html - my post about Code/Mar=
kup
> =A0injection and its prevention.
>
> * http://en.wikipedia.org/wiki/Cross-site_scripting
>
> * http://en.wikipedia.org/wiki/Cross-site_request_forgery
>

since we're on web security, my favorite general purpose reading is:
http://code.google.com/p/browsersec/wiki/Main

also this (which iirc, some browsers don't or google say are dangerous
- there doesn't seem to be any script running on this page - cursory
look):
http://ha.ckers.org/xss.html

ps - i like that 'bobby tables' link - that's just awesome :)
i like the run down they give of the proper way to do sql in each language.

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

RE: Validating input

From: shawn wilson

> On Sun, Oct 2, 2011 at 02:32, Shlomi Fish =
wrote:
>> On Sun, 2 Oct 2011 00:07:34 +0300
>> "Octavian Rasnita" 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
>> =A0injection and its prevention.
>>
>> * http://en.wikipedia.org/wiki/Cross-site_scripting
>>
>> * http://en.wikipedia.org/wiki/Cross-site_request_forgery
>>
>=20
> since we're on web security, my favorite general purpose reading is:
> http://code.google.com/p/browsersec/wiki/Main
>=20
> also this (which iirc, some browsers don't or google say are dangerous
> - there doesn't seem to be any script running on this page - cursory
> look):
> http://ha.ckers.org/xss.html
>=20

For general guidelines and tools, take a look at the OWASP Projects at =
.

Bob McConnell

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

RE: Validating input

--001517475b3ae870e704ae714a27
Content-Type: text/plain; charset=ISO-8859-1

On Oct 3, 2011 8:48 AM, "Bob McConnell" wrote:
>
> From: shawn wilson
>
> > On Sun, Oct 2, 2011 at 02:32, Shlomi Fish
wrote:
> >> On Sun, 2 Oct 2011 00:07:34 +0300
> >> "Octavian Rasnita" 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
> >>
> >
> > since we're on web security, my favorite general purpose reading is:
> > http://code.google.com/p/browsersec/wiki/Main
> >
> > also this (which iirc, some browsers don't or google say are dangerous
> > - there doesn't seem to be any script running on this page - cursory
> > look):
> > http://ha.ckers.org/xss.html
> >
>
> For general guidelines and tools, take a look at the OWASP Projects at <
http://www.owasp.org/>.
>

Good point. I always assume that everyone has heard of the top 10 and the
like so forget to put it out there.

But, I'll just say, if you think about what you're doing and know a little
about security you'll be in the upper 50%. If you run scans, you'll be in
the upper 25%. After that it gets hard. However the point is that its not
hard to rise above the lowest hanging fruit (which isn't saying much for the
state of ecommerse in general but is good for keeping inexperienced
programmers with a little knowledge out of the ruffage).

--001517475b3ae870e704ae714a27--

RE: Validating input

From: shawn wilson

> On Oct 3, 2011 8:48 AM, "Bob McConnell" wrote:
>>
>> From: shawn wilson
>>
>> > On Sun, Oct 2, 2011 at 02:32, Shlomi Fish
wrote:
>> >> On Sun, 2 Oct 2011 00:07:34 +0300
>> >> "Octavian Rasnita" 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
>> >>
>> >
>> > since we're on web security, my favorite general purpose reading
is:
>> > http://code.google.com/p/browsersec/wiki/Main
>> >
>> > also this (which iirc, some browsers don't or google say are
dangerous
>> > - there doesn't seem to be any script running on this page -
cursory
>> > look):
>> > http://ha.ckers.org/xss.html
>> >
>>
>> For general guidelines and tools, take a look at the OWASP Projects
at
> .
>>
>=20
> Good point. I always assume that everyone has heard of the top 10 and
the
> like so forget to put it out there.
>=20
> But, I'll just say, if you think about what you're doing and know a
little
> about security you'll be in the upper 50%. If you run scans, you'll be
in
> the upper 25%. After that it gets hard. However the point is that its
not
> hard to rise above the lowest hanging fruit (which isn't saying much
for the
> state of ecommerse in general but is good for keeping inexperienced
> programmers with a little knowledge out of the ruffage).

This is exactly why I never assume anyone has read the OWASP top ten.
But even if they have, a reminder to review them once in a while isn't
going to hurt. We go a few steps further. Some of our sites process
credit cards and some of our applications need to be certified for PCI
PA-DSS. So all development and QA teams had to attend training courses
in security and get a refresher class at least once a year.

Bob McConnell

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/