Wow, imagine the possibilities here. You could eventually have one page with a large text box allowing users to be able to plug in their own custom PHP code and have it run on the server. This is a new paradigm shift.

<span style="font-size: 12pt; font-family: "Times New Roman";">If the execPhp sends the string in the request
and the server runs the php code (I'm not familiar with php so I don't know if
php can run dynamically generated code) then this is an excellent example of
user extensibility. The user can extend the application to do whatever the user
wants.

"An apprentice" is right; their server must be blazingly fast with requests!

I have to admit, I really can't imagine that this is real, production code, let alone public facing in any way shape or form. Any company that actually DOES this deserves to go under, though I fear for the safety of their customer data. Perhaps an enterprising soul can drop all the tables in their database and commit, before anything terrible happens?

Careful attention to detail, though -- look how all those quotes line up in a row on the right side. After the database is destroyed, at least this neat formatting will be left.

Unless, of course, the attacker uses SQL injection to delete the site files too. Bwahaahaaha!

Something I haven't seen mentioned- this doesn't just compromise the database. The user can run any PHP code, which could include getting listings of files that can't normally be seen, deleting files (depending on permissions on the server), or pretty much anything. Or maybe you want to tie up the machine by sending it a couple of requests that execute something processor intensive (say, image manipulation) inside of an infinite loop. The possibilities are endless!

If the execPhp sends the string in the request and the server runs the php code (I'm not familiar with php so I don't know if php can run dynamically generated code) then this is an excellent example of user extensibility. The user can extend the application to do whatever the user wants.

You read the WTF, and you're going to leave a comment, but you don't know if php can run dynamically generated code?

But, but, but.... it's safe!!! Look it's even got an escapeSql() function!!!!!1!! That'll make sure that the SQL transmitted to the PHP script is 100% safe from injection attacks!!!!!!!!!111!11!1!1111one1!1!!

I can't believe this. Whomever did this *obviously* thought about SQL injection, but somehow thought they were avoiding it by embedding the check in the client code.

Not necessarily.. most PHP books are going to show escapeSql() before the query is executed, then have a footnote with something like "ALWAYS use escapeSql on queries. The reasons why are beyond the scope of this book, but just trust us and do it." Or maybe "see chapter 58 for more information as to why you do this".

If the execPhp sends the string in the request and the server runs the php code (I'm not familiar with php so I don't know if php can run dynamically generated code) then this is an excellent example of user extensibility. The user can extend the application to do whatever the user wants.

You read the WTF, and you're going to leave a comment, but you don't know if php can run dynamically generated code?

Careful attention to detail, though -- look how all those quotes line up in a row on the right side. After the database is destroyed, at least this neat formatting will be left.

Unless, of course, the attacker uses SQL injection to delete the site files too. Bwahaahaaha!

SQL Injection? Why bother, when you have actual PHP Injection. Who said the PHP code you send to the server has to do any SQL at all? Have it exec a shell on a TCP port, and voila, you've got shell access as whatever user the webserver is running as.

What is the point of eval() in php anyways? It just seems like an open invitation for stuff like this. Is there any case where it is more useful than harmful?

It's assumed that you are smart enough not to use it for anything unless you really need it and know the inherent danger there.

I recently modified a plugin for Wordpress and added an eval() to it. The point of the plugin is to accept php from the administrator and run it to generate content for a sidebar. However, only the administrator has access to the config screen, and since the administrator already has the ability to edit any file on the webserver, it's not really any more dangerous than it was before.

Nothing wrong with eval() as long as you're not using it in stupid ways.

SQL Injection? Why bother, when you have actual PHP Injection. Who said the PHP code you send to the server has to do any SQL at all? Have it exec a shell on a TCP port, and voila, you've got shell access as whatever user the webserver is running as.

Windows. As showen by the MSSQL calls. I assume there are a number of 0day privlage exploits out there for this OS ?

hmmm... it does not seem too bad, in fact it could be a very good design, and I am not kidding. The two things that must be true are:

The php app must be strictly limited to just execute the code that
comes - server's privileges must be very limited (no extensions, no
possibility of sending mails, no privileges to write to
disk/self-destruct etc.).

the authorization and authentication must be done on the DB side,
which is a rather clean design, and hardly a WTF. In such case letting
anyone execute just any queries is not dangerous, and even if it
results in users executing (sometimes) slow, unoptimized queries, it is
something you can't prevent on any system that has a thick client.
And that's it.

The sad thing is that even if a hurricane came and wiped out this sql-injection nightmare (we can all pray), there would be an outcry from the dislocated programmers (and management?), wanting to rebuild their tower of babel in all of it's splendor. But you know, maybe this AJAX thing ain't half bad? *spit*puke*uhhhhhhhh*bzzzt*[li]*dead.

hmmm... it does not seem too bad, in fact it could be a very good design, and I am not kidding. The two things that must be true are:
1. The php app must be strictly limited to just execute the code that
comes - server's privileges must be very limited (no extensions, no
possibility of sending mails, no privileges to write to
disk/self-destruct etc.).
2. the authorization and authentication must be done on the DB side,
which is a rather clean design, and hardly a WTF. In such case letting
anyone execute just any queries is not dangerous, and even if it
results in users executing (sometimes) slow, unoptimized queries, it is
something you can't prevent on any system that has a thick client.
And that's it.

Careful attention to detail, though -- look how all those quotes line up in a row on the right side. After the database is destroyed, at least this neat formatting will be left.

Unless, of course, the attacker uses SQL injection to delete the site files too. Bwahaahaaha!

SQL Injection? Why bother, when you have actual PHP Injection. Who said the PHP code you send to the server has to do any SQL at all? Have it exec a shell on a TCP port, and voila, you've got shell access as whatever user the webserver is running as.

Well, whatever the method of destroying the site, this design does have the advantage that the whole source code for the application might actually be in the browser cache, and I guess you could use the browser itself to put it all back. Self-repair.

All they need is some code in the javascript to the effect

"if (site has been obliterated) evalPHP( code to reconstruct the whole site )"

The next visitor who has the pages in cache would, albeit slowly, put the whole site back in place. It's like a massive and unintentional cluster.

Well, whatever the method of destroying the site, this design does have the advantage that the whole source code for the application might actually be in the browser cache, and I guess you could use the browser itself to put it all back. Self-repair.

All they need is some code in the javascript to the effect

"if (site has been obliterated) evalPHP( code to reconstruct the whole site )"

The next visitor who has the pages in cache would, albeit slowly, put the whole site back in place. It's like a massive and unintentional cluster.

I guess it could rebuild the whole database, too.

So this is the system that becomes the Matrix sometime in the early twenty-first century. I see.