I think you answered your own question in your post. You were able to successfully inject commands, that's how you exploit the vulnerability.

Thank you guys for replying . But actually i am not understanding what command i need. Because none command is working without ${@print(md5())}.

I tried many other php command such as systme or exec . But no any result.

Perhaps i need some hint or any link please?

I tried .... I have seen the source code......Because first tried it by burp too.

Only source with a javascript redirect location (document.cookie=login.html)

If <? system(ls) ?> or other command then it just :

<script>document.location=login.html</script>

If md5 hash
hashhere<script>..........</script>

That is all i am getting.

I am counfused that how i can Combination other command with ${@(md5(something))}.

OK now this is worked...

But some problem that i can't write anything on the server.

Suppose i am executing the command ${@system(ls)} and it out put all file but when i try like ${@system(ls /etc)} it is not executing.

All single command is working but whenever i try something advance(SO need space), it is not executing at all.

Perhaps this problem is for single quote and space. I was encoded but no luck yet

Any advice please?

Strange:

Here some result
1. ${@system(ls)} (It is fine)
2. ${@system(ls /etc)} :
<script language="javascript">document.location="default.html";</script>
3. ${@print(iamhere)} (It print out fine)
4. ${@system(i am here)}:
<hr>Query was empty

When i tried with ASCII encoding:
${@system(6920616d2068657265)}
The result: <hr>Query was empty

When i tried with random number without encoding:
${@print(692)}
Result:
692<script language="javascript">document.location="defualt.html";</script>

bah.

Not understanding what the hell is going on!!!

Please help ?

Okay, let's break some of it down:

How come this is possible?
Apparently, the input from the GET variable password seems to be evaluated as PHP. This can be caused by eval(), but also preg_match() where the 'e' flag is set.
(And other functions too, but in cases like these, most likely the above.)

How could the actual code look like?
This is just a pseudo-file based on the information shared,


The interesting part of this is that we can evaluate input as PHP with e.g., ${@print(md5(1))} and the URI may look like this: http://example.tld/path/script.php?user=1&password=${@print(md5(1))}


So, what's up with the ${@print(md5(1))} ?
It seems overly completicated, as print(md5(1)) could've possibly achieved the same, depending on filters and WAF's in use.

Furthermore, the @ only disables any error output, meaning you will only make it harder for yourself.

You may not even need the ${PHP code} , perhaps you may.

Why can't you use <?php phpinfo(); ?> ?
Because you would receive an error like this:
(not exactly like that of course.)

Why don't you get an error like that?
Because error_reporting(0); is set or display_errors is Off.

Why doesn't system() work?
Because A) The website has a filter or WAF in place blocking, removing, changing, etc., such requests or simply just the word system() in the URL (GET-requests) passed to varibles.
B) Perhaps because your syntax is incorrect. There can be multiple reasons, of them being that you don't encapsulate input in the system() variable with quotes or apostrophes. (i.e., system('ls') or system("ls"), you can also use base64_decode() to decode input in base64.)

What would error occurs when you just write "ls" like system(ls) ?
Notice: Use of undefined constant ls - assumed 'ls' in /var/www/script.php(5) : eval()'d code on line 1

See: http://php.net/manual/en/function.system.php

Why is there no output when the syntax is wrong?


What other commands can you use to execute code?
exec();
passthru();
backticks, e.g., $var=`ls`;print($var)
fopen() (Requires that allow_url_fopen() is enabled for remote connections to other servers.)
include(), include_once(), require(), require_once() (These requires allow_url_include() is enabled for remote connections too.)


What can we tell from these results?

1. You can use system()
2. The syntax is wrong (sorry, but it is).
3. You can use print()
4. See 2

What should you look out for when using ' and " ?
In case magic_quotes is enabled, then apostrophes ' and quotes " will have a backslash prepended so they look like this \' and this \" , meaning if you send: print(system('ls')), it will become print(system(\'ls\')) which is wrong and will therefore fail.

How do you circumvent this? One way is to make the code like this:
print(base64_decode($_GET[cmd]))
(You can always add e.g., system() later on between print() and base64_decode().)

The query would then look like this to test it:
http://example.tld/script.php?user=1&password=print(base64_decode($_GET['cmd']))&cmd=VGhpcyBpcyBhIHRlc3Qgb2Ygc3BlY2lhbCBjaGFyYWN0ZXJzOiAnIC8gXCA+IDwgPyA9ICkgKCA

Where the base64 is of course a connect-back shell home to me  Joke, the above Base64 represents:
This is a test of special characters: ' / \ > < ? = ) (


What should you be aware of too?
Besides magic_quotes, max_execution_time() but also Safe Mode where chroots can be enabled (so you won't have that many commands available to play with, including visible directories), and of course the Suhosin patch which hardens PHP a little bit too. 


Is there a limit / max input of characters in GET-requests?
Yes, typically 1024 or 2048 characters, sometimes 4096. (This depends on the webserver and can be read (and changed) in the source.



As you can see, there's a lot to know about web application security when it comes to to overcoming most challenges, but I'm glad you took the time to read this reply  It took a little while to write, as I was testing the examples I wrote as well, just to make sure they actually work 

No problem, sounds great you appreciated it and I suggest you save it for reference later, when you encounter similar problems. Unless you memorize it all 

It could be a WAF, but make sure your syntax for PHP is correct by testing your injected code locally on your own webserver first, if it works there, it could work on the target server.

The base64 encode method can easily go wrong, and in the case I suggested, you may have to wrap ${} around the injected commands, and you may have to avoid some filters / WAF's too.

$_GET[cmd] will work, as it will assume $_GET['cmd'], but you're right that you should generally use the last ( $_GET['cmd'] ), but if you can't use single quotes, you can use $_GET[cmd] too.