Do I need SSL on my Web Server for use with PayPal IPN?

PayPal upgrades:

1) Changes to PayPal security for HTTP/1.1 and TLS 1.2
2) IPN Verification Postback to HTTPS

PayPal say their target for these is June 2018

 

You may have seen an article from PayPal which talks about HTTP and TLS. This is a server issue
which is the responsibility of your web host. Essentially there is an upgrade by PayPal to ensure that
all their servers meet the latest standards and hence your web server will also require to operate
in that way. You should contact your host about this if you are unsure, although most servers will already
meet these standards.

 

The second update is using HTTPS for IPN verification.

PayPal says:

“If you are using PayPal’s instant Payment Notification (IPN) service, you will need to ensure
that HTTPS is used when posting the message back to PayPal for verification. HTTP PostBacks
will no longer be supported.”

“Merchants and partners use Instant Payment Notification (IPN) to receive notifications of
events related to PayPal transactions. The IPN message service requires that you acknowledge
receipt of these messages and validate them. This process includes posting the messages back
to PayPal for verification. In the past, PayPal has allowed the use of HTTP for these
PostBacks . For increased security going forward, only HTTPS will be allowed for PostBacks to
PayPal. At this time, there is no requirement for HTTPS on the outbound IPN call from PayPal
to the merchant’s IPN listener.”

In practice this means that you need https on your web server to send https to PayPal and
then you need to change the set up of you PHP-KeyCodes, PHP-eSeller or PHP-SecureArea
application to identify the URL of the site as https rather than http.

Note: if a customer tried to make a purchase it would still succeed, but your store would
not be notified of that fact, and your records will not reflect the sale properly. Nor
will the PHP application automatically send the information to the customer by email.

Refer to PayPal documentation:

https://www.paypal.com/au/webapps/mpp/ipn-verification-https

So do I need SSL on my Web Server when using PayPal IPN? Yes, the PostBack from PayPal will not work
and SSL will give better security for your site.

magic_quotes, addslashes(), and stripslashes() and PHP 6

magic_quotes_gpc, when on, automatically adds slashes to all GET/POST/COOKIE data so that you don’t need to use addslashes() before using GET/POST/COOKIE data in MySQL queries, etc. (e.g. with magic_quotes_gpc OR addslashes(), I’m becomes I\\’m). Well, magic_quotes_gpc is no convenience and just complicates things!

Since magic_quotes_gpc can be on or off, you don’t know whether to use addslashes() or not. You don’t want to use addslashes() when magic_quotes_gpc is on because you’ll add too many slashes (e.g. I’m becomes I\\\\’m), which is bad. Use addslashes() if magic_quotes_gpc is off, and don’t if it’s on (you can find out its setting with get_magic_quotes_gpc()). But you can’t use the same code all the time. One workaround is something such as:

if (!get_magic_quotes_gpc()) { $txt = addslashes($txt);

Using magic quotes has always been confusing and in PHP 6 they are apparantly going to remove it.  So it is better to program your scripts without using get_magic_quotes_gpc at all.

filter_var and validate an email address in PHP 5.2.0 onwards

PHP 5.2.0 onwards has the filter_var function which can be used to validate many different inputs.

To validate an email address :

<?php
//Validate an email address in PHP 5.2.0 onwards

$email_address = “me@example.com”;
if (filter_var($email_address, FILTER_VALIDATE_EMAIL)) {
// The email address is valid
} else {
// The email address is not valid
}
?>

Possible way of dealing with inserting quote marks into a database

This is another possible way of dealing with quote marks for inserting data into a database :

if (!get_magic_quotes_gpc()) {
$item_name = addslashes($_POST[‘txtItem_Name’]);
}
else
{
$item_name = $_POST[‘txtItem_Name’];
}

Dealing with quote marks for inserting data into a database
———————————————————–

if (!get_magic_quotes_gpc()) {
$item_name = addslashes($_POST[‘txtItem_Name’]);
}
else
{
$item_name = $_POST[‘txtItem_Name’];
}

Use regular expressions to validate PHP inputs

To help counter SQL injections you need to make sure that entered values use minimum character types as possible.  So you restrict usernames to just a-z and 0-9 characters.

To test for these, use something like :

//——————————————————
/**
* Purpose : Check input for paticular characters
* Only allow a – z, A – Z , 0-9
* returns true if a match was found, false if no match was found
* @return boolean
*/
function is_valid_input($words) {

if ( preg_match( “/[^0-9a-zA-Z]/”, $words, $array ) )
return false;        //invalid characters
else
return true;        //valid characters

}

Ways to counter SQL Injection

Database Permissions

Set the permissions on the database username / password as tightly as possible.  If you are displaying data, there is no need for the user to have insert or update permissions into the database.  One solution is to have two usernames / passwords.  One would have select permissions, and would be used only for display.  The other would have select, insert and update permissions used only for forms that require data to be stored in the database.

Test all data input

All form data and all url query strings should be tested.

For example, if you are passing data using a query string any record id’s are usually integer, so test that they are actually integer values with a function such as is_numeric in PHP.

Use correct data types and data sizes in the database

This means that if you have a colunn which is a persons name, the data type size for that column only needs to be 40 characters. There is no need to have a data size any larger than required.
Convert text to html

Before storing text in a database, convert it into html.  This will change inputs such as the Javascript <script> to its html equilivant which cannot be executed on a web page.

Filter out any characters that may cause issues. and are not required.

Use parameterized queries

If you use parametized queries for connection to the database you eliminate string concatenation.  You should always use parametized queries rather than constucting the sql.

Check characters particlarly with username / password

If an entry is a username, it normally does not require any other characters other than a to z and 0 to 9 and it only needs to be say, 8 characters long.

In php, always use the mysql_real_escape_string

http://uk3.php.net/mysql_real_escape_string

SQL Injection pdf

http://dev.mysql.com/tech-resources/articles/guide-to-php-security-ch3.pdf

Description of paramised queries and slq injection in dot.net

http://msdn.microsoft.com/en-us/library/ms998271.aspx

Description of paramised queries and slq injection for php

http://stackoverflow.com/questions/60174/best-way-to-stop-sql-injection-in-php