• fist (unregistered)

    first

  • (cs)

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

  • qasr (unregistered)

    I hope the webserver doesn't have DROP priviledges!

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

  • Lunkwill (unregistered) in reply to qasr
    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?
  • Hacksor (unregistered)

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

  • diaphanein (unregistered) in reply to Lunkwill

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

  • (cs) in reply to Lunkwill

    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.

  • Steve Corona (unregistered)

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

  • (cs)

    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.

  • (cs) in reply to squirrel

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

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

  • (cs)

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

  • Anon (unregistered)

    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?

  • (cs)

    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.

  • (cs)

    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?

  • Masiosare (unregistered) in reply to Steve Corona

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

  • pcooper (unregistered)

    You must be making this stuff up.

  • (cs) in reply to Anon

    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

  • Maweki (unregistered)

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

  • (cs) in reply to pcooper

    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.

  • Rob (unregistered)

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

  • (cs)

    Jesus tap-dancing Christ...

  • Ann Coulter (unregistered)

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

  • (cs) in reply to Steve Corona
    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!
  • (cs)

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

    Simon

  • (cs) in reply to Rob

    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!

  • (cs) in reply to fist

    I wonder what was in the ...

    Anonymous:
    /* ... */

    Something like

    /* An example of what not to do */

    /* Grade 1       Mrs. Parks Class */

  • Dave (unregistered) in reply to Rob

    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!

     

  • An apprentice (unregistered)

    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!

  • (cs)

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

  • (cs) in reply to An apprentice

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

  • (cs) in reply to maldrich
    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!
  • (cs) in reply to Ann Coulter

    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?

  • Paul (unregistered)

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

  • (cs)

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

  • (cs) in reply to Whiskey Tango Foxtrot? Over.

    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..
  • Marquee (unregistered)

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

  • Ann Coulter (unregistered) in reply to zip
    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.
  • (cs)
    Alex Papadimoulis:
    <font color="#990000"></font>  <font color="#990000">'  if (mssql_query("SELECT 1 FROM APPS WHERE SSN=\''</font>+ssn+<font color="#990000">'\'", $cn)) '</font> +
  <font color="#990000">'  { $ins = false; }                                                     '</font> +
  <font color="#990000">'  else                                                                  '</font> +
  <font color="#990000">'  { $ins = true; }                                                      '</font> +
  <font color="#990000">'                                                                        '</font> +
  <font color="#990000">'  if ($ins) {                                                           '</font> +
  <font color="#990000">'    $sql = "INSERT INTO APPS (FIRSTNM, LASTNM, ..., OFFERCD) VALUES ("; '</font> +
  <font color="#990000">'    $sql+= "\''</font>+firstName+<font color="#990000">'\',";                                        '</font> +
  <font color="#990000">'    $sql+= "\''</font>+lastName+<font color="#990000">'\',";                                         '</font> +
  <font color="#990000">'    $sql+= "\''</font>+offerCode+<font color="#990000">'\')";                                        '</font> +


    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

  • (cs)

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

  • (cs) in reply to maldrich
    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.

  • (cs)

    Here is the Web Site:

    ------------------
    |                             |
    |                             |
    |                             |
    |                             |
    ------------------


    Everything else is just a client side plug-in!

  • (cs) in reply to Anon
    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.

  • Me (unregistered) in reply to Otto
    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 ?
  • fdr (unregistered)

    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.
  • TomCo (unregistered)

    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

     

  • Me (unregistered)

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

  • (cs) in reply to fdr
    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.
  • (cs) in reply to Otto
    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
  • (cs) in reply to Richard 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.

  • (cs) in reply to maldrich
    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.

Leave a comment on “Client-side PHP”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article