$_GET['id'] is not working?????

[servis]

i am extemly newbie and don’t know whether I should post my problem here or somewhere else, however…
i have following problem in one of my php-mysql application
header link through browser is,
"http://localhost/test/reply.php?id=852"
and query is as follow,

$name=$_POST['name'];   //from  the name form  
$q_id=$_GET['id'];
$sql="INSERT INTO `test`.`reply`(`rid`,`tid`,`name`)VALUES(NULL,'$q_id','$name')";
$result=mysql_query($sql);

The application does not pass any value related to $q_id in database table, the table view is as follow, The query does not insert any value to tid column except default value. What should I do…

rid 	tid	name 
1	0	karam
3	0	drupal
4	0	Shuja-u-Rehman

The table specification is as follow,

Field	Type	      Null	Default	Extra
rid	int(11)	      No		auto_increment
tid	int(11)	      No		
name	varchar(25)     No

I have tried every method, I know but in vain.
Please any body helps me….

Shuja

[nav33n]

Hmm.. Does it give any error ? print out the query and see whats being passed as values..

$name=$_POST; //from the name form
$q_id=$_GET;

What method have you specified for the form ? POST or GET ?

[servis]

it does not give any error, $_GET is extracting from "http://localhost/test/reply.php?id=852"
and $_POST is coming from form using POST method, it is working well. But the $q_id=$_GET is not being inserted in database table.

[nav33n]

So, is your form action is like this ?

<form method="POST" action="reply.php?id=852"> 
</form>

If this is the case, then it should work fine. If not, then you should post your code..

[TopDogger]

You need to isolate the problem. At this point, you don't know if the GET variable is not picking up the value or if the value is not being inserted into thte table.

add echo $q_id;

just after

$q_id=$_GET;

also add echo $sql;

just before you assign the INSERT statement to $sql.

That will tell you right away where the problem lies.

[servis]

i can not tell you, how much i am thankful to you. yes it was the error. thanks for your great hint. application is working like rocket...

[nav33n]

Umm.. so, what was the error ?

[JRSofty]

His problem is quite simple actually. Here's his original code

$name=$_POST['name'];   //from  the name form  
$q_id=$_GET['id'];
$sql="INSERT INTO `test`.`reply`(`rid`,`tid`,`name`)VALUES(NULL,'$q_id','$name')";
$result=mysql_query($sql);

All he needs to do is remove the single quotes (' ') from around the $q_id in his SQL.

So his new code should look like this:

$name=$_POST['name'];   //from  the name form  
$q_id=$_GET['id'];
$sql="INSERT INTO `test`.`reply`(`rid`,`tid`,`name`)VALUES(NULL, $q_id ,'$name')";
$result=mysql_query($sql);

He has declared the tid field as an integer and he is trying to pass it as a string. MySQL probably doesn't like it.

ALSO

Just to be on the safe side you really need to run the $_GET and the $_POST variables through the mysql_real_escape_string() function to prevent someone from doing nasty things to your database. Example:

$q_id = mysql_real_escape_string($_GET['id']);
$name = mysql_real_escape_string($_POST['name']);

Hope that helps you.

[nav33n]

He has declared the tid field as an integer and he is trying to pass it as a string. MySQL probably doesn't like it.

No.. That wouldn't be a problem.. You can pass an integer like a string, but not vice-versa.
I still believe its the form action which was causing the problem! :-/

[TopDogger]

I have to agree with nav33n. That would not cause the problem.

[servis]

actually in the form submission i am writing the code like <form method="POST" action="reply.php"> when i chaged the same code in like, <form id="reply" name="reply" method="post" action="reply.php?id=<?php $q_id=$_GET['id']; echo "$q_id";?>"> after the above change, it run fine...

[nav33n]

ah! cool..

[rgviza]

No.. That wouldn't be a problem.. You can pass an integer like a string, but not vice-versa.
I still believe its the form action which was causing the problem! :-/

yea tacking get variables onto a form action is very bad form(no pun intended). Put the data in a hidden field or session and read it out of the appropriate array.

Anyone in the IT industry should get nervous when they see form variables or id's on query string. That stuff gets logged in some proxies (even over https in some cases) and if the proxy gets comprimised, so does your user that went through it, SSL notwithstanding. If the data is private or session related, use POST for form data and secure cookies for the session.

I had to rewrite session handling on a legacy app, after the whitehats pointed it out to me during an EH. The app was poorly designed and it took over a week to find it all in the source.

[servis]

thank you rgviza, but plz can you suggest me any tutorial about the matter.....

[nav33n]

Well, rgviza is saying, instead of having id in the action, pass the value of id in a hidden field. Access id value as $_POST instead of $_GET.
ie.,
instead of <form method="post" action="test.php?id=1"> do,

<form method="post" action="test.php">
<input type="hidden" name="id" value="1">

:)

[servis]

thank you nav33n for your great help....

[rgviza]

thank you rgviza, but plz can you suggest me any tutorial about the matter.....

I learned it by EH and advice from experienced penetration testers. people compromise proxies and search the logs for qstring vars sent from forms. Some proxies log the data, even over ssl. When they get compromised an attacker will tail the log and look for session ids, credit card numbers etc. While the chances of useful info being pulled about _your_ site is pretty small from any given proxy, if one of your user's proxy servers gets hit, your user will be comprimised if the attacker is interested in their account.

Sending anything on query string that could be considered private, or is a session id is very dangerous with or without SSL. Apply that to whatever you do. Anyone can hijack a session once they have a valid id. It's not the ssl communication they are breaking, it's the proxy.

For session IDs use an https secured cookie. It's pretty easy to secure against this type of threat. The https cookie values and POST variables don't get logged.

Here's some good stuff.

This is a set of web application security guidelines. While not complete, it's a great start. At the bottom of the page are other great links.
-r