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

Be careful of the examples you use. They stick

blog.thinkst.com

Post reply on HN
Print view View original

91–100 of 129 posts

Re: Be careful of the examples you use. They stick

#91

Post by SoftTalker »

andirk wrote: post #28

Can we please use `example.com` for an example domain name instead of like `somedomain.com`? It can create accounts with emails that someone can actually intercept.

Another "can we please" is stop illustrating (or providing as defaults) insecure configuration examples.

A large percentage of people following the examples will use them verbatim.

Had a case recently where someone was setting up a postgres container and the example was something like:

    docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
You guessed it, "mysecretpassword" ended up being the password. And the service predictably got compromised, because that example was one that was pretty high up in seasrch results for "how to run postgres in docker" and attackers probing for port 5432 will try "mysecretpassword."

Another one is can we please stop posting code examples that are illustrating some language feature or how to do thing X in language Y, where the code has a footnote "this isn't secure, don't do this in production code." That footnote will be ignored. If you're going to bother answering a question, answer it with a proper implementation and not something that is a gaping code injection vulnerability.

Re: Be careful of the examples you use. They stick

#92

Post by OkayPhysicist »

teddyh wrote: post #5

Oh, absolutely. If you give people an example (and you should), the overwhelming majority will copy the example exactly and then only change what they are forced to change when it doesn’t work otherwise . Therefore, prepare your examples accordingly.

This also applies to code. I come across the situation A LOT in OOP codebases that they have completely superfluous interfaces and/or abstract classes, that are made pointless by the fact that every single implementation extends some example implementation. The most egregious example I ever found was a Minecraft mod which had an interface, implemented by an abstract class, which had another abstract class that extended it, which was implemented by a an example class.

Every single mod I could find (sample size of ~1000) just extended the example.

Re: Be careful of the examples you use. They stick

#93

Post by pxc »

> Frankly it’s a reason enterprise software is often so terrible; tons of options you barely understand or know about, and are configured according to tutorials/examples rather than understanding.

This article stresses that it's not a 'customer-side problem', and what they'll do to try to address it on their end.

But is there anything that enterprises can do in order to encourage people not to work blindly from tutorials? What do companies where workers avoid this pitfall look like?

Re: Be careful of the examples you use. They stick

#94

Post by superfrank »

> It’s important to realise this isn’t a customer-side issue; they shouldn’t have to consider the impact of every configuration option we choose to put in front of them. They don’t have the full context and knowledge, and expecting them to be experts in the nitty gritty of Canarytoken discoverability

Yes!

> Going forward, we will show multiple examples of prefixes. A user looking to add a custom domain will see a variety of example zones when they visit the page, and the examples will cycle each time they open the configuration page. We want to convey that they have options in choosing the name, and we show them a variety of sample options. Our hope is that this will prompt customers to pick their own names, and if they do rely on our examples then those are now spread over a large list of examples.

No! They were so close and yet it sounds like they've still missed the point. The issue is that users don't understand the "why" behind the prefix. Just randomizing the prefix that they're shown does nothing to change that.

IMO, a better solution would be. 1. The shortest possible explanation under the field of why you shouldn't use "someprefix". 2. Prevent users from using "someprefix" as the prefix and show them the warning again. By eliminating the default option as an option, you force your users to leave auto-pilot mode and actually consider their choice.

Re: Be careful of the examples you use. They stick

#95

Post by tangentstorm »

This reminds me of the association between tetanus and rusty nails.

Why would rust make the presence of bacteria more likely? Is it a food source? No, tetanus on a rusty nail was just an example used in an article many years ago.

Sadly, I cannot find a source for the idea coming from an article at the moment. :/

Re: Be careful of the examples you use. They stick

#96

Post by corndoge »

hiAndrewQuinn wrote: post #76
JohnMakin wrote: post #74

Reminds me of a large company I worked at, I had some documents for developers how to set up some local environment thing they had to do exactly 1 time and never again. It was just a handful of terminal commands, all starting with the traditional shell notation like: $ (some command) Over the course of a year I got periodic complaints that it "wasn't working" and I tried to find issues on my end and couldn't. One par…

Is there a reason websites put that $ in front of commands you are fully expected to mindlessly copy and paste? I've seen it happen more and more and it simply baffles me.

Docker does this properly; they show the character but it's nonselectable so you can still copy paste directly without spending time removing the $. eg https://docs.docker.com/engine/install/ubuntu/

Re: Be careful of the examples you use. They stick

#97

Post by mikestew »

ThalesX wrote: post #48
chasd00 wrote: post #38

I gave what my company calls a “lunch and learn” presentation once of some interesting tools. People liked it and shared my deck around which was cool. But then my quick/dirty examples started showing up in best practice (I loathe that term) decks shared to very large teams with my name at the bottom. A security guy, who I greatly respect, raised some questions and I had to go through the whole story with him and the…

I did a similar thing as part of a "lunch and learn". NodeJS + Express was super fresh and I did a small example app. When returning the user profile, I just queried the database and returned the entry displaying some properties on the frontend. The team lead was like "show us the request in the console", and I opened it up and there was the non-encrypted password, createdAt date and basically all the not-needed prop…

I still cringe thinking about it.

Meh, as a sibling comment points out, it's a demo, it'll happen. And when it happens, it's a teachable moment (assuming you can keep your head together as your demo falls apart before your very eyes): "Ah, so as you can see it's import to set the $DO_NOT_DISPLAY_PLAIN_TEXT_CREDS environment var to 'true', otherwise you get this disaster! Hahaha...ha."

Or if you don't know at the time what's going on, "obviously I'm just getting started on this myself, and need to play with some configuration. Better make sure I do before any of this goes to production! Hahaha...ha."

Re: Be careful of the examples you use. They stick

#99

Post by cmovq »

superfrank wrote: post #94

> It’s important to realise this isn’t a customer-side issue; they shouldn’t have to consider the impact of every configuration option we choose to put in front of them. They don’t have the full context and knowledge, and expecting them to be experts in the nitty gritty of Canarytoken discoverability Yes! > Going forward, we will show multiple examples of prefixes. A user looking to add a custom domain will see a var…

> 2. Prevent users from using "someprefix" as the prefix and show them the warning again.

Don't do this - examples in documentation should be valid. Having an example that doesn't work when the user tries it out will just lead to frustration.

Re: Be careful of the examples you use. They stick

#100

Post by jabroni_salad »

hiAndrewQuinn wrote: post #76
JohnMakin wrote: post #74

Reminds me of a large company I worked at, I had some documents for developers how to set up some local environment thing they had to do exactly 1 time and never again. It was just a handful of terminal commands, all starting with the traditional shell notation like: $ (some command) Over the course of a year I got periodic complaints that it "wasn't working" and I tried to find issues on my end and couldn't. One par…

Is there a reason websites put that $ in front of commands you are fully expected to mindlessly copy and paste? I've seen it happen more and more and it simply baffles me.

As a generalist with many operating systems in use, I like that this tells you what OS the command is for. Especially now that powershell with its many unix-like aliases is getting popular, this isn't always evident.
Post reply on HN