I did a payment gateway integration on an existing website. The payment gateway gave me an API which I used and did the coding and stored it in a php file pay.php
If you configure your webserver (Apache,...) correctly, the webserver will render the PHP so no one will ever have the opportunity to see the file's source code. So there is some inherent protection. But needless to say, it can be hacked.
Now hackers of course wish to hack the website. And you don't have any contol on what data will be posted: that's up to the browser. Hackers sometimes modify the content before they send the request in the hope that the PHP script will fail somehow and reveal for instance SQL queries, etc. The first thing you thus better do is turn off error reporting:
error_reporting(0);
Since hackers can find some warnings/errors most helpful to figure out the underlying algorithm and corrupt it. By doing this explicitly in the PHP file, you prevent that if you modify the settings of the server, all of a sudden errors reappear.
You furthermore better make sure a user has no direct access to the sensitive data anyhow. This can be achieved by putting the sensitive data into a separate file (say secure.php
) and include_once()
it so you can read it's data.
As @Havenard and @AlexHowansky say, you can also store such files (secure.php
) better outside the publicly accessible directories. For instance above public_html
. This does not always fully resolves the problem because some webservers are sensitive to URL-injection (by specifying http://www.domain.com/../securefolder/secure.php
, you can sometimes access a file above the publicly available directory).
As @TomKriek says, you can also provide additiona protection to the "secure folder" by inserting a .htaccess
file that contains the following lines:
<Files *.php>
Deny from All
</Files>
It means that the webserver - again if configured correctly - will prevent the users access from all .php
files in the directory.
Finally, you better give the files proper permissions: if the PHP engine runs as the same user as the owner of the files, you can give it 600
access rights (chmod 600 secure.php
) or 640
in case the PHP engine runs on a different user than the owner of the file, but in the same user group, or worst-case 644
so that a hacker can't modify the file (or is at least not supposed to). You can also change the owner of the file to the www-data
by running chown www-data secure.php
so that the owner is the webserver and you can thus make the permissions more tight. The rule of thumb is always to give it the least access rights to do its job correctly.
You can also make the files read-only once they are implemented by setting the rights to 400
, 440
or worst-case 444
. In that case at least a hacker can't enter his/her own bank account as the receiver of the payment ;).
To conclude, when designing/implementing a secure server, one better uses a layered approach where several measures are taken so that if one measure might fail, others hopefully will still prevent a hacker from accessing the server/files.
.htaccess
. And users will not know about your real PHP files.To add to the answer of Commusoft and to give a slight alternative.
This piece of .htaccess
denies php file requests via the browser and makes sure you can only include the file from a different php file.
<Files *.php>
Deny from All
</Files>
Put this in a separate directory where pay.php
is located.
I think the best way of dealing with this payment issue is to turn the pay.php
into a full class and use it object oriented. That way you can use the functionality in any location and pass variables to it easily.