Printer Friendly Version
Email this thread to a friend
|
php update question (In: Coding & Databases - PHP, ASP, Perl, etc.)
Featured Web Site Template |
|
Reflects user activity within the last 5 minutes
|
|
| Member |
Message |
karrella
Joined: Aug 19, 2005
# Posts: 41
|
Posted: 2005-Oct-18 16:55
How much PHP is too much, is it possible?
I'd like to start a discussion about PHP and whether or not using too much can be bad for your site.
I, like many people are sick of updating one trivial thing on 100 pages, and so PHP is very helpful. Currently I use it for my navigation bar on the left hand side of my page as well as a little teaser ad to my own site's articles at the bottom of each page. I would also like to convert my title bar with my company logo at the top of the page into another PHP include. This however makes me wonder, how much is too much?
Is PHP viewable by most users, or am I cutting off a significant amount of visitors form viewing my site in its entirety?
Is all my PHP making my viewers angry? (like a badly designed frames webpage would)
Is it foolish to make something as important as my logo and title a PHP include? (I want to add and change some features to it regularly)
What are you thoughts and preferences?
Thanks,
|
 |
g1smd
Staff
Joined: Jul 28, 2002
# Posts: 10465
|
Posted: 2005-Oct-18 21:00
Use as much PHP as you like. The user never sees any of the PHP.
The user only sees the HTML page that is assembled by the webserver using the PHP script.
Use View Source in the browser to see what your HTML code and content actually looks like.
Use http://validator.w3.org/detailed.html to make sure that you really are generating valid HTML code.
|
|
lizardz
Joined: Nov 12, 2004
# Posts: 1394
|
Posted: 2005-Oct-18 21:46
what g1msd says, it's totally irrelevant how much php you use, it's outputting html no matter what. However, make sure you have at least a working knowledge of php security, how to test for bad parameters and the like.
php outputs html, that's all. Or bugs, or error messages, or access to root levels of your server if you make a serious enough mistake, those usually are connected to allowing file uploads without proper validation and testing, and allowing user controlled parameters that are used to include files.
If you use query string parameters to build pages, I can almost guarantee you that I can break into your server, I wouldn't do it, but I probably could.
My personal goal, which I've started achieving on my last few projects, is to have exactly zero HTML on my page, it's all programmed, included data, etc, so one page is maybe 8 or so function calls plus some variable assignements etc.
However, the thing you should try to learn is how to pull off all the hard coded php variable stuff off the page, and into functions, which are contained in a group of files, that's how you really make php pages maintainable long term. If you have a function call to say include your left nav, it doesn't matter what that function does, a simple include, a more active construction, building it from a db, it's all exactly the same code on page, the function itself is all that changes.
Having the same include call on every page isn't all that much more efficient than just having the html on every page, but abstracting away from the onpage stuff, that's where it gets fun.
On simple, smaller sites, I average about 500 to 1000 lines of programming for the site itself, plus some library files.
|
|
karrella
Joined: Aug 19, 2005
# Posts: 41
|
Posted: 2005-Oct-21 23:41
"If you use query string parameters to build pages, I can almost guarantee you that I can break into your server, I wouldn't do it, but I probably could."
If all I'm using is includes like this:
<?php include('page.php') ?>
am I in any danger from what you spoke of?
|
|
masidani
Joined: Oct 21, 2005
# Posts: 10
|
Posted: 2005-Oct-22 13:52
"If you use query string parameters to build pages, I can almost guarantee you that I can break into your server, I wouldn't do it, but I probably could."
Let's see you break into Google's servers then.
Query string data is used whenever the GET request method is used in forms. Nearly all search engines use GET because it allows you to bookmark search requests easily. The principal danger with form data (and the same applies to POSTed data) is if it is not checked and validated by the server-side program using it.
Simon
|
|
g1smd
Staff
Joined: Jul 28, 2002
# Posts: 10465
|
Posted: 2005-Oct-22 20:43
The include you mention is safe if the filename is hardwired into the code.
If the filename was supplied as part of a query string then it would be possible for anyone to include any file from any external site into your page.
|
|
lizardz
Joined: Nov 12, 2004
# Posts: 1394
|
Posted: 2005-Oct-22 21:02
masidani, I didn't say I could break into a professinaly programmed website that uses query strings, I said I could break into his/her website, since newbies almost invariably do not protect against that type of intrusion. That's why I used the word 'your' when I said I can break into 'your' website. I didn't say 'all'.
karrella, as g1smd says, if you are using hard coded values in the include, that's totally safe. It's only dangerous when the script gets that value from user data, or from the url/query string, that's when you have to apply protection, although in some ways it's not a bad thing to do to just protect it anyway, like:
if file_exists( include full local file path )....
I've forgotten to do that on some sites, and wouldn't you know it, some little jerk script kiddie finds that, and manages to get my server root path, nothing else, there's a minimum of protection in place always, but it gets annoying having to think of each and every thing that a script kiddie can come up with to crack your site, you always miss something or other, and, to the guy with the immense faith in google, google had a serious hole in their adwords for almost 3 weeks that may be forcing them to renew their entire database because of potential data corruption, and that's not the first google hole by the way, so don't be so darned sure about your faith in large company web data security, assume the worst.
[ Message was edited by: lizardz 10/22/2005 01:24 pm ]
|
|
karrella
Joined: Aug 19, 2005
# Posts: 41
|
Posted: 2005-Oct-23 04:54
Is it not also safe to assume that if I have nothing to hide, I have no security issues? Every file uploaded in my "web space" is public and included in my site somewhere.
I'm a little company all my credit card transactions are done through paypal so thats safe on my end. And other than someone stealing my password and modifying my site, I don't think I have much to worry about do I?
At the moment I don't use any PHP message boards on my site, I have messed around with a few free ones though. I had trouble installing my own, and was worried about security issues so I figure I'll hold off until I have a better understanding.
Thanks everyone for your helpful comments btw!
|
|
lizardz
Joined: Nov 12, 2004
# Posts: 1394
|
Posted: 2005-Oct-23 05:19
the game is to get escalated privileges on the server itself, not just in your webspace. You win the game by taking over the webserver, then using it for whatever purposes you might have in mind, spam sending is popular, so is DDOS, denial of service attacks.
If someone wins this game, sometimes you lose when your hosting company kicks you off their servers.
Hosters have widely varying skill levels in terms of what security they are able to implement well.
Being aware of security is just something to keep in your head, especially if you are dealing with more active processes online, one example is someone changes the url the person is forwarded to to a spoofed paypal page, where they collect their credit card information, they change the url by cracking your site.
|
|
dirty_shame
Joined: Aug 28, 2005
# Posts: 191
|
Posted: 2005-Oct-24 02:28
Somehting that might help you. Here's a small script we paste into our form processing pages might help you do simple validation:
/*********VALIDATE REFERER**************/
$url = parse_url($HTTP_REFERER);
$checkurl=strtolower($url["host"]);
if($checkurl!='www.yourdomain.com'){
die;
exit;
}
At least you can tell if the info is coming from your own form and act accordingly. You can also make it page specific if you wish. Just a quick 'n dirty precaution script.
|
|
lizardz
Joined: Nov 12, 2004
# Posts: 1394
|
Posted: 2005-Oct-24 02:40
Oh, don't do that, I got that method to fail in 1 minute in 3 different ways without even trying:
1: use the location bar to access the page, that's the same also as using bookmarks, history, anything where there is no referrer
2: turn off referrer logging, browser side
3: turn off referrer client side, using firewalls/security tools.
Also, some corporate IT guys disable sending referers completely from what I've read.
Most websites try not to alienate corporate users, or any other user, for unnecessary reasons.
Using referer tests is heaviily frowned on for security matters, for very good reason, I used to dabble with the idea until I realized that it didn't provide the security protection I needed. Think of the referrer as something that might be useful in some cases, it's like javascript, but because you can turn it off and on client side, and it's not always set anyway, you don't ever want to depend on it for security.
So you have to check if the referrer is set first, but if it's not set, the test is useless.
It's much better to just do an explicit 'if file_exists' or something along those lines test, after testing for the presence of non-local file paths of course. If the file path is not local, don't run the script, exit.
But in all cases, once you've started even thinking about security, you're 90% of the way home, usually protecting a script completely involves just a line or two of code, checking a parameter value, a little validation, it's really not that big a deal, but if you aren't aware, trust me, there are people out there who test sites all the time, I see it in my logs constantly.
[ Message was edited by: lizardz 10/23/2005 06:58 pm ]
|
|
dirty_shame
Joined: Aug 28, 2005
# Posts: 191
|
Posted: 2005-Oct-24 06:41
True, client side's a problem with HTTP_REFERER. Here's another simple one that doesn't depend upon it completely for a POST form:
<?
$ErrorMessage = "Go Fish";
if($_SERVER[REQUEST_METHOD] == "GET" OR stristr($_SERVER[HTTP_REFERER], "?" ){
$err = 1;
}elseif(!$_POST[submit]){
$err = 1;
}else{
foreach($_POST as $VarKey => $VarVal){
if(eregi("(%[a-f0-9])", $VarVal) OR stristr($VarVal, '0x')){ //check for HEX
$err = 1;
}
}
}
if($err){
echo"$ErrorMessage";
}else{
process the form
}
?>
Basically it just rejects GET vars and hex values and requires a POST[submit]. Nothing tough here either.
Note: I see after posting that it stripped the pipes out of the posted code. Guess I'm not familiar with posting it otherwise so I replaced them with the word OR.
|
|
lizardz
Joined: Nov 12, 2004
# Posts: 1394
|
Posted: 2005-Oct-24 08:38
damn, pressed the clear instead of submit button, oh well.
anyway, you also have to test for other stuff, isset, covers some instances, not all, array_key_exists, protects better in some instances, on and on. And that's before you even start actually doing any data validation.
By the way, forms the above poster's supplier/hoster is giving him use formail, a popular hack target.
Always be VERY wary of 3rd party scripts, they tend to be very bad, I avoid them unless absolutely necessary. Plus most of them just are either too generalized, too specific, too poorly written, etc, to be useful, with many noteable exceptions to this rule.
You can use broken pipes, they work fine. A code forum not allowing easy insertion of code is annoying to put it mildly, the stock phpbb handles all that stuff fine, I think this phpbb forum hack got broken at some point way back when...
|
|
dirty_shame
Joined: Aug 28, 2005
# Posts: 191
|
Posted: 2005-Oct-24 21:29
The code snippets I post here are intended only to encourage PHP newcomers to take a look at their own validation/security issues. They are not solutions by any means. The snippets prevent social tampering at best but anybody can plug them in, fool with them or change them as they like to see how they work. Bottom line, it just inspires them to get started.
A full-blown discussion of the merits of complex validation routines - like the ones we use on our own sites - is a different topic altogether. Just the PHP aspects alone involve so many variables, techniques and methods that it covers a monstrous scope for beginners.
It is, however, a great topic for a different thread in these forums since the need for security and validation becomes keener every day.
|
|
lizardz
Joined: Nov 12, 2004
# Posts: 1394
|
Posted: 2005-Oct-24 21:40
Yeah, I agree, the main problem is not being aware of security matters and web programming in the first place. Another thing to keep in mind is that several popular open source packages had major security holes in them, formaiil was one, awstats was another, these security holes are in some cases [awstats] severe enough to allow remote users to take over the actual server.
Once you start thinking about security, you'll start taking note of the stuff a little, it takes a while to figure it out, the best are getting hit all the time, google several times in the last year have had major security breaches, and some less major ones, and you'd think they'd know better.
It's just hard to think of every possible combination of attacks and weaknesses.
However, the referer checker is one I'd avoid using because it can trigger unrelated errors, and actually make matters worse, which is not what a newbie in general needs.
|
|
samstephens
Joined: Nov 10, 2005
# Posts: 2
|
Posted: 2005-Nov-11 00:55
I actually find the Referrer variable a problem too - security software like Norton Internet Security can withhold this kind of info, and some web servers don't support it (I had this problem a few years back).
And Lizards, Awstats has a security issue where people can take over your server? That's a little nasty - is that the latest versions, or has it been patched since then?
cheers
Sam
|
|
lizardz
Joined: Nov 12, 2004
# Posts: 1394
|
Posted: 2005-Nov-11 01:21
Awstats has been patched, but whether or not webhosters have installed the patch is another question altogether.
I forgot about the Norton 'internet security' blocking the referer, that's right, that was a biggy too. That's why you don't use referers for anything.
Almost every major webbased application will be compromised at some point, open source ones will generally be patched very quickly if they have an active development community, but they still are just as vulnerable as anything else.
|
|
dirty_shame
Joined: Aug 28, 2005
# Posts: 191
|
Posted: 2005-Nov-11 20:37
A workaround that we've employed recently to avoid problems with Norton IS, Corporate firewalls and anal-retentive technophobes is three-fold. We use it in our online ordering systems that need to track customers accurately. It goes something like this:
First we check the user-agent against an array of known crawlers and bots to identify it as a legitimate visitor (since SEs don't like cookie requests anyway). If it's not in the list, we attempt to set a session cookie.
On the next page (or even the same one reloaded) the script checks to see if the cookie is successfully set.
Finally, if the user-agent isn't a bot and still won't accept a cookie (because the security settings are too high or Norton rejects them or some firewall blocks them or...) then the page will pass the session variable into the URL which is then the last resort to track the customer order.
The result of all this is that the Search Engines can crawl all the pages unmolested - without ever having been asked for anything - and index them cleanly. Browsers set to standard security can order with the cookie set transparently and for those who are stuck behind bomb-proof corporate firewalls, the pages will track 'em in the URL.
We have to do all this because every software secutiry system in the universe is set to "worst-case-scenerio" status to dispel hackers, viruses, bugs and phishing scams.
While all that's necessary, it just makes ordering a tube of tooth paste or a new CD a lot more elaborate. This method can also work with logs and stats as a filter.
|
|
You are not permitted to post messages in this forum or topic, because of one or more of the following reasons:
- You have not yet logged in, or registered properly as a member
- You are a member, but no longer have posting rights.
- This is a private forum, for which you do not have permissions.
If you are a recent member, it's possible that you simply have not yet confirmed your account. Please
check your email for a message entitled 'JimWorld Forums: Confirm Your Account' and follow the instructions
contained within.
If you cannot find this message, click here to Re-Send it.
|
If you are still experiencing problem, please read the
Login Assistance
Article for some advice on what may be causing your login not to work properly.
|
Switch to Advanced Editor and ...
Create a New Topic
or Reply to this Thread
|
|
Inbox
