Dangers of CSRF and XSS
Monday 27 July 2009 1:59:13 am
It is imperative to validate all input, no matter the source. A common mistake is to filter only the data coming through GET, POST and cookies, while forgetting to validate data received from the web server environment variables from the $_SERVER super-global. While the data found within it is provided by the web server, it is often based on user-supplied content, making it just as dangerous as data coming directly from the user. These values are the ones that are often found in control panels when an error occurs, which makes them particularly dangerous; the user subjected to the modified content will then often have elevated access privileges (as administrator).
One such attack can involve the HTTP_HOST value, which holds the domain name that is currently being accessed. Many think of it as a safe value; after all, how can the attacker change the domain? The value of this header is actually based on the Host: header supplied by the user making the request. If the site being accessed is running on a dedicated IP address or is the primary (first) site on virtual IP, a request with a bogus value for this header will still work on an Apache web server. A request for a page on such a site can be forged, allowing arbitrary data to be injected into HTTP_HOST:
GET / HTTP/1.0 Host: <script>...
The result is that $_SERVER['HTTP_HOST'] now equals "<script>..." or potentially a far more dangerous payload. The same logic can be applied to other headers like Via (HTTP_VIA) and X-Forwarded-For (HTTP_X_FORWARDED_FOR), which are normally used by proxies to indicate the address of the user behind the proxy. Perhaps the only truly safe field is REMOTE_ADDR, the user's IP address. This is resolved by the web server and will always contain a valid IP. All other fields should be meticulously validated prior to usage.