Date: Fri, 4 Jul 2003 08:23:03 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: JacobRhoden <jrhoden@unimelb.edu.au> Cc: Matt Heath <matt@thebigchoice.com> Subject: Re: Which server-side programming should i choose. Message-ID: <20030704072303.GA69059@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <200307041026.47024.jrhoden@unimelb.edu.au> References: <20030702201929.79497.qmail@web12604.mail.yahoo.com> <07e301c340ec$1159e770$1b41d5cc@nitanjared> <3F03FB8A.9080700@thebigchoice.com> <200307041026.47024.jrhoden@unimelb.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 04, 2003 at 10:26:47AM +1000, JacobRhoden wrote:
> Even though this is getting waaay off topic...
>=20
> On Thu, 3 Jul 2003 07:46 pm, Matt Heath wrote:
> > Ever seen something like this :
> > $r =3D mysql_execute("select * from table_1 where id=3D$_GET[id];");
>=20
> Actually people do do the same thing and perl and you know it :P Both per=
l and=20
> php support calling sql with parameters using ? to insert variables. If=
=20
> someone does not know what language to use at all, I would suggest php si=
mply=20
> because its a good, quick, easy language to get started in without too mu=
ch=20
> difficulty. (In lots of ways including not needing to understand cgi=20
> variables, and what the heck Content-type: text/html\n\n is, or learning =
how=20
> to include perl librarys to do all that stuff for you!)=20
You're missing the point. $_GET[id] is one of the arguments used when
calling the PHP and as such is completely under the control of an
external user. This permits all sorts of shenanigans that generally
go under the name "SQL injection attacks". For instance, in this
case, if you could arange for the $_GET[id] variable to have the value
'joe OR 1=3D1' then you could dump out the whole of table_1. I'm sure
that with a little thought you could come up with something much more
damaging.
Exactly the same problem occurs with perl CGI --- any time you take
user input in an application, you've got to assume that there will be
hostile intent, and sanitize the input accordingly. The basic step in
sanitization is to decide what characters are permitted in the input,
and filter out everything else. You probably want to limit the length
of the input, and (depending on the precise circumstances) there may
be other criterea you can apply. Only then should you pass the input
into your SQL select statement.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE/BStXdtESqEQa7a0RAgvOAJ9hQB3a7AUZtbFQMN4ITilZYIZQFACffhmr
a3EIoIUGrU69B6rZWqTEV6c=
=L+gg
-----END PGP SIGNATURE-----
--wRRV7LY7NUeQGEoC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030704072303.GA69059>