[13773] in bugtraq
Re: RFP2K01 - "How I hacked Packetstorm" (wwwthreads advisory)
daemon@ATHENA.MIT.EDU (Aaron Ross)
Wed Feb 9 04:24:37 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000208085010.A16093@mathforum.com>
Date: Tue, 8 Feb 2000 08:50:10 -0500
Reply-To: Aaron Ross <ross@MATHFORUM.COM>
From: Aaron Ross <ross@MATHFORUM.COM>
X-To: Jaanus Kase <terminus@tartu.cyber.ee>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <000401bf6f0d$9cf2d080$094aa8c0@krabi.tartu-labor>; from
terminus@tartu.cyber.ee on Fri, Feb 04, 2000 at 02:44:43PM +0200
Despite MySQL's implicit conversion, many RDBMS do _not_ allow strings around
numeric values:
With Sybase 11.9.2 e.g.
1> create table strnum (
2> col1 int
3> )
4> go
1> insert into strnum values ('1')
2> go
Msg 257, Level 16, State 1
, Line 1
Implicit conversion from datatype 'VARCHAR' to 'INT' is not allowed. Use the
CONVERT function to run this query.
Aaron
> Hi,
>
> > -----Original Message-----
> > From: Bugtraq List [mailto:BUGTRAQ@SECURITYFOCUS.COM]On Behalf Of rain
> > forest puppy
> > Sent: 03. veebruar 2000. A. 18:33
> > To: BUGTRAQ@SECURITYFOCUS.COM
> > Subject: RFP2K01 - "How I hacked Packetstorm" (wwwthreads advisory)
>
> a nice analysis otherwise, but this caught my eye:
>
> > You see, there are different field types. You can have
> > strings, boolean
> > values, various numeric values, etc. While a string field
> > needs to be in
> > the format of field='data', a numeric field doesn't use the '' (i.e.
> > numeric_field='2' is invalid). The correct syntax for
> > numeric fields in
> > numeric_field=2. Ah ha! There's no quotes to deal with, and
> > you can't
> > even use quotes anyways. The correct solution is to make
>
> If you're stating that you cannot enclose your numeric values in single
> quotes in SQL query strings, it seems to be incorrect. I'm also using SQL as
> my backend, and I've ALWAYS enclosed numbers in single quotes, and it has
> always worked.
>
> Besides, when using PHP as front end, it has the nice AddSlashes and
> StripSlashes functions, which, according to the manual, "Returns a string
> with backslashes before characters that need to be quoted in database
> queries etc. These characters are single quote ('), double quote ("),
> backslash (\) and NUL (the null byte).", and "Returns a string with
> backslashes stripped off. (\' becomes ' and so on.) Double backslashes are
> made into a single backslash.". So it's exactly what we need to "disarm" web
> queries, and pretty much the same as the $dbh->quote thing (though you later
> have to 'decode' the data and strip the backslashes).
>
> I wrote two "wrapper" functions for PHP, which take their input and add or
> strip slashes (recursively if needed) on both arrays and normal variables
> (never mind the funny names, you can change them if you want, but the idea
> should be clear :). I'm sure it could be done more effectively, and in other
> languages too, but I'm not much of a code wizard, so let's stick with these
> for now.
>
> function paneslash (&$sisend) {
> if (is_array($sisend)) {
> while (list($siskey) = each($sisend)) {
> paneslash($sisend[$siskey]);
> }
> } else {
> $sisend = addslashes($sisend);
> }
> }
>
> function korjaslash (&$sisend) {
> if (is_array($sisend)) {
> while (list($siskey) = each($sisend)) {
> korjaslash($sisend[$siskey]);
> }
> } else {
> $sisend = stripslashes($sisend);
> }
> }
>
> This way, when fetching data from database, you can just say
>
> $my_array=mysql_fetch_array($some_query);
> korjaslash($my_array);
>
> and boom, backslashes are stripped (provided there were any). Prior to
> inserting/updating data, just go through each variable with
> paneslash($varname) and off you go. When performing insert/update, I have
> always used the "update blaah set columnname='value'" syntax with single
> quotes always surrounding, regardless of the columnname type (integer,
> string etc), and it has worked with no trouble.
>
> However, checking numeric data for validity is still a healthy practice,
> since it's likely you'll later pass it to functions (like calculations or
> something) that assume they're dealing with valid numbers - and when
> inserting non-numeric data to columns of numeric type, MySQL seems to
> quietly replace it with zero (at least in case of integers).
>
> PHP has a nice set of is_* functions (like is_array, is_int etc), but they
> seem to be somewhat broken/misdocumented - when using <input type="text">
> and passing the form to PHP script, this variable (before interpreting it
> anyhow) is always assumed to be string, even when it only contains valid
> numeric data. (the is_array in above functions works fine, though, so
> perhaps I've misread something.) Other functions that could be used are the
> GetType and SetType in PHP - when a variable is supposed to be numeric, but
> contains non-numeric data, GetType reports it to be something else than
> integer, and perhaps you can then warn user about this - A.K.A. server-side
> validation, which should be a normal, healthy, common sense programming
> practice anyway ("NEVER trust the user..."). Moreover, it's more secure than
> client-side validation, since one who has malicious intent can always
> construct their own form/query and just delete the validating JavaScript or
> whatever on the client side.
>
> The PHP/MySQL combination is powerful, elegant, and easy to use (as well as
> many other front- and backends). As dynamic page generation is gaining
> momentum and discussion forums, user profile maintenance pages etc are
> popping up all over the place, I'm sure we'll see many more vulnerabilities
> of this type both in custom-written scripts as well as commercial software
> (as the WWWThreads example demonstrated). With software that is both easy to
> use and rich in features, security concerns are often disregarded - many
> entry-level webmasters and script developers are clueless about the above
> possibilities. So let's keep our eyes open, and queries safe.
>
> Regards,
> Jaanus Kase
> Cybernetica (http://www.cyber.ee/)
