Another way for IPv6 to blow up an IPv4 website
I found another interesting avenue for affecting a web application recently when Heather was trying to renew one of her magazine subscriptions. She mentioned that the site was getting a '500 Server Error' and I recognised the e-mail address it was suggesting, so I banged an e-mail off to advise the problem.
Curiously, they weren't able to duplicate the issue while I was still seeing the problem. I did a little fooling around and discovered that I only saw the error when I was making the request through my proxy server.
A little more digging and I ascertained that if I connected to the proxy normally via IPv6 I got the '500 Server Error', but if I instead connected to the proxy via IPv4 it all worked just fine.
Communicating this back to the site developer, it turns out the site had some blacklist checking in it which was checking not just my source IP (the site was only hosted on IPv4) but also checking the 'Via' header for my IP, which was coming through as an IPv6 address and causing the software to throw it's hands in the air at that point.
So chalk up another interesting way in which an IPv6 address on the somewhat remote client can be passed through as input to a web application running on IPv4. I believe I've heard talk of ISPs considering running native IPv6 internally and proxying requests out to IPv4 in exactly this manner, so the sooner web developers realise that addresses could come in more than one shape, the better.
And yet another reason to validate your data: just because you received a 'Via' header in the request does not mean there was ever a proxy involved in the request - it is untrusted data, people: like every other piece of data you receive down the wire from the client at the far end.