MCIS/UA PHP Training 2003 Chapter 9 Web Techniques, Security, - PowerPoint PPT Presentation

MCIS/UA PHP Training 2003 Chapter 9 Web Techniques, Security, & Design

Introduction • This chapter will cover several miscellaneous topics concerning web application design in PHP and in general that were not covered elsewhere. • Persistence • Error handling • Maintenance • Security • Design • PHP5 preview persistence

Persistence ->

Persistence hidden form variables

Persistence • Persistence (sometimes referred to as state) refers to the ability to retain information between web requests and across servers • In PHP , this is primarily done in any of the following ways: • Hidden form variables • Session data • Cookies hidden form variables

Hidden Form Variables • Hidden form variables can be used to pass information from one web request to the next • Persistent only for the next web request • Not necessarily secure (can be spoofed) • use the 'form_hidden' form element • See modify.php for an example $form->add_element('form_hidden', array('name' => 'shortname'), $shortname); session data

Session Data • Data stored in the $_SESSION array will automatically be retained across web requests • Persistent across the entire "session" $_SESSION['uniqueid'] = 'covertka'; • Session data can extend to multi-dimensions $_SESSION['names']['covertka'] = 'Kent Covert'; $_SESSION['names']['tepeds'] = 'Dirk Tepe'; • More secure than form data or cookies cookies

Cookies • Cookies are name/value pairs of data that are stored within the user's browser • Can also be arrays - but stored as individual items • Persistence can be current session or longer (basically indefinite) • Not necessarily secure (can be spoofed) • Cookies are tied to browser (not user) • Cookies are set using the setcookie() function setcookie( name [, value [, expire [, path [, domain [, secure ]]]]]); ->

Cookies • Can contain the following attributes: • name - the name for the cookie - no whitespace or semi- colons - must be unique for this domain • value - the value for the cookie - should be less than 3.5 KB • expire - when the cookie should expire - specified as number of seconds since 1/1/1970 GMT - if not specified, then cookie expires at end of session • path - the URL path this cookie should apply to - if not specified, applies to the current directory only • domain - the IP domain that the cookie should apply to - if not specified, applies to the current host only • secure - if set, will only apply the cookie to https connections ->

Cookies setcookie('uniqueId', 'covertka'); setcookie( 'uniqueId', #name 'covertka', #value mktime(0, 0, 0, 1, 1, 2030), #expire '/', #path '.muohio.edu', #domain 0); #secure setcookie('names[covertka]', 'Kent Covert'); ->

Cookies • Cookies are returned in the $_COOKIE array $uniqueId = $_COOKIE['uniqueid']; $name = $_COOKIE['names']['covertka']; error handling

Persistence Summary Hidden Form Session Data Cookies Data Secure no relatively no session or Lifetime session session any other time Can be used by other yes no yes applications Tied to session/user session/user browser error handling

Error Handling • We will discuss the following items: • Normal error handling • Changing default error handling • Error report suppression • Triggering errors • Custom error handling • PHP5 error handling Normal

Normal Error Handling • Under normal conditions, any statement that produces a warning or error, will cause a message to be displayed. • warnings - execution continues • errors - execution stops Warning : fopen("nonexistentfile.txt", "r") - No such file or directory in /usr/local/www/share/ htdocs/phpdev/covertka/test2.php on line 3 • Most functions return an error value (false, NULL, etc) • Textual error messages are generally stored in the $php_errormsg global variable following an error error_reporting()

Changing default error handling • Which conditions are reported can be controlled with the error_reporting() function. • Parameter is an bitfield of the conditions to report. • By default, error_reporting is set to the following: error_reporting(E_ALL & ~E_NOTICE) • A list of error constants can be found in the PHP documentation error_suppression

Error Report Suppression • Error reporting can be suppressed for any statement by preceeding it with an @. $fh = @fopen("nonexistentfile.txt","r"); • Only suppresses the reporting of the error • $fh will still contain FALSE triggering errors

Triggering errors • An application can trigger an error with the trigger_error() function trigger_error( message [, type ]); • message is the textual error message to display (and put in $php_errormsg) • type is the error level to generate: • E_USER_ERROR • E_USER_WARNING • E_USER_NOTICE custom error handling

Custom Error Handling • An application can replace PHP's global error handler with its own custom global error handler with the set_error_handler() function. $oeh = set_error_handler('myErrorHandler'); • Returns the old error hander • All runtime warnings and notices will be sent to the custom error handler • Does not include fatal errors, parse errors, internal PHP errors, etc. ->

Custom Error Handling • Custom error handlers should be defined with the following parameters: • error - error code • error string - textual error message • filename - name of file the error occurred in, optional • line number - line number where error occurred, optional • symbols - copy of the active symbol table, optional example

Custom Error Handling function myerrorhandler($error, $error_string, $filename, $line, $symbols) { die("Got to myerrorhandler: $error_string"); } set_error_handler('myerrorhandler'); PHP5

PHP5 Error Handling • PHP5 will introduce the try...catch methodology that's used in C++, Java, etc. try { $fh = fopen($filename,"r"); $content = fget($fh, 1024); fclose($fh); } catch(Exception $e) { $emsg = $e->getMesage(); die "An error occurred reading the file: $emsg"; } • PHP5 is in beta now. example

Maintenance • Several items can help with long-term maintenance • File/URL paths • Published URLs • Class/Objects/Libraries File/URL paths

File/URL paths • File/URL paths change over the life of an application • Development -> Staging -> Production • Future maintenance/modifications • Pain for Technical Services and Data Admin solutions

File/URL paths • Use relative URLs whenever possible $navmenu = array("Search" => "search.php"); • When full URLs or paths are needed, use pre- defined constants if possible • MU_WEB_HOST - https://webdev.admin.muohio.edu • MU_WEB_APP_DIR - /phpdev • MU_WEB_STATIC_DIR - /static • MU_FS_APP_DIR - /usr/local/www/share/htdocs/phpdev • MU_FS_STATIC_DIR - /usr/local/www/share/htdocs/static published URLs

Published URLs https://admsol02.mcs.muohio.edu:11180/phpapps/ finance/raises.php X https protocol required X Specific machine X Port X Specific file X No webcache X Long URL X Not flexible/maintainable better

Published URLs http://www.admin.muohio.edu/phpapps/finance/raises/ https protocol optional No specific machine No ports No specific files Uses webcache More flexible X Specific path X Long URL best

Published URLs http://www.muohio.edu/raises/ https protocol optional (currently not allowed) No specific machine No ports No specific files Uses webcache Short URL Most flexible (bookmarks still a problem...today) classes/objects/libraries

Classes/Objects/ Libraries • Begin thinking of code reuse. do

Security • Some security concerns have already been dealt with or disabled • register_globals is disabled ->

Security • Be wary of any user-controlable data: form data, cookies, etc. • Don't use in filenames (e.g. '/etc/passwd' or '../../../ index.php') • Don't use in system() function system("grep somefile.txt $username"); print $username; covertka; rm -r / 2> /dev/null • Don't use in eval() function ->

Security • Use SQL placeholders • $_REQUEST variable is populated in the following order: • Get variables • Post variables • Cookies ->

Security • Don't trust that your form processing PHP program was actually called from the form you wrote • Easily spoofed • Use session variables rather than cookies or hidden form elements if in doubt ->

Security • PHP (and most other Web App Development environments) trusts everyone with development access to the system • If your application has information that must be secured from others on the system, use Zend Encoder design

Design ->

Design • People don't read web pages. • Data driven, not function driven • Think of MS Word ->

Questions?