I faced a major issue with the module yesterday. I am using this module on one of my sites to send out mass emails. When you choose to save a copy of the message that is been sent out, it opens up that node for access to anyone. The problem with that is , that then it gets indexed by google and eventually it is there for anyone to see it. I got 50 email addresses exposed due to this vulnerability. I believe the node view of this module should be locked down to be only visible to the administrator. This is a major issue for any company with a user base.

CommentFileSizeAuthor
#2 security_issue_with_the-2555091-2.patch1.13 KBarkener

Comments

Aniessh Sethh created an issue. See original summary.

arkener’s picture

Version: 7.x-1.0 » 7.x-1.x-dev
Status: Active » Needs review
Related issues:
StatusFileSize
new1.13 KB

Just tested this on 7.x-1.x-dev and everyone with the 'View published content' can view the archived message, including the email addresses. While this can be fixed using the Content Access module, I believe this module should implement it's own check. I've attached a patch which includes a new permission "View archived messages", which allows the user to view archived messages.

larowlan’s picture

Unpublishing because security issue, moving to security.drupal.org

David_Rothstein’s picture

Title: Security Issue with the module » The module exposes email addresses by default when it is configured to archive messages as nodes
Issue tags: -Security

The Drupal Security Team discussed this and it seems OK to continue this issue in the public queue.

The nodes and fields are public by default like all content in Drupal, but if you want to hide them there are various ways to do that (e.g. access control modules). I guess it's this module's position that it is the site administrator's job to make that decision via site configuration, or to decide that they want to have them public (since for certain use cases that would make perfect sense).

That said, the default configuration of the module is likely to be insecure for a lot of people's use cases. So either changing the default behavior or putting warnings in the admin UI at appropriate places might be a good idea.