Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Follow-up to #2819987: Download mail attachments on click
Problem/Motivation
Header::toArray() adds field value separation by comma which is the rule for HTTP headers, not for MIME headers.
Proposed resolution
Removing it could cause overwrite in the header... What we could do is to replace toArray() with getFields() and then leave to the caller to do what is necessary.
Also, EmailDisplayController uses toArray() call to create HTTP headers from the given MIME headers. Let's just Content-Type, Content-Disposition MIME header values as HTTP ones.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#8 | remove_field_value-2820667-8.patch | 4.8 KB | mbovan |
|
Comments
Comment #2
miro_dietikerYes, we can't passthru headers like we do now.
We need to treat each header cleanly on its purpose and decide what to do with it.
And we need test coverage for many different cases and validate their headers as expectations are.
Comment #3
miro_dietikerAh, you propose to do the test coverage separate:
#2820669: Improve tests for attachment downloads
This is kindof related / overlapping. I think we should do the test coverage then first so we have proper expectations.
Comment #4
miro_dietikerconnecting, so un-postponing works.
Comment #5
miro_dietikerLots of updates recently. Is this still pending?
Comment #6
miro_dietikerOriginally we passed all headers into HTTP headers, but that's very dangerous and wrong since those are MIME headers and not HTTP headers - and untrusted anyways. For instance i could cause an open redirect by injecting a Location: header. :-)
So we need to treat header by header manually with output.
Comment #7
mbovan CreditAttribution: mbovan at MD Systems GmbH commentedYeah, we fixed this for the raw message access, but it still applies for the general attachment case.
Comment #8
mbovan CreditAttribution: mbovan at MD Systems GmbH commentedConverted
toArray()
togetFields()
.Also, made header related updates in
EmailDisplayController::getAttachment()
.Comment #9
miro_dietikerNo :-)
The implementation in toArray was perfectly right and it adds value. It follows the RFC that defined it.
The problem is here. You are simply not allowed to do a HTTP response and passing in the headers from the original entity.
Again, i could send you a mail with this:
"Location: example.com"
Then if you visit the download URL with a browser, you are redirected. This is a security issue, called open redirect.
Every header you want to pass to the browser from the mail needs to be identified by name and with validated properties.
Don't pass headers forward you don't know.
Comment #10
mbovan CreditAttribution: mbovan at MD Systems GmbH commentedWell, it's defined by the following HTTP-related RFC standard: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2.
I couldn't find if it applies for MIME messages. Most likely, no... On the other side, it could cause problems with some header fields (e.g. "Received" header).
Re #9.2: I think that's what we are preventing with #8.
Comment #12
miro_dietikerOK great, Examples also look pretty fine about header checks.
I was wrong with both parts. :-)
I'm only not sure about image delivery. If an image is contained with disposition attachment, we still pass it forward as inline.