Five Minute Guide to Software Security • Hacker News Board

Re: Five Minute Guide to Software Security

#21

Post by AlexCoventry » Fri, Oct 13, 2017, 9:33 PM UTC

Cyberdelic wrote: post #12

Not trusting user input is a good start, but the client shouldn't be trusted, either. I have seen plenty of web apps that fell short on this... Whenever I'm on a web app that has a button shown but disabled, you can be pretty sure that I will enable that button and click it... If the client is limiting the maximum length of the contents of a textbox, I'm probably going to change that and see if the server is performi…

> Not trusting user input is a good start, but the client shouldn't be trusted, either.

That's in there:

"Validation must occur on the receiving side of communications. Validation on the sending side is a user experience decision."

Re: Five Minute Guide to Software Security

#22

Post by dsacco » Fri, Oct 13, 2017, 9:37 PM UTC

vec wrote: post #20

danenania wrote: post #9

Earlier quoted context omitted.

While this is great advice in principle, in practice it substantially complicates development. We need far better and more accessible end-to-end encryption tools if we want developers to start doing this by default in non-security critical use cases.

No it doesn't. It just requires a shift in your thinking. Having a database is a code smell. If you absolutely have to have a database, then having a `users` table (or equivalent) is a code smell. If you absolutely have to have a `users` table, having any columns in it other than `id`, `username`, and `password_hash` is a code smell. ...and so on. Admittedly this isn't necessarily easy in a company setting. It's in d…

Speaking as someone who has worked in security with many different companies: I don’t think your bar is reasonable (or intrinsically desirable).

Re: Five Minute Guide to Software Security

#23

Post by eterm » Fri, Oct 13, 2017, 9:44 PM UTC

Cyberdelic wrote: post #12

Not trusting user input is a good start, but the client shouldn't be trusted, either. I have seen plenty of web apps that fell short on this... Whenever I'm on a web app that has a button shown but disabled, you can be pretty sure that I will enable that button and click it... If the client is limiting the maximum length of the contents of a textbox, I'm probably going to change that and see if the server is performi…

I would consider "user input" to be everything coming back from the client, that includes everything down to cookies, HTTP-Headers, form values.

Validate everything. Re-check authorisation always.

My favourite too was being new into a development job and buying our biggest package for a penny. What I hadn't counted on was that this was a fairly new system and the CEO was still copied in to every buy order.

Thankfully the company took it in good spirit, I was even sent an expenses form to reclaim the penny! :)

Re: Five Minute Guide to Software Security

#24

Post by stevoski » Fri, Oct 13, 2017, 9:45 PM UTC

Can anyone explain what this means (or point me to somewhere where I can learn?)

> If a stateless architecture being used, use a MAC or an authenticated encryption mode to authenticate input.

I ask as a developer of a SaaS product. I understood most of the tips but not this one.

Re: Five Minute Guide to Software Security

#25

Post by vec » Fri, Oct 13, 2017, 9:58 PM UTC

dsacco wrote: post #22

vec wrote: post #20

Earlier quoted context omitted.

No it doesn't. It just requires a shift in your thinking. Having a database is a code smell. If you absolutely have to have a database, then having a `users` table (or equivalent) is a code smell. If you absolutely have to have a `users` table, having any columns in it other than `id`, `username`, and `password_hash` is a code smell. ...and so on. Admittedly this isn't necessarily easy in a company setting. It's in d…

Speaking as someone who has worked in security with many different companies: I don’t think your bar is reasonable (or intrinsically desirable).

It's not actually a reasonable goal. Almost all pieces of software will need some nontrivial amount of data to fulfill their purpose.

I am convinced, however, that it is a very useful heuristic. The platonic ideal of a perfectly secure database is a completely empty one. Every step away from that requires individual justification. That doesn't mean your database will be small, but it should mean the database is as small as possible.

I treat permanently storing user data (any data, for any reason) as my solution of last resort. That doesn't mean I don't use it. It just means I have to convince myself I don't have any better ideas before I do.

Re: Five Minute Guide to Software Security

#26

Post by zzzcpan » Fri, Oct 13, 2017, 10:04 PM UTC

stevoski wrote: post #24

Can anyone explain what this means (or point me to somewhere where I can learn?) > If a stateless architecture being used, use a MAC or an authenticated encryption mode to authenticate input. I ask as a developer of a SaaS product. I understood most of the tips but not this one.

Presumably, if you don't want to store some state on the server for a client, you can go stateless and store it only on the client but with MAC, so you can authenticate it. For example for session cookies.

Re: Five Minute Guide to Software Security

#27

Post by gkop » Fri, Oct 13, 2017, 10:04 PM UTC

stevoski wrote: post #24

Can anyone explain what this means (or point me to somewhere where I can learn?) > If a stateless architecture being used, use a MAC or an authenticated encryption mode to authenticate input. I ask as a developer of a SaaS product. I understood most of the tips but not this one.

They're implying that you are storing state in the client which sends that state back to your system in subsequent requests, e.g. an HTTP cookie. If doing so, make sure to use a MAC [0] to tell if the client has tampered with the state you stored.

[0] https://en.wikipedia.org/wiki/Message_authentication_code

Re: Five Minute Guide to Software Security

#28

Post by yjftsjthsd-h » Fri, Oct 13, 2017, 10:07 PM UTC

vec wrote: post #20

danenania wrote: post #9

Earlier quoted context omitted.

While this is great advice in principle, in practice it substantially complicates development. We need far better and more accessible end-to-end encryption tools if we want developers to start doing this by default in non-security critical use cases.

No it doesn't. It just requires a shift in your thinking. Having a database is a code smell. If you absolutely have to have a database, then having a `users` table (or equivalent) is a code smell. If you absolutely have to have a `users` table, having any columns in it other than `id`, `username`, and `password_hash` is a code smell. ...and so on. Admittedly this isn't necessarily easy in a company setting. It's in d…

I work in a SAAS company whose product is used by businesses to exchange data and run reports, which are emailed. What exactly should we cut without destroying the utility of our work?

Re: Five Minute Guide to Software Security

#29

Post by petra » Fri, Oct 13, 2017, 10:08 PM UTC

This security list is only a partial list, and it's not realistic for a busy programmer to cover everything well.

On the other hand, visual tools(low-code/no-code), sold in cloud based models(and probably grabbing a lot of money), are backed by teams of experts who do security well and don't expect the user to do any of it.

And as for tools take 100% of the security burden from the hands of the programmer - i haven't seen any.

So my conclusion is: where security will matter - visual tools will dominate.

Re: Five Minute Guide to Software Security

#30

Post by foobiekr » Fri, Oct 13, 2017, 10:14 PM UTC

danenania wrote: post #9

matt_wulfeck wrote: post #6

These types of guides always overlook the most important principle of software security: Always avoid reading, storing, or interacting with secure, personal, or otherwise "interesting" data. As much as possible, strip this information from your application, so that when it gets pwned the blast radius is absolutely miniscule. Create software not liabilities.

While this is great advice in principle, in practice it substantially complicates development. We need far better and more accessible end-to-end encryption tools if we want developers to start doing this by default in non-security critical use cases.

IMHO I think that's only sort of true. I would also like to add something:

If you can, move the computation to the data and never take possession of it _or any equivalent_ such as _a credential that allows perpetual access to the data_.

A lot of the time, while it may complicate the conceptual part of development, it doesn't really complicate the implementation too terribly much and it also forces a kind of sane layering.

That said, we should really embrace the idea that it doesn't matter if it complicates development. Start with that premise and back off if and only if you cannot accomplish your goals.

The "or equivalent" thing is very important and does not get enough attention. I was evaluating a solution (a competitor) at one point that as part of installation required, and cached, an (active directory) domain administrator account name and password (obviously in reversible form). That's just crazy. It's begging for the product to be at the center of a complete compromise of the administrative systems of the customer.