Keeping in mind that we're passing the session identifier in a cookie, and this already requires that an attack be used to compromise this cookie (and likely all HTTP headers as well), we should pass this fingerprint as a URL variable. This must be in all URLs as if it were the session identifier, because both should be required in order for a session to be automatically continued (in addition to all checks passing).

In order to make sure that legitimate users aren't treated like criminals, simply prompt for a password if a check fails. If there is an error in your mechanism that incorrectly suspects a user of an impersonation attack, prompting for a password before continuing is the least offensive way to handle the situation. In fact, your users may appreciate the extra bit of protection perceived from such a query.

__________________
With,
J. Jeyaseelan
Everything Possible

There are many different methods you can use to complicate impersonation and protect your applications from session hijacking. Hopefully you will at least do something in addition to session_start() as well as be able to come up with a few ideas of your own.

Some experts claim that the User-Agent header is not consistent enough to be used in the way described. The argument is that an HTTP proxy in a cluster can modify the User-Agent header inconsistently with other proxies in the same cluster. While I have never observed this myself (and feel comfortable relying on the consistency of User-Agent), it is something you may want to consider.

The Accept header has been known to change from request to request in Internet Explorer (depending on whether the user refreshes the browser), so this should not be relied upon for consistency

__________________
With,
J. Jeyaseelan
Everything Possible

When on a shared host, security simply isn't going to be as strong as when on a dedicated host. This is one of the tradeoffs for the inexpensive fee.

One particularly vulnerable aspect of shared hosting is having a shared session store. By default, PHP stores session data in /tmp, and this is true for everyone. You will find that most people stick with the default behavior for many things, and sessions are no exception.

__________________
With,
J. Jeyaseelan
Everything Possible

Unfortunately, it is pretty trivial to write a PHP script to read these files, and because it runs as the user nobody (or whatever user the web server uses), it has the necessary privileges.
The safe_mode directive can prevent this and similar safety concerns, but since it only applies to PHP, it doesn't address the root cause of the problem. Attackers can simply use other languages.
What's a better solution? Don't use the same session store as everyone else. Preferably, store them in a database where the access credentials are unique to your account. To do this, simply use the session_set_save_handler() function to override PHP's default session handling with your own PHP functions.

__________________
With,
J. Jeyaseelan
Everything Possible

while we include the files in PHP, we have to careful on

* Exposed Source Code
* Backdoor URLs
* Filename Manipulation
* Code Injection

__________________
With,
J. Jeyaseelan
Everything Possible

you create secure authentication and authorization mechanisms and protect your applications from things like brute force attacks and replay attacks as the belows

* Brute Force Attacks
* Password Sniffing
* Replay Attacks
* Persistent Logins

__________________
With,
J. Jeyaseelan
Everything Possible

Setting expose_php = off in php.ini will prevent PHP sending a header with the PHP version in it.

__________________
With,
J. Jeyaseelan
Everything Possible

Many exploits use wget. So don't install wget, rename wget or make sure www-data can't use wget. An easy fix is setfacl -m u:www-data:--- /usr/bin/wget. There are many more wget alike programs. Use a very minimalistic chroot to ease administration.

__________________
With,
J. Jeyaseelan
Everything Possible

Errors are very helpful when debugging but could also reveal too much information. So display_errors should be turned off when deploying an application. Errors are needed if a bug in the production version pops up. It is possible to log errors to a file or syslog with the log_errors and error_log settings. The developer should get the bug, not the user.

It's also good practice to log all failed and successfuly authentication attempts.

__________________
With,
J. Jeyaseelan
Everything Possible

we have to avoid the exposure of your source code and session data to protect your applications from attacks such as session injection.

By this way we have ensure that to provide certain security to the pages

__________________
With,
J. Jeyaseelan
Everything Possible

Hi,
If you want to know more on PHP security then u can go the PHP Security Consortium Library at PHP Security Consortium: Library.

__________________
With,
J. Jeyaseelan
Everything Possible

Session Security

* Sessions are a common tool for user tracking across a web site.

A few simple techniques can help to hide PHP,All user inputs are unreliable and can’t be trusted.

__________________
web design services
free web templates

When PHP installed as CGI the following cases to be considered
* only public files served
* using --enable-force-cgi-redirect
or

A good way to ensure that security.inc is always included at the top of every PHP script is to use the auto_prepend_file directive.

__________________
web design
Free Templates

PHP is a powerful and flexible tool. This power and flexibility comes from PHP being a very thin framework sitting on top of dozens of distinct 3rd-party libraries. Each of these libraries have their own unique input data characteristics. Data that may be safe to pass to one library may not be safe to pass to another.
----------------------------
Tom
-----------------------------
Keyword Research Florida Health Insurance