PHP and Security

PHP and Security:

In today’s world most of the web applications and sites are developed using PHP. PHP is more popular among other web programming language and easy to learn too. PHP provides a wide variety of security features. Since every programmer or developer cannot modify the server files of apache or .htaccess files security gets low and vulnerability are increased. But PHP provides various security features that prevent any unwanted or spamming or hacking activities form your personal web application or site.

There are several methods for making the applications secure create through PHP and are as follows.

SQL Injection

In this case someone enters an SQL fragment as a value in your URL or web form. This can be avoiding by suspicious of any input you accept from a user. PDO prepared statement can be the efficient method to prevent this sort because prepared statement separate the data from the instructions moreover it prevents data from being treated as anything other than data.

XSS (Cross site Scripting)

The essence of any attack is the injection of code (usually javaScript code but it can be any client-side code) into the output of your PHP script. This action is possible when you display input that was sent to you, such as would do with a forum posting for example. The attacker may post javaScript code in his message that does unspeakable things to your site.

Source code Revelation

We all know that PHP is server side – you can’t just do a view source to see a script’s code. But if something happens to Apache and all of a sudden your scripts are served as plain text, people see source code they were never meant to see. Some of that code might list accessible configuration files or have sensitive information like database credentials.

The solution centers around how you set up the directory structure for your application. That is, it isn’t so much a problem that bad people can see some code, it’s what code they can see if sensitive files are kept in a public directory. Keep important files out of the publicly-accessible directory to avoid the consequences of this blunder.

Remote File Inclusion

Suppose you have a situation where your site at www.example.com .com includes the library www.goodpeople.com/script.php. One night, www.goodpeople.com is compromised and the contents of the file is replaced with evil code that will trash your application. Then someone visits your site, you pull in the updated code, and Bam! So how do you stop it?

Fortunately, fixing this is relatively simple. All you have to do is go to your php.ini and check the settings on these flags.

  1. allow_url_fopen – indicates whether external files can be included. The default is to set this to ‘on’ but you want to turn this off.
  2. allow_url_include – indicates whether the include(), require(),include_once(), and require_once() functions can reference remote files. The default sets this off, and setting allow_url_fopen off forces this off too.

 

Session Hijacking

If someone steals a session key, is that bad? And the answer is: if you aren’t doing anything important in that session then the answer is no. But if you are using that session to authenticate a user, then it would allow some vile person to sign on and get into things. This is particularly bad if the user is important and has a lot of authority.

So how do people steal these session IDs and what can decent, God-fearing folk like us do about it?

Session IDs are commonly stolen via a XSS attack, so preventing those is a good thing that yields double benefits. It’s also important to change the session ID as often as is practical. This reduces your theft window. From within PHP you can run thesession_regenerate_id() function to change the session ID and notify the client.

For those using PHP5.2 and above (you are, aren’t you?), there is a php.ini setting that will prevent JavaScript from being given access to the session id (session.cookie.httponly). Or, you can use the functionsession_set_cookie_parms().

Session IDs can also be vulnerable server-side if you’re using shared hosting services which store session information in globally accessible directories, like /tmp. You can block the problem simply by storing your session ID in a spot that only your scripts can access, either on disk or in a database.

Cross Site Request Forgery

Cross Site Request Forgery (CSRF), also known as the Brett Maverick, or Shawn Spencer, Gambit, involves tricking a rather unwitting user into issuing a request that is, shall we say, not in his best interest

Directory Traversal

There are a few ways to protect against this attack. The first is to wish really, really hard that it won’t happen to you. Sometimes wishing on fairies and unicorns will help. Sometimes it doesn’t. The second is to define what pages can be returned for a given request using whitelisting. Another option is to convert file paths to absolute paths and make sure they’re referencing files in allowed directories.