Pages

Monday 15 August 2022

GET and POST

GET and POST

There are two ways to send data to a web page, GET and POST. GET puts the data into the URL - that means that the data is stored in the server logs and the browser history.

POST is, very slightly, more secure, because it doesn't have the above issues.

If you use https (and you have to use https to use the Barclays services), then all the data is encrypted before it's sent from your end, and only decrypted at the server end. That means that an interloper can find out what server you're accessing (payments.epdq.co.uk, which we knew already) and what port you're using (443, the https port). so the security benefits of POST, and quite tiny.

I use Barclays for running credit cards, and I do it with a program I wrote. I used GET to send the data, because it's slightly easier to implement. But, suddenly, Barclays have woken up to the difference, and they've just told me that as of October 2022, they won't accept GET, everything has to be POST.

There's nothing in my browser history, because I'm not using a browser, I'm using LWP::UserAgent. That is a perl library. There's no history. And yes, the info is in the server logs, but the server is run by Barclays, and they should have it under the most stringent security.

I hate it when they do this. I've been running credit cards for 25 years now. Originally, they could only accept paper, so my database would print out each billing, and we'd ship the paper to our local bank. They would then ship the paper to Poole (except one time when they lost it and didn't tell me until several months later) and some typist at Poole would type it all in again.

Since then, they've been gradually improving their service. The problem is, each time they make a change like this, thousands of businesses all over the country, have to make changes in their software. I've been though this maybe a dozen times now.

The security difference between GET and POST has been known for a very long time. Why have Barclays only just woken up to it? And why do they think it would affect my systems?

Also, it would be nice if Barclays gave a sample working program. Since they haven't, I'll do it.

It would also be nice if someone at Barclays tried to read their documentation. Everything one needs is there, but it can be really difficult to find.

I'm not telling you my id, userid or password, obviously - if you use Barclays to run cards, you have your own. This program works, and I can then parse $content to take action depending on whether the card was accepted or declined.

#!/usr/bin/perl
use LWP::UserAgent;
use CGI::Carp qw(fatalsToBrowser);
print "Content-type: text/html\n\n";
$epdqurl = "https://payments.epdq.co.uk/ncol/prod/orderdirect.asp";

$amount = '1000'; # meaning $10
$cardno = '4111111111111111'; # that's a test card, it will be declined
$expires = '0824';
$transactionid = 'post-test-1';

my $browser = LWP::UserAgent->new;
my $response = $browser->post(
    $epdqurl,
    [
'AMOUNT'    => $amount,
'CARDNO' => $cardno,
'CURRENCY' => 'USD',
'ECI' => '9',
'ED' => $expires,
'OPERATION' => 'SAL',
'ORDERID' => $transactionid,
'PSPID' => 'my_id',
'PSWD' => 'my_passwd',
'USERID' => 'my_userid'
    ],
);
open RES, ">test.out";
print RES $content;
close RES;



No comments:

Post a Comment