5 ms·

Five Minute Guide to Software Security

142 points by jtaft 9y ago

wnevets 9y ago
>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 9y ago
  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/cross-domain-xml-for-streaming.html http://www.adobe.com/devnet/adobe-media-server/articles/cros... [2]: https://twitter.com/crossdomain.xml https://twitter.com/crossdomain.xml
qaq 9y ago
"Be prepared to investigate breaches." << This
salqadri 9y ago
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-hacking-scene-68d219134b14 https://medium.com/@salqadri/a-peek-into-the-pokémon-go-hack...).
X86BSD 9y ago
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?
- maxxxxx 9y ago
  Easier said than done in the real world.
  - X86BSD 9y ago
    Maybe but I would think if you want to be taken seriously you would add it to the list.
    - maxxxxx 9y ago
      To me it seems a little like a platitude or general development advice.
- zzzcpan 9y ago
  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 9y ago
    Software security engineers design for simplicity; it's one of the fundamental ideas of the discipline.
    - kasey_junk 9y ago
      As do engineers designing for reliability.
matt_wulfeck 9y ago
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.
- derefr 9y ago
  Unless the point of your software is to collect and manipulate this data. Like Facebook (in one sense); or like electronic medical record-keeping software (in a very different sense); or... like most free-without-microtransactions casual mobile games today, that are "free" because they make all their money on selling audience analytics.
- danenania 9y ago
  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 9y ago
    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 9y ago
      Speaking as someone who has worked in security with many different companies: I don’t think your bar is reasonable (or intrinsically desirable).
Cyberdelic 9y ago
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 9y ago
  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.
- AlexCoventry 9y ago
  > 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."
- eterm 9y ago
  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! :)
pjmlp 9y ago
- Use languages whose designers care about secure code
nwrk 9y ago
> Don't assume something is secure without testing it. Just don't assume, please. Golden rule.
- carlmr 9y ago
  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.
stevoski 9y ago
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.
- zzzcpan 9y ago
  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.
- gkop 9y ago
  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 9y ago
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.
deleted 9y ago
[deleted]

142 points by jtaft 9y ago

>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 9y ago
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/cross-domain-xml-for-streaming.html http://www.adobe.com/devnet/adobe-media-server/articles/cros... [2]: https://twitter.com/crossdomain.xml https://twitter.com/crossdomain.xml

qaq 9y ago

"Be prepared to investigate breaches." << This

salqadri 9y ago

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-hacking-scene-68d219134b14 https://medium.com/@salqadri/a-peek-into-the-pokémon-go-hack...).

X86BSD 9y ago

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?

maxxxxx 9y ago
Easier said than done in the real world.
- X86BSD 9y ago
  Maybe but I would think if you want to be taken seriously you would add it to the list.
  - maxxxxx 9y ago
    To me it seems a little like a platitude or general development advice.
zzzcpan 9y ago
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 9y ago
  Software security engineers design for simplicity; it's one of the fundamental ideas of the discipline.
  - kasey_junk 9y ago
    As do engineers designing for reliability.

matt_wulfeck 9y ago

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.

derefr 9y ago
Unless the point of your software is to collect and manipulate this data. Like Facebook (in one sense); or like electronic medical record-keeping software (in a very different sense); or... like most free-without-microtransactions casual mobile games today, that are "free" because they make all their money on selling audience analytics.
danenania 9y ago
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 9y ago
  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 9y ago
    Speaking as someone who has worked in security with many different companies: I don’t think your bar is reasonable (or intrinsically desirable).

Cyberdelic 9y ago

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 9y ago
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.
AlexCoventry 9y ago
> 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."
eterm 9y ago
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! :)

pjmlp 9y ago

- Use languages whose designers care about secure code

nwrk 9y ago

> Don't assume something is secure without testing it. Just don't assume, please. Golden rule.

carlmr 9y ago
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.

stevoski 9y ago

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.

zzzcpan 9y ago
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.
gkop 9y ago
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 9y ago

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.

deleted 9y ago

[deleted]