skip to Main Content

What would be the recommended way to securely view emails in a browser (in PHP)?

Emails are highly insecure content and desktop email software obviously implements only a very limited subset of HTML and no javascript at all to prevent attacks. But if I’d take an email HTML source and display it in a browser, javascript code and other stuff would be executed.

I thought a solution would be to send a header like this along with the email source:

header("Content-Security-Policy: sandbox");

But this would prevent me from fetching inline images from the server as I still would need a PHP session id to be transmitted to understand that the user is allowed to fetch this content.

As there are many web email clients out there I wonder if there is a best practice model.

(FYI: I try to implement my own web email tool fitting to specific needs of a larger software suite)

2

Answers


  1. Chosen as BEST ANSWER

    I finally decided to modify the HTML source of the email (in my php script) to serve the inline images as base64 encoded data inside the HTML source. Therefore no additional loading of images is needed:

    <img src="data:image/gif;base64,R0lGODlhDgE3APf/ALJUMt3W0aMyFPTixGRHOXNXSvnu3b1sSu7SpPLduurTxapEIvbly/bq4+bAffTo31Q1J/369dGafaAtDO3o5ePd2c6Tdfz6+a9...">
    

    This will solve the current problem of displaying emails, because then I can stay my

    header("Content-Security-Policy: sandbox");
    

    because it is one major way to prevent attacks to be successful. Additionally, for enhanced security, I plan to look again into roundcubemail and see if I find out how they handle this problem and also use HTMLpurifier to further strip the email source from possible threats.


  2. You can address the issue of images by not requiring authentication and then making the URLs hard to guess (ex: <img src="/resources/SomeReallyLongHardToGuessRandomString">).

    More broadly though, securely displaying user generated HTML is hard. Like really hard. This is a case where you should use a library. Keep in mind that you might have a user with a browser that is too old for the Content-Security-Policy header. This browser would happily run any scripts on the page. HTML Purifier is my personal choice, but there are others. Also, keep in mind that this is a dependency you will want to update often as people are constantly discovering new bugs.

    As an additional line of defense, many sites use a seperate domain for user generated content. For example Google uses googleusercontent.com. That way if something does slip by, they haven’t compromised the whole application. Note that this would still be bad, as an attacker might be able to read user content they shouldn’t be able to (emails in this case).

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search