How To Access Your Data
Now all your code is cross-script proof and saving proper data.
Time to make your site public, right? This is another time where you
should think twice. For example, your customers are logging into your site to use
your two-click purchase (patent pending) fork-in-a-box (patent pending)
e-commerce site. You do one of these for a front page:
Time to make your site public, right? This is another time where you
should think twice. For example, your customers are logging into your site to use
your two-click purchase (patent pending) fork-in-a-box (patent pending)
e-commerce site. You do one of these for a front page:
<form method=”get” action=”account.php”>
ID: <input type=”text” name=”id”>
Password: <input type=”password” name=”password”>
</form>
ID: <input type=”text” name=”id”>
Password: <input type=”password” name=”password”>
</form>
See the first problem? To submit to your account page, a URL is
constructed to pass the variables, like so:
constructed to pass the variables, like so:
<http://www.forkinabox.com/account.php?id=me&password=ilikecheese>
In the worst case scenario, the password is sent in plain text, saved
in the browser’s history, sent to a proxy and saved in the proxy log,
and saved in the webserver’s access log. Using the POST method
makes things a little (not much) more secure, but someone who is
persistent enough can even fake a form using the POST method.
in the browser’s history, sent to a proxy and saved in the proxy log,
and saved in the webserver’s access log. Using the POST method
makes things a little (not much) more secure, but someone who is
persistent enough can even fake a form using the POST method.
Since we are using the GET method to get the variables into PHP in the
prior example, anyone can try an infinite number of IDs and passwords.
(Microsoft suffered this one with their passport system a while back.)
Instead of GET, use $HTTP_POST_VARS[] for information that is vital for
access or needs to be secure for other reasons. The rest of the time
you can use the GET method — most of the time a search term doesn’t
have to be kept secret.
prior example, anyone can try an infinite number of IDs and passwords.
(Microsoft suffered this one with their passport system a while back.)
Instead of GET, use $HTTP_POST_VARS[] for information that is vital for
access or needs to be secure for other reasons. The rest of the time
you can use the GET method — most of the time a search term doesn’t
have to be kept secret.
Since it is possible for someone in the network to be sniffing for
clear-text (non-encrypted) data, using https (SSL) will encrypt the remaining data to make
it more secure. It is possible to break this kind of
encryption, but at present it takes someone with a lot of
computing power to decrypt your data and fake input to your forms. [Insert
your favorite conspiracy theory here.]
clear-text (non-encrypted) data, using https (SSL) will encrypt the remaining data to make
it more secure. It is possible to break this kind of
encryption, but at present it takes someone with a lot of
computing power to decrypt your data and fake input to your forms. [Insert
your favorite conspiracy theory here.]
But let’s say that we want to be slick and bypass PHP. (That’s the
reason why we’re writing bad code, no?) Checking with JavaScript for
valid input or even a valid user and password has been done. But then what
happens when I turn off JavaScript?
reason why we’re writing bad code, no?) Checking with JavaScript for
valid input or even a valid user and password has been done. But then what
happens when I turn off JavaScript?
Don’t depend on JavaScript for anything more important than user
convenience. You can cache data with it, make pretty things with it, use it to do
fast checks for invalid data, but don’t depend on JavaScript to get
proper input to your server. As soon as the user turns it off,
your authentication and data checking are out the door. You can
speed up the data checking and shave some processing time off the server,
but, users can turn it off. I know I do!
convenience. You can cache data with it, make pretty things with it, use it to do
fast checks for invalid data, but don’t depend on JavaScript to get
proper input to your server. As soon as the user turns it off,
your authentication and data checking are out the door. You can
speed up the data checking and shave some processing time off the server,
but, users can turn it off. I know I do!
This article may be in three parts, but it has one point in mind:
Never trust anything that you don’t have control over. Don’t trust the
input to your functions, the data used to generate pages, nor the
network. This means check your input when it comes in, clean the input for
further use, and access it in a sane (and maybe even secure) fashion.
The more authority you take, the less chance the user can be malicious.
Never trust anything that you don’t have control over. Don’t trust the
input to your functions, the data used to generate pages, nor the
network. This means check your input when it comes in, clean the input for
further use, and access it in a sane (and maybe even secure) fashion.
The more authority you take, the less chance the user can be malicious.
— Spencer
