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

211–220 of 249 posts

Re: Web Developer Security Checklist

#211

Post by spydum »

creepydata wrote: post #178
aeronautic wrote: post #159

Earlier quoted context omitted.

I think we can all agree that developers can get better educated about security and can participate building security into the product from the very start. It is hard to engineer security in via a sec-team at a later stage. Education is the key.

How is something like "Use CSP without allowing unsafe-* backdoors" in any way educational? If I'm a newbie web developer, even coming over from embedded systems, how do I know what CSP is? What do I use CSP for? How do I start with CSP? What do I do to configure CSP? What does CSP even stand for? I don't know, it wasn't even defined! Basically, this is a useless listicle. If you know anything about web security you…

You are right: checklist is not for education. If you don't know how to implement one of those items, you need to go learn. The checklist itself is still valuable, even to a seasoned security developer.

A checklist will not teach a pilot how to fly and land a plane, but it's value is not zero..

Re: Web Developer Security Checklist

#212

Post by atemerev »

DamonHD wrote: post #165
atemerev wrote: post #128

Earlier quoted context omitted.

...and this is why Gerard 't Hooft, the famed theoretical physicist, can't register with his real name nearly anywhere. :( https://en.wikipedia.org/wiki/Gerard_%27t_Hooft

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 prevention.

Re: Web Developer Security Checklist

#213

Post by atemerev »

randallsquared wrote: post #147
atemerev wrote: post #104

Earlier quoted context omitted.

I think, the author is right, and you might be not. "Data at rest" means the data that you have no intention of querying soon. Which implies "hot" / "cold" data partitioning, which is usually a good idea. Can be complicated, but commonly encountered in financial backends. Two layers of encryption can be better than one (if logically and temporarily separated). Encryption algorithms are usually not a problem; credenti…

I work in health care, where "data at rest" does not mean you won't query it soon, but instead that it isn't either in transit (datastore to app, app to app, app to customer, etc; all of these have transport encryption) or being worked with in memory currently. If the data is in a store, it's almost certainly "at rest".

OK, for anything that is queried on demand it is not a good idea, until we get homomorphic encryption.

Re: Web Developer Security Checklist

#214

Post by SadWebDeveloper »

thatwebdude wrote: post #175
SadWebDeveloper wrote: post #167

Earlier quoted context omitted.

Nop.. it isn't good, secure endpoints for API's shouldn't be exposed in plain, an error should be raised when a developer/app tries to contact via HTTP rather than HTTPs.

Is 404 sufficient?

Depends on your choice, personally i would choose between 410 or 501 but whatever you choose, just don't allow an implicit redirect with any of the 301/302 codes.

Re: Web Developer Security Checklist

#215

Post by john61 »

drostie wrote: post #166
john61 wrote: post #133

Earlier quoted context omitted.

>> Fully prevent SQL injection by only using SQL prepared statements and stored procedures > That is an extraordinarily inefficient and costly way to develop. Why is this inefficient? Can you elaborate?

As mentioned beneath, the comment was secretly fixated on the 'stored procedures' side and not the 'prepared statements' side. Stored procedures have many costs associated to them; for example, they don't get version-controlled by default and they don't lend themselves easily to a development/production schism; both of these need to be solved by writing out some sort of database-synchronizer-script which will handle…

In my development style every database ddl change is done with a version controlled sql file piped trough psql and/or apgdiff. So I guess these points do not apply to me since there is no difference in normal code and database code handling.

Re: Web Developer Security Checklist

#216

Post by badminton1 »

aeronautic wrote: post #91
badminton1 wrote: post #89

Earlier quoted context omitted.

But all the objects remain leaked even if the request connection ends. And if the request stream got piped into another stream the problem can become more severe. Usually error events propagate through piped streams, but that largely depends on the order in which the event handlers were defined.

Are you sure the objects remain leaked when a connection disconnect comes through? I don't have hard data on that. Depending on the node web framework (express, ...) they may handle that differently and may have timeouts to cleanup. I'd love to get a firm answer on this one.

Yes, I am certain of that. I've seen it in production environments and verified it by looking at heap dumps.

Re: Web Developer Security Checklist

#218

Post by FLUX-YOU »

eropple wrote: post #191
FLUX-YOU wrote: post #135

Earlier quoted context omitted.

>Do both. I'm a big believer in having dev learn and own a part of the security process. Devs already do enough, take some bloody ownership of security outside and inside of code. When devs start having to whiteboard security issues in interviews, then you can make us responsible for it because we'll appropriately charge you for being decent at two things instead of one.

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're not a good developer if you're not prepared to be the best at everything!

As a web developer, your security knowledge is rarely assessed and tested. If you're not focusing on security 100% of the time, you're not going to be as good as a professional and the bad guys.

You need people focused on security doing the security work. Having someone do business features and security work at the same time is an indication you don't take security seriously because you do not have dedicated people for it. If Bob who's mostly front-end but some back-end says it's secure, I'm not going to believe him. That's the same false confidence that companies parrot to us when they say that "security is a priority", but they have XP machines on their network still and code vulnerable to SQL injection in their code. Don't tell me this doesn't exist because I woke up this morning and read that exact email. You can't half-ass security and a line of business developer is not a security professional.

This doesn't mean you get to be lazy and continue to concat SQL strings even after someone has told you it's bad in a code review.

Re: Web Developer Security Checklist

#219

Post by badminton1 »

slackingoff2017 wrote: post #66
badminton1 wrote: post #33

A largely incomplete list. One of the most important items would be: handle errors correctly and make sure errors do not result into any sort of resource leak or sensitive information disclosure. For example, this code was from a guy in Stack Overflow: ... function (req, res, next) { if (err) return console.log(err) What will that piece of code do? Leak the request object, the response object, including the underlyin…

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.

Re: Web Developer Security Checklist

#220

Post by winut23 »

aeronautic wrote: post #90
winut23 wrote: post #87

Isn't best practice when it comes to passwords to actually choose a good one, use a password safe, and _not_ rotate?

Both. You want to choose a good password and then not let it get too stale. A very old password (say 1 year) has a higher chance of being subverted purely because there is more elapsed time wherein attackers could have gained access. Choose good passwords, long, special chars, preferably random and generated by a password generator / manager. And then change periodically. That period depends on your application. We c…

You are wrong, at least if you listen to what people like Bruce Schneier and other experts say about password security.
Post reply on HN