[HN Gopher] Kobold letters: HTML emails are a risk
___________________________________________________________________
Kobold letters: HTML emails are a risk
Author : chillax
Score : 292 points
Date : 2024-04-04 10:27 UTC (12 hours ago)
(HTM) web link (lutrasecurity.com)
(TXT) w3m dump (lutrasecurity.com)
| bluetidepro wrote:
| > "However, you are still not convinced, so you call your manager
| to ensure that the email is legit. He confirms, so you transfer
| the money."
|
| I feel like it's a HUGE (silly) assumption you'd ask generically
| "did you send this email" instead of something more specific like
| "do you REALLY want me to transfer you money like this?" to which
| the manager would obviously be confused and the attack would
| likely be killed in that conversation.
|
| This is an interesting attack vector but I am questioning how
| likely it is to succeed. The article paints a very specific and
| narrow window of events for this attack to really work. I don't
| buy it, personally.
|
| EDIT: I know phishing happens and works. I am not saying it
| doesn't. I just mean the people that fall for phishing don't need
| this sophisticated of an attack to fall for. In fact, the
| attacker probably narrows the chance of success by putting this
| much extra (very specific) effort into the attack. They are
| likely to just succeed with their typical phishing email.
| Macha wrote:
| Worked for a 10,000 person company, 50% engineers. There'd be
| several cases a year of someone using the company credit card
| to buy gift cards for "the CEO" or other senior execs whose
| details are available on linkedin or corporate sites, despite
| that exact case being the example in the anti-phishing
| training. So you'd be surprised.
| bluetidepro wrote:
| I don't doubt phishing happens. I just think this specific
| scenario/technique is one that is probably extremely rare.
| The attacker likely wouldn't put this much extra
| effort/thought in when their basic attacks already work, like
| you're describing.
| fkyoureadthedoc wrote:
| Security at my job pumps their numbers by pretending you
| fell for a phish if you click the link in their obvious
| phishing test emails. I clicked one to see how good of a
| job they did at the other end of the link trying to extract
| whatever they want from me, but there's nothing there! So
| lazy.
| hk1337 wrote:
| I got dinged once for using curl (in a VM) on the link
| get the details to pass one when I reported it.
| npongratz wrote:
| I once got dinged for forwarding an obvious gotcha email,
| without ever opening it, to our security team's phish
| notification address, as our employee handbook
| instructed. I learned my lesson.
| testudovictoria wrote:
| I once got dinged for not reporting. I saw an email that
| was clearly an internal security campaign. I deleted it.
| I received an email a day or two later stating that I
| failed to take action on a phishing attempt. Damned if
| you do; damned if you don't.
| Macha wrote:
| For a while I had a thunderbird filter to automate
| forwarding based on our provider's email header.
|
| They disabled SMTP and the Gmail web client has no such
| ability to filter on arbitrary email headers.
| ohthatsnotright wrote:
| You can setup a Google app automation to do this for you.
|
| I did for e.g. knowbe4 since all their test emails have
| the same header information. It made it quite easy to
| never see any of their attempts, though I did have to
| check every once in a while to see if I'd been signed up
| for any random learning and it removed those emails as
| well..
| Macha wrote:
| iirc, the same company had locked down the allowed oauth
| apps, so you would have needed an exception from security
| to run one.
|
| I doubt they'd have granted an exception to stop getting
| annoyed by their own training.
| tripdout wrote:
| Yeah the links from Proofpoint are unique to you, so
| however you visit it you still get tracked
| hk1337 wrote:
| It was when I was working at HP/HPE/DXC (I don't remember
| what it was at the time), I don't remember what they
| used.
| MakeThemMoney wrote:
| Thank you!
|
| - Browser 0-day vendor
| planede wrote:
| It's good that I otherwise don't click on links in my
| browser during my day-to-day work. /s
| themoonisachees wrote:
| Good thing browser aren't able to display content of
| random unvetted third parties in exchange for money on
| any website you visit too :)
|
| Adblock is a security measure at this point.
| autoexec wrote:
| You aren't wrong. I've got a heavily locked down browser
| on an off-network device for working with questionable
| websites. While the vast majority of phishing sites
| aren't pushing malware spearphishing is another story.
| bee_rider wrote:
| IT still might not want you to follow the link.
|
| * Other users might have, instead, an incompetently
| secured browser that they think is locked down on their
| work devices. It is hard for IT to distinguish between
| you and them.
|
| * If the URL is personalized, it tells the attacker that
| the address is active. This is probably pretty limited
| help to the attacker. But it might tell them if your
| company emails follow a particular format, right?
| fkyoureadthedoc wrote:
| > * If the URL is personalized, it tells the attacker
| that the address is active. This is probably pretty
| limited help to the attacker. But it might tell them if
| your company emails follow a particular format, right?
|
| I just asked chatgpt and it knows what email format the
| company I work for follows, so I'm not sure this is of
| particular value.
| autoexec wrote:
| It's useful, even if you aren't a scammer, but it's
| generally not hard info to get elsewhere.
| fkyoureadthedoc wrote:
| I feel truly sorry for whoever spends a browser 0-day
| giving RCE on me.
| kurnikas wrote:
| I got dinged for clicking "report as phishing" as part of
| that process forwards it to microsoft threat intelligence
| in outlook and so their systems said I forwarded and
| therefore fell for the phishing, now I look for a
| particular header and put all of those messages in a
| "phishing" folder
| imzadi wrote:
| I run my organization's phish sims, and we had a similar
| issue one month. A bunch of people failed for downloading
| attachments. When I looked into it further, all the
| attachments were downloaded by the same Czech IP address.
| With some research, I found that it was an AVG IP
| address. The fix is very simple. The phish sim service
| has a place to exclude IP ranges. Any activity from those
| IPs are just ignored. I'm sure all phish sim services and
| software have this ability.
| Finnucane wrote:
| Now when I see a phish, I check to see where it is coming
| from. 97 percent of the time, it is a test. We're getting
| these tests often enough that I just assume that's what
| it is.
| imzadi wrote:
| Which is fine, actually. If you see it and think "oh, IT
| is at it again" and delete it or report it, mission
| accomplished, because there is still that 3/100 chance it
| is real.
| Kinrany wrote:
| It only works on fake fishing.
| imzadi wrote:
| So when you look at the sender of a suspicious email and
| it's not the phish sim service you just go ahead and open
| it? That doesn't sound like a problem with the phish sim.
| Kinrany wrote:
| It's certainly a problem with the phish sim if you're
| trying to teach people not to open random links and
| instead you're teaching people not to open phish sim
| emails.
|
| It fact, it can be actively harmful if it creates a false
| sense of security.
| sdrinf wrote:
| Question: why is clicking on the (test) phishing email's
| link "fail"? Isn't the whole contract between browsers
| and society that one can safely open any website they
| want (ie loading a webpage is safe), and what you do on
| the actual site is the actually unsafe op?
|
| Asking because in the vast majority of cases, the
| phishing landing page has way more signals to recognize
| than the email headers.
| jrockway wrote:
| We must use the same vendor, as I heard about that
| happening to my coworkers. I clicked "it's phishing you
| idiots" in Outlook and got a gold star. I find it funny
| because my organization doesn't even use email, so 100%
| of email I get is spam or phishing.
|
| The dead giveaway on this email was that there was a Via:
| header that was like "phishingtestsforyourworkplace.com"
| or something.
| seethishat wrote:
| Many phishing simulation systems are not technically
| correct. Microsoft, Google and other 'security vendors'
| may inspect links in emails. That link inspection can
| sometimes be blamed on the end user. "You clicked the
| phishing link, now you have to take remedial security
| training!"
|
| The only way to know for certain that a user fell for a
| phish, during a simulated exercise, is to make an HTML
| form that does a HTTP POST request and contains the
| user's credentials (that only they could type in). If a
| user enters their username and password and clicks
| submit, then they fell for the phish, otherwise no one
| can say for sure who or what software clicked that link
| that did a simple HTTP GET.
| w3ll_w3ll_w3ll wrote:
| Microsoft Safe Link technology does not actually inspect
| the link until the user clicks on the link. This is to
| avoid that confirmation links, used by some service to
| confirm registratio or as 2FA, may be triggered by the
| security engine without user consent.
| GrinningFool wrote:
| I did that once for the same reason, and found myself
| sentenced to mandatory security retraining videos with no
| possibility of appeal.
| raptor99 wrote:
| Maybe it's just good to be aware.
| tomhallett wrote:
| While I'm not saying the specific scenario will work 100%
| of the time, it doesn't need to - by the email getting
| forwarded at all, there is some element of trust in "my
| manager forwarded me this email and typed 'complete this
| for me'". If this css technique increases the attackers
| odds, then it's an issue.
|
| Or for your specific example, imagine the recipient is
| passing their manager in the hallway: "hey, can we chat
| about the Acme Corp email, I've got some questions about
| it". Response: "sorry, super busy. It's a fairly common
| ask, just get it done!"
| mmsc wrote:
| You're right. They wouldn't ask any questions at all, and just
| send the money.
| bluetidepro wrote:
| Agreed, the people falling for this would already fall for a
| much more basic phishing attempt. Thus, the attacker has no
| need to put this much extra effort/thought into it.
| themoonisachees wrote:
| This doesn't even need to be a hypothetical. We know that
| the attacked currently do not need to do this, because they
| don't. Darwin's law is very much in effect for scams of all
| types.
| croes wrote:
| Could be a link to some kind of portal.
|
| You ask your boss if he sent the link to the portal, he
| confirms, they change the link to a phishing site.
| nkrisc wrote:
| My gut says this could be more effective. After all, the
| initial "phish" (the innocent looking email the manager
| receives) isn't fishy at all, and unlikely to trigger any
| concern. Once the stakes are raised and the scam is revealed,
| the email has already been granted some amount of legitimacy.
|
| Sure, it can easily fail ("did you really want me to wire money
| to Cyprus?"), just as any phishing email can. But by bypassing
| the initial phishing filters of the recipient's awareness, I
| could see it having a higher success rate than a cold phish
| that leads immediately with the scam.
|
| No evidence or knowledge either way, just a hunch.
| duxup wrote:
| I agree that his seems so specific that while it is very
| interesting from a technical perspective, it is also much less
| likely compared to most phishing.
| dimask wrote:
| I think that, in theory, it could allow for more sophisticated
| and targeted attacks, like changing the intended recipient of a
| money transfer. That would be much harder to detect.
| chromanoid wrote:
| It depends on the people I guess. Some managers will be annoyed
| of such conversations when they have to approve payments like
| that on multiple occasions a day - so employees might want to
| avoid such conversations.
|
| The attacker could even add something like that: "I am
| currently on a trip. If you are unsure call me on my private
| mobile phone number..." and then respond with a faked voice. I
| think a good way of reaching targets would be a "double"
| forward. So the sender assumes the role of an employee
| forwarding the email of a manager to an administration adjacent
| employee. This employee unsuspectingly forwards the seemingly
| harmless mail (that seems to be forwarded from the manager)
| again for a reason like birthday wishes or sick notice. This
| will make it hard for the actual target to understand where the
| email originally comes from.
|
| Beside that one can easily think up more creative ways to use
| this "feature". E.g. letting unsuspecting persons forward
| problematic content and then blackmail them etc.
| bambax wrote:
| > _I just mean the people that fall for phishing don 't need
| this sophisticated of an attack to fall for_
|
| Yes. It's more of the opposite. It's a well documented fact
| that the most obvious/ridiculous scams work the best, because
| they help select the most gullible potential victims.
|
| https://www.microsoft.com/en-us/research/publication/why-do-...
| comicjk wrote:
| That analysis is from the perspective of the _scammer_. The
| scammer has limited time to write to each victim once the
| responses come back from the initial mass-email, so the
| scammer is better off if only the most gullible people reply.
| From the perspective of the _person being attacked_ , the
| counterintuitive result based on selection bias goes away,
| and a more convincing scheme is more of a risk to you
| personally. (The assumption that scammers have limited time
| to write to each victim may itself become less true because
| of LLMs.)
| izacus wrote:
| That doesn't mean those scams are actually commonly
| successful.
| n2d4 wrote:
| This is only true for high throughput spam e-mails, such as
| those sent to literally every e-mail address in a large data
| breach. Corporate phishing attacks are much, much more
| advanced.
| nebulous1 wrote:
| I agree, but actually it's just a really bad example that takes
| the reader to the wrong place because it has the participants
| acting so irrationally.
|
| The underlying issue is still there, they've just distracted
| from it by putting this in and having the reader go "hang on a
| second". They should have used a situation that was more
| believable, but also concentrated more on requests where the
| target likely wouldn't even seek confirmation.
| salesynerd wrote:
| One scenario where this night not be far-fetched is when such
| mails are sent to the accounts payable department of large
| companies. The people are not going to call a line manager
| everytime a payment request comes through email, especially if
| the dollar amount is small and didn't require pre-approval.
|
| I remember even Google had fallen prey to such a scam where
| they were paying somebody even though no work was done.
| Admittedly, that case involved fictitious invoices. However,
| the principle remains the same.
| sonicanatidae wrote:
| This attack works like normal Sales calls. Hit enough of them
| and you'll find someone that's new, or in a rush, or distracted
| or ancient or challenged or a Republican idiot, or, or.
|
| That's why it's still in use today. It works, but takes a lot
| of "cold calling" via phishing to find targets.
| michaelmrose wrote:
| A more trivial gambit is logging into an attacker controlled
| site leaking credentials or installing malware.
|
| Also office drones are probable targets. They won't want to
| waste important peoples time asking for confirmation.
| willd13 wrote:
| Still pretty cool trick though
| maaaaattttt wrote:
| I see that some of the email clients mentioned wrap the mail's
| content in extra HTML tags and modify the CSS and classes names.
| I'm wondering why email clients don't use sandboxed iframes to
| render HTML email? Do they still present security risks?
| red_trumpet wrote:
| The extra HTML does not happen from the client reading the
| forwarded email, but when forwarding. That is expected, because
| the forwarding party might want to add more text to the email.
| echoangle wrote:
| At least the person forwarding the mail could check the
| preview and see that the text changed.
| raptor99 wrote:
| Did you see the GMail section at the bottom of the article?
| echoangle wrote:
| No, I started skimming before that point, thanks for
| pointing that out. I guess you have to check your sent
| mails now after sending one, until this is fixed
| echoangle wrote:
| Wouldn't this be fixable by not allowing Stylesheets but only
| inline style attributes on the tags? To improve usability, email
| clients could include an automatic step where all Stylesheets are
| "compiled" to inline styles. The only thing this would break
| would be advanced CSS selectors (hover etc.) but I'm not sure
| they would be needed.
| chromanoid wrote:
| I agree. Just baking all classes into inline styles before even
| presenting the mail should fix this. It makes sense to do this
| anyway. Pseudo classes and media queries wouldn't work, but
| those would pose a security risk anyway and are not supported
| by major mail clients (see
| https://www.caniemail.com/features/css-at-media/)
| ketch wrote:
| This would also break the current approach for responsive
| emails.
|
| Usually the default/desktop styles are already compiled and
| inlined, then a style tag with media query selectors is used in
| the `head` to improve readability for mobile devices.
| yosefk wrote:
| The horror! Is there a real need here though as opposed to
| just something people do, and where does such CSS come from
| in the case of emails? You could be "responsive" by not doing
| certain things instead of actively doing something and for
| email content it feels fitting.
| afavour wrote:
| You're asking if email CSS ever needs to be tailored to
| mobile devices? It's not any different than web pages
| needing to be tailored to mobile devices. The answer is
| yes, sometimes it is necessary.
| yosefk wrote:
| The answer is different because an email is not a
| standalone webpage and there are a lot of things you
| might want to do in a website that you won't expect to be
| able or need to do in an email. You probably don't want
| to control font sizes or page margins in an email, for
| instance; you probably do want to control color or
| override some overflow defaults. Maybe I'm off in the
| above but the point is that you expect to control a
| subset of things for an email (same as eg for RSS
| entries) and media selectors aren't obviously necessary
| for these kinds of things.
| afavour wrote:
| What if you want to place two divs alongside each other
| on desktop but stacked vertically on a phone?
| bitvoid wrote:
| How about not placing two divs alongside each other in
| the first place? Every time I see that, I immediately
| start looking for the unsubscribe link or mark it as
| spam.
| afavour wrote:
| Your preference is not everyone's preference. It's silly
| to suggest every email client disable media queries
| because you dislike seeing two elements side by side.
| bitvoid wrote:
| That's true, but is anyone going to be up in arms because
| things are _not_ side by side in an email?
|
| I agree with others that emails should just be plain
| text. It has never bothered me or anyone else I've known
| to just have plain text and a link that sends them to an
| actual webpage if HTML is absolutely necessary.
| pembrook wrote:
| HTML emails have to inline CSS already due to Outlook & Gmail
| using decades-outdated rendering engines (outlook literally
| uses the 2006-era MS Word html engine).
|
| Also, killing all style attributes would also kill mobile
| optimization and dark mode as well, since you cannot inline
| media queries.
| quesera wrote:
| This is really clever!
|
| Premise: CSS in HTML email allows some text to be visible only
| after the message is forwarded. This is a huge threat to the
| trustworthiness of verified email! Examples given in Thunderbird,
| Outlook, Gmail. Excellent work.
|
| I read all mail in mutt, so this is officially "someone else's
| problem".
|
| ...
|
| Consequently, I'll complain about something else:
|
| > _This issue was reported to Mozilla on 05.03.2024. The planned
| release date and a draft of the following section were
| communicated to Mozilla on 20.03.2024._
|
| I agree that little-endian dates make more sense than US-style
| middle-endian dates.
|
| But I will assert that any technologist who does not use ISO 8601
| date formatting (2024-03-05, with or without hyphens), is _doing
| it wrong_. :)
| shrimp_emoji wrote:
| Not only that, but any _person_ using middle-endian date format
| is doing it wrong. It 's the least rational way to write
| something! Little-endian at least has the virtue of just being
| backwards relative to how you write every other number, but
| middle-endian is just bonkers. (So of course it's the way
| Americans do it.)
| _blk wrote:
| I thought so too for most of my life but living in the states
| has changed my perspective since the practice is coherent
| with spoken language. Now I mostly write out the month to
| make it clear. Let me just appeal to all Americans to use
| slashes as separators and not dots.
|
| Side note: Military format 12MAR24 seems both concise and
| unbiguous but most people understandably find that unusual
| (just like ISO dates)
| adrianN wrote:
| Is that March 24th, 1912?
| quesera wrote:
| For many years, I used "12 Mar 2024" in written form.
|
| But the convenience of ISO 8601 for electronic form is
| compelling, and it has slipped into my writing as well.
| someplaceguy wrote:
| The military format is ambiguous. For example, 12MAY24
| means 2024-05-12 in English but it means 2024-03-12 in Manx
| Gaelic [1].
|
| Also, tell me: what date is 10SKA11? Or 01DU02?
|
| Furthermore, a lexicographic sort will do the wrong thing.
|
| Better stick with ISO 8601.
|
| [1] https://gv.m.wikipedia.org/wiki/Mayrnt
| shrimp_emoji wrote:
| Yep. Numbers > names, always. I'll go even further:
| months shouldn't even _have_ names (which no longer even
| make sense, like October)! Neither should the days of the
| week, like the Chinese do it.
| wongarsu wrote:
| 12MAR24 is so close. If they just went with 12MAR2024 it
| would have been unambiguous.
|
| Of course it lacks many advantages of ISO8601 like sorting
| correctly in alphabetical sorting or working across
| languages, but it's a huge step up from 3/12/24.
| quesera wrote:
| Americans use "March 5th" as the verbal form of dates when
| the context (year) is clear. This actually makes sense -- it
| puts the most significant part first, and narrows from there.
| The numeric representation follows that form, becoming "3/5".
|
| But of course for full context, Americans say "March 5th,
| 2024", yielding "3/5/24" or similar atrocities.
|
| I'm a big fan of ISO 8601. They got this one right. It's
| clear, non-preferential, and (critically) it sorts lexically
| with expected results!
| wongarsu wrote:
| But if Americans follow the reasoning to put the most
| important information first, then why do they say "March
| 5th, 2024"? With that reasoning shouldn't it be "2024 March
| 5th"?
|
| For spoken communication you could even extend it to "Anno
| Domini 2024 March 5th", following the common pattern in
| spoken language of adding somewhat redundant filler to
| indicate something worth paying attention to is coming up.
| quesera wrote:
| > _Anno Domini 2024 March 5th_
|
| Gregorian Anno Domini 2024 March 5th. :)
| sfink wrote:
| > But if Americans follow the reasoning to put the most
| important information first, then why do they say "March
| 5th, 2024"? With that reasoning shouldn't it be "2024
| March 5th"?
|
| Because you're falsely equating "important" and
| "significant". It's not about little endian vs big
| endian, which is all about magnitudes. Most of the time,
| the year is implicit (i.e., this year, or perhaps next
| year but that will be inferred from the month). Rolling
| over months happens quite often, rolling over years is
| rare. And in cases where the month really doesn't matter,
| it'll be dropped: "see you on the 5th!"
|
| That said, I personally dislike both MM-DD-YYYY and DD-
| MM-YYYY. Mon DD, YYYY is fine. YYYY-MM-DD (ISO8601) is
| fine (and to be preferred when naming files or in any
| other context where you'll be seeing lots of dates at
| once).
| afavour wrote:
| The real risk to your organisation is that the developer you
| assign to generate HTML emails will go mad, lock themselves in
| the server room and destroy all the hardware while screaming "why
| is Outlook rendering DIFFERENT"
|
| (Seriously though, this is a fascinating exploit)
| lobsterthief wrote:
| This is why I decided years ago to just pay an HTML email
| coding service for anything email-related. There's a lot of
| bespoke knowledge required for coding HTML templates that pass
| litmus tests and I never want to go there again.
| ognarb wrote:
| I long argued that we should use markdown (without the inline
| HTML) or a similar simple text markup instead of HTML for rich
| text in emails. This would makes it easy for emails clients to
| decide about either showing the text as rich text or just plain
| text, while supporting most of the formatting that a normal user
| might need: bold, italic, quotes, inline images, code blocks,
| headers, ...
|
| Sure it wouldn't be good for marketing emails with the super
| advanced HTML but I don't think anyone should care about this
| use-case.
| PaulDavisThe1st wrote:
| Given that the Lynx browser (HTML in a text terminal) continues
| to function reasonably well, why is there any need for a
| different markup language?
| layer8 wrote:
| It helps for keeping the feature set limited. With HTML, the
| incentive to use a full-blown implementation is just too
| strong, and the risk of inconsistent implementations and
| deliberate or accidental extensions too high.
| lobsterthief wrote:
| You could also in theory just restrict which HTML elements
| can be used. You'd need to do that anyway for MD,
| especially since MD can contain HTML itself.
|
| I'm a huge fan of MD either way ;) I've built entire large
| sites where raw content is stored in MD (along with a MD
| WYSIWYG) and then the MD is converted to HTML. I've found
| it's easier and more reliable to parse MD vs HTML, unless
| of course you're using a block editor or something more
| structured.
| layer8 wrote:
| > You could also in theory just restrict which HTML
| elements can be used.
|
| That's not enough, because you also have to restrict what
| attributes they may carry (inline styles, event
| handlers), the type of meta tags and image formats, and
| so on.
|
| But in any case, such a restricted subset was what I was
| already presuming in my comment.
| PaulDavisThe1st wrote:
| You don't have to restrict them at all.
|
| You just ignore them.
| layer8 wrote:
| That's what is meant by restricting.
| layer8 wrote:
| Something similar exists as _text_ / _enriched_ defined in RFC
| 1896. Apple Mail, among others, supports it.
|
| https://en.wikipedia.org/wiki/Enriched_text
|
| https://www.rfc-editor.org/rfc/rfc1896.html
| diggan wrote:
| > https://en.wikipedia.org/wiki/Enriched_text
|
| Ironically references an article called "Why HTML is
| Inappropriate for E-Mail"
| (http://www.avernus.com/~gadams/essays/20020418-html-
| mail.htm...) posted way back in 2002 apparently.
|
| We're just walking around in circles after all...
| layer8 wrote:
| This goes back to 1998 at the very least:
| https://en.wikipedia.org/wiki/ASCII_ribbon_campaign
|
| It was clear from the start that using HTML in email was a
| bad idea.
| zokier wrote:
| This sort of dogmatic rejection of HTML ended up being
| the bigger problem. If instead futilely fighting against
| HTML email the community would have just embraced the
| idea, we could have a sensible spec for email (instead of
| just ad-hoc whatever Outlook does) and email could have
| had a chance to prevent its fading relevancy.
|
| But no, we had to fight the great evil of rich text which
| left vendors, MS in the forefront, to their own means to
| fulfill the strong and justified user demand, with
| predictable outcome.
| layer8 wrote:
| RFC 1896 defined a sensible alternative in 1996. I agree
| that it should have received more support, although at
| least a range of Unix MUAs and Apple Mail did and do
| support it.
| lupire wrote:
| Color and Size are basic, useful aspects of writing.
| hinkley wrote:
| Many markdown parsers allow inline html. In some languages,
| it's most of them. Only a few let you turn it off. So stupid.
| zokier wrote:
| For better or worse, inline HTML was key part of original
| markdown spec:
|
| > For any markup that is not covered by Markdown's syntax,
| you simply use HTML itself. There's no need to preface it or
| delimit it to indicate that you're switching from Markdown to
| HTML; you just use the tags.
|
| > If you want, you can even use HTML tags instead of Markdown
| formatting; e.g. if you'd prefer to use HTML <a> or <img>
| tags instead of Markdown's link or image syntax, go right
| ahead.
|
| Markdown was not really intended as standalone markup format,
| instead it was more just a tool for authoring HTML
|
| > Markdown's syntax is intended for one purpose: to be used
| as a format for writing for the web.
| cdcarter wrote:
| Well, the markdown specification allows inline HTML, so
| that's to be expected. But it's true if you're taking user
| input as markdown and display it as rendered HTML, you need
| to think very carefully about escaping and sanitization.
| SilasX wrote:
| Well, getting enough uptake is difficult because email
| standards are hard to change. We still don't have support for
| hyperlinking emails, though I tried to fix that recently:
|
| https://pastebin.com/kHQs50xm
| jcranmer wrote:
| The mid: scheme (see
| https://datatracker.ietf.org/doc/html/rfc2111) can
| theoretically do that and has been around since, uh, 1997.
| SilasX wrote:
| Yep, and even with it being possible, no one's bothered to
| make it usable for email hyperlinks, hence the problem. The
| (attempt at an) RFC I linked avoids depending on the other
| side tracking the MessageID, assuming only things they
| would want to store.
| velcrovan wrote:
| "Why emails are a risk to your organization" there fixed it for
| you
| wongarsu wrote:
| At that point it's just "why communication with the outside is
| a risk to your organization".
|
| This article presents an attack vector unique to HTML emails,
| but most attacks over email can be easily adapted to work over
| WhatsApp, Slack, Jira, Zoom, or whatever else people use to
| communicate with the outside world.
| RedShift1 wrote:
| Where does the term "kobold letters" come from?
| JLCarveth wrote:
| From the article "I'll refer to these elements as kobold
| letters, after the elusive sprites of mythology."
| mschuster91 wrote:
| > To prevent the CSS of emails to affect the style of the
| webmailer, Outlook modifies the email by prefixing all ids and
| classes with x_ and adjust the CSS accordingly.
|
| Wait what, OWA _loads emails directly into the same DOM tree as
| the rest of the app_ instead of an iFrame?
| jgrahamc wrote:
| See also: The Spammers' Compendium:
| https://www.virusbulletin.com/resources/spammerscompendium/
| nickburns wrote:
| If we style the kobold letter as an overlay, we can not only
| affect the forwarded email, but also (for example) replace any
| comments your manager might have had on the original mail,
| opening up even more opportunities for phishing.
|
| clever doesn't even begin to adequately describe.
|
| tangentially and anecdotally, it's only occurred to me fairly
| recently, like within the past year or so, to configure all my
| mail clients, including both desktop and mobile Outlook ( _and_
| OWA), to _not_ 'automatically download new messages'. this really
| needs be the default setting.
| sylware wrote:
| Don't let me start on phishing SMS texts... still around and
| strong. My phone will fireup a non-big-tech noscript/basic
| (x)html browser if I mistakenly click on an URL in it _AND_ my
| phone does not run android (or an other linux based phone OS) nor
| iOS.
| cozzyd wrote:
| Some possible mitigations from the top of my head (maybe
| ineffective):
|
| - warn prominently on hidden elements
|
| - randomize the number of enclosing div, on both incoming and
| outgoing
|
| - compute what the forwarded message would look like on
| forwarding, ask for confirmation if differs significantly. Or do
| the opposite (probably more effective since doesn't require other
| clients to help)
| SoftTalker wrote:
| Clever trick. It reinforces the position I've held since the
| 1990s. Emails should be text. HTML is for web pages.
| tombert wrote:
| I've been using exclusively plain-text email for a long time,
| and it's not even for security; I want to be able to respect
| people's font choice.
|
| When you send HTML emails, the font is chosen by the sender,
| which normally is fine, but some people prefer to use dyslexic-
| friendly fonts (e.g. OpenDyslexic or Comic Sans) to read their
| email, and I don't want my message to be artificially more
| difficult to read.
|
| Since most emails really don't need elaborate formatting, I'm
| not 100% sure why this isn't the default.
| radarsat1 wrote:
| The other day I was discussing the design for an "update" email
| that our designer was putting together and showing me the size of
| this stupid graphical header he put at the top and I was showing
| him how with that you can't even see the text of the title of the
| email without scrolling down, and then he forwards some other
| version to me for more feedback and suddenly started getting all
| disturbed and upset because something looked different to him..
| like the fonts were a bit smaller.. and then he said, oh no, when
| you forward it, it transforms it to the desktop version, instead
| of the mobile version! And I'm sitting there in disbelief, just
| staring at him, like,... this is EMAIL we're talking about, what
| do you _mean_ "desktop" version and "mobile" version? How is that
| even a thing? What do you _mean_ it "transforms" it? It's
| literally just copying it! The fact that it "breaks" when you do
| that is evidence of how _stupid_ this is. My god man, why is CSS
| in my email _at all_?
|
| The fact that we haven't adopted something much simpler to just
| be able to express italics or whatever, like markdown, is just
| bonkers to me. It just shows how little anyone cares about
| actually improving the situation. And all just to cater to the
| bizarre corporate need to put logos and banners everything. HTML
| email is just ridiculous.
| JacobThreeThree wrote:
| Responsive email frameworks are a thing, like MJML.
| jcranmer wrote:
| > The fact that we haven't adopted something much simpler just
| to be able to express italics or whatever, like markdown, is
| just bonkers to me.
|
| Sounds like you want text/enriched [1], which was published in
| (checks notes) 1996 and has read support in likely every email
| client ever.
|
| [1] https://www.rfc-editor.org/rfc/rfc1896.txt
| shortformblog wrote:
| A classic cut off the limb to fix the cut solution. The problem
| is bad standardization for email that has allowed hacks like this
| to rule the day.
|
| HTML in general is susceptible to these very concerns. Plenty of
| emails exist that use HTML without incident. This reads as one
| user's frustration with something in the wild that is dressed as
| a security issue.
| hannob wrote:
| When efail came out, I wrote a blogpost about the security risks
| of HTML mail.
|
| It is really amazing how problematic all of this is, despite its
| widespread use. The HTML mail spec is really old, and contains
| almost no security considerations.
|
| HTML in emails can only be a subset of HTML to be secure. But
| nobody has ever defined what exactly that subset is, so everyone
| does whatever they think. And unsurprisingly, this leads to an
| endless stream of security flaws.
|
| See: https://blog.hboeck.de/archives/894-Efail-HTML-Mails-have-
| no...
| tonymet wrote:
| this highlights a broader issue of irreproducible content.
|
| Another good example are group chats where some recipients see
| messages inconsistently or in a different order than others. It
| can happen due to inconsistent delivery, inconsistent ACLs, or
| other reasons.
|
| How can people agree on things when they are not looking at the
| same thing? And people assume that everyone sees what they see by
| default.
|
| Can a board make a decision when not everyone has the same
| presentation of facts?
|
| Remember when you judged someone for asking a stupid question
| when the answer was just posted a moment ago? How do you know
| they even received it?
| ledgerdev wrote:
| Between these sorts of email tricks and ability to easily voice
| clone using ai, it would seem that invoicing systems should put
| some sort of 2 factor approval/confirmation into the workflow for
| payouts.
| rglover wrote:
| HTML in email shouldn't be as big of a nightmare as it is. It
| really comes down to rendering engines. If all email clients just
| checked for text vs HTML and when HTML switched the rendering
| engine to Webkit, this problem could be solved overnight.
|
| There's zero reason why you can't render an email the same way
| you can as a regular page (minus JavaScript).
|
| Out of curiosity, is anybody working on this? It seems like a
| standard could be produced w/ relative ease to make it easier on
| vendors. Imagine somebody has at least proposed the idea
| before...
| upofadown wrote:
| >...it may even be cryptographically signed ...
|
| In general, anything you are going to sign has to be in a simple
| enough format to make it so that the sender and the receiver(s)
| can actually determine what is signed. HTML should automatically
| be considered unsigned. It simply is not suitable for the
| purpose.
___________________________________________________________________
(page generated 2024-04-04 23:01 UTC)