[deleted]
Coder wrote a bug so bad security guards wanted a word when he arrived at work
31–40 of 68 posts
Re: Coder wrote a bug so bad security guards wanted a word when he arrived at work
#32I worked for a large retailer on their iPhone app and our test environments were terribly slow so we tended to do most of our development against production.
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.
Re: Coder wrote a bug so bad security guards wanted a word when he arrived at work
#33Long story short, as a junior programmer I did not fully appreciate the difference between credit and debit and ended up putting a bunch of money on customer credit cards instead of deducting it. And yes the app somehow passed our payment processor's validation exercises. Total damage was maybe $10k, but I think we managed to roll most of it back.
Re: Coder wrote a bug so bad security guards wanted a word when he arrived at work
#34Are all these articles this "lightweight" and short on details and sound like a made up coding morality tale? Just the style here throws me.
I have briefed Register journalists 100+ times and this is is absolutely their editorial style. If you go technical, they do their best to translate what you've said into analogies that mid-market IT managers will understand. It was embarassing because my fellow engineers would often read an article and be alarmed that I may not understand our technology because of this.
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.
Re: Coder wrote a bug so bad security guards wanted a word when he arrived at work
#35It's unstated but are we to understand that he set up the test to send money to a test account which was his own personal account?
Not to defend that, but the question is how quickly would they be able to set that dev up with a test-bank account? In the orgs I know this would probably take a month or so. So taking your own account during early development can make sense. Leaving it in is probably a bad idea tho.
Its my opinion, but you shouldn’t need a bank account or even internet connection to work on the code at all. Instead its better to mock it out in development.
Re: Coder wrote a bug so bad security guards wanted a word when he arrived at work
#36Are all these articles this "lightweight" and short on details and sound like a made up coding morality tale? Just the style here throws me.
I have briefed Register journalists 100+ times and this is is absolutely their editorial style. If you go technical, they do their best to translate what you've said into analogies that mid-market IT managers will understand. It was embarassing because my fellow engineers would often read an article and be alarmed that I may not understand our technology because of this. The issue is that you can't not brief The Regi…
They also Know Their Stuff; even if they have a "redtop" style.
Re: Coder wrote a bug so bad security guards wanted a word when he arrived at work
#37Reminds me of a similar bug in a payment processing system the company I worked for used. Long story short, overflow in Java numerical types (counting milliseconds for durations in weeks...) caused the system to go haywire and charge customers 1000x the normal amount... 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 goo…
This is not a true story because as a merchant you cannot "refuse chargebacks". In fact too many chargebacks will result in a loss of your merchant account. You should really stop making things up.
Sorry Sherlock, I meant charge back as in "refunds" not credit card disputes. Also, merry Christmas.
Re: Coder wrote a bug so bad security guards wanted a word when he arrived at work
#38Office Space just keeps replaying in my head. All he needed was a timely fire to get away with it.
Re: Coder wrote a bug so bad security guards wanted a word when he arrived at work
#39I always liked this clause from the Underhanded C Contest:
"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."
Re: Coder wrote a bug so bad security guards wanted a word when he arrived at work
#40In the early wild-west days of ecommerce a friend working as a tester at a well known British supermarket discovered that the backend card-validation logic on their payment form was essentially "return true" ... good thing the volumes were miniscule I guess?
I worked at a very well known news company. Their auth proxy layer was set to “fail open” for a period of time if there was any issue detected in the auth backend (i.e. just return ok and a new cookie for 30 seconds). When I checked the logs that system was in a fail-open state over 50% of the time.