[PATCH] wwwattach: set "Content-Disposition: attachment"

[Eric Wong <e@80x24.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;