Why use a JSON object to pass data with POST versus a Query String in Perl?

Question

I'm looking to run a script using Stripe.pm, basically looking to do credit card processing. The credit card number is not being passed at all. All the examples I see use a JSON object passed in a POST call but I have a lot of experience using Query Strings i.e.

 http://www.example.com/cgi-bin/processingscript.pl?param1=XXXX&param2=YYYYY&param3=ZZZZZ

Is this a security risk? What is the advantage or disadvantage of posting using JSON versus a query string like I'm used to using?

Answer 1

From a purely technical point of view, there is no difference between POST and GET if you pass a reasonably short parameter. You can also just pass JSON as a GET parameter no problem:

GET foo.pl?json={'foo':'bar'}

It would make sense to url-encode the data in this case. You can also send the same request using POST.

If you do not want to use query params at all, you need POST and put your JSON into the request body. Depending on which option you choose, there are differences in how to deal with it in Perl. Let's say you are using the CGI module... Perl makes no difference between POST and GET params.

For the query string GET or POST, you need to do:

use CGI;
my $cgi = CGI->new;
my $json = $cgi->param('json');

If you put the payload directly into the request body, you will instead need to do:

use CGI;
my $cgi = CGI->new;
$cgi->param('POSTDATA');

This is documented in CGI under "handling non url-encoded ...".

For JSON, there is also of course the time it takes to parse it, but that should be negligible.

The advantage JSON has over query strings without JSON inside them is, that you can encode arbitrary complex data structures inside JSON, while plain-text query strings are just one level deep.

---

From a security point of view, pretty much everything has been said. I'll recap my own ideas:

• use SSL
• do not put sensitive stuff into log files
• if you are dealing with CC data (even if it is not the number itself), take extra care; read up on PCI DSS and encrypt stuff during transmission
• NEVER store a cvc!
• if you want to learn more about that topic, there is a Stack Exchange site called Information Security.

Answer 2

Security - making sure no one other than user/server know the data GET/POST has no influence. Use SSL to ensure this. - Stopping the user passing "interesting" arguments to your script. POST has a certain amount of security-through-obscurity in that most users won't see the parameters, but it's no real security. You should check the parameters in your application to cover that.

Generally POST with a nice data package (e.g. JSON) makes for a much more flexible and maintainable application interface, and has the advantage that you don't need to worry about encoding and length of parameters the same way you do when using GET.

Answer 3

POST:

• Generally safer for important data
• Parameters not shown in url
• You can pass longer Strings-Structures (e.g. JSON) than by using GET that has length limit on the parameters you send