
Five Minute Guide to Software Security - jtaft
https://oneupsecurity.com/research/five-minute-guide-to-software-security?tr=hn
======
Cyberdelic
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 performing the same
validation...

My favorite so far, though, was client-side calculation and validation of
order amounts for some products. Intercepting the JavaScript file and tweaking
it before the browser started using it allowed me to place an older for a
bunch of products for only $0.01 (going negative was also attempted, too, but
this particular system did a pre-approval with a payment gateway and it didn't
like that... so I settled on a penny).

These were all things I've done with permission, of course... but it's amazing
what you can do when people assume the browser will always follow the rules...

~~~
artursapek
At my last job the HR guy installed this super annoying Slack bot that would
spam everyone every week with a "happiness survey". I got so tired of it I
eventually logged the requests my survey made and used curl to replay one with
a happiness score of -100 (usually the value would be between 0 and 10).
Response said "success".

Turned out the backend happily took that value and it skewed our average a lot
and the next week I was laughing my ass off while HR was trying to figure out
why everyone was suddenly so unhappy.

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

~~~
danenania
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.

~~~
vec
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 direct
conflict with what the sales & marketing people want, and unfortunately that
means your job is sometimes to fight with the sales & marketing team. But it's
not _complicated_.

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

~~~
vec
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.

~~~
danenania
So where do you store this data then? Or do you just live with forgetting
everything about a user (their name, details, history) every time they switch
devices?

~~~
vec
First I try really hard to not need it. e.g. I'm "vec" on HN. They don't know
my real name, my physical address, or my Twitter handle. Any features that did
need that data are simply not going to be implemented, and the site is
designed accordingly.

Next, I don't store what I cam fetch or derive. Say I'm using GitHub as an
oauth provider. I don't need to store an email, an avatar, or a password hash.
I can use GitHub's data. All I have to store is an opaque oauth ID.

Finally, if I do really need it and I can't get it from anywhere else then
I'll happily store it. I just won't do it first, and I often won't do it until
I've had a talk with the designers about what's possible with the data we
already have.

------
X86BSD
Wow did I miss arguably the most important box to check, KISS?

Seriously, keep it EFFING SIMPLE. The more complex and involved it is the more
things can and will break.

Does no one follow that anymore?

~~~
zzzcpan
Sorry to burst that bubble, but KISS doesn't produce neither secure nor
reliable software. Security and reliability is something you have to design
for.

~~~
tptacek
Software security engineers design for simplicity; it's one of the fundamental
ideas of the discipline.

~~~
kasey_junk
As do engineers designing for reliability.

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

~~~
gkop
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](https://en.wikipedia.org/wiki/Message_authentication_code)

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

------
qaq
"Be prepared to investigate breaches." << This

------
salqadri
Great guide. Reminded me of some of the learnings from the Pokémon Go hacking
expeditions I wrote about last year ([https://medium.com/@salqadri/a-peek-
into-the-pokémon-go-hack...](https://medium.com/@salqadri/a-peek-into-the-
pokémon-go-hacking-scene-68d219134b14)).

------
nwrk
> Don't assume something is secure without testing it.

Just don't assume, please. Golden rule.

~~~
carlmr
Same for performance or space optimization. Always measure. I'm working on
embedded systems where performance and sometimes size matters. I know so many
senior engineers that "optimize" a lot of things without measuring, it's
insane.

------
wnevets
>Ensure use of Anti-CSRF tokens, CORS, and crossdomain.xml policies to prevent
an attacker from forcing a user to submit authenticated requests.

isn't crossdomain.xml an adobe flash thing?

~~~
jsegura
In theory it was designed for any "web client" [1] but it designed for Flash.

Just for curiosity, you can check twitter's [2]

[1]: [http://www.adobe.com/devnet/adobe-media-
server/articles/cros...](http://www.adobe.com/devnet/adobe-media-
server/articles/cross-domain-xml-for-streaming.html) [2]:
[https://twitter.com/crossdomain.xml](https://twitter.com/crossdomain.xml)

------
pjmlp
\- Use languages whose designers care about secure code

