Member Avatar for happygeek
happygeek 2,411 Most Valuable Poster

More bad news from the Las Vegas Black Hat Convention, this time for the blogging community. Most RSS reader software is vulnerable to malicious JavaScript insertion attacks, and web based readers are not immune either. With typical JavaScript based attacks targeting passwords and personal data, it is something that should be taken seriously, Yet when I did a quick pop quiz amongst family and friends, not a single one (those in the IT security business apart) was aware that such software was a potential risk.

The fact that this kind of attack can be easily launched from even a trusted site, by way of blog commenting with rogue code included, makes it all the more dangerous. It is not something restricted to rogue bloggers by any means.

Although it is easy to lay the blame at RSS reader software developers for not building in better security checks from day one, the real problem runs deeper than that. The root of the problem is, it has to be said, not RSS software at all but rather the lack of understanding of IT security at its most basic of levels, and an apparent inability for the average user to realize the very real risk to their very real personal data by not getting it.
If you can, then disable script and applets from in-feed launching.

Combining this with general safe computing practice, including running a firewall and anti-malware scanners, represents the best defense.

  • 1 Contributor
  • 0 Replies
  • 176 Views

Dani AI

Generated

As observed, feeds can carry HTML and embedded resources; when a reader renders that content without treating it as untrusted, classic web attack vectors become possible (script tags, inline event handlers, javascript: URIs, iframes and remote-resource tracking). The risk profile depends on the reader’s rendering strategy: some show only titles, others display raw HTML in an embedded WebView. That variability is the core problem — assume every feed is untrusted and act accordingly.

Quick hardening checklist:

  • Prefer “titles only” or “show excerpts” modes to avoid rendering feed HTML.
  • Disable automatic loading of remote content (images/iframes) in the feed viewer.
  • Use readers that explicitly sanitize feed HTML; if uncertain, treat the client as not sanitizing.
  • Keep feed-reading confined to a sandbox: separate browser profile, dedicated user account, or a VM/container with no saved credentials or autofill.
  • For web-based readers, avoid using a profile that is signed into sensitive sites; session cookies should not be shared with the reader.
  • When self-hosting an aggregator, perform server-side sanitization (strip <script>, on* handlers, javascript: URIs), and render previews with strict Content Security Policy or a sandboxed frame.

Advice for site operators and bloggers: never assume consumers will sanitize output. Escape or strip HTML from user-generated content before it becomes part of a feed, require moderation for comment-rich feeds, and avoid embedding third-party widgets or raw HTML into feed fields.

A practical verification step is to publish a private test feed with a harmless benign script snippet and observe whether the reader executes it; execution indicates the client treats feed content as active. If that is the case, either change reader settings, move to a reader with documented sanitization, or place a sanitizing proxy between feeds and the client. These measures reduce exposure without depending solely on perimeter tools like antivirus or firewalls.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.