Security checklist for php project

Posted by

PHP security should never be taken lightly because it forms the foundation of practically all websites. Nonetheless, PHP developers are fortunate to be shielded from common security risks like data manipulation, SQL injections, and cross-site request forgery. And all of this is made possible by PHP’s built-in security capabilities, which facilitate website protection for developers.

When it comes to security, PHP is the programming language that receives the most flak. A significant portion of developers and QA specialists believe PHP lacks effective methods for application security. The fact that PHP is the most established and popular language for developing web applications lends credence to the assessment. However, there haven’t been any significant security improvements since PHP 5.6, therefore the language has certain security flaws.

How Secure is PHP

As safe as any other popular language is PHP. Of all the major server-side languages, PHP is the most secure. Maintaining excellent security is now simpler than ever thanks to the new PHP frameworks and tools that have been released in recent years.

Security Issues in PHP CMS

I have spent a great deal of time working on PHP security and performance concerns. I am also quite involved in the PHP community, frequently asking experienced developers about the best practises they employ in their current projects. Thus, this PHP security tutorial’s primary goal is to inform you about the best security practises for PHP online applications. The following issues will be defined, along with potential fixes, by me.

1. Update PHP Regularly

PHP 8 is currently the most recent and stable version of the language available. Additionally, we have produced the perfect PHP benchmarks for our audience. It is recommended that you update to this new PHP application. When updating PHP applications, you will encounter numerous deprecations if you are still running PHP 5.6 or 7. It will also be necessary for you to update your code and modify some functional logics, such as hashing passwords, etc. Additionally, there are tools that can assist you in converting your code and check if it is deprecated. Below is a list of various tools I use.

2. Cross-site scripting (XSS)

A malicious online assault known as “cross site scripting” occurs when an external script is inserted into the output or code of a website. While the browser is unable to recognise the malicious code as a trustworthy script, the attacker can deliver it to the end user. The majority of these attacks target locations where users can enter and submit data. Cookies, sessions, and other private browser data are all accessible to the assault. Let’s examine an example of a GET request that sends data via a URL:

With html specialchars, this attack can be deciphered. You can escape single and double quotes as well by using ENT_QUOTES.

3. Cross site request forgery XSRF/CSRF

XSS attacks are not the same as CSRF attacks. In a Cross-Site Request Forgery (CSRF) attack, the victim can carry out undesired actions on websites that have been authenticated and can send malicious orders to the website to carry out any unwanted action. CSRF mostly targets state-changing requests by providing links or modified data in HTML tags, and it is unable to read the request data. It may compel the user to carry out requests to modify their state, such as money transfers or email address changes. Look at this URL, where GET requests are being used to transfer funds to a different account:

Now, to take advantage of the online application, someone would alter the URL with the name and quantity in the manner shown before.

Now this URL can be sent via email in any file, Image etc and the attacker might ask you to download the

4. SQL Injection Attacks

The most frequent attack in PHP scripting is SQL injection. An application as a whole may be compromised by a single query. An attacker using a SQL injection attack aims to change the data you are sending through queries. Let’s say that when you are directly processing user data in SQL queries, an anonymous attacker surreptitiously circumvents it by using a different character set. View the SQL query listed below:

The database may be harmed by changed data in the $username, even to the point of instantaneous database deletion. What then is the remedy? PDA. You should always employ prepared statements, in my opinion. PDO aids in the security of SQL queries.

The connection between the database and application is made with the below statement:

Based on the ID above, you can choose a username, but be patient! Here, your query contains SQL code that is inserted, “GET data.” Take care to stay away from this kind of coding and substitute prepared statements:

Now you can avoid the above SQL injection possibility by using

Additionally, using ORMs like doctrine or eloquent is a smart idea because there is less chance of SQL queries being injected into them.

5. Session Hijacking

One specific kind of harmful web attack is called “session hijacking,” in which the attacker takes the user’s session ID covertly. The corresponding $_SESSION array on the server receives that session ID, confirms its storage in the stack, and then authorises access to the application. An XSS attack or unauthorised access to the server folder containing the session data can result in session hijacking.

To prevent session hijacking always bind sessions to your IP address to:

When working on localhost, be aware of it as it only gives you values of the :::1 or :::127 kind rather than the precise IP. Whenever a violation happens, you should act swiftly to invalidate the session (unset cookie, unset session storage, delete traces), and you should always strive to avoid exposing IDs under any circumstances.

The recommended practise when it comes to cookies is to never use serialised data that is saved in a cookie. Cookies are easily manipulated by hackers, which increases the variables within your scope. Remove the cookies safely by doing this:

The code’s first line makes sure that cookies expire in the browser, and the second line shows how to remove cookies in a conventional manner (i.e., false cannot be stored in a cookie). The cookie is eliminated from your script in the third line.

6. Hide Files from the Browser

If you’ve worked with PHP micro-frameworks, you’ve probably encountered the unique directory structure that makes sure files are placed correctly. Frameworks enable the presence of several files in that directory, such as controllers, models, configuration files (.yaml), etc., but most of the time the browser does not handle all of the files even though they are visible to the user. In order to fix this problem, you should save your files in a public folder rather than the root directory, which will prevent constant browser accessibility. Take a look at the Slim framework’s directory structure below:

7. Securely Upload Files

Any application that processes user data must have the ability to upload files. But keep in mind that, as I’ve already said in the essay, files might occasionally be utilised for XSS assaults. Going back to the fundamentals, make sure you declare the property enctype=”multipart/form-data” in the
tag and always utilise the POST request in the form. Next, use the finfo class to validate the file type as follows:

Although many frameworks, such as Laravel, Symfony, and CodeIgniter, already include pre-defined ways to validate file types, developers can still construct their own unique, ultra-secure file validation criteria.

Let’s examine one more illustration. This is how the form’s HTML should look:

And upload.php contains the following code:

8. Use SSL Certificates For HTTPS

The HTTPS protocol is advised for usage with online apps by all contemporary browsers, including Google Chrome, Opera, Firefox, and others. For untrusted websites, HTTPs offers a safe and encrypted access channel. You have to put an SSL certificate on your website in order to enable HTTPS. Additionally, it makes your web apps more resistant to XSS attacks and stops hackers from utilising codes to read data that is being transferred. With just a single click, Cloudways offers free SSL certificates that are valid for 90 days. You may quickly revoke or renew them at any time. You can configure SSL certificates in your Drupal, WordPress, Magento, and PHP apps by following the instructions.

9. Whitelist Public IP for Mysql

You commonly need to set up MySQL databases in both internal scripts and MySQL clients while working with PHP applications. The majority of clients are utilised to configure remote MySQL connections, which require an IP address or hostname supplied by the hosting server in order to establish a connection.

In order to prevent an anonymous user from accessing the database, your hosting server needs to whitelist the public IP for the remote MySQL connection. For example, Cloudways allows you to whitelist IP addresses as:

Now you can connect SQLyog or Mysql workbench to work remotely with database.

11. Document Root Setup

For PHP applications running on any server, the document root needs to be set to var/www/html in order for users to view your website through their browser. However, there are instances in which you must update the webroot to the ~/public folder when creating APIs with frameworks like Laravel, Symfony, and Slim.

The application’s output, located in /public, resembles a straightforward PHP website with an index.php file. Setting the webroot to var/www/html/public serves the dual function of concealing sensitive files such as.htaccess and.env, which hold credentials for payment APIs, databases, and mail services.

13. Log all Errors and Hide in Production

after the website has been created and put online on a server. Disabling the error display should be your first priority because hackers could use it to obtain important information. Configure this setting in the php.ini file:

Now, after making display off, log PHP errors to a specific file for future needs:

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x