My bank used to send statements via email as .PDF, but now sometimes switch to .HTM(L) file attachments instead. Here's why that's an elevation of risk...
Both HTML and .PDF files can contain auto-running JavaScript, elevating the risk from "reading a document" to "running a program". But whereas one can (and should) disable JavaScript in Acrobat Reader, it's impractical to do that for the web browsers that typically "open" HTML files.
Microsoft's Chromium-based Edge does not run JavaScript in .pdf files, at least as at August 2022, so these files are still safer than HTML even if "opened" in Edge.
Inspecting the bank's HTML "statement" in Notepad shows JavaScript followed by an encrypted mass of content, which could be (and do) anything. Here's the start of a "real" bank statement "document"...
-script type="text/javascript"-
document.write(decodeURIComponent(atob('JTNDaHRtb...
...munged to invalidate HTML syntax for safety; here's a suspected malware sample...
-script type="text/javascript"-
document.write(decodeURIComponent(atob('JUVGJUJCJUJGJT...
...can you tell the difference? Why should I have to trust embedded code to "read a statement"?
Automated messages containing attachments and/or links are always hi-risk, as it's so easy to forge what the recipient sees as "message text" - and already I see fake "email statements" from "my bank", given the message dates don't correlate with statements as seen via the bank's web site.
So, let's hope the bank re-thinks this strategy, rather than reprise "Banking On Java"
The HTML problem
Using HTML everywhere as "rich text" for "documents" started with the "everything is a web page" mania of Windows 98, where HTML Application files (.hta) abounded, and HTML Templates (Folder.htt) were dropped into file system directories and namespace folders to create a "web" look. This was when Internet Explorer was meshed deeply into Windows, to support Microsoft's claims it was not a separate bundled program competing unfairly with Netscape. HTML also became the new .chm Help at this time.
Using HTML as rich text for "documents" creates a wide safety gap between the low skills needed to use a system, and the higher skills needed to use it safely. The seeds of this lie in the Object Oriented Programming concept, where "documents" are "objects", and all objects can have Methods (code) and Properties (variables). Normal programming practice is to interface with such objects by asking their methods to expose their internals - and so "reading a document" becomes "run code".
JavaScript
How risky is JavaScript - doesn't it just work safely within a single document or page? Well, it's powerful enough to be the sole code for Progressive Web Apps, that are expected to become ubiquitous as the "desktop" programs we use today - and malware use is already rife.
No comments:
Post a Comment