Comment On Client-side PHP

first

LOL! Can't say I've never done stuff like that though.... Although when I did it, it was simply for fun!

I hope the webserver doesn't have DROP priviledges!

I can't imagine what idiot must have thought this was good design...  

Anonymous:

I hope the webserver doesn't have DROP priviledges!

I can't imagine what idiot must have thought this was good design...  

I can...

Who needs DROP when you have UPDATE and SELECT?

Remote code execution? What's that?! :P

My only hope is that this isn't a publicly-facing website.  I know I'm wrong...but please keep the hope alive.

Can it really be called a sql "injection" if you're given the sql in the source, and the server-side script used to run the sql? Isn't that less of an injection and more of an invitation?

I mean, you don't have to inject your own code into the servers'. You can just replace it. You can ask the server to run your code. Very nice.

... Are.. you.. kidding me? Whoever wrote that code should probably stop using computers.

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.

Looks like the 'programmer' discovered RPC (Remote Procedure Calls) for Web 2.0.

What a POC (Pile Of C..p).

While I don't doubt the stupidity level of some programmers ( especially PHP programmers [;)] )... surely this is not on a production site(?).

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?

The real WTF is why the mssql_connect line is slightly shorter than the rest.

It's a good thing (s)he bothers to the escape the SQL parameters, though. That's keeping an eye on security.

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.

 I have four words to say about this:

Well, why repeat them, when you can just look at my name?

They finally got to keep all the business rules in I side...

Why should he has to update javascript and php?

He is genius, plain genius...

You *must* be making this stuff up.

Anonymous:

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 there for creating dynamically generated code. You can do this in most languages, even .NET and Java. The programmer is assumed to know how dangerous it is, however.

 

What an ASSumption

Funny Idea. Should really try that with my next modularized Design.

Anonymous:

You *must* be making this stuff up.

You know, I've often thought along those lines... stuff like "that's so stupid, nobody would do it! I call fakesies!".

 

If he is making it up, Alex is a comedic genius.

I think this is the first time a WTF has nearly made me angry.  I honestly cannot even begin to fathom how someone could work through this whole thing and not see how absurd this is.

Unbelieveable...

Jesus tap-dancing Christ...

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.

Anonymous:

... Are.. you.. kidding me? Whoever wrote that code should probably stop using computers.

ROFLMAO!!! I totally agree... You simply can't make this stuff up, it's just way to FU!

How did you get your hands on the code for the next version of Community Server?

Simon

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!

I wonder what was in the ...

Anonymous:

/* ... */

Something like

/* An example of what not to do */

/* Grade 1       Mrs. Parks Class */

He has truly invented something wonderful. I will call it ...

SQL Highly Integrated Transactions !

Yes, he has designed a program that is full of S.H.I.T!

 

What I see is a very nice open source system.

And they probably cut the costs by 50% because there is no server-side part at all - client is responsible for all logic!

Given the name of the submiter, and the type of genius involved, i bet its live, and its on a governamental site.

"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?

maldrich:

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!

Anonymous:

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?

I absolutely love the "escapeSql" function he uses to prevent SQL injection. He is truly a security genius.

the real WTF here is that they are using string concatination in JavaScript...

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

Just because he knew to do it doesn't mean he knows why it's done..

We are all doomed by this "web 2.0" hype. 

zip:

Anonymous:

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?

Yup.

Alex Papadimoulis:

  '  if (mssql_query("SELECT 1 FROM APPS WHERE SSN=\''+ssn+'\'", $cn)) ' +

  '  { $ins = false; }                                                     ' +

  '  else                                                                  ' +

  '  { $ins = true; }                                                      ' +

  '                                                                        ' +

  '  if ($ins) {                                                           ' +

  '    $sql = "INSERT INTO APPS (FIRSTNM, LASTNM, ..., OFFERCD) VALUES ("; ' +

  '    $sql+= "\''+firstName+'\',";                                        ' +

  '    $sql+= "\''+lastName+'\',";                                         ' +

  '    $sql+= "\''+offerCode+'\')";                                        ' +

As well as the injection possibilities mentioned by others, the logic for $ins allows for a race condition (unless the server wraps this in a transaction).

Sincerely,

Gene Wirchenko

The real WTF is he didn't store his SQL in a cookie.

maldrich:

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.

Here is the Web Site:

*------------------*
|                             |

|                             |

|                             |

|                             |

*------------------*


Everything else is just a client side plug-in!

Anonymous:

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.

Otto:

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:

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.

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.

--

More than one goose are geese.  What's more than one moose?

TomCo

 

Always good to see code that handles Social Security Numbers to be so hard core safe, see he escapes the SQL!!!

Anonymous:

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.

"very good design, and I am not kidding"

I hope our paths never meet, and I am not kidding.

Otto:

maldrich:

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.

In this case: root.

ZING!

sincerely,
Richard Milhouse Nixon

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.

maldrich:

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.