user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: Leah Neukirchen <leah@vuxu.org>
Cc: meta@public-inbox.org
Subject: [PATCH] wwwattach: set "Content-Disposition: attachment"
Date: Sun, 8 Nov 2020 07:49:17 +0000	[thread overview]
Message-ID: <20201108074917.GA29704@dcvr> (raw)
In-Reply-To: <87imagyap9.fsf@vuxu.org>

Leah Neukirchen <leah@vuxu.org> wrote:
> Eric Wong <e@80x24.org> writes:
> > 1) Image rendering libraries and complex graphics stacks increase
> >    attack surface.  IIRC libpng/libjpeg have both had problems with
> >    malicious data in the past, and could be in the future.
> >
> >    From what I can tell, text-only stacks seem barely capable of
> >    displaying text without arbitrary code execution.  I'm not
> >    optimistic about something as complex as image rendering from
> >    untrusted sources.
> 
> Well, that's what probably literally every other website on the web does. ;)

Yes, but this project has never been about doing what others do :>

> >    The current practice of linkifying URLs poses that problem,
> >    too, but the public-inbox admin isn't responsible for hosting
> >    the content in those URLs, bringing us to...
> 
> Yes, I don't want to inline the data but just display it on click.
> It's the same as any other Mailman or Google Groups archive.

OK, it seems possible to support optionally.  I don't think it's
a good default for Mailman given the risk.  Of course Google has
vast legal resources which we can't expect our users to have.

> > 3) (Probably) risk to admins hosting public-inbox instances if
> >    there's illegal content.  Right now, the data is still there,
> >    but having it less obviously visible probably helps reduce
> >    exposure when combined with 2).
> 
> Notice that deep-linking this attachment (e.g. with <img src= />)
> will already display the image, as it triggers content autodetection.

Yikes, I did not know that!(*)  It doesn't happen with dillo,
though Firefox seems affected.

(*) Because I never use <img> out of concern for folks with
    slow and/or metered Internet access.

> > I am not a lawyer, and laws vary wildly by jurisdiction;
> > so I think it's prudent to err on the side of paranoia when
> > dealing in untrusted data sources.
> >
> > That said, a patch + options to allow passing through certain
> > content types for the server to pass through could be accepted.
> > It needs to also require a secondary option visible to the client
> > (via opt-in cookie or POST), to avoid surprising differences
> > between differently-configured server instances.
> 
> I think it would be more correct to send the real MIME type
> and "Content-Disposition: attachment" (or "inline" then, when asked for).

I think passing MIME type is too risky by default even with
"Content-Disposition: attachment".  Browsers can still
auto-launch external programs on attachments, right?

But C-D:a definitely seems needed, and below is a patch for it.

> (However this does not prevent hotlinking either...)

Right.  I'd be much more comfortable if the default behavior
was consistently "Save As..." and then have the user process
it as a separate step (perhaps on an air-gapped machine).

Care to test the following patch?

It's also right where you or someone else would need to
make changes to optionally enable MIME type pass through.

Thanks.

--------8<-------
Subject: [PATCH] wwwattach: set "Content-Disposition: attachment"

This prevents `<img src=' tags from being used to deep link
image attachments.  Some browsers favor content detection and
will display images irrespective of the Content-Type header
being "application/octet-stream".

Reported-by: Leah Neukirchen <leah@vuxu.org>
---
 lib/PublicInbox/WwwAttach.pm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/PublicInbox/WwwAttach.pm b/lib/PublicInbox/WwwAttach.pm
index 0b2cda90..a6ed6caa 100644
--- a/lib/PublicInbox/WwwAttach.pm
+++ b/lib/PublicInbox/WwwAttach.pm
@@ -30,6 +30,9 @@ sub get_attach_i { # ->each_part callback
 	} else { # TODO: allow user to configure safe types
 		$res->[1]->[1] = 'application/octet-stream';
 		$part = $part->body;
+
+		# prevent deep-linking via <img>:
+		push @{$res->[1]}, 'Content-Disposition', 'attachment';
 	}
 	push @{$res->[1]}, 'Content-Length', bytes::length($part);
 	$res->[2]->[0] = $part;

  reply	other threads:[~2020-11-08  7:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-07 19:10 MIME types for image attachments Leah Neukirchen
2020-11-07 20:39 ` Eric Wong
2020-11-08  0:05   ` Leah Neukirchen
2020-11-08  7:49     ` Eric Wong [this message]
2020-11-23 14:15       ` [PATCH v2] wwwattach: prevent deep-linking via Referer match Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201108074917.GA29704@dcvr \
    --to=e@80x24.org \
    --cc=leah@vuxu.org \
    --cc=meta@public-inbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/public-inbox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).