KasparEtter
commented
1 day ago Hi, thanks a lot for your feedback! What I meant by the second sentence (among other things) is that you can phish "only" for a user's email credentials if the user logs in to their mail service via a website (by directing them to a malicious website instead). (A native app could also emulate the interface of your dedicated mail client and prompt for a re-entry of your password, of course, but if you have full access to a user's computer, there are many other things you could do as well or instead.) Web services try to prevent XSS and XSRF, of course, but those are issues you don't have to think about when you build a native app (and properly disable JavaScript for user/dynamically loaded content). Regarding your example, I see two ways to improve my statement:
- … because the browser runs untrusted code by design, which a dedicated mail client doesn't,
- … because the browser runs untrusted code, which a dedicated mail client doesn't or at least shouldn't.
I think/hope I don't need to say that any software can have bugs with security implications.
Do you see what I mean? (My statement is more about web apps versus native apps in general, somewhat independent from email.)
On https://github.com/KasparEtter/ef1p/blob/main/pages/email/email.md
When you say
Webmail has the advantage that you always run the newest version of the code, which is sandboxed from the rest of your system by the web browser. On the downside, attacks like phishing, cross-site scripting, and cross-site request forgery are only possible because the browser runs untrusted code, which a dedicated mail client doesn't, I think this is not true: many dedicated mail clients run embedded web browsers (webviews) for email visualization, enabling the run of untrusted code (javascript) in an email, same as webmails. These attacks also affect dedicated mail clients, for example: https://security.snyk.io/vuln/SNYK-RHEL6-THUNDERBIRD-7841995 .