Live data from Hacker News

Web Developer Security Checklist

simplesecurity.sensedeep.com

221–230 of 249 posts

Re: Web Developer Security Checklist

#221

Earlier quoted context omitted.

This is...shortsighted. Security is part of your development work. It always has been, always will be. You need to understand application and server-level security--the former is always your responsibility and while you may have specialists for the latter they do not replace you understanding the fundamentals of it. The server is part of your "stack", even if the "full-stack" people want you to believe it ends at the…

>Security is part of your development work So is everything else, apparently: databases, algorithms, data structures, operating systems, cloud infrastructure, front end design, business logic features, etc., etc., etc. -- the list just keeps fucking growing and you people are turning devs into skill black holes where they're never going to master anything. All of it apparently matters at one point or another and you'…

> So is everything else, apparently

Yes. Sorry (not snarky) that it sounds like you work in a lousy place, but if your "security people" aren't cutting it, you are the line of defense for your users. You need to understand this stuff to be able to do the right thing. Being at least competent--and we're not talking A-plus or best-in-the-business, we're talking a solid C-plus to B, able to consistently make things better rather than leave them static or regress--in these things is your responsibility when you take a job working on stuff that touches these fields, because somebody has to and you're a somebody. "Security people" (and I'm not one, I'm a software developer--though, somehow, [this part is snarky] none of databases, algorithms, operating systems, cloud infrastructure, front end design, business logic features, or application security are beyond me; weird, that) are there to help you, not excuse you from your responsibilities.

There's a lot of stuff to understand! This is why you are paid the medium bucks. Remove "not your job" from your vocabulary and you'll be better at not just these things, but the things you think are your job, too. Because each bit informs the rest.

Re: Web Developer Security Checklist

#222
post #60

I do not like this list. > [ ] Use minimal privilege for the database access user account. Don’t use the database root account. This advice seems outdated. In general, every significant security breach will get the attacker root access. Playing games with database accounts gets you no security at all, while introducing lots of friction and headache.

Significant breach in the context of web development is usually logic error that leads to unauthorized application-level access, leaking cookies, service unavailability etc.

This is however not the most likely thing to go wrong, in general. Topping the charts is as always, the one and only, User Error!

Restricting db access is the last line of defense against accidentally DROP-ing TABLE in production.

Re: Web Developer Security Checklist

#223
post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

> That is an extraordinarily inefficient and costly way to develop. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries. I agree with you, but I don't think that's what the author meant. Nowadays, when most people talk about "prepared statements" and "stored procedures", they are just conflating those things with…

ActiveRecord uses actual, PostgreSQL prepared statements in many cases. Eg if you execute `User.where(email: "foo@bar.com")`, it will prepare, bind and execute the query separately, with "foo@bar.com" being sent to PG as a bound parameter. You can see this if you flip the proper flags in the PG config and tail its log.

In other cases, like `User.where("email like ?", "#{params[:email_like])}%")`, AR will escape the provided value itself and no bind parameter will be used. However, it will still use a prepared statement, which at least means that only one database query will execute; no matter what AR does or fails to do with it's escaping, you won't execute both the `SELECT` and a `DROP TABLE` because a prepared statement can only be one statement.

Re: Web Developer Security Checklist

#224

Earlier quoted context omitted.

>Security is part of your development work So is everything else, apparently: databases, algorithms, data structures, operating systems, cloud infrastructure, front end design, business logic features, etc., etc., etc. -- the list just keeps fucking growing and you people are turning devs into skill black holes where they're never going to master anything. All of it apparently matters at one point or another and you'…

> So is everything else, apparently Yes. Sorry (not snarky) that it sounds like you work in a lousy place, but if your "security people" aren't cutting it, you are the line of defense for your users. You need to understand this stuff to be able to do the right thing. Being at least competent--and we're not talking A-plus or best-in-the-business, we're talking a solid C-plus to B, able to consistently make things bett…

>Remove "not your job" from your vocabulary and you'll be better at not just these things

No one else is removing that from their vocabulary. I don't see the incentive for me to do that.

This is the problem. You haven't realized that everyone is saying "not my job" and pushing it all onto developers.

Re: Web Developer Security Checklist

#225

Earlier quoted context omitted.

> So is everything else, apparently Yes. Sorry (not snarky) that it sounds like you work in a lousy place, but if your "security people" aren't cutting it, you are the line of defense for your users. You need to understand this stuff to be able to do the right thing. Being at least competent--and we're not talking A-plus or best-in-the-business, we're talking a solid C-plus to B, able to consistently make things bett…

>Remove "not your job" from your vocabulary and you'll be better at not just these things No one else is removing that from their vocabulary. I don't see the incentive for me to do that. This is the problem. You haven't realized that everyone is saying "not my job" and pushing it all onto developers.

> I don't see the incentive for me to do that.

Oh, I don't know, to not be bad at what you do for a living so you can call yourself a professional without it being a farce?

I don't care what other people are doing and you shouldn't either. I care about doing the right thing and building good systems that work for people rather than expose them to risk and you should too--and that means understanding the breadth of your profession. The people who are pushing responsibilities onto you are the people that software is automating out of existence and are of no account except that you get to feel good by "pushing back" in ways that just make everything worse.

Re: Web Developer Security Checklist

#227

Earlier quoted context omitted.

>Remove "not your job" from your vocabulary and you'll be better at not just these things No one else is removing that from their vocabulary. I don't see the incentive for me to do that. This is the problem. You haven't realized that everyone is saying "not my job" and pushing it all onto developers.

> I don't see the incentive for me to do that. Oh, I don't know, to not be bad at what you do for a living so you can call yourself a professional without it being a farce? I don't care what other people are doing and you shouldn't either. I care about doing the right thing and building good systems that work for people rather than expose them to risk and you should too--and that means understanding the breadth of yo…

>I don't care what other people are doing and you shouldn't either.

Until their decisions affect your work, and you don't get to say anything about it. Because the people pushing around responsibilities are usually your bosses or equals, so you can't really do anything about that. If you get to work in a silo where you're responsible for everything and you understand everyone and do it well, great, you're a master of the universe. You should be a multi-millionaire by retirement at 45.

But most developers won't ever approach that level. Putting your best people in the best slots is a practical approach for teams > 1. And there's no reason you should be mixing responsibilities and watering down everyone's chance at becoming good at ~literally everything in development~

Re: Web Developer Security Checklist

#228

Earlier quoted context omitted.

> I don't see the incentive for me to do that. Oh, I don't know, to not be bad at what you do for a living so you can call yourself a professional without it being a farce? I don't care what other people are doing and you shouldn't either. I care about doing the right thing and building good systems that work for people rather than expose them to risk and you should too--and that means understanding the breadth of yo…

>I don't care what other people are doing and you shouldn't either. Until their decisions affect your work, and you don't get to say anything about it. Because the people pushing around responsibilities are usually your bosses or equals, so you can't really do anything about that. If you get to work in a silo where you're responsible for everything and you understand everyone and do it well, great, you're a master of…

Let me restate, so you can catch it: I'm not saying be good at everything. I am saying be bad at nothing relevant to your work.

Security is without exception and in all circumstances critically relevant to web development. You cannot be an adequate web developer if you cannot look at a system and break down its security impact and how to mitigate it. You can be a bad one, but you can't be even an adequate one.

Less excuses, more practice. It's what you signed up for.

Re: Web Developer Security Checklist

#229

Earlier quoted context omitted.

Data is only 'in the clear' inside a machine. All machine to machine communication in Cloudflare is encrypted with mutually authenticated TLS. If a user chooses to not encrypt the back haul from Cloudflare to their origin then, sure, that's not encrypted, but we offer free certificates for origin machines so there's no reason to use that option. If you don't like Cloudflare's Origin CA then use Let's Encrypt on the o…

Even so, there's nothing preventing a LE or court order from compromising the confidentiality of your customers, no matter how hard you work on minimizing the scope of your cleartext domains. I know that you, Prince, rdl, and others are serious about security and privacy, but let's be honest here: If the Feds come a-knocking, you will comply. It's not that we don't trust you or your competence. You're just not immune…

Actually, we'd fight like crazy legally — as we've demonstrated repeatedly and successfully — and have implemented our technical systems to make it difficult to reveal anything even if we were ordered to. Moreover, we've included warrant canaries in our Transparency Policy so you can know if anything has changed:

https://www.cloudflare.com/transparency/

See section "Some things we've never done."

Re: Web Developer Security Checklist

#230

Earlier quoted context omitted.

Even so, there's nothing preventing a LE or court order from compromising the confidentiality of your customers, no matter how hard you work on minimizing the scope of your cleartext domains. I know that you, Prince, rdl, and others are serious about security and privacy, but let's be honest here: If the Feds come a-knocking, you will comply. It's not that we don't trust you or your competence. You're just not immune…

Actually, we'd fight like crazy legally — as we've demonstrated repeatedly and successfully — and have implemented our technical systems to make it difficult to reveal anything even if we were ordered to. Moreover, we've included warrant canaries in our Transparency Policy so you can know if anything has changed: https://www.cloudflare.com/transparency/ See section "Some things we've never done."

Have you ever received a legal order not to change your warrant canaries?

Have you ever received a legal order to not disclose that you have been ordered to not change your warrant canaries?

And so on.

Post reply on HN