The document discusses various security issues related to sessions and form handling in PHP, as well as methods for preventing attacks. It covers session fixation, session hijacking, and form spoofing. For sessions, it recommends regenerating IDs, checking IP addresses and user agents, and using secure hashes. For forms, it suggests using a shared secret key stored in the session to validate form submissions. The document also discusses PHP filters for validating and sanitizing user input.

1. Security in PHP

2. Session Fixation
• Session Fixation. This is where an attacker
explicitly sets the session identifier of a
session for a user. Typically in PHP it's done by
giving them a url like
http://www.example.com/index...?session_na
me=sessionid . Once the attacker gives the url
to the client, the attack is the same as
a session hijacking attack.

3. Session Fixation
• This is where an attacker explicitly sets the
session identifier of a session for a user.
Typically in PHP it's done by giving them a url
like http://www.example.com/index...?session
_name=sessionid. Once the attacker gives the
url to the client, the attack is the same as a
session hijacking attack.

4. • There are a few ways to prevent session fixation (do
all of them):
• Set session.use_trans_sid = 0 in your php.ini file.
This will tell PHP not to include the identifier in the
URL, and not to read the URL for identifiers.
• Set session.use_only_cookies = 1 in your php.ini file.
This will tell PHP to never use URLs with session
identifiers.
• Regenerate the session ID anytime the session's
status changes. That means any of the following:
– User authentication
– Storing sensitive info in the session
– Changing anything about the session
– etc...

5. • Preventing fixation
• URL-based session handling appends the session URL to
every request. This method is not preferred because it
creates unattractive URLs with an appended GET
parameter and it makes URL-based caching more tricky.
Furthermore this is a potential way of starting session
fixation by distributing such links to unsuspecting users
with a preset valid session ID.
• http://mydomain.com/some/page?PHP_SESSID=xxx
• Cookie based session handling creates a cookie with the
session ID. This method is preferred because it does not
append anything to the URL while the cookie provides
good options for controlling the client-side session
lifetime. You can make the cookie expire when the user
closes the browser window, or define any time-based
cookie lifetime you prefer. Remember to delete redundant
session data on the server as well, if applicable.

7. Session Hijacking
• This is where an attacker gets a hold of a
session identifier and is able to send requests
as if they were that user. That means that
since the attacker has the identifier, they are
all but indistinguishable from the valid user
with respect to the server.

8. Session Hijacking
• Preventing hijacking
• You can do two things to effectively fight hijacking attempts.
Change the session ID on every request so an attacker cannot
continue with an exposed session ID even if the attacker knows
the current session identifier’s value.
• // Change the session ID on every request
session_regenerate_id();
• The second defense is adding some security checks to your
session handler to make sure the client is the same that started
the session. It is suggested that you check the client’s browser
and IP address. Notice that whatever information you use in
such checks can potentially be spoofed by the attacker, thus
providing only a limited help for security. Furthermore beware
that IP addresses for sessions can change for valid reasons,
which should be considered in the check.

9. Session Hijacking
• Additional checking could be done by adding
another cookie with a value that changes on every
request. Thereby not only the session ID has to be
valid together with the browser and IP coming
from the same device, but another secret value
also has to be presented by the client in order to
be trusted as the correct session owner.

10. Session Hijacking
• You cannot directly prevent session hijacking. You can
however put steps in to make it very difficult and harder to
use.
• Use a strong session hash
identifier: session.hash_function in php.ini. If PHP < 5.3, set
it to session.hash_function = 1 for SHA1. If PHP >= 5.3, set it
to session.hash_function =
sha256 or session.hash_function = sha512.
• Send a strong
hash: session.hash_bits_per_character in php.ini. Set this
to session.hash_bits_per_character = 5. While this doesn't
make it any harder to crack, it does make a difference when
the attacker tries to guess the session identifier. The ID will
be shorter, but uses more characters.

11. Session Hijacking
• Set an additional entropy
with session.entropy_file and session.entropy_length in your php.ini file. Set
the former to session.entropy_file = /dev/urandom and the latter to the
number of bytes that will be read from the entropy file, for
example session.entropy_length = 256.
• Change the name of the session from the default PHPSESSID. This is
accomplished by calling session_name() with your own identifier name as the
first parameter prior to calling session_start.
• If you're really paranoid you could rotate the session name too, but beware
that all sessions will automatically be invalidated if you change this (for
example, if you make it dependent on the time). But depending on your use-
case, it may be an option...
• Rotate your session identifier often. I wouldn't do this every request (unless
you really need that level of security), but at a random interval. You want to
change this often since if an attacker does hijack a session you don't want them
to be able to use it for too long.
• Include the user agent from $_SERVER['HTTP_USER_AGENT'] in the session.
Basically, when the session starts, store it in something
like $_SESSION['user_agent']. Then, on each subsequent request check that it
matches. Note that this can be faked so it's not 100% reliable, but it's better
than not.

12. Form Spoofing in php
• As a php developer you create lots of form in
your application.
• But how do you track that the form submitted is
submitted from your website?
• This is how you spoof a form submission:
Lets assume we have following code located at
http://www.yourdomain.com/form.php

13. Form Spoofing in php
<form action="submit.php" method="post">
<select name="myvar">
<option value="1">1</option>
<option value="2">2</option>
</select>
<input type="submit">
</form>
• From the above code we notice that the value
of $_POST[‘myvar’] is either 1 or 2.
• Now if some one saves this form from their browser
in their desktop, they can change action attribute to
the full URL of the from .They can even replace select
tag to textbox with the name ‘myvar’.

14. Form Spoofing in php
• Now the modified form will be like this
<form action="http://yourdomain.com/submit.php"
method="post">
<input type=”text” name=”myvar”
value=”333333”>
<input type="submit">
</form>
• Now this person can submit anything as the value
of $_POST['myvar'].

15. Form Spoofing in php
• The solution for this is to have a Shared secret . You
can create a Secret key everytime the form loads
and keep that key in a session. When you are
submitting it you can also pass the session key as
hidden variable. At the receiving end you can check
if the hidden secret variable is same as the session
variable .
$secret = md5(uniqid(rand(), true));
$_SESSION['secret'] = $secret;
<input type="hidden" name="secret" value="<?php
echo $_SESSION[‘secret’];?>">

16. PHP Filters
• Validating data = Determine if the data is in
proper form.
• Sanitizing data = Remove any illegal character
from the data.
• PHP filters are used to validate and sanitize
external input.
• The PHP filter extension has many of the
functions needed for checking user input, and is
designed to make data validation easier and
quicker.
• The filter_list() function can be used to list what
the PHP filter extension offers:

17. PHP Filters
• <table>
<tr>
<td>Filter Name</td>
<td>Filter ID</td>
</tr>
<?php
foreach (filter_list() as $id =>$filter) {
echo '<tr><td>' . $filter . '</td><td>' .
filter_id($filter) . '</td></tr>';
}
?>
</table>

18. Why Use Filters?
• Many web applications receive external input.
External input/data can be:
• User input from a form
• Web services data
• Server variables
• Anything from $_GET, $_POST, $_REQUEST
• Cookies ($_COOKIES)
• Files
• Some server variables (e.g.
$_SERVER[‘SERVER_NAME’])
• Environment variables
• Database query results

19. Why Use Filters?
• You should always validate external data!
Invalid submitted data can lead to security
problems and break your webpage!
By using PHP filters you can be sure your
application gets the correct input!

20. PHP filter_var() Function
• The filter_var() function both validate and
sanitize data.
• The filter_var() function filters a single variable
with a specified filter. It takes two pieces of
data:
• The variable you want to check
• The type of check to use

21. Sanitize a String
• <?php
$str = "<h1>Hello World!</h1>";
$newstr=filter_var($str,FILTER_SANITIZE_STRING);
echo $newstr;
?>

22. Validate an Integer
• The following example uses the filter_var() function to
check if the variable $int is an integer.
• If $int is an integer, the output of the code above will be:
"Integer is valid". If $int is not an integer, the output will
be: "Integer is not valid":
<?php
$int = 100;
if (!filter_var($int, FILTER_VALIDATE_INT) === false) {
echo("Integer is valid");
} else {
echo("Integer is not valid");
}
?>

23. Validate an Integer
• <?php
$int = 0;
if (filter_var($int, FILTER_VALIDATE_INT) === 0 ||
!filter_var($int, FILTER_VALIDATE_INT) === false) {
echo("Integer is valid");
} else {
echo("Integer is not valid");
}
?>

24. Validate an IP Address
<?php
$ip = "127.0.0.1";
if (!filter_var($ip, FILTER_VALIDATE_IP) === false) {
echo("$ip is a valid IP address");
} else {
echo("$ip is not a valid IP address");
}
?>