Web Front‑End Security: External Link Restrictions, Rich‑Text XSS, Opener Phishing, and Clickjacking Mitigations

Prohibit All External Link Resources

External links generate off‑site requests and can be exploited to carry out CSRF attacks.

Many domestic routers suffer from CSRF vulnerabilities, and a large number of users still use the default admin credentials. By embedding an external image, an attacker can modify the router’s DNS configuration, creating a massive security risk for the Chinese Internet.

Case Demonstration

When Baidu Travel filtered rich‑text content, it failed to consider the style attribute of tags, allowing users to inject custom CSS and thus embed off‑site resources.

All users who view the page can trigger arbitrary URL requests.

Because the external server is uncontrolled, the attacker can return any content:

If the request originates from an administrator or an external‑link‑checking server, a normal image is returned.

If the request comes from a regular user, a 302 redirect to a malicious URL can be issued, e.g., to modify a router’s DNS settings.

http://admin:[email protected]/userRpm/PPPoECfgAdvRpm.htm?wan=0&lcpMru=1480&ServiceName=&AcName=&EchoReq=0&manual=2&dnsserver=黑客服务器&dnsserver2=4.4.4.4&downBandwidth=0&upBandwidth=0&Save=%B1%A3+%B4%E6&Advanced=Advanced

During testing, the image was requested over 500 times within two days, and nearly ten distinct IPs began issuing DNS queries to us.

Through a man‑in‑the‑middle proxy, all user privacy can be captured, leading to more severe consequences such as traffic hijacking.

Prevention Measures

Eliminate all user‑provided external link resources. If external images are needed, download them and serve them from the internal server.

Apply a whitelist strategy for rich‑text, allowing only specific CSS properties.

Enable Content Security Policy (CSP) to let the browser block off‑site resources automatically.

Rich‑Text Front‑End Scanning

Rich‑text is a major source of XSS vulnerabilities because it ultimately renders as HTML, which historically tolerates many non‑standard usages.

Case Demonstration

In a travel forum that supports rich‑text, after previous fixes only embed tags and src attributes remain injectable.

Nevertheless, an attacker can embed an iframe that loads a malicious page.

Although the iframe runs in a different origin and cannot read the main page, it can change top.location to redirect the user to a phishing site.

By embedding the original page in a full‑screen iframe and overlaying a fake login dialog, the attacker can harvest credentials.

Prevention Measures

This section focuses on front‑end defenses, assuming back‑end filtering may be bypassed.

After constructing the DOM but before rendering, scan off‑screen elements for risky tags such as script , iframe , frame , object , embed , and applet , and remove them or sandbox them.

For example, add the sandbox attribute to iframe to display content without executing scripts.

For Flash, use allowScriptAccess and allowNetworking to limit interaction.

The DOM is inert until it is attached to the main document; therefore, a scanning step before attachment can block malicious execution.

Implementation details can be found at http://www.etherdream.com/FunnyScript/richtextsaferender.html . For static pages, consider using MutationEvent as described at http://fex.baidu.com/blog/2014/06/xss-frontend-firewall-2/ . Dynamic rendering is recommended for better extensibility and lower performance overhead.

Opener Phishing via Window Opener

The browser’s opener property allows a newly opened window to access its source page, which can be abused when hyperlinks open in a new window.

An attacker can lure a user to click a link, causing the original page to be silently redirected by the malicious third‑party page, even though same‑origin policy prevents content reading.

Case Demonstration

Baike’s hyperlinks open in a new window, exposing the same vulnerability.

Attackers post enticing content with images or static GIFs that appear harmless; the actual resource may be an HTML page that executes a hidden script to redirect the original page.

When the user returns to the original tab, they are on a phishing site, potentially exposing login credentials.

Prevention Measures

Block the opener reference for windows opened via hyperlinks. Instead of allowing the default behavior, intercept click events on user‑generated links, open them with window.open , and set the returned window’s opener to null .

Reference implementation: http://www.etherdream.com/FunnyScript/opener_protect.html .

User‑Generated Content Permissions

Custom decorations are a high‑risk area for phishing because attackers can mimic system interfaces.

Case Demonstration – Layout Overflow

Baike’s rich‑text editor does not whitelist the class attribute, allowing users to apply any CSS class from the host page, potentially breaking the layout.

Prevention Measures

Enforce size limits on user content, embed it within an iframe , or hide overflow to prevent layout overflow attacks.

Case Demonstration – Functional Overflow

Custom decorations often allow external hyperlinks on elements such as images, making them highly deceptive and capable of triggering opener phishing.

Prevention Measures

Scan user‑provided hyperlinks on click; for external URLs, route them through a backend redirect that performs security checks. Warn users if the target is identified as malicious or an executable file.

Clickjacking Detection

Clickjacking tricks users into clicking hidden or transparent elements embedded in an iframe, causing unintended actions such as following a user.

Case Demonstration

Attackers calculate the size and position of a target button, embed the victim page in a hidden iframe, offset it so only the button is visible, enlarge the button to cover the entire page, and make it fully transparent.

Any click on the page triggers the hidden button’s action.

Prevention Measures

Detect if the page is framed by checking self === top . For critical actions (e.g., follow, delete), verify the page is not embedded; if it is, display a confirmation dialog with random offset to invalidate the attacker’s click area.