Coder wrote a bug so bad security guards wanted a word when he arrived at work
theregister.com
theregister.com
This retailer is pretty old and had issued their own credit cards that didn't have any sort of checksum validation. This made making test orders easy because any sequence of numbers for that credit card type would let the "checkout" call succeed, and then the order wouldn't actually be fulfilled because the card would turn out to be invalid.
We usually used a sequential list of numbers because that was so fast to type and we used a made up Address in Tok Alaska. The state picker had Alaska first and Tok (also Eek) were the shortest city names we could find in Alaska.
One day someone took a look at one of our test account's order histories and noticed that there was a tracking link for the order. That "fake" credit card number turned out to be quite real. We shipped a dress to Alaska, which was then returned to sender because the address (1 A St) didn't exist.
We were much more careful after that but as far as I know, nobody ever complained and we never heard about it from anyone outside our team.
One day, we got a big box of makeup at the office - turns out their warehouse had gotten so fast that in the time it took us to cancel the order they had already picked & shipped it.
After that we put "TEST DO NOT SHIP TEST DO NOT SHIP" as the shipping name and "123 Fake St" as the address to try and avert this scenario, which seemed to work until we could modify the system to hide those orders from the warehouse entirely.
now that's a true end-to-end test.
?id=48391&test=lol
As a dotcom kid who founded and wrote the core systems for several payment processing companies over the decades I recall 2005 when a company using one of our partner banks was breached. This was CardSystems, the largest publicly known breach at the time, and I was tasked to perform a full code review of their systems to find any issues. The payments gateway contained a valid crc nontest card number compiled into authorization logic that had no deployment switching control and recorded no transaction information when that card number was used. Any merchant using CardSystems under this payment gateway suffered unknown losses from approved transactions that were never recorded into any system. I postulated who had done this but federal law enforcement around the breach buried this and other key discoveries I had found since the company was being dissolved and my findings were therefore deemed immaterial.
Just the style here throws me.
The issue is that you can't not brief The Register because they're insanely influential with customers in certain tech markets. All said, they're usually fun to meet with and many of their writers are real characters.
(Which my child consistently gives me shit for. "Dad, why we we have a cup with the F-word on it!?")
In case it needs to be said, I'm kidding.
Yes, son, the Future is the new F-word. And you'll be living in it. You're welcome.
There was a tiny bit of logic in there if I remember correctly, relating to when and whom to show the ad to.
I implemented it, tested in dev, assigned it to QA, QA approved it and rolled it out that afternoon.
The next morning when I showed up to work one of the other team leads walked straight up to me as I entered the campus, laughing hysterically.
Turned out that in production it behaved differently. The ad appeared, correctly. Then doubled every couple of seconds,1 ad, 2 ads, 4 ads and so on, until the client browser exploded into flames.
As luck would have it there was zero consequence, only chuckles all over the place. It was something to do with order of inclusion of a mad number of js libraries which differed in production and went unnoticed. The End.
If it contained the words “you’ll never believe what happened next…” they would be completely at-home.
Like, for a lot of state free application logic, or even read-only frontend stuff, just do. A roll-back or a roll-forward is easier than heavy-weight procedure.
But if payment, customer authentication, migrations of large databases comes in... Suddenly these ops-guys with their careful rollout, validation functionality, dry-runs and ring rollouts are pretty good at keeping the day boring.
(And before anybody says it, yes I know they refer to Superman 3 in Office Space)
It turned out very profitable for the company though. Stonewalling customers and refusing charge backs is too easy. Not picking up the phone is a good business strategy.
That doesn't sound right...? Credit/debit card chargebacks are handled by the bank. If the merchant doesn't pick up the phone, the bank will take the money from the merchant and return it to the customer.
https://www.usatoday.com/money/blueprint/credit-cards/credit...
Were you using a different payment system with fewer consumer protections than credit/debit cards?
However, merchants do have an opportunity to respond to a chargeback request. Providing plausible evidence that the request is in bad faith will often result in the bank not performing an actual chargeback.
Refusing chargebacks and not issuing refunds are two very different things with distinct language. And if you don't issue refunds for a case like the GP described, where thousands of customers were incorrectly billed, you certainly would be flooded with chargebacks and likely put your merchant account in jeopardy. (Most of the big processors would close your account if they get evidence you are fraudulently billing customers and actively resisting making it right.)
It's clearly a made up story by someone with no experience actually managing credit card payments for a real business.
Then I have a bash script that runs on the raspberry pi board that has a speaker installed, something of this sort to play the doorbell chime:
while [ true ]; do
mosquitto_sub --exit-after-first-message /my-topic
play_wav my-file.wav
done
In the end, it turned out OK. The joint burned down, and Milton ended up on a beach, sans Swingline.
Funny enough, in a fintech I worked for, developers and QAs actually used their own personal credit cards and bank accounts for testing.
Interestingly, they also needed to test ApplePay, but the laptops didn't allow for adding their personal iCloud accounts. So someone in the development team got the "admin" password and distributed among devs and QA team, and they all had unprotected laptops. They probably still do.
So taking your own account during early development can make sense. Leaving it in is probably a bad idea tho.
"The Underhanded C Contest was a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake even if discovered."
“move fast and break things” …
It’s the same cavalier attitude taken by startups that treat user data and privacy as something to worry about later, someday.