How to identify php application security holes

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • dlite922
    Recognized Expert Top Contributor
    • Dec 2007
    • 1586

    How to identify php application security holes

    I made a bet with a coworker. See if I did good.

    Bet:
    Try to compromise or otherwise disturb the normal function of an app because of a problem with PHP.

    Problems/holes with network and the server are excluded. (ie DoS attack does not count)

    The app runs some CLI commands, uploads a file, stores data in MySQL and has an user/access login.

    Most of your know my level of expertise with PHP, so skip the mysql_escape_st ring() talks. :)


    1. Sanitize every input and request from the page
    2. Encrypt session and store session on server/not in a cookie
    3. Block all bad-IPs. (if I see bad input, do not process any request from that IP)
    4. ????
    5. Win 100 Bucks!

    He'll have 1 week to do it.





    Dan
  • dlite922
    Recognized Expert Top Contributor
    • Dec 2007
    • 1586

    #2
    WOW! No Takers?

    PHP is that secure?

    Well...maybe it is. And I did say to not give trivial responses like

    "Avoid doing this:
    Code:
    system("rm -rf /home/" . $_POST['userDir'] . "/" . $_POST['file']);
    hehehe :D

    Dan

    Comment

    • Markus
      Recognized Expert Expert
      • Jun 2007
      • 6092

      #3
      Well, it generally is secure; but there's not much I can advise you on, because I've no idea what your application will be doing.

      Silly n00b, help us to help you!

      Mark (is joking ;).

      Comment

      • dlite922
        Recognized Expert Top Contributor
        • Dec 2007
        • 1586

        #4
        Well, Mr excuuuuuuse me!

        I thought you'd have an imagination of what my code could look like.

        If I wrote an application that that executed system commands and stored stuff (user login, password, and some data like age, gender).

        Pretend I pasted the code. It's all on one line (just kidding)

        What would you look for besides sanitized variables?

        I can also put this another way. How would you go about hacking a PHP site?

        1. SQL Injection...... ...check
        2. Causing fatal errors by bad input.........c heck (set_error_hand ler())
        3. Scan all files of the site and check for left over files, other unlinked pages that maybe undeveloped, .inc config files that PHP won't process.
        4. ????
        5. Profit!



        Dan (could share the $100 if he learns a new way to close down PHP against this hacker)

        Comment

        • unauthorized
          New Member
          • May 2009
          • 81

          #5
          So basically, you want us to shoot bulls eye when blind folded and not in line of sight of our target?

          Hmm, let's see...
          1. Are you filtering data that comes from "trusted" sources such as your own DB?
          2. Have you disabled the exec SSI?
          3. Are you filtering the gender and any other dropbox/radiobtn fields?
          4. Have you removed write permissions outside /tmp?
          5. Have you set up your scripts to handle incomplete requests without having to timeout?
          6. Are all of your .inc files protected from being accessed through HTTP requests?
          7. And most importantly, have you set up an utterly annoying 404 page? One that makes people want to commit suicide if they see it even once?

          If you answered "yes" to all of the above questions, than congratulations , I sure as hell don't know how to hack your app... maybe.

          Oh, here are two extras:
          E1. What will happen if someone tries to make bad requests from every single assigned IP on the planet?
          E2. How do you recognize clients if the session is on the server? Surely not by IP?

          Comment

          • dlite922
            Recognized Expert Top Contributor
            • Dec 2007
            • 1586

            #6
            Originally posted by unauthorized
            So basically, you want us to shoot bulls eye when blind folded and not in line of sight of our target?
            Yes! :)
            Originally posted by unauthorized

            Hmm, let's see...
            1. Are you filtering data that comes from "trusted" sources such as your own DB?
            No, it wouldn't be trusted then, right?

            Originally posted by unauthorized
            2. Have you disabled the exec SSI?
            Oo!!! no..you got me googling even though I know a little about server side includes...tell me what you would to to hack.

            Originally posted by unauthorized
            3. Are you filtering the gender and any other dropbox/radiobtn fields?
            Yes!, a noobie!

            Originally posted by unauthorized
            4. Have you removed write permissions outside /tmp?
            Who's this guy? Apache is a 'nobody'! *wink* *wink*

            Originally posted by unauthorized
            5. Have you set up your scripts to handle incomplete requests without having to timeout?
            uhh...ummm...ca n you repeat the question?. seriously though, care to elaborate on this? some malformed/altered HTTP request or? if so than will this poke a hole in Apache or PHP specifically. if Apache, I don't care.

            Originally posted by unauthorized
            6. Are all of your .inc files protected from being accessed through HTTP requests?
            Yes. in a non-www folder.
            Originally posted by unauthorized
            7. And most importantly, have you set up an utterly annoying 404 page? One that makes people want to commit suicide if they see it even once?
            Got any ideas? send them to aol.com? hehehe, kill them?...uh by that i mean with a long running javascript loop that prints every character known to man and known to freeze most browsers...yes even FF. I tried it. I had to kill the process. This should surely be annoying, having to restart the browser with every request?

            Remember: This is not a live site, I don't have any actual users yet to serve YET!!

            This site will be publicized once this and other QA processes are done.

            Originally posted by unauthorized
            If you answered "yes" to all of the above questions, than congratulations , I sure as hell don't know how to hack your app... maybe.

            Oh, here are two extras:
            E1. What will happen if someone tries to make bad requests from every single assigned IP on the planet?
            You mean like a DoS attack? too bad, he knows I have one server and one ISP. This won't count.

            Originally posted by unauthorized
            E2. How do you recognize clients if the session is on the server? Surely not by IP?
            let me rephrase: Session "data" will be stored in a DB table. session_id. The site is SSL. THe session id will be a specific salt for each user (such as the first ten characters of the log of the year of birth) the user's IP and the php session id. (maybe combined in a sha-1?)

            this "ID" then will be in a cookie or URL.

            SSL (-256) is required for the entire site.

            Let's talk about number 5.

            Thanks!!


            Dan

            Comment

            • unauthorized
              New Member
              • May 2009
              • 81

              #7
              I just wrote a very long post, just to be greeted with the "please login" page... *Goes emo*.

              ...

              *Ahem*, anyway...

              Yes! :)

              No, it wouldn't be trusted then, right?
              There is no trusted data. For example:

              Code:
              // insert some escaped data into a table
              
              $res = $mysqli->queue("SELECT somefld FROM table1 WHERE id=$hacker_id");
              // insert error handling
              $obj = $mysqli->fetch_object();
              // insert more error handling
              $somefld = $mysqli->unescape_real_string( $obj->somefield );
              
              // see what I did here? or rather, what I didn't?
              $res = $mysqli->queue("INSERT INTO table2('someotherfld') VALUES( '$somefld') ");
              The above code is a textbook example, but there are far more subrile situations that can arise from not filtering your own data.

              Oo!!! no..you got me googling even though I know a little about server side includes...tell me what you would to to hack.
              This is an issue where your server would send HTTP responses with data written from an inside of a user database.
              Let's say you've allowed a user to have any character in his username for some unknown reason. Let's also say that your page starts with "hello, username....".
              What do you think will happen when your server tries to greet user
              Code:
              <!--#exec cmd="rm -rf /"-->
              ?
              Ofc, you are much more likely to be greeting <!--#exec cmd="cat /usr/wwwroot/index.php"--> but I'm sure you get the point.


              Yes!, a noobie!
              Idk about that being a "noobie" thing, I've seen some high grade security sites go down in smoke because someone exploited their "rate this item" drop box.

              Who's this guy? Apache is a 'nobody'! *wink* *wink*
              If only I had $10 for every web server that has ever run as root...

              uhh...ummm...ca n you repeat the question?. seriously though, care to elaborate on this? some malformed/altered HTTP request or? if so than will this poke a hole in Apache or PHP specifically. if Apache, I don't care.
              This is less of an issue with the HTTP server which gets patched all the time to specifically avoid such situations and more of an issue with PHP scripts that preform asynchronous operations and wait for shared lockable resources. It's sort of situational, so I can't give you a concrete example on what your app may need it for, but it's usually an issue with depending too much on AJAX requests.
              A slightly unrelated, but very simple to miss example, would be to create a linked list like structure which doesn't check for circular dependencies. I'm sure you know what happens when you try to iterate over this.


              Yes. in a non-www folder.
              Good man.

              Got any ideas? send them to aol.com? hehehe, kill them?...uh by that i mean with a long running javascript loop that prints every character known to man and known to freeze most browsers...yes even FF. I tried it. I had to kill the process. This should surely be annoying, having to restart the browser with every request?

              Remember: This is not a live site, I don't have any actual users yet to serve YET!!
              My eyes started shining when I read this...
              Let's see, in the past I've done things like:
              Redirect people to teletubies vids on youtube. In multiple frames.
              Calculate primes in JS, Java and Flash all at the same time. Nothing beats computationally intensive tasks ran in a VM!
              Go**se. 'nuf said.
              Send people to porn sites they would likely puke from.
              Circular redirects. Too bad it doesn't work anymore :( (at least not in FF)
              Is your friend American? Send him to the communist party!
              while(1) { alert("alert!") ; } // sure, someone can just disable JS, but this is a classic
              while(1) echo "..."; // without output buffering, ofc
              fake admin pages. after about a 100 normal 404s.
              Popups storms. "Buy v|arga 100% off only on our site!". "Download our free cursors and smiles. Get malware bonus!". This is just a classic.


              You mean like a DoS attack? too bad, he knows I have one server and one ISP. This won't count.
              I meant something like figuring out which request would get banned, and then spoofing requests from different IPs until you've banned the internet.

              let me rephrase: Session "data" will be stored in a DB table. session_id. The site is SSL. THe session id will be a specific salt for each user (such as the first ten characters of the log of the year of birth) the user's IP and the php session id. (maybe combined in a sha-1?)

              this "ID" then will be in a cookie or URL.
              Oh, so that's what you meant. I thought you were storing the sesid itself on the server. Wait.... there are people who still store user vars in a cookie!?

              Comment

              • dlite922
                Recognized Expert Top Contributor
                • Dec 2007
                • 1586

                #8
                (Thanks for the better title...Markus? )

                sorry about your long post unauthorized, that's why I always Ctrl+A;Ctrl+C every 2 minutes.

                ---
                Love your 404 ideas, although didn't get the Go**se reference. I could also send him this thread :D

                ---

                See if I get this right: In the "See what I did There" query example, You basically took an 'assumed' escaped data from another table, un-escaped it (which may now contain a hacker_id like "1' OR 1=1; DROP TABLE user) and inserted it into another table...DOH!!! Lost my user table!!

                ----
                Not much AJAX. But now I want to know how to lockup a resource. Going to play around this weekend. I know you said there's no real example, but got any links to share to research this ? Aside from basic googling. Keywords maybe?

                ----
                I'll be sure to stay away from circular linked lists.

                ---
                I meant something like figuring out which request would get banned, and then spoofing requests from different IPs until you've banned the internet.
                So what should I do?
                Brute force my passwords vs. make him get every IP. In which case, I still somewhat stay up and he didn't really "hack" any data. I don't' count that as winning the bet because I'll set a timer on the IP block to like 1 hour. So when he comes in on Monday and says I blocked you from all work IP, and I can still log on and tell him..Nope! you didn't.



                Dan

                Comment

                • unauthorized
                  New Member
                  • May 2009
                  • 81

                  #9
                  (Thanks for the better title...Markus? )

                  sorry about your long post unauthorized, that's why I always Ctrl+A;Ctrl+C every 2 minutes.
                  Sounds like a logical thing to do. I guess this is one new thing I learned today :)

                  Love your 404 ideas, although didn't get the Go**se reference. I could also send him this thread :D
                  You've never heard of that shock site? Do you really live on the same internet as me? Anyway, it's something that can kill gandma's so don't go looking into it unless extremely gross things don't bother you.

                  See if I get this right: In the "See what I did There" query example, You basically took an 'assumed' escaped data from another table, un-escaped it (which may now contain a hacker_id like "1' OR 1=1; DROP TABLE user) and inserted it into another table...DOH!!! Lost my user table!!
                  This is a very basic example. However, I remember reading at least one doc that described how this technique can be applied in less obvious situations. If I'm not mistaken, the pdf was linked in the Wikipedia references on the SQL Injection topic.

                  Not much AJAX. But now I want to know how to lockup a resource. Going to play around this weekend. I know you said there's no real example, but got any links to share to research this ? Aside from basic googling. Keywords maybe?
                  Admitedly, I was talking more from C++ experience than PHP here. I'm not sure how familiar you are with the concepts of multithreaded programming, but in C++ we often have to deal with lockable memory barriers a.k.a. mutexes. For the most basic lockout situation, you need to look no further than the keyword "deadlock", which you probably have if you've coded in a low level language or have CompSci degree.
                  The good news is that PHP is completely thread safe and you can't really enter a deadlock by using standard memory objects, unless there is a bug in the PHP core. Not to mention that PHP doesn't have the concepts of shared memory and multithreading, so every script is for itself and no two threads ever access the same data in memory.
                  However there are other kind of resources that can be locked indefinitely, such as file system objects and database tables. Let's say you have a script that tries to open a file and waits for some user event before closing it. In this situation, your server can get DoSed through a single dialup connection.

                  So what should I do?
                  Brute force my passwords vs. make him get every IP. In which case, I still somewhat stay up and he didn't really "hack" any data. I don't' count that as winning the bet because I'll set a timer on the IP block to like 1 hour. So when he comes in on Monday and says I blocked you from all work IP, and I can still log on and tell him..Nope! you didn't.
                  If you only block IPs for a certain timeout period, then you are safe from this technique. 1h may be a bit of an overkill, but that's for you to decide.
                  I find it more useful to sleep(2) on a failed login attempt and prevening a single IP from making two login attempts at once. And on top of that, I also add catchpa check after a certain number of failed login attempts.

                  Comment

                  • dlite922
                    Recognized Expert Top Contributor
                    • Dec 2007
                    • 1586

                    #10
                    I'm familiar with Deadlocks as a concept. Spent an entire week on it (Linux vs Windows vs Mac, causes, prevention, etc). Have coded C++ basic programs and in fact that's what got me into programming, but Deadlocks was discussed in a low-level operating systems course.

                    We do live on the same internet the same way we live on the same planet :)

                    Earth? right?


                    Dan

                    Comment

                    • Dheeraj Joshi
                      Recognized Expert Top Contributor
                      • Jul 2009
                      • 1129

                      #11
                      You are from dark side of MOON....

                      So ... I don't know what internet you get there....

                      Just kidding.... Don't take it personally :)

                      Regards
                      Dheeraj Joshi

                      Comment

                      • Markus
                        Recognized Expert Expert
                        • Jun 2007
                        • 6092

                        #12
                        I didn't change the title :D

                        Comment

                        • Dheeraj Joshi
                          Recognized Expert Top Contributor
                          • Jul 2009
                          • 1129

                          #13
                          I know Mark....

                          I was kidding... You can remove the post if you want..

                          Regards
                          Dheeraj Joshi

                          Comment

                          Working...