22

I am testing a website which accepts invalid credit card numbers for reservations. The interesting thing is they do CC validation if the currency is USD, but not for any other currencies. Should I report this as a security issue or will it come under fraud management?

AleksanderCH
  • 711
  • 3
  • 10
  • 23
Jaya
  • 411
  • 3
  • 6
  • 11
    Security issue or not, be careful on how to report this to the website. I assume you did all this testing on their live/production environment, so they could be upset and try to retaliate (because of the bogus reservations, to try to hide the vulnerability, because they thought the system was perfect and you hurt their ego, etc.). If they have a bug bounty program great, use it, otherwise think if it´s worth it. If the test was done on their sandbox/test environment, that could explain the lack of further validations on the cc. – Felipe Pereira Apr 24 '19 at 12:48
  • 11
    is there a reason why you can't ask the point of contact for testers where you initially got permission to perform testing ? Either you are hired to do this, or doing this on a website with a clear bug bounty program. I would hope you aren't testing payment methods on a production/live website without permission. – J.Doe Apr 24 '19 at 15:43
  • 2
    There are legal issues with pen-testing another's website without their permission, first. Bug bounty? Great! That means you have permission. Contacting them affirms that you intended to "hack" them, regardless of whether your motivation was benevolent or not. – jpaugh Apr 24 '19 at 22:43
  • @FelipePereira, This was for a bug bounty. I have reported, but the issue was ruled out saying that it is out of scope. – Jaya May 03 '19 at 03:47

3 Answers3

33

Should I report this as a security issue or will it come under fraud management?

There may be a business risk issue, which you can document under security, but how significant it is depends on the business.

You say the web site

accepts ... credit card numbers for reservations.

What are those reservations for?

If it's a hotel room, then there is limited potential for fraud, since the actual card would be required at check-in time. An attacker could attempt to impact service by blocking off rooms with bogus cards, thus reducing the pool legitimate visitors could reserve, but I see that as a minor concern based on scalability and sustainability issues.

If it's a game store that is purchasing stock based on pre-order reservations, then the store is extending actual capital to stock games they might then be stuck without buyers for. This sort of business is more threatened by invalid card reservations, because they're sinking real dollars into the expected sales those reservations indicate.

There are other businesses where 'reservations' are largely meaningless, a way to encourage engagement by the customer at no real cost. In these cases, the business impact is negligible.

The interesting thing is they do CC validation if the currency is USD, but not for any other currencies.

And that may be reflective of business risk acceptance. If 99% of their reservations are in USD, then the risk of accepting invalid non-USD card reservations may be negligible. If implementing non-USD validation has any specific cost to it (fees from processor? coding time to handle if-then-else branches?) then it's a legitimate option to leave it out at 1% coverage.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • Does the business file authorizations on the credit cards? That's typical with hotel reservations in the US. – chrylis -cautiouslyoptimistic- Apr 24 '19 at 11:20
  • 3
    I'm not sure about your last point. That they validate USD cards to me implies that they do see a risk in not validating cards. For an attacker who wants to negatively impact the business with bogus reservations, it doesn't matter that 99% of common-use cards are validated if they can just use the 1% that aren't. – tim Apr 24 '19 at 12:59
  • 10
    @tim Possibly the "risk" they are mitigating against in validating USD cards is not against "dedicated attackers" but just against "normal users" who – through error, carelessness or fraudulently – enter an incorrect or invalid card number. – TripeHound Apr 24 '19 at 13:15
  • @tim most controls are <100%, and we really don't know enough about the target environment or the business to know how this fits in or what other controls might overlap. Would love more info about the assessment but understand it's likely not forthcoming :) – gowenfawr Apr 24 '19 at 13:44
1

There may be other controls and business processes that you are not aware of that mitigate the risk, such as verifying the credit card through a different processor, or calling the cardholder.

In all of the testing I've been involved with, there has always been a section of the report that lists interesting findings, but that are not necessarily security problems. I would expect this finding to be listed in that section.

longneck
  • 273
  • 1
  • 8
0

Why do you assume an invalid credit card is either a security issue or fraud? It should be expected that users will sometimes enter the card number incorrectly. I've done it. Most everyone has done it.

If you aren't going to validate the card at the time of entry, then you lose two things:

  1. The ability to correct an incorrect entry immediately
  2. The ability to determine if it is a security/fraud issue

I would rather validate all cards than worry about fraud with the ones I don't validate.

Mohair
  • 101
  • 1