Caleb G's blog

In this short screencast a variety of security holes are shown, as well as some malicious things which are made possible due to these lapses. We'll take a walk-through of two security issues showcased in the vulnerable.module, as well as two other exploits which I put together:

• User account hijacking via cookie/session XSS thievery
• User account hijacking via password-changing-inline-XSS

During a recent browser upgrade I found myself stuck in a bit of a corner. The Firefox add-on I had been using, Xdebug Helper, was discontinued, and the supposed replacement add-on for it didn't work correctly.

Since the functionality of this now-defunct add-on made my life a lot easier (e.g., don't have to manually append/strip '?XDEBUG_SESSION_START=default' in my browser all day long to start/stop debugging sessions) I took it upon myself to keep this functionality and perhaps get rid of yet-one-more-add-on (which pays off when upgrade time comes).

In all their simplicity, here are two bookmarklets you can use to start and stop a Xdebug session in your browser of choice. Note that if you are using a custom proxy key value then you'll need to change the '=default' part in the bookmarklet to '=YourProxyKey'.

UPDATE: I've updated some of the numbers below to reflect corrections for a testing error. Let's just say to be sure not to benchmark with any external links in your test pages (because if you do use external links you'll obviously be benchmarking the external server too, which is not what we want in this case). To summarize the effect of these corrections - having lighttpd in front of Apache and pipelining actually provide a substantially larger boost in performance than I had indicated before. Other than that the results are the same.

So things with my first attempt at benchmarking HTTP pipelining did not go exactly as planned. It turns out that if two different domains/subdomains you are using for content on your site are pointing to the same IP, based on previous testing, it looks like browsers (at least FireFox) will not pipeline requests (e.g., create more concurrent requests to your site) because it considers the requests as being from the same origin. In order for a browser to pipelining requests at all, they seem to require two domains/subdomains which are using two separate/unique IPs. If you read the Wikipedia entry for hostnames this all makes sense, as it indicates domains are associated with IP's, and browserscope's testing of browsers checks for "Connections per Hostname", not "Connections per Domain".

After figuring out how to get requests to pipeline correctly, I re-benchmarked all the configurations from the first article . Everything from that article regarding lighttpd is still holds true, so without covering those aspects again, here's the updated benchmarks and notes for browser request pipelining:

I finally had a chance to investigate an optimization which I've been wondering about for a while now - serving static files of a site from somewhere else. As a side, but related, experiment I also tested the claim that serving files from a static file server/separate domain/subdomain will speed things up because it results in browsers opening more concurrent requests than they would from a single domain.

For my tests I used lighttpd (pron. lighty) as a static file server for Apache. The idea is that lighttpd, which is acclaimed as being fast and light on memory, will serve the non-dynamic pages of the site (images, CSS, Javascript, etc), which should thereby help relieve Apache of some of its workload. This arrangement involves changing the paths, either on the backend or frontend, to these static resources so that they no longer get served by Apache.