Oh please. I'm not building anything that requires a credit card, or anything sophisticated. When you have literally just a hundred users, YES I will skip paying lots of attention on injection attacks because the chances of that happening is very low. To you techies, it sounds like a huge deal, but the priority in any business to make profit first.
Sorry, but this is bull. If you take any information, even if it's an email and password, data security is either tops on your list or you're abusing your users (even "only a hundred"; one is too many!). There is literally zero middle ground on this: you do it or you shouldn't be building web applications. And given how utterly trivial it is to provide proof against injection attacks in any modern language and toolkit, choosing not to do so because it's "hard" as irresponsible as you can get.
This sort of behavior is why the rest of us get a bad rap.
> Sorry, but this is bull. If you take any information, even if it's an email and password, data security is either tops on your list or you're abusing your users (even "only a hundred"; one is too many!). There is literally zero middle ground on this: you do it or you shouldn't be building web applications
Needless to say, almost 5 years have passed and they're still around :) their traffic probably a couple of orders of magnitude higher. I was there when it happened, and yes, probably some Russian hacker or whatnot has my password from there, but that's not such a big deal because reddit doesn't know my name, doesn't have my CC number or any details related to my life.
Now, were this to happen to a company that has a lot more information available about each and every one of us stored in one central place (think Google or FB), then things could get really nasty. And I'm not talking about stupid mistakes like the one from above, I'm talking about MITM attacks orchestrated by (vicious) Governments, or cyber-warfare, or just plain old NSA not having to bother to collect information from a myriad of places anymore, when they can just go directly to the source.
Compromising user data isn't a prerequisite to building something cool. Negligence is still negligence. Drunk drivers make it home without killing anyone more often than not.
Let this post be a warning to web entrepreneurs everywhere-- if you take shortcuts like this, your business will get burned at some point in the future. Every single thing you've just said is wrong. Every single thing.
First -- "the chances of that happening is very low." Let this be an education; there are automated toolsets that seek out and exploit known vulnerabilities in software across the entire Internet. If you have a public-facing website, you will get attacked. Period. The chances aren't "very low", they are a certainty. There are also toolsets that are used to do much more low-level scans for things like XSS, SQL injection, etc. These are commonly used by security auditors, but are also used by 13 year old kids who want to compromise your site. Again-- the chances aren't "very low", they are a certainty.
Next -- "...but the priority in any business to make profit first." State attorneys general are very quickly drafting personal privacy laws. I believe Massachusetts and Nevada are leading the way here, whereby any personally-identifiable information is _required_ _by_ _law_ to be held to the same rigorous data protection standards as PCI. If your site is breached, you will get sued, and you will lose.
Following OWASP takes maybe an extra day's worth of time out of a developer-- saying that you're just going to ignore it because hey, what's the worst that could happen -- again, I would ask you to list what you're building, so I can avoid it forever.
Sure. But if you've built a crap back-end for a content site (that doesn't even ask for emails) and someone manages to inject some alware taht attempts to download crap to your users computer -- then you realise that crappy unprotected php is a really really bad idea. (In my defence - I was very young)
I'm not going to jump down your throat on this, because everyone is inexperienced at some point, and you can never know everything, so on one hand your attitude of "just ship" is healthy.
That said, one of the things that (hopefully) comes with experience is knowing when and where to cut corners. Basic security practices are one place where you need to bake your understanding into everything you do from a low level, because security is one of the hardest "features" to retrofit. Also because basic security does not have to be hard. Hell, you can make an informed decision not to use SSL on your login page, but it must be just that, informed.
Unlike the language du jour, security principles are something that will apply to all programming you do for the rest of your life. So, though you may decide not to use trendy framework x, y or z today, failing to learn basic security and apply it consistently will slowly turn you from a young developer with bright ideas and a lot of potential, to a middle-aged hack developer with a defensive chip on his shoulder.
Credit cards are only part of the problem. If your site can be hacked, then the hackers can:
1) upload scripts to send unsolicited email, getting your IP address banned.
2) upload scripts to scan the internet for other targets (most common---an SSH scanner)
3) modify the HTML output to leak Google Page Rank to questionable sites, which risks your Google Page Rank.
4) passwords of users, who typically use the same password on other sites.
5) setup an illegal file trading section, hidden from most users (anything from music and films to kiddie porn (saw this first hand, and what once was seen can never be unseen---shudder))
6) IRC clients to control botnets.
I've seen all of these first hand working at several web hosting companies. It's more than just "credit cards."
