PHP security introduction - Phoenix IT MOS

bemutefrogtownΑσφάλεια

18 Νοε 2013 (πριν από 4 χρόνια και 1 μήνα)

288 εμφανίσεις

PHP security introduction                                           
                                                        
   
page 
1
 of 
85
MASTER INDEX
Part 1 : 
Overview
About this document
Prerequisites
Layout conventions
Some 
key words
L
inks
I
ntroduction
Part 2 : Security basics
 
G
eneral security measures
L
anguage specific measures
Part 3 : B
asic building blocks
The u
ser
The i
nput / 
o
utput 
d
ata
The b
rowser
The cookies
The 
HTTP
The 
s
ession
The 
Web 
s
erver
Part 4 : 
Web server details
The 
Apache
 Web server
 
and the PHP interpreter
The operating system
Dedicated 
Web server
 issue
s
S
hared 
Web server
 issues
Web server problems and solutions
Part 5 : A
pplication level 
and
 
securing 
elements
The f
orm
s
The d
atabase
The l
ogging 
The a
uthentication
The a
uthorization
 / access control 
Password cryptography
The 
c
aptcha
Part 6 : Miscellaneous attacks
Part 7 :
 
L
ook up 
chapter
 
PHP 
functions
 
mentioned 
in this document
D
irectives 
mentioned
 in this document
Key
 measures
Checklist
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
2
 of 
85
INDEX
Part 1 : 
Overview
About this document
Prerequisites
Layout conventions
Some 
key words
L
inks
I
ntroduction
Part 2 : S
ecurity 
basic
s
G
eneral security measures
­ 
Code and 
application 
structure
­ 
Testing
­ 
Input v
alidation 
­ 
I
nitialize variables
­ 
Error output
­ 
H
iding
 i
nformation
­ 
Permissions
­ 
Development 
environment
­ 
Updates
 and backup
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
3
 of 
85
L
anguage specific measures
­ 
CMS
­ 
Test t
ools
­ 
Variable life cycle and scope
The life cycle
The scope
Global
Superglobal
Local
Static (local)
Parameter
­ 
Input v
alidation and sanitizing
General definitions
PH

defines 2 filters
Important
Check if a variable is set
Validate the type
V
alidate 
the 
length/size
V
alidate
 (
sanitize
)
 the content
/format
 
Sanitize
S
ome 
inbuilt 
functions
Some examples
E
­mail filtering
Custom filter function 
Filtering of special characters
 
­ 
I
nitialize variables
Example
Conclusion
­ 
Error output
Basics in
 a p
roduction environment
Custom
ize the HTTP
 error 
message
O
ther
 possibilities
 to h
id
e
 errors
 messages
Create your 
own 
error handler
Enable full error reporting
 
for development purposes
­ 
Hiding i
nformation
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
4
 of 
85
­ 
The PHP function include()
I
ncluding files from your own 
site
I
ncluding files from remote
/
external sources
 
I
ncluding
 files 
defined by a param
e
ter
 
from your own 
site
Additional possibilities to secure include()
­ 
The 
PHP function eval()
Part 3 :
 
B
asic building blocks
The u
ser
The i
nput / 
o
utput 
d
ata
The b
rowser
­ 
Overview
­ 
URL
 
­
manipulation
­ 
Browser p
lugins
 
­
manipulation
­ 
P
roxy
 
­
manipulation
­ 
Browser cache poisoning ­attack
The c
ookies
­ 
Introduction
­ 
Session cookies
­ 
Persistent cookies
­ 
PHP 
c
ookies
­ 
The 
cookie 
eavesdropping
 ­attack
­ 
The 
c
ookie 
p
oisoning
 ­attack
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
5
 of 
85
The 
HTT
P
­ 
Introduction
­ 
Basic
 HTTP 
­manipulation
­ 
Basic
 HTTP protection
Input filtering
The 
Web 
A
pplication 
F
irewall
 
­ 
The HTTP header
 injection
 ­attack
­ 
The 
HTTP referer 
spoo
fing
 
­attack
 
­ 
The HTTP response splitting
 ­atta
ck
­ 
The HTTP request 
smuggling
 ­attack
 
The 
s
ession
­ 
Introduction
­ 
PHP session management
Start a session
The session ID
The session file
The 
session 
ID 
cookie
The 
$_SESSION
  
superglobal
Destroying a session
Basic 
session example
­ 
Session hijacking
 ­attack
 
­ 
S
ession fixation ­attack
­ 
Session poisoning ­attack
­ 
Basic concepts
 to secure sessions
The 
Web 
s
erver
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
6
 of 
85
Part 4 : 
Web server details
The 
Apache
 Web server
 
and the PHP interpreter
­ 
Apache
 basic d
irectories
­ 
PHP basic directories
­ 
R
un 
PHP as
 
Apache 
module
­ 
Run PHP as a CGI 
­ 
The 
Apache configuration
Apache
 configuration
 files
PHP configuration file
Change 
the 
configuration for 
"
PHP as Apache modul
e
"
Change 
the 
configuration for 
"
PHP as CGI
"
Schema
Where a configuration setting may be set
G
et information about 
PHP, 
Apache, 
directives
...
Syntax of directives
­ 
The 
.
htac
c
ess
 file
Overview
Example of a 
.htaccess
 file
P
revent viewing the .htaccess
 file
Simple c
heck if .htaccess is enabled
­ 
The 
php.ini
 file
Overview
Example of a 
php.ini
 file
P
revent viewing the 
php.ini
 file
The operating system
­ 
Regular tasks
­ 
Miscellaneous
­ 
Housekeeping
­ 
Additional software
­ 
Configuration 
and kernel 
issues
 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
7
 of 
85
Dedicated 
Web server
 issue
s
­ 
Introduction
­ 
Regular tasks for Apache and PHP
­ 
Miscellaneous for Apache and PHP 
­ 
O
nline
 
d
irective 
reference
­ 
Apache hardening
General issues
 ­ Apache
Hide Information
Installed 
operating system 
and 
modules
Server v
ersion
 a
n
d name
Error messages
Use only absolutely necessary Apache modules
O
perating system 
specific stuff
 ­ Apache
Isolate Apache
C
hroot
Vi
rt
ualization
Permissions
For r
oot
For 
Apache
UID / GID
I
mmut
 configuration file
(
s
)
 
Configuration issues
 ­ Apache
Protect 
the 
ServerRoot
 and configuration file(s)
Enable specific directories
CGI issues
Server Side Includes
Mitigate the effects of DoS attacks 
Miscellaneous
Additional software
 ­ Apache
m
od
_s
ecurity
mod_ssl
mod_evasive
IP filtering
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
8
 of 
85
­ 
PHP hardening
General issues
 ­ PHP
Hide Information
Version 
number
Error messages 
Change the 
file 
extension
Use only absolutely necessary 
PHP 
modules
Compiled­in modules
D
ynamic extension
 modules
O
perating system 
specific stuff
 ­ PHP
Isolate 
PHP
C
hroot
 (jail)
Permissions
UID / GID
I
mmut
 configuration file
(
s
)
 
Configuration issues
 ­ 
PHP
Protect 
the 
PHP installation 
and configuration file(s)
Limit resources
P
revent dangerous shell code execution
File and directory 
restrictions
File upload
Session security 
Avoid r
emote code execution
M
iscellaneous
Additional software
 ­ 
PHP
Suhosin Patc
h
S
hared 
Web server
 issues
­ 
Introduction
­ 
C
onfiguration
 
issues
Overview
Apache configuration
Session files directory
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
9
 of 
85
Web server problems and solutions
­ 
The register_globals directive
­ 
Information gathering
Web serve
r
 components
 
F
orcing an error message
 
Get the 
Web 
server banner
 

HTTP 
r
esponse 
h
eader
F
ingerprinting tool "HTTprint"
N
etcat

T
elnet
Internet tool
Minimize / hide
 the Web server banner 
C
heck
 
if
 the
re is an
 PHP
 interpreter
I
nformation about CMS or other tools
Get 
information 
about 
open ports
­ 
F
ile system issues
File system access
Default
 d
irectories
Upload
Hiding files / directories
Remote file inclusion
 (RFI)
 
­attack
Directory traversal
 ­attack
­ 
Web server attacks
DoS ­attack
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
10
 of 
85
Part 5 : A
pplication level 
and
 
securing 
elements
The f
orm
s
­ 
F
ields
 in general
­ 
Hidden fields
 ­manipulation
­ 
Check boxes

radio buttons
 and drop­down menus
 ­manipulation
­ 
Unwanted repeated inputs
 ­manipulation
­ 
E­mail 
fields
 ­manipulation
­ 
Cross 
S
i
t

S
cripting
 (
X
SS)
 ­attack
­ 
Form s
poofing
 ­attack
­ 
White list 
validation
­ 
URLs
The d
atabase
­ 
SQL injection
 ­attack
The l
ogging 
The a
uthentication
The a
uthorization
 / access control 
Password cryptography
The c
aptcha
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
11
 of 
85
Part 6 : 
Miscellaneous attacks
Cross­Site Request Forgeries
 (CSRF)
 ­attack
Cookies / s
ession
 
hacking
 ­attack
Web cache poi
soning ­attack
Part 7 : L
ook up 
chapter
PHP 
functions
 
mentioned 
in this document
D
irectives 
mentioned
 in this document
Key
 measures
Checklist
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
12
 of 
85
Part 1 : Overview
About this document
The goal of this document is to 
show
 PHP junior programmers the 
tip of the iceberg 
of PHP security.
 
This is not a complete description of all actual known attacks
 and wh
a
t you can do against them. T
he idea 
was to focus on the whole picture 
in order to give you a good basis and to show you how things are 
working together. You can dive in t
he
 details
 by reading the manuals
 and get the newest threads on 
specialized sites like 
OWASP
, etc.
It is possible that some attacks and solutions described here are similar, because each 
chapter
 is treated as 

whole unit (when possible)
.
 Some attacks/manipulations are described for educational purposes
 only

your 
actual
 Web server will block them by default
 
!
I tried to describe 
some 
fundamentals as simple
 
as possible
 in
 
order to let you
 
understand
 them
 
easy and 
painless
.
Prerequisites
­ You have to understand the basic concepts mentioned in the 
Computer Crash Course
.
­ You have to understand the basics of 
Web development
/design (front­end, back­end)
.
­ You have to know any high level programming language or PHP.
Computer Crash Course 
(CCC)
The Computer Crash Course contains a guideline for teachers
 
in basic computer knowledge.
It can also be used as an introduction for beginners. You have to follow the Internet links and read 
additional information concerning the keywords mentioned in the CCC document, otherwise you won't 
understand this course.
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
13
 of 
85
L
ayout conventions
blue  
Apache/PHP : directives, modules
PHP script : code, functions
Linux : commands, files, directories
URL's
php.net
  
Links
red
type in
underline
  
highlighting key words
 
blue gray
correlations
 (in a section)
Chart 3
title 
cross­reference
 
(­>  means later) or (<­  means before)
Some 
key words
­ 
"Web server" (HW+SW) also used as "Server" or "Host"
­ 
"
PHP a
pplication
"
 
also used as
 
"
Web 
a
pplication
"
,
 
"
application
","
program
", "script"
­ "client" is used as "browser" and vice versa
­ "hosting company" means "hosting provider"
­ "
directives

is used as
 "settings" 
and vice versa
 in the appropriate context
­ "Apache Web server" is also used as "Apache server"
L
inks
PHP 
php.net
(PHP) Security 
php.net security manual
phpsec.org
owasp main page
owasp top 5 security issues
Apache
apache.org
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
14
 of 
85
I
ntroduction
When
 you start thinking about PHP security, 
it's 
a good approach
 to 
make you
 familiar with the security 
basics like :
 
G
eneral security measures
 and
 
L
anguage specific measures
.
To 
get
 an overview 
of
 the 
w
hole picture
;
 
have a look at the 
B
   
asic
   
 elements
   
 
  
while
 a PHP application is 
running.
 
Y
ou have to know
,
 
how an
 element
 
works and how it 
can be 
secured. 
K
now
ing
 
about 
the most common attack
s
 and how to parry them
 completes the basic security skills !
Basic e
lements
   
        
User
 
<
­­­
­­­

PC

­­­­­­­­­­
­>
 
Internet
 <
­
­
­
­­
­­
>
 
Web s
erver
 HW
 
         
B
rowser
<
­
­
­­­­
­­­­­­­
­
 
D
ata 
­­­­­
­
­
­
­
­­
>
 
Web s
erver
 
S
W
 <­
­­­­­­­
>
PHP interpreter
<
­
­­­­­­
­­­­­­­
H
TTP 
­­­­­
­
­­­

PHP a
pplication
<
­­­
­
­
­­
­­­­­­­
 
S
ession ­
­
­
­­­
­­
>
In a simple case the 
U
   
ser
   
 
interacts
 via the 
B
   
rowser
   
 with the 
PHP application

Input
 /
 output 
D
   
ata
   
 is flowing between the browser and the 
Web 
server
 via the Internet. 
The 
HTTP
 
(Hyper Text Transfer Protocol)
 
and the so called 
S
  
ession
   
 are the 
"
carrier
s
"
 for the data flow. 
The PHP code is executed
 on the 
Web 
   
server
   
 by the 
PHP interpreter.
The 
Web server 
layers
PHP a
pplication
PHP
 interpreter
Web server SW
 (for example Apache
..
.
)
O
perating system
Web server HW
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
15
 of 
85
Part 2 : Security basics
G
eneral security measures
Code and 
application 
structure
Code
Of  course you know the importance 
to have
 valid code, invalid code can be responsible for security holes 
and
 
/
 
or unstable functioning of the application. 
Write an easy readable code for everybody and use 
comments in order to make things more clear. The guy who has to maintain your application will be able 
to 
do 
his job 
with ease 
!
Application 
structure
Divide the application in to functional blocks. The blocks are easier to check
 / fix
 in case of a
 problem
.
 
Separate the security functions 
for example 
from the 
main
 
application/
program logic. 
Build your 
own 
security library. 
Use multiple security layers (defense lines
 or defense in depth
), if one breaks the next will probably hold 
the attack.
Testing
Make excessive 
(pen) 
testing of your application to identif

and eliminating vulnerabilities
.
Input v
alidation
 
Never trust user input,  
e
nsure that people will not enter malformed or unexpected data
 !
All input data must be validated, if you don't do this you will leave your "door" wide open for attacks.
Validate the type

the 
length
 
and the content 
of 
variables

Define
/be aware of
 the life cycle of a variable

Define the 
 environment limits
 
for a variable 
as strict as possible
 (path, access...)
.
Always validate on 
the Web 
server side not on 
browser
 side.
 
When data is passing trough various subsystems,
 
re validate to be sure the subsystems receives proper 
data. 
White list ­ black list
A "white list" approach is easier to implement, because you define all data you accept. The "black list" 
approach defines, what you don't want ­ this list can be enormous and will never be complete !
I
nitialize variables
Avoid random values in variables;
 always 
properly 
initialize 
them
 prior to first use.
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
16
 of 
85
Error output
I
f the error output is turned on
:
­ 
A
ttackers 
can get 
vital information about the application
 and or sensitive data
­ 
it might give 
attackers a
n
 idea
 
how to
 break your site
Once the application goes live :
­ hide standard error messages

log error messages
 instead
­ 
show 
customize
d
 the error messages
 
and/
or switch to another 
page
 in order to continue using 
   
  
 
  
 
the application
Hiding information
It is a good practice to make your Web server "quiet". 
Hiding i
nformation avoids to give a potential 
attacker useful information 
to hack
 
your
 Web server.
 Information 
about the operating system, the Web 
server software, the used language (aka PHP), used modules, versions of installed software
,
 
standard error 
messages, 
etc 
should be suppressed or falsified.
Permissions
Permission should be valid for a minimum of time. This can concern sessions as well as access to specific 
services...
 Stolen permissions would expire (asap) and the attacker will be blocked.
Development 
environment
 
Development accounts such as user
 
name: admin, password: admin and default user
 
names and passwords 
should always
 
be 
changed
 
at least
 
before the 
application
 goes live.
 Separate the development and the 
production environment !!
Updates
 and backup
If you 
application is running on
 
a dedicated
 Web 
server keep in mind to update all software running on 
it
 
on a 
regular
 
basis

Backup is the most "forgotten" measure to secure a painless and uninterrupted running 
of your Web application.
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
17
 of 
85
L
anguage specific measures
CMS
PHP 
f
rameworks and 
pre
­
build
 CMS applications are generally very secure and could be considered an 
option for inexperienced developers
 (Drupal, 
Joomla!, 
WordPress...) 
.
Test tools
There are many PHP tools to test code security such as 
­ PHP Security Scanner for Linux 
click here
­ PHP Security Audit Tool for Linux 
click here
­ PhpSecInfo 
click here
-
WebScarab 
Proxy
click here
WebScarab is for 
analyzing
 applications that communicate using the HTTP and HTTPS protocols. 
You
 
have the possibility to check vulnerabilities of your application.
 
More
 tool
s
 at
phpsec library
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
18
 of 
85
Variable
 life cycle
 and scope
Be aware of  the variable life cycle and the scope
 mechanism !
 Unset variables
,
 if no more used
,
 for 
security reasons.
The l
ife cycle
Before a variable is used, it has no existence. It is unset.
 
So 
isset
()
 
is 
false
.
$var; 
$checked = isset($var);
The first time a variable is used

it's automatically created. 
I
t also receives a type according to the 
assignment.
 
Now
 
isset
()
 is 
true
.
 
$a = 1;
$b = 1.0;
$c = 'text';
$d = 
$
animal
['unicorn'] = '
p
ink unicorn';
Setting an existing variable to null 

$var = null;
 )
 
is a way of un
­
setting a variable. 
Another way is 
by 
using the 
unset()
 construct. 
Un
­
set variables are also empty
.
 
So 
empty()
 
is 
true
.
The empty values are for :

booleans 
FALSE
$x = FALSE;

integers and floats 
zero
$a = 0;

strings 
empty string
$c = '';

arrays 
empty array
$d = array();
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
19
 of 
85
The 
Scope
A
 scope is the context within a computer program in which a variable name or other identifier is valid and 
can be used
 (
from 
Wikipedia)
.
The 
scope
 of a variable in PHP is the context in which the variable was created, and in which it can be 
accessed
.
PHP has different variable scopes
 
:

global 

superglobal

local 

static 

parameter 
­ Global
Global scope refers to any variable that is defined outside of any function.
Global variables can be accessed from any part of the script that is not inside a function.
To access a global variable from within a function, use the "global" keyword.
­ Superglobal
S
uperglobals
 
is 
a special set of predefined global arrays containing various useful information.
T
hey
 a
re 
accessible from anywhere in your script 
(
including inside functions
).
 Exa
m
ples $_GET, $_POST, 
$_SESSION, $_SERVER ...
­
 
Local
A variable declared within a PHP function is local and can only be accessed within that function
.
Local variables are deleted as soon as the function is completed.
­ Static
 (local)
When a function is completed, all of its variables are normally deleted. However, sometimes you want a 
local variable
 to not be deleted

U
se the 
"
static
"
 keyword when you declare the variable

Then, each time 
the function is called, that variable will still have the information it contained from the last time the 
function was called
.
­ Parameter
 
(local)
A parameter is a l
ocal variable 
whose value is passed to the function by the calling code.
Parameters are declared in a parameter list as part of the function declaration. Parameters are also called 
arguments.
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
20
 of 
85
Input v
alidation and sanitizing
 
General d
efinitions
­ 
Filter
 let desired things trough, filter undesired things ou
t
 
­ 
or vice versa
­ 
Validation
checks if something meets certain criteria or not
­ 
Sanitize
make something clean and healthy
   
so filter an validation is very similar
PH

defines 2 filters
­ 
Validation
 
is used to validate or check if the data meets certain 
criteria
 ­ 
manual
­ 
Saniti
zing
 
will sanitize the data, so it may alter it by removing undesired characters ­ 
manual
Important
­ 
Use JavaScript only to show data entry errors
.
 NEVER validate input data for processing with
 JS
­ 
Do not allow 
any 
code 
(
like HTML, JavaScript, CSS, PHP
, SQL 
...
)
 in user input
 
without 

clear 
and 
  
   
defined purpose!
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
21
 of 
85
Check if a variable is set
 
(
<­ 
Variable
 life cycle
 and scope
)
Determine if a variable is set and is not 
null

The f
unction 
isset()
 r
eturns 
true
 if 
the variable
 exists and has 

value other 
 
than 
null
 or
 
false

V
alidate
 
the 
type
­ 
Get the variable type
gettype()
 
then compare if 
got
 what you want
­ Check, if
 its an
 integer
is_int()
­
 Allows only
 
an 
integer
<?php 
if ((string)((int)$_
POST
['id']) !== $_
POST
['id'])
   die (
"put a valid 
ID
 please"
); 
echo '
ID
 is ok';
?> 
­­ 
the same in less condensed code
<?php 
$raw = $_POST['id']; 
$numeric = (int)$_POST['id']; 
if ( $raw !== (string)$numeric ) 
  { 
  echo '
put a valid 
ID
 please
'

  } 
else 
  { 
  echo 'ID
 is ok
'; 
  } 
?> 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
22
 of 
85
V
alidate 
the 
length/size (value range)
<?php
$text = $_POST['pwd']; 
if (strlen($text) < 2 || strlen($text) > 10) 
 {   
  echo "please type in a keyword between 2 and 10 characters"; 
 } 
else 
 { 
  echo 'ok'; 
 }
?> 
V
alidate
 (
sanitize
)
 the content
/format
 
E
xample
 : e
­mail 
address
 filtering
<?php 
$email = $_POST['mail']; 
if (filter_var($email, FILTER_VALIDATE_EMAIL)) 
  { 
   echo "This e­mail address is considered valid."; 
  } 
else 
  { 
   echo "This e­mail address is invalid."; 
  } 
?>
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
23
 of 
85
S
anitize
 (
to a 
given
 
format)
 
You should not use the inbuilt functions blindly. Study them in order to get the functioning and limits of 
them, eventually build your own filter.
­ 
S
ome 
inbuilt
 
functions
­ 
filter_input()
 
gets external variables and filters them
­ 
strip_tags()
 
s
trip
s
 
out 
tags of 
HTML
, PHP and XML
­ 
stripslashes()
s
trips quotes escaped with slashes
­ 
addslashes()
 
m
ask
s
 special characters
 in
 put
ting
 backslashes in front 
them
­
 
htmlspecialchars()
 
­ 
converts some predefined characters to HTML entities
 
in the source code
­ 
does the minimum amount of encoding to ensure that your string is not parsed as 
  
HTML. This leaves your string more human­readable than it would be if you used 
  
htmlentities()
 
­
 
htmlentities()
 
­ 
converts characters to HTML entities in the source code
­ 
to encode absolutely everything that has an encoding
­ 
trim()
removes white spaces and other predefined characters
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
24
 of 
85
­ 
Some
 e
xample
s
­­ 
E
­mail filtering
<?php
if (!filter_input(INPUT_POST, 'mail', FILTER_VALIDATE_EMAIL)) 
 { 
  echo "e­mail is not valid"; 
 } 
else 
 { 
  echo "e­mail is valid"; 
 }
?> 
­­ 
Custom filter function 
T
he 
check_input 
function strips unwanted characters (extra space, tab, newline)
, f
rom the beginning and 
end of the data using the PHP 
trim() 
function
.
 
S
trips any quotes escaped with slashes 
using 
stripslashes() 
and passes it through 
htmlspecialchars().
<?php
function check_input($data)
{
    $data = trim($data);
    $data = stripslashes($data);
    $data = htmlspecialchars($data);
    return $data;
}
?>
I
nstead of typing the same code for each of our input fields we simply check each 
$_POST
 variable with 
the 
check_input
 function.
<?php
 
$
checked_text
 = check_input($_POST['
message
']);
 
?>
­­
 
Filtering of special characters
 
The following code will sanitize
 
in 
replacing some none
 alphanumeric characters
 by
 spaces.
<? 
$checked_text = preg_replace("/[\/\&%#*\?'$]/", " ", $_POST['message']);
 ?>
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
25
 of 
85
I
nitialize variables 
It is not necessary to initialize variables in PHP however it is a 
very
 good practice. Uninitialized variables 
have a default value of their type depending on the context in which they are used ­ booleans default to 
FALSE
, integers and floats default to zero, strings are set as an empty string and arrays become to an 
empty array.
 (from the PHP manual)
 
BUT
  
­
>
 read 
the following
T
he default value of an uninitialized variable 
can be
 problematic
 in
 case of including one file into
another which uses the same variable name. 
T
he default value of an uninitialized variable is also a major security risk with 
register_globals
 turned 
 
on. 
(
­> 
The 
register_globals
 directive
)
A
ccessing a non­existent array item can trigger errors; you may want to test arrays and array items for 
existence with 
isset
()
 before using them
 or initialize them.
E_NOTICE 
error level checks for a usage of the uninitialized variables in runtime and not in compile time.
 
The first problem is that it is too late. The second problem is that PHP doesn't warn before adding 
elements to 
an 
uninitialized array but warns before 
the 
usage of non­existing elements in properly 
initialized array. 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
26
 of 
85
Example
­ 
The
 
p
roblem
The 
$auth
 
variable can be 
modified
 from 
outside
 
if 
register_globals
 
 is 
turned
 
on
. G
et 
authentication 
granted
 in c
all
ing
 the page
 
like that 

 
page.php?
auth
=1
 
.
<?php 
function authUser($id, $pwd) 
 { 
  // do some checks on $id and $pwd 
  return $check = TRUE; // if check is ok 
 } 
if (authUser($id, $pwd)
)
 { 
   $auth = TRUE; 
 } 
if ($auth) 
 { 
   echo "
access granted
"; 
 } 
else 
 { 
   echo "
access 
denied"; 
 } 
?>
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
27
 of 
85
­ 
The s
olution
I
nitialize
 !
 
Now, if 
$auth
 is modified from outside, it will always be reset to 
false
.
<?php 
function authUser($id, $pwd) 
 { 
  // do some checks on $id and $pwd 
  return $check = TRUE; // if check is ok 
 } 
$auth = FALSE; // initialize 
if (authUser(
$
id, $pwd)
)
 { 
   $auth = TRUE; 
 } 
if ($auth) 
 { 
   echo "
access granted
"; 
 } 
else 
 { 
   echo "
access 
denied"; 
 } 
?>
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
28
 of 
85
Conclusion
Do
 always 
initialize
 variables (even in PHP) 
:

the code is easier to maintain

you 
have a known state of a variable (

defined 
variable
)

for security reasons

there will be 
no 
E_NOTICE 
error
s

applications that initialize all variables work independently of 
register_globals
 

(
­> 
The
 
register_globals
 directive
)

if certain variables 
(for example arrays) 
are not initialized before a script runs
 ­
 
errors 
can occur 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
29
 of 
85
Error output
Many errors generated and displayed by the server contain information that is 
useful
 for 
an attacker
 to 
hack your site. 
Table names
, file locations, etc can be used in MySQL injections and other hacks. You 
should 
least 
hide all error and warning reports and 
write them to a log file. 
It's useful to 
mail 
the 
reports
 
to yourself or only display 
them
 for 
specific
 IP's (your home
 for example
).
Basics in
 a p
roduction environment
1)
 
Do not display standard error messages
2)
 
Define the error reporting level
3)
 Ignore repeated errors
4
)
 
Enable error 
log
5
)
 
Write the 
error
 log
 to a file
­ 
Implementation
  in the 
php.ini or .htaccess file
 
(
­> 
The php.ini file
 

The .htaccess file
)
1)
 
display_errors = Off
2
)
 
error_reporting
()
see the 
PHP manual 
http://php.net/manual/en/function.error­reporting.php
 
3
)
 
i
gnore_repeated_errors = On
4
)
 
log_errors = On
5
)
 
error_log = /var/log/php_error.log
Custom
ize the HTTP
 error 
message
Custom
ize the HTTP
 error 
message
 in
 
order to display
 
no
 vital information concerning your 
Web server
.
.htaccess 
file entries
meaning
ErrorDocument 404 /errors/404.html
404 File Not Found
ErrorDocument 500 /errors/500.html
500 Internal Server 
E
rror
 (ex CGI script crash)
ErrorDocument 401 /errors/401.htm
l
401 Authorization Required
The html documents will be displayed instead of the standard error messages
.
 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
30
 of 
85
O
ther
 possibilities
 to h
id
e
 errors
 messages
­ 
h
ide the error message only for 
one
 statement
   
example : 
@include("filename"); 
 
   
@  
is
 the 
so called 
error control operator
­ 
hide 
the error message
s
 for a given 
script
  
put this at 
the 
top
 
of your script 
:
 
ini_set('display­erros','0'); 
Create your 
own 
error handler
It is possible to override PHP's default mechanism for handling errors. This option gives the programmer 
full control over what actions to take when an error is raised.
­ 
E
xample
 
1
, if a specific instruction fails
 :
I
f you have this code 
­>
  
$file=fopen("hello.txt","r"); 
y
ou can get this message
 
­>
 "Warning: fopen(hello.txt): failed to open stream: No such file or directory 
in /opt/lampp/htdocs/tests/control.php on line 15"
Y
ou can modify the code 
in order to hide the detailed error message 
:
<?php 
if(!file_exists("hello.txt")) 
  { 
  die("File not found"); 
  } 
else 
  { 
  $file=fopen("hello.txt","r"); 
  echo 'file is open to process now'; 
  } 
?>
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
31
 of 
85
­ 
Example 2
I
f you have this code 
­>
 
echo($test);
 and the variable does not exist
you will get 
a
 message 
like this 
­> 
Notice: Undefined variable: test in /opt/lampp/htdocs/tests/control.php 
on line 13
P
ersonaliz
ing
 the error message :
<?php 
function customError($errno, $errstr) // this is your personalized error handler function 
  { 
  echo "<b>error:</b> [$errno] $errstr"; 
  } 
set_error_handler("customError"); // overwrite the standard PHP error handler by your personalized error handler 
echo($test); // call a non existing variable in order to trigger an error 
?>
You can ad

functionality in the "customError" function. For example sending you an e­mail if an error 
occurs or stop the script
 with 
die();
.
error_log("Error: [$errno] $errstr",1,
 
"
yourMail
@
xyz.c
om","From: 
errorLog
@example
Site
.com");
Enable full error reporting
 
for development purposes
­ 
php.ini
 file
error_reporting(E_ALL | E_STRICT)
or
error_reporting(­1)
 
will show every possible error, 
even when new levels and constants are added in 
future PHP versions
Hiding information
For 
Apache
/PHP specific issues got to the following sections in this document :
<­ General security measures 

Error output
<­ 
Language specific measures
 : 
Error output
­> 
The 
Apache
 Web server
 
and the PHP interpreter 

P
revent viewing the 
php.ini
 file
­> 
The 
Apache
 Web server
 
and the PHP interpreter 

P
revent viewing the 
.htaccess
 file
 
­> 
Dedicated 
Web server
 issue
s
 : Apache hardening : 
General issues
 ­ Apache
 : 
Hide information
­> 
Dedicated 
Web server
 issue
s
 : 
PHP 
hardening : 
General issues
 ­ 
PHP : 
Hide information
­> 
Web server problems and solutions
 : 
Information gathering
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
32
 of 
85
The PHP function 
i
nclude
()
I
ncluding files from your own 
site
< ?php 
include("/directoryname/
filename
.
php
");
 
?>
­
­>
 is secure
"Hard wired" 
filenames
 
from
 your own 
site
 
can not be altered !
 
I
ncluding files from remote
/
external sources
 
< ?php 
include("http://www.remotedomain.com/
filename
.
php
");
 
?>
­
­>
 
is 
   
NOT 
   
secure
   
"
Never
"
 include any
 code 
you found on the web
 ! 
An attacker can spoof the address and try to execute a 
malicious script on your site
.
 
You can include for example plain text or 
photos
 with the 
appropriate
 filtering
 techniques
 or 
replace 
include
()
 
simply 
by 
the 
readfile()
 function.
I
ncluding
 files 
defined by a param
e
ter
 
from your own 
site
­ 
C
ode in your page
<?php include($_
GET
['page']) 
;
 
?>
­
­>
 
is 
   
NOT 
   
secure
   
  
Include a page via a variable can be alter
e
d !
­ N
ormal use 
as 
http://www.test.com/?page=
your_PHP_file
.php
­ C
an be misused by
 
http://www.test.com/?page=http://attacker.com/bad_code.php
­ Solution
s
1)
 
Put the all allowed pages in an array, then check before executing the include
<?php 
$files = array('page1.php','page2.php','page3.php'); 
if ( in_array($_GET['page'],$files)) 
  
include ($_GET['page']); 
else 
echo 'access denied'; 
// or "call" the index.php
?> 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
33
 of 
85
2)
 
Check, if 
the 
file exists on the server
<?php
$ipage = 'content/startpage.php'; // standard page
if (
isset
($_GET['page']))
 {
   $page = 
basename
($_GET['page']);
   $tpage = 'content/' . $page . '.php';
   if (
file_exists
($tpage))
    {
      $ipage = $tpage;
    }
 }
include($ipage);
?>
Additional
 p
ossibilities
 to secure 
include
()
­ use POST instead of GET
­ 
set_include_path
 
/
directory
O
f
T
he
I
nclude
F
iles
;
 
works only for the duration of the script
 !
­ 
prevent listing the included file
(s)
 
:
­ 
by using
 the
 
.htaccess
 
IndexIgnore 
/
path_to_the include_file
s
/
*
  
or
­ 
put an 
(
empty
)
 index.php file in in your
 
directory
 
wh
e
re the included file resides
 
­ The 
php.ini or .htaccess
 directives
 :
 
(
­> 
The php.ini file
 
/
 
The .htaccess file
)
­
 allow_url_include
 

Off 
 means remote files will be not included 
­ 
open_basedir
 
 
/onlyThisDirectory
 
allow
s
 
only 
the 
defined 
directory structure
 to 
access
­ see also (­> 
Remote file inclusion
 (RFI)
 ­attack
 
/ solution(s)
)
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
34
 of 
85
The 
PHP 
function
 
eval()
There are very few situations where 
eval()
 is neccessary, but if you can't avoid using it, always 
validate
/sanitize
 the string that is executed by 
eval()
. Especially when user generated content is parsed by 
the 
eval()
 function.
If you have to use eval() 
­
 e
scape shell commands in using the functions  : 

escapeshellarg()

escapeshellcmd()
(from the PHP manual)
The 
eval()
 language construct is 
very dangerous
 because it allows execution of arbitrary PHP code. 
Its use 
thus is discouraged.
 If you have carefully verified that there is no other option than to use this construct, 
pay special attention 
not to pass any user provided data
 into it without properly validating it beforehand. 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
35
 of 
85
Part 3 : B
asic building blocks
The u
ser
Problem(s)
Have you a malicious user behind the keyboard / browser which tr
ies
 to break in
to
 your application or 
web site
 
? Or is there a
n
 innocent user trying to submit the demanded data 
your application is asking for

Maybe the keyboard is not locked while 
a user is
 going to get a coffee, meanwhile 
h
i
s
 cat is running over 
the
 keyboard producing random input values...
 These are some of the possibilities input data can be 
"produced"
 and you never know which type of input 
data 
you receive!!! 
Solution(s)
Nice users should be guided 
in a 
clear and simple manner in order to get the data you want from them.
Al
l
 user input data must be validated / sanitized in order to prevent unwanted changes in your application 
and/or 
Web server
.
 (
<­ 
Input v
alidation and sanitizing 
)
The i
nput / 
o
utput
 data
Input
 data
As already mentioned before : all user input data must be carefully validated and sanitized before 
processing! 
(
<­ 
Input v
alidation and sanitizing 
)
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
36
 of 
85
Output
 
data
When displaying user generated content, like comments on a blog, 
you need to validate/sanitize the output 
in order to get what you want.
 
(
<­ 
Input v
alidation and sanitizing 
)
A
lways strip and escape the content. 
htmlspecialchars()
 converts all special characters to there html 
entities thus preventing HTML code to be rendered by the browser
 and displaying what you don't want
.
The function 
s
trip_tags()
 goes a step further and strips out all HTML tags, including J
ava
S
cript
, CSS, etc.
Example
<?php 
function check_input($data) 

    $data = strip_tags($data); 
    return $data; 

$checked_text = check_input($_POST['message']); 
echo $checked_text; 
?> 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
37
 of 
85
The b
rowser
Overview
An attacker can use his browser 
to 
attack your Web site
/server

The URL, b
rowser plugins and proxies can 
be 
misused
 
for that. 
Coo
k
ies and HTTP headers can 
so 
be modified.
 
(
­> 
The cookies
 / 
The 
HTTP
 
)
URL
 
­
manipulation
­ The problem
(s)
1)
An attacker can c
hange the browser
s
 GET 
parameter
s
 
, then send the URL to the Web server

http://www.example.com/index.php?mode=
abcd
&
id=
2
2)
In manipulating the URL, y
ou can get  an error message which gives 
you
 information about the Web 
server
s structure used software, etc

3)
Depending on the
 
applications 
behavior
 you can 
even 
get access to
 database records.
 
4)
Ad
d
ing
 
?
page
/etc/passwd
 to an URL may give you access to to valid user
 
names, 
system paths
, etc
.
­ The solution
s
­ 
Use POST instead of 
GET
 (
GET reveals the info
rmation 
sent in the URL, leaving it open to easier theft
)
­ 
Implement strong validation of your variables
/parameters
 (
<­ 
Input v
alidation and sanitizing
)
­ 
C
ustomize the error messages (<­ 
Error 
output
)
­ 
Run a 
Web 
A
pplication 
F
irewall
 
on your Web server (­> 
The 
Web 
A
pplication 
F
irewall
)
­ 
Configure your Web server as strict as possible
 (
­> 
The Web server
)
­ 
S
et the 
register_global
s
 directive to O
ff
 (
­> 
The register_globals directive
)
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
38
 of 
85
Browser p
lugins
 
­
manipulation
             
 ­ The problem 
Plugins like Tamper Data, Web Developer, Modify 
H
eaders, etc can be misused to attack
 by manipulating 
the HTTP headers.
An attacker
 can define the architecture and the the used validation principles 
in 
observing
 the results after 
having 
chang
ed
 
the 
parameters
 and/or HTTP headers
.
 
(
­> 
The HTTP
)
 
                                  
 ­ The solution
s
­ 
Implement strong validation of your variables
/parameters
 (
<­ 
Input v
alidation and sanitizing
)
­ 
C
ustomize the error messages (<­ 
Error 
output
)
­ 
Run a 
Web 
A
pplication 
F
irewall
 
on your Web server (­> 
The 
Web 
A
pplication 
F
irewall
)
­ 
Implement strong session 
management (
­> 
The session
)
­ 
Configure your Web server as strict as possible
 (
­> 
The Web server
)
Prox
y
 
­
manipulation
­ The problem 
A proxy can be used in the same way as the browser plugins mentioned above.
 (<­ 
Browser p
lugins
 
­
manipulation
)
­ The solution
­ 
Implement strong validation of your variables
/parameters
 (
<­ 
Input v
alidation and sanitizing
)
­ 
C
ustomize the error messages (<­ 
Error 
output
)
­ 
Run a 
Web 
A
pplication 
F
irewall
 
on your Web server (­> 
The 
Web 
A
pplication 
F
irewall
)
­ 
Implement strong session 
management (
­> 
The session
)
­ 
Configure your Web server as strict as possible
 (
­> 
The Web server
)
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
39
 of 
85
The c
ookies
Introduction
Cookies are 
also 
called
 HTTP cookie, 
W
eb cookie, or browser cookie
.
A cookie  is usually a small piece of data sent from a 
W
eb
 
server/site
 and stored in a 
W
eb browser
 or hard
 
disk
 as a text file
. When the user browses the same 
W
eb
 
site in the future, the data stored in the cookie can
 
be retrieved by the 
W
eb
 
server/
site to notify the user's previous activity.
 (from Wikipedia)
Many Web applications use cookies to save information (user IDs, passwords, account numbers, time 
stamps, etc.). The cookies stored on a user's hard drive maintain information that allows the applications to
 
authenticate the user identity, speed up transactions, monitor behavior, and personalize content presented 
to the user based on identity and preferences.
Session cookies
A user's session cookie for a 
W
eb
 
site exists only while the user is reading and navigating the 
W
eb
 
site.
 
Web browsers normally delete session cookies when the user exits the browser. So it is automatically 
removed when user close the web browser.
 
(from Wikipedia)
Persistent cookies
Also called a 
permanent cookie
, or a 
stored cookie
. The persistent cookie
 is stored on a use
r's 
hard
 disk
 
until it expires or until the user deletes the cookie. 
P
ersistent cookies are set with expiration dates
.
 
Persistent cookies are used to collect identifying information about the user, such as Web surfing behavior 
or user preferences for a specific Web site. 
PHP 
c
ookies
PHP have 
mechanisms
 to create, 
retrieve
 
 a
n
d delete cookies
 :

Create a cook
ie
 with
 the function 

setcookie()

R
etrieve a cookie value 
by using the
 
$_COOKIE
 variable
.

When deleting a cookie you should assure that the expiration date is in the past. 
Example
 : 
 
setcookie("
cookie_name
", "
 
", time()­3600);
 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
40
 of 
85
The 
cookie 
eavesdropping
 ­attack
The 
problem
Cookies are sent in plain text over the Internet
. This makes 
them vulnerable to packet sniffing
.
A packet sniffer can intercept and log traffic 
between a browser and a Web server
. A packet sniffer has to 
be in the same network (WiFi for example) in order to do its work. 
The 
s
olution
SSL
 
(
S
ecure 
S
ocket 
L
ayer)
 
allows 
a secure 
communicat
ion 
between the 
browser
 
and the
 Web 
server
 (via 
the Internet)
. This can
 prevent 
packet sniffing
 and tampering.
If you need 
SSL 
you have to install the SSL
 
packet on your Apache server.
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
41
 of 
85
The 
c
ookie 
p
oisoning
 ­attack
The problem 
C
ookie poisoning is the 
unauthorized 
modification
 
of a cookie
.
 
The modification can be used 
by an attacker 
to
 :

gain unauthorized information about the user
 
(
by sniffing the cookie
)

gain access to the user's existing accounts
 (
identity theft
)

open new accounts
 (in playing around with user names and passwords)

etc
The s
olution
(
s
)
1)
 Secure cookie
A secure cookie has the secure 
attribute
 enabled and is only used via HTTPS, ensuring that the cookie is 
always encrypted when transmitting from 
the browser
 to 
the Web 
server. This makes the cookie less likely 
to be exposed to eavesdropping.
 
(from Wikipedia)
setcookie( name, value, expire, path, domain, 
secure
, httponly);
The 
HTTP layer on the top of SSL 
gives
 HTTPS
.
2)
 
HttpOnly cookie
The HttpOnly cookie is supported by most modern browsers. 
If a 
client side script code attempts to read 
the cookie, the browser returns an empty string as the result. This causes the attack to fail by preventing 
the malicious (usually XSS) code from sending the data to an attacker's 
W
eb
 
site
.
 
(
­>
 
Cross 
S
i
t

S
cripting
 
(
X
SS)
 ­attack
)
PHP supports setting the HttpOnly flag since version 5.2.0
 :
­ For session cookies managed by PHP
the flag is set either permanently in php.ini 
 
session.cookie_httponly = True
   
or 
in and during a script via the function 
session_set_cookie_params
()
­ For application cookies last parameter in 
setcookie()
 set
 the "h
ttp
o
nly
"
 flag
3) 
Do 
not
 store user names and/or password
s
 in 
non secure 
cookie !!
4)
A Web Application Firewall (WAF) can block cookie poisoning attacks. 
(­> 
The Web Application Firewall
)
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
42
 of 
85
The 
HTTP
 (Hyper Text Tran
s
fer Protocol)
Introduction
The HTTP is the application­level protocol that is used to transfer data on the Internet. HTTP comprises 
the rules by which browsers and Web servers exchange information. 
Almost everything you see in your browser is transmitted to your computer over 
the 
HTTP.
The 
HTTP is a 
stateless
 protocol because each command is executed independently, without any 
knowledge of the commands that came before it
.
 
A
 browser must establish a new
 
network connection to 
the 
W
eb server with each new request. The 
W
eb server
 
cannot rely on an established network connection 
for longer than a single 
r
equest
 
from the browser
.
When the
 b
rowser sends a HTTP request
 to the Web server
, t
he Web server responds with a HTTP 
response
 to the browser

The HTTP request contains 
a
 
HTTP header
, while t
he HTTP response contains 
a
 HTTP header and the 
content
.
 HTTP 
headers
 carry information 
in plain text
.
 Each line of a 
HTTP 
header is called a header 
field.
Example
­ type in your browser : 
http://
anysite
.com
­ 
HTTP 
request
 header
HEAD / HTTP/1.0 
this is the so called request line
Host: 
anysite
.com 
Connection: Close 
­
 HTTP 
response
 header 
HTTP/1.1 200 OK
this is the so called 
response
 line
Date: Fri, 21 Dec 2012 08:41:09 GMT
Server: Apache
X­Powered­By: PHP/4.4.9
Connection: close
Content­Type: text/html
­ 
here come
s
 the 
content
 (the Web page
'
s HTML)
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
43
 of 
85
Basic
 HTTP 
­manipulation
1)
Modifying 
 the URL
 can 
be used for attack
s
. Strong 
i
nput filtering
 can avoid most of these attacks
.
 
see
 also 
(
<­ 
URL
 
­
manipulation
)
2)
Your Web application should not base any security decision on information in the HTTP headers
.
 
I
t is easy
 
for an attacker to manipulate the header
 fields
 !
The attacker can use browser plugins
 or
 
a proxy
 
in order to manipulate the HTTP header fields.
 
see also 
(<­
 
Browser p
lugins
 
­
manipulation
 / 
Proxy
 ­manipulation
)
Use a Web Application Firewall to block HTTP manipulations. (­
>
 
The 
Web 
A
pplication 
F
irewall
)
Basic
 HTTP protection
Input filtering
Filtering of user related data in the HTTP 
request 
header is the first defense line.
(
<­ 
Input v
alidation and sanitizing
)
The 
Web 
A
pplication 
F
irewall
 (WAF)

Web Application Firewalls can be either software or hardware appliance based
. T
hey are 
installed in 
front of a 
W
eb
 
server 
to
 shield it from incoming attacks.
 
Web Application Firewalls are 
also
 called 
"
Deep 
Packet Inspection Firewalls
"
 because they monitor the HTTP traffic in real time in order to detect attacks.  
They 
operates as a 
W
eb intrusion detection tool
.
Some WAF look for certain 
"
attack signatures
"
 
in order
 to identify a specific attack that an intruder may 
be sending
.
 
O
thers look for abnormal behavior that doesn't fit the 
W
eb
 
site
'
s normal 
HTTP 
traffic patterns.
 
Open source WAF : 
ModSecurity
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
44
 of 
85
The HTTP header
 injection
 ­attack
Introduction
 (from Wikipedia)
HTTP header injection is a general class of 
W
eb application
 
security vulnerability
 which occurs when 
Hypertext Transfer Protocol
 (HTTP) 
headers
 are dynamically generated based on user input. 
The problem
(s)
1)
If we can inject newline 
(aka CR LF)
 
into the 
HTTP 
request 
header we a
re in 
control
.
 
W
e will be able to 
insert some additional HTTP 
h
eader 
fields

Carriage­return
:
CR
  
or
%0D
or
/r
Line­feed
 
:
LF
  
or
%0A
or
/n
Example
A correctly filled out Web 
form 
will look
 
like :
Subject: 
Demand
From: 
my_
fake_mail
@
abcd
.com
To: 
webmaster@example
_site
.com
Your message comes here
Add
, inject 
your malicious code for spam
 
purposes 
in t
yp
ing
 in
 at the end of the Subject field : 
­ 
The
 CR LF code
 (see above)
­ 
BCC:
 user1@ex1.com, user2@ex2.com, user3@ex3.com
­ the spam message : 
this is a spam test only, sorry
The Web server will now send the spam message as a blind carbon copy (BCC) to all mentioned e­mail
 
addresses
 for YOU !
2)
Attackers inject code in to HTTP requests
 
header
 allowing them to execute arbitrary commands 
on the 
Web server
 and perform 
malicious activities such as reading, altering or destroying sensitive data. 
 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
45
 of 
85
T
he solution(s)
1) 
­ Input filtering of the meta characters, carriage­return, line­feed, slash, backslash, etc
­ Limiting the length of form fields
2)
­ Configure your Web server as strict as possible (­> 
The Web server
)
3)
­ Use a Web Application Firewall to block HTTP manipulations. (<­ 
The Web Application Firewall
)
­ Use the PHP security patch Suhosin
4)
PHP from the versions 4.4.2 
and
 5.1.2 has 
 
an in build protection against 
HTTP header
 injection
. You have 
only to secure the mail functions by hand.
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
46
 of 
85
The 
HTTP referer 
spoo
fing
 
­attack
 
Definitions
The word “referrer” is misspelled in the RFC as well as in most implementations
 
!
W
hen a user clicks 
on 
a hyperlink in a browser, the browser sends a 
HTTP 
request to the 
Web 
server
.
The request includes the destination 
W
eb
 
page
 and
 the 
R
eferer field
. The Referer field 
holds the URL of
 
the 
previous
 page 
visited
 by the user
.
A
 spoofing attack is a situation in which one person or program successfully masquerades as another by 
falsifying data and thereby gaining an illegitimate advantage.
The problem
(s)
Some
 sites
 
allow access to their materials only from 

certain login page. This is enforced by checking the 
R
eferer 
field
 of the HTTP request. This 
R
eferer 
field
 however can be 
spoofed/
changed allowing users to 
gain unauthorized access to the materials
.
 
You can put for example an URL of the member area in the Referer field in order to get access to the 
protected area of the Web site.
T
he solution(s)
Don't use the Referer header field for authentication
/authorization
 !
 Implement a session control 
mechanism instead.
 
(­> 
The session
)
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
47
 of 
85
The HTTP response splitting
 ­atta
ck
The problem
(s)
The HTTP response splitting
 allows attackers to split a HTTP response into 
two responses
 by injecting 
malicious HTTP headers.
 
This attack 
can
­
 poison 
browser
 
cache
­ poison 
w
eb cache
 (­> 
Web cache poisoning ­attack
)
­ 
trigger cross­site scripting
­ 
open the door to phishing
The attacker sends a 
single 
poisoned request to the Web server. This request generates a 
"
302 redirect
"
 and
 
a poisoned 
"
200 ok
"
 response. 
If the poisoned response is cached, 
user
s
 will get the poisoned 
response 
in 
their
 browser.
­ Extract 
from Amit Kleins white paper
 "HTTP Response Splitting" Sanctum, Inc. 2004 (yes I know it's an
 
old one) 
 The first response may be partially controlled by the attacker, but this is less important. What is material 
is that the attacker completely controls the form of the second response from the HTTP status line to the 
last byte of the HTTP response body. Once this is possible, the attacker realizes the attack by sending two 
requests through the target. The first one invokes two responses from the 
W
eb server, and the second 
request would typically be to some “innocent” resource on the 
W
eb server. However, the second request 
would be matched, by the target, to the second HTTP response, which is fully controlled by the attacker. 
The attacker, therefore, tricks the target into believing that a particular resource on the 
W
eb server 
(designated by the second request) is the server’s HTTP response (server content), while it is in fact 
some data, which is forged by the attacker through the 
W
eb server – this is the second response. 
T
he solution(s)
1)
T
he PHP interpreter contains protection against th
is
 attack since version 4.4.2 and 5.1.2
2)
D
isallow the CRLF sequence
 
in data embedded in HTTP 
response headers
3)
Filter o
ut
, on the Web server side, 
character­sequences which are normally NOT in a request header

For example 
HTTP/1.1 200 OK
HTML
 tags
JavaScript 
code
etc
4
)
Reject requests with overlong URL's. 
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction                                           
                                                        
   
page 
48
 of 
85
The HTTP request 
smuggling
 ­attack
 
(HRS)
Introduction
The 
HTTP Request Smuggling (HRS) attack is the result of a failure to properly handle deformed HTTP 
requests. HRS works by taking benefit of the discrepancies in HTTP request parsing when one or more 
"devices" (
proxies
, cache, firewall...)
 are in the data flow between the 
browser
 and the 
W
eb server.
 
B
eing 
vulnerable to HRS is increased by the use of HTTP 
pipelining.
The problem
(s)
When 

browser
 sends 

HTTP request, it will go through various 
"devices"
 like 
c
ache, proxy, firewall etc. 
before reaching the 
W
eb server. 
An a
ttacker will modify the request in these 
"devices"
. Hence 
this is
 
call
ed
 as smuggling of 

request in­between the source and destination.
HRS can be used 
:

to poison 
W
eb
 
caches
 (­> 
Web cache poisoning ­attack
)

bypass security solutions 
(
<­ 
The 
W
eb 
A
pplication 
F
irewalls
)

for the delivery of malicious payloads 
(
worms, viruses
...)

to exploit known vulnerabilities in 
W
eb servers 
Conditions to run an HRS attack :

the presence of specific proxy system and version such as SunOne Proxy 3.6 (SP4) 
 
FW­1/FP4­R55W beta 

an XSS vulnerability in the Web ­page or ­application
 
(­> 
Cross 
S
i
t

S
cripting
 (
X
SS)
 ­attack
)
created : 08/2012                                                                                                             
                                   version : 11/04/2013
by 
Marc Oscar Schwager
                                       
 
                   
http://www.phoenix­it­mos.com/
PHP security introduction