Home Accessibility Courses Twitter The Mouth Facebook Resources Site Map About Us Contact
 
Python and Tcl - public course schedule [here]
Private courses on your site - see [here]
Please ask about maintenance training for Perl, PHP, Lua, etc
 
Defensive coding techniques in PHP?

I used to write CAD system software (many moons ago), and when doing so I used what I call "defensive coding techniques". Which meant that I never trusted user input, that a file would be available, that I could write correctly to a device - I tested, tested and tested again. In our environment, it made huge sense. The application had to be installed on a wide variety of machines and be self configuring, and to report back in layman's terms about any problems. User inputs - typically made by draughtsmen who were excellent in their filed but very new to computers - had to be tested for the right type of content, and sensibility too. And checks had to be made on system resources to make sure that they really were available. It was no good just pouring the output to a pen plotter onto an RS232 port on which the plotter was switched off or off-line or out of paper - a meaningful trap and error message was needed.

So why is it that I see so many PHP web applications written in a non-defensive manner, and indeed I write non-defensive PHP pages myself?

* Web applications in PHP are running for hundreds or thousands of users on a single server, so the issues of installation and resources on lots of individual machines do not apply

* There are far few inputs to a PHP page, and it's running as a "batchlet", so that the inputs are far more controlled and easily validated

* There is no need to defend agaist array overruns due to dynamic memory allocation; the power of the computer is used to eliminate from within the language things that the authors of code have had to do for themselves for years.

* Modern language have far better error trapping and handling built in to them. So that although error conditions need to be checked, it's done at a very much higher level

* With PHP code being writeable so much faster than traditional code, you're working with a much smaller developer team - perhaps just one person where there would have been 3 had you been using C or Fortran. So there's no need for you to have as much testing and checking at the interface between various parts of your system - they're an individual's call to another of his functions and not a possible API misunderstanding between to members of a team

* With huge numbers of users on a single instance of the code, any error will be reported and shake out quickly; if the absence of defensive code leads to a problem it will be seen by a higher number but a lower proportion of users - soreported faster, but less upsetting to the user community.

You may not agree with all of the above, but look at each carefully and it's a justification for not writing code as defensively in PHP as you would have in C++.

My personal view?

There is no need to code as defensively as you would have done in the past os projects that (in PHP) are quite small - BUT - you should remember that when you develop what you think will be a small application, it's likely to end up turning into something bigger. And that you might want to share code later in which case a few extra checks and balances may be no bad thing.

And you should ALWAYS secure your PHP application against injection attacks!




OK - Let's answer that "the other way around" ;-)

Put another way, you should take a step back and when you right code you should decide WHAT you're defending against. And in a web / PHP environment it's different to what it was in a traditional coding environment!

You MAY be able to ease up on some of the traditional "defences" but you need to add things like ...
• Injection Attack considerations - technical (<, ", ' \ and space characters, file names that start / or ../, etc)
• Injection of undesired content (malicious and silly sign ups, content into anything that manages content such as blogs, forums)
• Action to ensure that the HTML you generate is high quality / always to standard - helps avoid browser dependency issues
• Issues with login systems / cookies / account hijacking
• User documentation issues - your users on the web are unlikely to call you if they can't understand how to use the site, where such issues would have been picked up during training on the CAD system
• Tests to ensure that robots (some of which are malicious) can't do large scale damage.
• protect code against installation on systems which may have register_globals on, or magic_quotes off, or short_tags off - which can make a difference to the source code.
• allow for system changes later - PHP4 to PHP5 if you copy objects, and modules such as mysql -> mysqli (or perhaps sqlite in the future?)
(written 2008-07-02)

 
Associated topics are indexed as below, or enter http://melksh.am/nnnn for individual articles
H115 - Designing PHP-Based Solutions: Best Practice
  [4691] Real life PHP application using our course training MVC example - (2016-06-05)
  [4641] Using an MVC structure - even without a formal framework - (2016-02-07)
  [4326] Learning to program - comments, documentation and test code - (2014-11-22)
  [4118] We not only teach PHP and Python - we teach good PHP and Python Practice! - (2013-06-18)
  [4069] Even early on, separate out your program from your HTML! - (2013-04-25)
  [3926] Filtering PHP form inputs - three ways, but which should you use? - (2012-11-18)
  [3820] PHP sessions - a best practice teaching example - (2012-07-27)
  [3813] Injection Attacks - PHP, SQL, HTML, Javascript - and how to neutralise them - (2012-07-22)
  [3539] Separating program and artwork in PHP - easier maintainance, and better for the user - (2011-12-05)
  [2679] How to build a test harness into your PHP - (2010-03-16)
  [2430] Not just a PHP program - a good web application - (2009-09-29)
  [2221] Adding a newsfeed for your users to a multipage PHP application - (2009-06-06)
  [2199] Improving the structure of your early PHP programs - (2009-05-25)
  [1794] Refactoring - a PHP demo becomes a production page - (2008-09-12)
  [1623] PHP Techniques - a workshop - (2008-04-26)
  [1533] Short and sweet and sticky - PHP form input - (2008-02-06)
  [1490] Software to record day to day events and keep an action list - (2007-12-31)
  [1487] Efficient PHP applications - framework and example - (2007-12-28)
  [1482] A story about benchmarking PHP - (2007-12-23)
  [1391] Ordnance Survey Grid Reference to Latitude / Longitude - (2007-10-14)
  [1390] Converting from postal address to latitude / longitude - (2007-10-13)
  [1389] Controlling and labelling Google maps via PHP - (2007-10-13)
  [1381] Using a MySQL database to control mod_rewrite via PHP - (2007-10-06)
  [1323] Easy handling of errors in PHP - (2007-08-27)
  [1321] Resetting session based tests in PHP - (2007-08-26)
  [1194] Drawing hands on a clock face - PHP - (2007-05-19)
  [1182] Painting a masterpiece in PHP - (2007-05-10)
  [1181] Good Programming practise - where to initialise variables - (2007-05-09)
  [1166] Back button - ensuring order are not submitted twice (PHP) - (2007-04-28)
  [1052] Learning to write secure, maintainable PHP - (2007-01-25)
  [1047] Maintainable code - some positive advice - (2007-01-21)
  [945] Code quality counts - (2006-11-26)
  [936] Global, Superglobal, Session variables - scope and persistance in PHP - (2006-11-21)
  [896] PHP - good coding practise and sticky radio buttons - (2006-10-17)
  [839] Reporting on the 10 largest files or 10 top scores - (2006-08-20)
  [572] Giving the researcher power over database analysis - (2006-01-22)
  [563] Merging pictures using PHP and GD - (2006-01-13)
  [426] Robust checking of data entered by users - (2005-08-27)
  [394] A year on - should we offer certified PHP courses - (2005-07-28)
  [340] Code and code maintainance efficiency - (2005-06-08)
  [261] Putting a form online - (2005-03-29)
  [237] Crossfertilisation, PHP to Python - (2005-03-06)
  [123] Short underground journeys and a PHP book - (2004-11-19)

H117 - Security in PHP
  [4642] A small teaching program - demonstration of principles only - (2016-02-08)
  [3747] An easy way to comply with the new cookie law if your site is well designed - (2012-06-02)
  [3698] How to stop forms on other sites submitting to your scripts - (2012-04-15)
  [3210] Catchable fatal error in PHP ... How to catch, and alternative solutions such as JSON - (2011-03-22)
  [2939] Protecting your images from use out of context - (2010-08-29)
  [2688] Security considerations in programming - what do we teach? - (2010-03-22)
  [2628] An example of an injection attack using Javascript - (2010-02-08)
  [2025] Injection Attack if register_globals in on - PHP - (2009-02-04)
  [1779] Injection Attacks - avoiding them in your PHP - (2008-08-31)
  [1747] Who is watching you? - (2008-08-10)
  [1679] PHP - Sanitised application principles for security and useability - (2008-06-16)
  [1542] Are nasty programs looking for security holes on your server? - (2008-02-17)
  [1396] Using PHP to upload images / Store on MySQL database - security questions - (2007-10-19)
  [1387] Error logging to file not browser in PHP - (2007-10-11)
  [1086] Injection attacks - safeguard your PHP scripts - (2007-02-20)
  [947] What is an SQL injection attack? - (2006-11-27)
  [920] A lion in a cage - PHP - (2006-11-10)
  [345] Spotting a denial of service attack - (2005-06-12)


Back to
July to December 2008 - Open Source training schedule
Previous and next
or
Horse's mouth home
Forward to
Lua Course - here is the index
Some other Articles
Dealing with The Press
Sorting in lua - specifying your own sort routine
Saying NOT in Perl, PHP, Python, Lua ...
Lua Course - here is the index
Defensive coding techniques in PHP?
July to December 2008 - Open Source training schedule
Towards Object Oriented Programming in Lua
Co-routines in Lua - co-operative processing
Conversion of c/r line ends to l/f line ends
Some sideways thoughts on the news
4759 posts, page by page
Link to page ... 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96 at 50 posts per page


This is a page archived from The Horse's Mouth at http://www.wellho.net/horse/ - the diary and writings of Graham Ellis. Every attempt was made to provide current information at the time the page was written, but things do move forward in our business - new software releases, price changes, new techniques. Please check back via our main site for current courses, prices, versions, etc - any mention of a price in "The Horse's Mouth" cannot be taken as an offer to supply at that price.

Link to Ezine home page (for reading).
Link to Blogging home page (to add comments).

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2019: 404 The Spa • Melksham, Wiltshire • United Kingdom • SN12 6QL
PH: 01225 708225 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho

PAGE: http://www.wellho.net/mouth/1694_Def ... -PHP-.html • PAGE BUILT: Sat May 27 16:49:10 2017 • BUILD SYSTEM: WomanWithCat