On February 28, 2014, keith smith wrote: > I'm curious about putting my PHP code outside of the webroot. Let's say you do so.
> How do you run your code? Do you put an index in the docroot and then what? Are > you using a symlink? No, somewhere in apache's httpd.conf file you put a <directory [code dir]> entry. For an example of that that I've used (not one I wrote, but one I do like) look at the squirrelmail webmail package. If my memory is correct, it does that. Nothing goes in /var/www/html at all. Instead it creates an entry so that when you use http://[server]/webmail/ it processes squirrel's's index.php at that point. > First, create your app with one entry point, second block direct access to all other > files. If you're talking about what I THINK you're talking about, then I do something like that by default for any big project. When a person hits the "login" page, they have to enter a valid username/password to continue. Doing so creates a login token that is valid for however long (usually 10 minutes) between GET requests. If anyone tries to access one of the page files without first logging in, they are automatically redirected to the login page with an error message saying that a valid login token could not be located for them and to please log in normally. If the token expires, then the next GET also redirects them to the login page, with an error that indicates that their session's idle time expired and they should please login again. All pages except login.php would reference the valid_login() function I wrote for that project that is stored in common.php. That function first looks to see if there is a token ID that looks valid (usually stored in $_SESSION). If there is, then it pulls the timeout portion of that token and compares it to the time() function. If time() returns equal or greater, then redirect to login.php?err=3&. If the valid token doesn't exist, redirect to login.php?err=2&. For times when I want to force a specific flow, I usually do some extra checking where each php page sets a SENDER element in the login token and each page also checks that token, and if the SENDER element isn't correct (i.e. they came from a wrong page) then it throws up an error instead of the page and a link back to the main page that you'd see after login.php. > One of the things we see with PHP is the use of library files that contain queries > that can be accessed directly. This approach leaves PHP vulnerable to being > exploited. I see this approach all the time. The reason most of this code does not > get exploited is no one knows enough to exploit it. However using this approach in > an open source project opens the door to someone exploiting the code. Not quite sure what you mean here. Any project that is going to have user input queried against a database has to allow the user to input that data. Even a simple login form has that need. Of course there's a difference between simply plugging in the $_REQUEST (or $_GET/$_POST) element in the request and doing some basic sanity checking and some basic sanitizing. Anyone who does query directly against the input is asking for problems no matter the language, and I don't know of any language that would specifically prevent you from doing that. Even if there's some kind of check that prevents you from using that languages equivalent of the $_REQUEST/$_GET/$_POST variables directly, I doubt there's a problem with assigning a temp var to the same value and passing the temp var to the DB query. And most things I've seen these days use PHP's DB libraries and prepared statements. That's not so easy to hack. Anyway, that's how I do things. And it seems to work. Because the code is executed and not viewed, no one knows the exact format I use (and I do change it from project to project) for the token ID, so they can't ape it by editing/hacking/forging a cookie in their browser. Even if they did manage to view the cookie and get the token ID, they first have to KNOW it's the token ID, and not some other numeric value (most tokens I write are just large numbers with specific modulus requirements), then they have to verify which field is the timeout field (with multiple integer fields, all of which are unlabeled, that's not so easy). That's required so they can bypass the timeout requirements. And in case you're wondering, yes, logging out normally (by clicking the logout link) does delete the cookie from the computer. The logout link would normally take you back to login.php?act=logout. When login.php runs, if the act element of the $_REQUEST/$_GET/$_POST array is logout, it calls session_destroy() which my understanding is tells the browser to delete the cookie that was created by session_start(). So far it's worked well, and I've had no major complaints. --- Dan /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
