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...

ah! cool..

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.

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

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['id'] instead of $_GET['id'].
ie.,
instead of
<form method="post" action="test.php?id=1"> do,

thank you nav33n for your great help....

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