Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Developer Security Checklist

simplesecurity.sensedeep.com

Post reply on HN
Print view View original

231–240 of 249 posts

Re: Web Developer Security Checklist

#231

Post by DamonHD »

atemerev wrote: post #212
DamonHD wrote: post #165

Earlier quoted context omitted.

That sounds like BAD validation that needs fixing, not an excuse not to do any. Some US sites still won't let me in because (a) they insist that I must have a middle name or (b) screw up the hyphen in my surname. Many sites and payroll systems assume that everyone has a surname. Never mind its character set and ordering. Even if you don't make these assumptions you don't need to accept a binary gzipped GB of zeros or…

Designing a _good_ validation system (to reliably discriminate between "good" strings and "bad" strings, including all corner cases) is really hard, error-prone, not future-proof (standards change) and might be even theoretically impossible in some cases. Some basic sanity checks are useful, of course. But it is not a good idea to use input sanitization as the only (or even main) method of injection attacks preventio…

I never said:

1) That it was easy to do right: that's why we get paid.

2) That it was an excuse not to do other checks elsewhere: defence in depth is key.

Anyhow, I hope that we're really furiously agreeing.

Re: Web Developer Security Checklist

#232

Post by Terr_ »

ams6110 wrote: post #143
sho wrote: post #31

Earlier quoted context omitted.

My apologies - my brain focussed on "stored procedures" and that's what my rant was addressing. Prepared statements are great and I'd use them whereever possible - totally agreed.

Nothing wrong with stored procedures. Like anything else, they might not be right for every application.

IMO you should either (A) avoid customizing the database and treat it as a relatively commodity data store or (B) treat it as its own service with its own developers (DBAs) that just happens to use an SQL connection as its network interface.

Some of the most horrible systems are when people just went half-way, and you've got logic randomly scattered between two systems with two programming languages etc.

Re: Web Developer Security Checklist

#233

Post by omegaworks »

sctb wrote: post #226
omegaworks wrote: post #38

>Use... CloudFlare. lol

It's time to stop posting unsubstantively like this; we ban accounts that won't. https://news.ycombinator.com/newsguidelines.html

All of my supposedly unsubstantiated posts have spawned productive conversations. That they tend to be short skeptical responses is simply my service to foil the groupthink that forms around the saccharine content marketing and growth-hacked-to-death affiliate-linked nonsense that we're all staring at to fill compilation lulls.

Sometimes something short and pithy is more impactful than a big long explainer with citations. Here's a clever little comic that helpfully explains my rationale:

http://theoatmeal.com/comics/believe

I'm not in it for the internet points. I'm in it to express points of view that people like to forget about on here.

Re: Web Developer Security Checklist

#234

Post by slackingoff2017 »

badminton1 wrote: post #219
slackingoff2017 wrote: post #66

Earlier quoted context omitted.

Well, I've avoided the node hype because of people warning about bad debugging experience. With that, I'm going to try to avoid touching it ever. I've used many web stacks over the years and not a single one defaults to blowing up like that. They all follow proper modularization... The framework cleans up objects that the framework creates, you deal with yours. In any other framework forgetting to end the request wou…

It's not a problem with the garbage collector, just how the objects are referenced. Basically you need to ensure the request reaches a terminal state where you either close the connection (ServerResponse.end) or send a response (ServerResponse.send and similar). All the cleanup happens after you do that.

Is there not an OnDispose or some kind of hook to detect when requests can end? To end a request in every framework I've used you just return from your code back to the framework. You shouldn't have to worry about a framework object like request state.

Re: Web Developer Security Checklist

#235

Post by wglb »

aeronautic wrote: post #187
tptacek wrote: post #173

There are 168 comments on this thread all earnestly discussing what is pretty clearly a marketing document written by someone without a firm grip on most of the bullets they've written. Is there that much of a need for another "security checklist", that we'll dive in this deep on a really bad one? Seriously asking! Finally: if you're worried about "APTification" or whatever it is this company is talking about, and yo…

As the author, I should clarify that I am a developer - full time and have been for years. If my english seems to imply a lack of depth of understanding - I'm sorry. The purpose of the checklist is to get people thinking about items they may have forgotten to address during their dev. In the push to ship new products quickly, that happens all too often. I agree with you that there are many more important and basic th…

English is not the problem.

You are missing fundamentals like the Seven Deadly Sins of Web Security. Also missing is ninja threat model.

These are the thing that will wipe you out.

Re: Web Developer Security Checklist

#236

Post by wglb »

sho wrote: post #31
xupybd wrote: post #15

Earlier quoted context omitted.

Totally with you on the DB encryption but I'm not sure about your comments on prepared statements >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've always found using only prepared statements is feasible and justifiable. What is about using…

My apologies - my brain focussed on "stored procedures" and that's what my rant was addressing. Prepared statements are great and I'd use them whereever possible - totally agreed.

Stored procedures offer no inherent protection.

Re: Web Developer Security Checklist

#237

Post by wglb »

aeronautic wrote: post #52
pjungwir wrote: post #51

Earlier quoted context omitted.

Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physicall…

If the hacker gets access to the database due to a network config error, then they will be able to query the database, but only get records with some sensitive fields encrypted. Given the number of email addresses that have been hacked and stolen (3.75 billion in Troy Hunt's haveibeenpwned alone), I believe doing one little extra bit of encryption on email addresses is worthwhile. We push that into our ORM layer and…

I am wondering if you are clear on exactly what database encryption protects you against.

Hint: not much at all.

Re: Web Developer Security Checklist

#238

Post by ianamartin »

ams6110 wrote: post #149
ianamartin wrote: post #93

Earlier quoted context omitted.

I'm going to go the other way on the SQL advice, even though the author has clarified below that he was talking about prepared statements. It doesn't cost me much, if any, developer time to work with stored procedures. I realize most full stack devs don't have as much in-depth experience with SQL. That was literally all I did for the first several years of my career. Before it ever occurred to me to learn other progr…

Agree 100%. I've written longer responses like this on various web forums and email lists, but these days don't have the energy to keep hammering on this nail. Thanks for taking the time.

Thank you for the agreement. It's worth it to me to keep writing these things. My ideas aren't perfect, and I understand that.

But there are good reasons to keep telling people that this is a reasonable way to do things.

It's clearly not the only way to do things, but I'm tired of this idea that it's an awful, terrible way to do things.

There are way to do this that don't suck, and there are legitimate benefits.

It's not always the best way to do things.

But I often feel like we're dealing with people who haven't properly considered the options when we get into thee kinds of threads.

Re: Web Developer Security Checklist

#239

Post by ianamartin »

haburka wrote: post #123
ianamartin wrote: post #93

Earlier quoted context omitted.

I'm going to go the other way on the SQL advice, even though the author has clarified below that he was talking about prepared statements. It doesn't cost me much, if any, developer time to work with stored procedures. I realize most full stack devs don't have as much in-depth experience with SQL. That was literally all I did for the first several years of my career. Before it ever occurred to me to learn other progr…

Data, logic and presentation sounds a lot like model controller and view. I feel like you suggested most logic should be in how days is handled? But let's be serious here, there's no right way to make a web app. There are certainly wrong ways and inefficient ways. If we focus all our efforts on doing things perfectly well then we would miss the point. Essentially, you're just theory crafting how people should code wh…

Yes, okay. Every part of my real life experience developing web apps at the full stack is just theorycrafting.

I've clearly never done this in the real world, and I am simply thinking about my idea of a way to create a web app. And I've never worked with, thought about, or managed a team.

Do I actually need a sarcasm tag for this? I think I do, sadly. /s

I'm being a sarcastic fuckhead. Jesus.

Re: Web Developer Security Checklist

#240

Post by flukus »

vultour wrote: post #97

Prepared statements are amazing. Found out about them very soon after I started programming (incidentally my first language was PHP), and switched to PDO right away. This was years ago, I don't understand how people are still using the deprecated and insecure mysql_* functions, you can still find them all over SO and my university "web" class was teaching them as well...

As other people have noted, prepared statements aren't a security panacea, and string concatenation you do in the query can be vulnerable.
Post reply on HN