Hacker News Reader

Comment by chromedev | Hacker News Reader

How can someone build such a feature and not consider the most basic security concerns?

The feature is useful for desktop applications that want to help the user compose a mail to the customer service, including some report logs as attachment.

Notice that the user is still required to actually press Send in front of their default mail client with an open window showing the full email and attachments.

I can't imagine any scenario of a widely used email app opening a hyperlink that automatically composes and attaches local files being acceptable, even if they have to click send.

What about sending crash reports or log files? Or some kind of internal workflow where you need to send something from one PC to another and this is the most convenient solution? (I could imagine some kind of tool that semi-automatically sends email but you don't wanna give it your SMTP credentials so it has to work with your MUA. Sounds weird but these kinds of awful problems with awful solutions exist probably en masse.)

(Addendum: See spacebar heating macro XKCD.)

Our program has documents attached to declarations. These typically come from some integration and is saved on a server/shared drive, in some arbitrary sub-directory to avoid too many files in one directory, and typically with some non-intuitive filename for good measure.

Our users want to be able to be able to open a declaration and email the documents, either internally or to their customers, along with some message.

We don't really want to implement a full email client in our program nor having to deal with their SMTP server setup, including proxies, firewall and so on. So we basically do exactly this, open a new mail in their client with some template text and with one or more attachments.

We use MAPI though and not "mailto:", but use-case is there.

If it does this without prompting the user for permission, it should stop doing that.

Our program doesn't prompt the user for permission explicitly, but then the user has to initiate this process by clicking the "email documents" button so...

> How can someone build such a feature and not consider the most basic security concerns?

How can someone press the "Send" button on a email without checking Subject:, TO:, CC:, and attachment list for plausibility?

(A mail-client could contain basic "warn"-lists of credential-holding places, containing a few dozen file names covering 99% of current platforms/programs)

And some "advanced" config options to also configure allowed URI schemes.

I think we've kind of established that, especially when it comes to security, that the onus is on the software to set secure and sensible defaults. I do not think an email client accepting untrusted input to automatically attaching any arbitrary file to the email is sensible or secure.

> A mail-client could contain

but it doesn't.

This feature is probably from a more innocent time. Back then, things like automatically executing a macro with unrestricted filesystem access when opening a text document were treated as useful features.

JIRA sprints occur every two weeks, and half of that is QA!

I guess, but if developers and team can't comprehend the security concerns and ramifications of a change then it should wait until someone does.

You guys do QA?

I swear they're paid by the bug, because every ticket is "is this requested behavior i uncovered a bug?"

I think the same reason that SQL Injection is still so common despite frameworks / orms protecting so hard and even the most broken english youtube tutorial mentioning that security issue

maybe devs just dont care?

maybe they tend to believe "who would inspect our page and try to manipulate form?? no one"?

maybe lack of review?

lack of time?

too much context switching?

Combination of not caring and little to no ramifications if there is a major breach. Heck, sometimes they may be intentional but it is easy to play dumb if you get caught.

Honestly the devs probably didn't consider the worst case scenario. They probably thought "the users will be able to preview the e-mail and notice that s/he will send the attached files when s/he hits send" and that that's secure enough.

Sadly we have the year 2020 and as Rick Cook said: “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.”.

If the email program would pop up a warning that says "The following files have been automatically attached: [List of files]", would that meet the security concerns?

While there are times where that quote applies, in the vast majority of cases, that's the programmer's cop-out upon discovering that the feature they thought was done is in fact broken and obtuse, and they don't care to take the time to understand their customer.

I don't want my email client automatically attaching files from my computer, period. I don't care how well or poorly it displays that fact. There's no use case important enough to warrant that kind of intrusion.

Imagine you want to send a few photos - currently stored on your disk - to your mom. File manager, select a few files, right click, "send via e-mail".

Or a letter you're typing, to some company: in your word processor, File -> Send as E-Mail.

For these features to be able to work, the email client would need to have an API so it can create an e-mail with attachments directly attached.

Sure they're not important, but they're convenient. You might not like them, but hey am I glad you're not a product owner of a mail software.

Yes, of course you should be able to do that using an internal API. Maybe even an internal mailto: link, in the interest of interoperability. But no mail client should ever respect attachments requested by a mailto: link followed by a browser.

> If the email program would pop up a warning...

A moment's thought should illustrate that "pop up a dialog box to ask permission" isn't really a fix for a hole like this. It has conspicuously failed in the past.

I think your quote, which has the benefit of being funny, does miss one key thing, and it's that the number of users and our interactions with our systems keep growing.

Prob(user error) might well be increasing a bit, but N * Prob(user error) is definitely increasing.

Reply on news.ycombinator.com