> Sound like a strange place to have a captcha indeed. What information is needed in the form to submit it? Does it validate stuff that an attacker might want to scrape? I guess they added it for a reason.
In the past, I used curl to get some billing info, add the money to a dedicated virtual prepaid card, then pay the bill, then send an email to a gmail (+paidinvoice) label. These day, at least for my bills, they have pre-approved withdraw directly from the bank. However I guess this is not widely deployed.
If other people did this, but ended up doing it from an insecure machine and lost the credentials / got hacked, I can see why at least some orgs might want to prevent people from doing this. This is a classic over reaction, but a plausible scenario.
> If other people did this, but ended up doing it from an insecure machine and lost the credentials / got hacked, I can see why at least some orgs might want to prevent people from doing this.
The measure is not really about protecting the user that is using the payment form, it is meant to "protect" the system that is validating the payment data. The payment form may be a target for attacker which has gotten a large batch of credit cards from somewhere else, and wants to validate the data. They then regularly exploit such forms, or other naive payment system to check if the credit card data is valid.
CandyJapan owner wrote some blog posts about the subject.
In the past, I used curl to get some billing info, add the money to a dedicated virtual prepaid card, then pay the bill, then send an email to a gmail (+paidinvoice) label. These day, at least for my bills, they have pre-approved withdraw directly from the bank. However I guess this is not widely deployed.
If other people did this, but ended up doing it from an insecure machine and lost the credentials / got hacked, I can see why at least some orgs might want to prevent people from doing this. This is a classic over reaction, but a plausible scenario.