Inbound email and renderers
Inbound mail becomes a ticket, a comment, or HTML. The questions are who renders it, whether links are unfurled server-side, and whether the address the app stores is the address that received the mail.
Tags: email, parser
Level: advanced
Method
Find the inbound path
Support inboxes, comment-by-mail, and 'email this document' are the features. You need a mailbox the program allows you to use.
Tools: browser
See who renders the body
If the HTML is shown to another user, say which user, in a test you both control. A renderer that runs script is XSS with a mail delivery path. Describe the context. Do not include a payload page.
Tools: browser
Unfurl and attachments
If the server fetches links or parses attachments from mail you sent yourself, record the fetch or the parser. Fetch impact belongs with SSRF. Parser impact belongs with the archive page.
Tools: Burp Suite
Identity of the sender
Compare the From address the app stores with the mailbox you actually sent from. Spoofed display names are not the same as accepted mail from an address you do not own.
Tools: browser
Threading and IDs
A reply that lands on another ticket because the message id was guessable is an authorization bug. Test with two tickets you own.
Tools: browser
Keep it in your mailboxes
Do not send test mail to customers or to people outside the program.
Tools: browser
Field notes
- Display-name spoofing alone is usually not a finding.
- DMARC alignment explains whether the provider should have trusted the sender. Cite what you observed, not a tutorial.
- An unfurl of a URL you control is a canary, not impact, until you show what the server did next.