By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,631 Members | 1,678 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,631 IT Pros & Developers. It's quick & easy.

_GET['name'] truncates

P: n/a
Hi all,

I've written a php script, called test.php, consisting of the following
statements:

<?php
error_reporting(E_ALL);
$query = $_GET['sql'];
echo $query;
?>
Using the script with 'small' values for the parameter sql works fine.
Although, using the script with the sql query as specified below

http://localhost/test.php?sql="SELECT orders_id, customers_id,
customers_name, customers_company, customers_street_address,
customers_suburb, customers_city, customers_postcode, customers_state,
customers_country, customers_telephone, customers_email_address,
customers_address_format_id, delivery_name, delivery_company,
delivery_street_address, delivery_suburb, delivery_city, delivery_postcode,
delivery_state, delivery_country, delivery_address_format_id, billing_name,
billing_company, billing_street_address, billing_suburb, billing_city,
billing_postcode, billing_state, billing_country, billing_address_format_id,
payment_method, cc_type, cc_owner, cc_number, cc_expires, last_modified,
date_purchased, orders_status, orders_date_finished, currency,
currency_value FROM orders where ((date_purchased >= 18991230 and
last_modified is null) or last_modified >= 18991230 ) and orders_status in
(1,2,3) and ((date_purchased <= 20071201203454 and last_modified is null) or
last_modified <= 20071201203454 ) and orders_id = 2 order by
date_purchased"

results in the following:

\"SELECT orders_id, customers_id, customers_name, customers_company,
customers_street_address, customers_suburb, customers_city,
customers_postcode, customers_state, customers_country, customers_telephone,
customers_email_address, customers_address_format_id, delivery_name,
delivery_company, delivery_street_address, delivery_suburb, delivery_city,
delivery_postcode, delivery_state, delivery_country,
delivery_address_format_id, billing_name, billing_company,
billing_street_address, billing_suburb, billing_city, billing_postcode,
billing_state, billing_country, billing_address_format_id, payment_method,
cc_type, cc_owner, cc_number, cc_expires, last_modified, date_purchased,
orders_status, orders_date_finished, currency, currency_value FROM orders
where ((date_purchased >= 18991230 and last_modified is null) or
last_modified >= 18991230 ) and orders_status in (1,2,3) and%2√n√

I do not understand why the value of the sql parameter is truncated. Any
help is appreciated!!

Thanks in advance!


Feb 5 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Rik
Ramon <in**@kwekerijschiffelers.nlwrote:
Hi all,

I've written a php script, called test.php, consisting of the following
statements:

<?php
error_reporting(E_ALL);
$query = $_GET['sql'];
echo $query;
?>
Using the script with 'small' values for the parameter sql works fine.
Although, using the script with the sql query as specified below
<SNIP very long url>
I do not understand why the value of the sql parameter is truncated. Any
help is appreciated!!
The GET string has a maximum, both by HTTP design and browser limitations,
and you probably reached it (anyone willing to look up what that exact
maximum is?).

You shouldn't try to get this in a GET, just use POST.

--
Rik Wasmus
Feb 5 '07 #2

P: n/a
The length of the string is +/= 1200 characters. The maximum for IE is 2048,
and for other browsers even longer...

"Rik" <lu************@hotmail.comwrote in message
news:op***************@misant.kabel.utwente.nl...
Ramon <in**@kwekerijschiffelers.nlwrote:
Hi all,

I've written a php script, called test.php, consisting of the following
statements:

<?php
error_reporting(E_ALL);
$query = $_GET['sql'];
echo $query;
?>
Using the script with 'small' values for the parameter sql works fine.
Although, using the script with the sql query as specified below
<SNIP very long url>
I do not understand why the value of the sql parameter is truncated. Any
help is appreciated!!
The GET string has a maximum, both by HTTP design and browser limitations,
and you probably reached it (anyone willing to look up what that exact
maximum is?).

You shouldn't try to get this in a GET, just use POST.

--
Rik Wasmus
Feb 5 '07 #3

P: n/a
Rik
Ramon <in**@kwekerijschiffelers.nlwrote:
The length of the string is +/= 1200 characters. The maximum for IE is
2048,
and for other browsers even longer...
Hmmz, you're right. I've tested it, and here it works perfectly.
rawurlencoded yields about 1270 characters, and I can get them back nicely
without any trouble, the full string.

Seems a configuration issue of either PHP, browser of webserver to me, but
I'm not going to find out: it still seems very silly to me to try this in
a GET.
--
Rik Wasmus
Feb 5 '07 #4

P: n/a
Rik wrote:
Ramon <in**@kwekerijschiffelers.nlwrote:
>The length of the string is +/= 1200 characters. The maximum for IE is
2048,
and for other browsers even longer...

Hmmz, you're right. I've tested it, and here it works perfectly.
rawurlencoded yields about 1270 characters, and I can get them back
nicely without any trouble, the full string.

Seems a configuration issue of either PHP, browser of webserver to me,
but I'm not going to find out: it still seems very silly to me to try
this in a GET.
--Rik Wasmus
Yep, in addition, it's very insecure. I could just put in my browser
windows

http://www.example.com?sql=delete%20from%20orders

You shouldn't even attempt to put a sql statement in the $_GET or $_POST
string. Rather, put only the values you need for the query.

Or save the query in the $_SESSION.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 5 '07 #5

P: n/a
Jerry Stuckle wrote:
Rik wrote:
Ramon <in**@kwekerijschiffelers.nlwrote:
The length of the string is +/= 1200 characters. The maximum for
IE is 2048, and for other browsers even longer...
>
Hmmz, you're right. I've tested it, and here it works perfectly.
rawurlencoded yields about 1270 characters, and I can get them back
nicely without any trouble, the full string.

Seems a configuration issue of either PHP, browser of webserver to
me, but I'm not going to find out: it still seems very silly to me
to try this in a GET. --Rik Wasmus

Yep, in addition, it's very insecure. I could just put in my browser
windows

http://www.example.com?sql=delete%20from%20orders
Or even worse (just to prove a point to the OP):
http://www.example.com?sql=drop%20table%20orders
You shouldn't even attempt to put a sql statement in the $_GET or
$_POST string. Rather, put only the values you need for the query.

Or save the query in the $_SESSION.
--
Kim Andrť AkerÝ
- ki******@NOSPAMbetadome.com
(remove NOSPAM to contact me directly)
Feb 6 '07 #6

P: n/a
Jerry Stuckle wrote:
http://www.example.com?sql=delete%20from%20orders
Given the sample code posted:

<?php
error_reporting(E_ALL);
$query = $_GET['sql'];
echo $query;
?>

Your query would just print:

delete from orders

Which would not be insecure in the slightest -- after all, the script
doesn't even open a database connection!

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/CSS/Javascript/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!
Feb 6 '07 #7

P: n/a
Toby A Inkster wrote:
Jerry Stuckle wrote:
>http://www.example.com?sql=delete%20from%20orders

Given the sample code posted:

<?php
error_reporting(E_ALL);
$query = $_GET['sql'];
echo $query;
?>

Your query would just print:

delete from orders

Which would not be insecure in the slightest -- after all, the script
doesn't even open a database connection!
Don't be dense, Tony. This is obviously some debug code. In the real
code he would be opening the connection and executing the sql.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 6 '07 #8

P: n/a
Jerry Stuckle wrote:
Don't be dense, Tony. This is obviously some debug code. In the real
code he would be opening the connection and executing the sql.
That's your assumption.

My assumption is that in the real code, *if* he opened a connection to the
database, then he'd be sure to authenticate the user first, by at least
username/password and preferably IP address too.

Besides which, there are perfectly good reasons you might want to pass a
SQL query to a script that does not execute it. For example:

http://developer.mimer.com/validator/
http://www.phpclasses.org/browse/package/1484.html

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/CSS/Javascript/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!
Feb 6 '07 #9

P: n/a
Rik
Toby A Inkster <us**********@tobyinkster.co.ukwrote:
Jerry Stuckle wrote:
>Don't be dense, Tony. This is obviously some debug code. In the real
code he would be opening the connection and executing the sql.

That's your assumption.

My assumption is that in the real code, *if* he opened a connection to
the
database, then he'd be sure to authenticate the user first, by at least
username/password and preferably IP address too.

Besides which, there are perfectly good reasons you might want to pass a
SQL query to a script that does not execute it.
Sure there are. And all of them are better served with a POST.
--
Rik Wasmus
Feb 6 '07 #10

P: n/a
On Mon, 05 Feb 2007 23:10:36 -0800, Rik <lu************@hotmail.comwrote:
Toby A Inkster <us**********@tobyinkster.co.ukwrote:
>Jerry Stuckle wrote:
>>Don't be dense, Tony. This is obviously some debug code. In the real
code he would be opening the connection and executing the sql.

That's your assumption.

My assumption is that in the real code, *if* he opened a connection to
the
database, then he'd be sure to authenticate the user first, by at least
username/password and preferably IP address too.

Besides which, there are perfectly good reasons you might want to pass a
SQL query to a script that does not execute it.

Sure there are. And all of them are better served with a POST.
Unless you specifically want the page state bookmarkable.

--
Curtis, http://dyersweb.com
Feb 7 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.