I am just writing a few slides about IPv6 for our expanded defending web application class. For about 2 years now, the SANS Internet Storm Center is reachable via IPv6. Here are a couple ideas to consider as you move your web application to IPv6:
Configuring the server
This is the easy part. Apache/IIS or whatever server you are using is most likely already IPv6 ready. All it takes is enabling it in your configuration. Maybe you got it already turned on without using it ;-).
IPv6 will allow you to “track” a user using the last 64 bits of the IP address. However, be careful. First of all, the IP could be spoofed just as likely as an IPv4 address. Secondly, there are two schemes to derive the last 64 bits of the IP address: (a) EUI64, which means derive it from the systems MAC address, or (b) privacy enhanced, which will change the IP address on each reboot. Either way, it is possible to use the last 64 bits to backup session cookies. Similar how you would use an IPv4 address. In IPv4, developers frequently use only the first 2 bytes to deal with load balancers. We will have to see how this works out in IPv6. If a load balancer implements a proxy, the IP address will still change.
This part will likely be tricky. You will now have longer (IPv6) addresses. If you for example setup a database table, you may have assumed that IP addresses are never longer then 15 characters, or can be represented as a long integer. Neither is true for IPv6. Also, IPv6 addresses add a bit more flexibility to how they may be presented. For example, leading 0’s may be omitted.
An additional complication arrives from hosts that may issue some requests via IPv4 and some via IPv6. While I haven’t seen this happening yet in normal IPv6 traffic, it may happen as part of an attack.
Of course, an IPv6 address will not pass input validation for an IP address (unless your regular expression / test is wrong). I prefer three distinct validation functions:
- one to validated if a string is an “IP address” (IPv6 or IPv4)
- one to validate that it is an IPv4 address
- and lastly, one to validate that the string is IPv6.
If you write new code, be ready for IPv6 and make sure you allow for it. A configuration option may be useful to enable / disable IPv6 support for your application.
Assume that your IDS/IPS is blind when it comes to IPv6. Proxies (web application firewalls) shouldn’t care, and will probably still work fine. But test test test… they will probably still not detect any IPv6 specific attacks.
If you want to do something now: Make sure that you confirm if your current web server supports IPv6 or not. Modern operating systems tend to establish IPv6 tunnels over IPv4 automatically. Make sure they are disabled until your application is ready for IPv6. Communicate clearly with your networking team to avoid accidental IPv6 exposure of your application. Finally: Get an IPv6 test environment running to get your feet wet.