Defensive Programming - Discuss
Moderator: General Moderators
- CoderGoblin
- DevNet Resident
- Posts: 1425
- Joined: Tue Mar 16, 2004 10:03 am
- Location: Aachen, Germany
Defensive Programming - Discuss
OK just talked about defensive programming in a topic and asked a few questions which may be used when designing and coding. Off the top of my head...
1) What stupid errors can a non technical 70yr old user make.
2) How can I hack into the system.
3) What happens if the database is down
4) What happens if the database structure changes.
In my opinion defensive programming is a must (providing it is not overdone) even if it does "complicate" the code. Anyone agree/disagree ?
1) What stupid errors can a non technical 70yr old user make.
2) How can I hack into the system.
3) What happens if the database is down
4) What happens if the database structure changes.
In my opinion defensive programming is a must (providing it is not overdone) even if it does "complicate" the code. Anyone agree/disagree ?
- smpdawg
- Forum Contributor
- Posts: 292
- Joined: Thu Jan 27, 2005 3:10 pm
- Location: Houston, TX
- Contact:
1. They can make mistakes that we can't even fathom. That is why you need to process every piece of information that can coming from a user. All post data, the URL, etc. Filter, filter, filter.
2. By using the URL, attempting to inject data into forms and URL's. Making a copy of the form on their local machine, editing it to remove validation, max field sizes, inject odd data in the POST that would be difficult to do from the page itself. And so much more.
3. Gracefully handle it. Show a nice error message, give some kind of explanation that doesn't give away the details of the server or query. I hate die() - I never use it. I trap all errors and have a function called showAlert that displays a formatted error message. I also log all errors, warnings and information for every page acces on mission critical sites.
4. One of the mistakes people make is doing an INSERT without specifying the field names. The moment you change field order, add or delete fields the INSERT dies and if it is a popular table, you can spend a while tracking down each place that is affected.
I think you should always use database abstraction. You never know when you may need to use another database type. Plus it also gives you a central location to log and display errors for debugging purposes.
I could go on and on...
2. By using the URL, attempting to inject data into forms and URL's. Making a copy of the form on their local machine, editing it to remove validation, max field sizes, inject odd data in the POST that would be difficult to do from the page itself. And so much more.
3. Gracefully handle it. Show a nice error message, give some kind of explanation that doesn't give away the details of the server or query. I hate die() - I never use it. I trap all errors and have a function called showAlert that displays a formatted error message. I also log all errors, warnings and information for every page acces on mission critical sites.
4. One of the mistakes people make is doing an INSERT without specifying the field names. The moment you change field order, add or delete fields the INSERT dies and if it is a popular table, you can spend a while tracking down each place that is affected.
I think you should always use database abstraction. You never know when you may need to use another database type. Plus it also gives you a central location to log and display errors for debugging purposes.
I could go on and on...
- CoderGoblin
- DevNet Resident
- Posts: 1425
- Joined: Tue Mar 16, 2004 10:03 am
- Location: Aachen, Germany
- smpdawg
- Forum Contributor
- Posts: 292
- Joined: Thu Jan 27, 2005 3:10 pm
- Location: Houston, TX
- Contact:
Missed the agree/disagree. LOL
One of the biggest mistakes that people make with PHP is that they use it for what if scenarios or 'Hey, look what I did!' and then try to force it into production. This creates situations where people wrote sloppy code as a proof of concept and then moved on which introduces all types of problems.
People also start writing a web app with no direction or planning and the resulting code/databases are a hodge podge. They force data in tables sense relationally. The do a bunch of nested loops to process a query that could have been handled with a join.
I write all of my code as if it will be production code.
I handle each situation that could cause an error by checking the results.
I also set error_reporting to E_ALL and will not accept that code with produce "good warnings." Yes, I have heard people use that term before.
I declare every variable and I take warnings about variables not existing very seriously.
I write functions or objects to deal with repetitive tasks because I don't like writing and debugging the same code over and over...
I also consult these forums and the PHP documentation when I wonder if what I am doing is right.
One of the biggest mistakes that people make with PHP is that they use it for what if scenarios or 'Hey, look what I did!' and then try to force it into production. This creates situations where people wrote sloppy code as a proof of concept and then moved on which introduces all types of problems.
People also start writing a web app with no direction or planning and the resulting code/databases are a hodge podge. They force data in tables sense relationally. The do a bunch of nested loops to process a query that could have been handled with a join.
I write all of my code as if it will be production code.
I handle each situation that could cause an error by checking the results.
I also set error_reporting to E_ALL and will not accept that code with produce "good warnings." Yes, I have heard people use that term before.
I declare every variable and I take warnings about variables not existing very seriously.
I write functions or objects to deal with repetitive tasks because I don't like writing and debugging the same code over and over...
I also consult these forums and the PHP documentation when I wonder if what I am doing is right.
-
php_wiz_kid
- Forum Contributor
- Posts: 181
- Joined: Tue Jun 24, 2003 7:33 pm
I've always tried to keep good coding practices in mind. Such as trying to keep everything efficient and secure. Unfortunately I'm a self taught college student who writes good apps but isn't sure if the code is sloppy or "hodge podge"-ish. Do you think you could give me a list of critical (and even non-critical if you have the time) things I need to do to make sure my code is good code. Not just code that works. It's always been in the back of my mind, but I didn't know where to go for these kinds of answers. Thanks.
The most critical point in my view is validation! As stated above validate everything that comes form the outside. It is disturbing how many of the so called 'professional programs' can be hacked by changing the URL or using SQL injection.
Every programmer gets sloppy now and then. I try to use OOP (even though not really OOP most of the time but a collection of related functions) to be able to track errors more easily. Also still people out there don't even structure the code and have every line start at the same position but this should be a given.
Every programmer gets sloppy now and then. I try to use OOP (even though not really OOP most of the time but a collection of related functions) to be able to track errors more easily. Also still people out there don't even structure the code and have every line start at the same position but this should be a given.
- smpdawg
- Forum Contributor
- Posts: 292
- Joined: Thu Jan 27, 2005 3:10 pm
- Location: Houston, TX
- Contact:
If you find that disturbing, this will keep you up at nights.
A while back I read about PHP-Nuke and that it had "added support" for sites that ran with register_globals set to off. How did they accomplish it? By writing a function that read every variable that came from the outside world (like $_GET, $_POST) and created variables based on those names. Call me stupid but that sounds like you have just defeated the benefits of register_globals and done something very similar to turning it back on.
And this from a "mature" PHP application thus proving that we can always learn and get better. Well most of us can...
A while back I read about PHP-Nuke and that it had "added support" for sites that ran with register_globals set to off. How did they accomplish it? By writing a function that read every variable that came from the outside world (like $_GET, $_POST) and created variables based on those names. Call me stupid but that sounds like you have just defeated the benefits of register_globals and done something very similar to turning it back on.
And this from a "mature" PHP application thus proving that we can always learn and get better. Well most of us can...
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
-
magicrobotmonkey
- Forum Regular
- Posts: 888
- Joined: Sun Mar 21, 2004 1:09 pm
- Location: Cambridge, MA
This is always a difficult one for me. Sometimes there seems to be endless potentially deadly situations in scripts. Especially when working in an environment that is large and complex. Sometimes I feel I just have to draw the line and say "I've done what I can." After all, I've got deadlines!I handle each situation that could cause an error by checking the results.