PHPBuilder - Check Data Page 4



RSS Twitter
Articles Application Architecture

Check Data - Page 4

by: Spencer P
|
November 3, 2000

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:
<form method="get" action="account.php">
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:
<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.
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.
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.]
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?
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!
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.
-- Spencer

« Previous Page
1
|
2
|
3
|
4

Comment and Contribute

Your comment has been submitted and is pending approval.

Author:
Spencer P

Comment:



Comment:

(Maximum characters: 1200). You have characters left.