Hacker News Reader

Comment by StavrosK | Hacker News Reader

As the former CTO of that company, I really doubt this. When I was there, the app was built on Django, and I left some pretty competent people behind, so I'm quite sure they wouldn't have made a mistake so rudimentary.

However, I don't know what happened after I left, so there might have been some dubious decisions.

View on HN

Facebook and Google have to do a lot of penetration tests to keep their security in tip-top shape, sure, they have a much larger attack vector in terms of code but my point is there:

Where there is public facing code, there is vulnerability.

Regardless of if you are built on Django, CodeIgniter, Rails or super-secret-obfuscated-language-mark-two, no application is bullet proof and it would be trivial for any highly skilled security tester to interface this way with your database.

> trivial for any highly skilled security tester to interface this way with your database.

It's not if you're not doing dumb stuff.

I suppose so, but this heavily relies on no one in your operation having made a mistake, or that mistake having been caught before it was pushed live.

You have to be lucky every time, an attacker only needs to be lucky once.

Above you are essentially saying every application has SQL injection vulnerabilities and any good security guy will find them. This is a very specific and dubious conclusion to draw from the more general principle that there will be some vulnerability, somewhere. SQL injection specifically is quite easy to avoid. With some frameworks it would actually be rather laborious to introduce an SQL injection vulnerability. This is what Alexander is alluding to. This does not imply that applications are easily secured, just that this attack vector isn't what it used to be.

Well, statistics of pentests does show that, if tested, the vast majority of good quality, generally securely built applications have some vulnerabilities, and average applications have a huge multitude of vulnerabilities.

SQL injections are just one class of many. There are ways to vastly reduce SQL injection risks but that still leaves many other venues of attack.

No, I never have to be lucky at all. I literally can not put an SQL injection vulnerability into production unless I do so deliberately, my code wouldn't compile. Not everyone uses terrible rails style "lets automagically do shit behind your back so security holes are hidden from you" frameworks.

You're being too harsh. You seem to be talking about Haskell, so saying "not everyone" is a weird way to put it. You really mean a tiny fraction of people use Haskell to be safe in advanced ways. Well, Haskell is ahead of its time. Of course not that many people use it.

Even Haskell is not a silver bullet against every kind of security problem. Didn't Snap have a directory traversal bug a while back?

I don't understand what you are trying to convey. It appears like a deliberate red herring to try to distract from what I actually said. I personally use haskell, but you do not need to do so to get a complete guarantee against SQL injection. Nobody said anything about silver bullets or protecting against every security problem. I very clearly said SQL injection is a solved problem, in reply to someone claiming every single web app has SQL injection vulnerabilities in it and that any security researcher can easily sit down and exploit them, and the only way to deal with SQL injection is to be lucky over and over.

You are being too harsh (again). Whatever problems you deal with, whatever mistakes you make in your professional work, are also solved problems, using some technology that is unacceptable to you (probably for very good reasons).

You could have been informative and made your original point tactfully. Instead, you badmouthed a certain technology without even naming the stuff that was supposedly better. I'm a Haskell evangelist and agree with you 100%, and you came off like a jerk even to me.

I think perhaps we are operating with very different definitions of harsh. If your response is simply intended to be a poor attempt at criticizing my tone, you did not make that clear. Obviously such vacuous nonsense would not warrant a response.

Your assertion that whatever problems I deal with are solved problems is absolutely insane. Please, tell me how problems like interpreting customers requirements are "solved" and what technology I can use to ensure that all the code I write will 100% always match the users mental picture of what they wanted.

Criticizing the choice to deliberately create security holes for convenience is not "badmouthing", and "I'm offended" is not a productive response. It literally conveys no useful information at all.

I was talking about SQL injections specifically, not all vulnerabilities.

Unless you built it on you know... a language that barely anyone uses and has been reviewed and patched over the past 70 years. Like Fortran.

Ahhh, but then you have to content with the 90 year old specialist Fortran penetration checker. :)

Most vulnerabilities probably aren't due to the language but the application writers, simply because there are more eyes on the language than the application.

It was a joke BTW ;)

No, it was an attempt at a joke. :P

A failed attempt.

Oops, thought I clicked on HN... How'd I end up on Reddit?

The fact that this wasn't about the latest Javascript light framework didn't tip you off?

Ah, so apparently guys are still good enough to hire. Interesting. Care to share your experiences on what it was like to work there?

While I was there, we were building a social network for women, something between Path and Facebook where they could share their day-to-day with their closest friends. The rating thing was sort of an afterthought, I guess they pivoted.

There wasn't really a guy-hating culture, in fact, most of the employees there were men. I don't know how it's changed since.

Hopefully we still have a few good men on the inside.

> so apparently guys are still good enough to hire. Interesting.

I re-read the parent, and nowhere does it say nor imply that the CTO nor the people he hired were male. For all that we know, the site might be built by bimbos scratching one of their own itches.

I wouldn't bet on it, of course, but I'm amazed to see that prejudices are so deeply ingrained that:

* you read what was absolutely not written;

* nobody noticed.

His username is "StavrosK", and his full name, Stavros Korokithakis is in his profile. If you weren't familiar with the name Stavros and didn't know the gender, you could google it and the first link would take you to his website which shows his photo.

I don't see the 'deeply ingrained prejudice' here.

The parent is StavrosK, in their profile it says "I'm Stavros Korokithakis.", Stavros being a mans name.

Of course, it could not be true, but I can't see why anyone would bother.

If there's one thing the internet has taught me, there is no such thing as ironclad code. OpenBSD still has security vulnerabilities, and I highly doubt Lulu's security chops are as good.

That said, I'm not trying to doubt the skill of Lulu's employees. Just warning that vulnerabilities are always a possibility.

Oh, sure. I'm just saying that, as far as I know, nobody ever wrote inline SQL, so the specific vulnerability would be unlikely.

Why did you leave ?

I was working remotely and they wanted to concentrate the team, but I didn't want to move away.

This complacent overconfidence tells me that Lulu probably has major security holes that the staff refuse to look for.

How did you get this from that? I'm curious.

Reply on news.ycombinator.com