Session 8: Working with Form
Download
Report
Transcript Session 8: Working with Form
Session 11: Cookies,
Sessions ans Security
iNET Academy
Open Source Web Development
Objectives
Cookies
Sessions
Security
Cookies
User details such as the number of visits, names or the date of the last
visit stored on the client
Client machine sends cookies to the web server whenever there is a
request
Cookies data is sent along with the HTTP headers
Cookies can be read only from the domain that created them
Cookies have an expiration date after which they’re deleted
The maximum size of cookie’s data is 4KB
Cookies (cont.)
Setting a Cookie
Syntax
Setting a Cookie
setcookie()
Defines a cookie to be sent along with the HTTP headers
Cookies must be sent before any output. Thus, this function must be
call prior to any output, including <html>, <head> tags or any any
whitespaces
Accessing a Cookie
Accessing cookies via $_COOKIE[‘cookie_name’]
Destroying a Cookie
Deleted by the client: use removing cookies function of the browser
Deleted by the server:
Specifying an expiration time
Specifying its name only
Sessions
Sessions keeps track of user’s sessions by assigning them a unique
session ID, generated by the server, when the session starts.
The session identifier is sent to server each time a page is requested
Sessions are stored in a file on the server and are serialized
Using Sessions
To start a session, use session_start()
Ending a Session
Using session_destroy()
To remove session’s variables
Use session_unset()
Use session_unregister()
Ending a Session (cont.)
Garbage Collection: happens to the contents of a session on the server
after a session is destroyed or times out from inactivity.
PHP run GC at the ratio of 1/100 of session request.
Setting a session’s timeout
Security
Best Practices of PHP Security
Session Security
Validating User Input
Pattern Matching
Redisplaying a Form after PHP Validation
fails
Best Practices of PHP Security
Limit Access to Administrative Pages
Limit access by IP address of remote client
Best Practices of PHP Security
Including Files
Problems of naming including files with the extension different from
.php
Allow users to see PHP source code
Allow users to see password stored in files
Always name included files with .php extension
Put included files in a directory not under the published web root,
restrict access by Apache
Best Practices of PHP Security
Storing Password in the Database
Never store passwords of users in the database without encoding them
To encrypt password
Use md5() function which returns 128-bit string
Use sha1() function which returns 160-bit string
Best Practices of PHP Security
Problem of Global Variables
Always initialize variables before use it
Always access variables that come outside of PHP using global arrays
$_SERVER, $_GET, $_POST, $_SESSION
Always escape the variables that are used in SQL query (SQL injection)
Always filter variables before display their values (cross site scripting)
Session Hijacking & Fixation
Session hijacking: attacker access client’s cookies or session ID and
then attemps to use this data
Session fixation: attemping to set your session ID
Solution: store the client IP address and browser type in a session and
check them eachtime client request
Trusting User Data
GET: user data comes from form submission and URL parameters
POST: user data comes from form submission
Cookies: stored on client’ computer, also user data
Session data: can be trusted if the value is set based on validated data.
$_SERVER[] super global: comes from browser, can’t be trusted
User data should be checked and escaped properly
Data that bound for the database must have all special characters
escaped.
Data that displays should be checked for embedded HTML
Share Hosting Concerns
It’s very dangerous to use the default PHP setting to store user’s
session data in one temporary directory. Thus, all users can read our
session data
Set the temporary folder to user directory
Hide Server Information
Hide information of Database
Hide Server Information (cont.)
PHP recommended configuration
Blocking Access to the DB
Restrict by create user for localhost only
Use firewall to block the port 3306
Each application have a separate database account that can access to
only the application database.
Never use root account for application.
Question ???