PHP Programming (was JOB: LAMP Artisan)
ddavidegli at gmail.com
Mon Mar 3 02:18:08 MST 2014
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
> 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
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
> that can be accessed directly. This approach leaves PHP vulnerable to
> exploited. I see this approach all the time. The reason most of this code
> get exploited is no one knows enough to exploit it. However using this
> 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.
More information about the PLUG