1

Common website save your ip address while your are connecting to display it on a security section view-able by the user or an admin.

I thought servers like Apache, Nginx ... extracted the ip address from the IP packet (REMOTE_ADDR)and passed it to the CGI program.

However, I recently read an article that claim to achieved self-XSS due to no proper sanitization of ip address. The guy used True-Client-IP to inject his payload but I also found some others headers like X-Forwarded-For.

  • While the true solution would be to automatically sanitize ip address before displaying it, i would like to know when should we really do it?
  • Is there any configurations where webservers automatically change the REMOTE_ADDR to the value of one of this headers?
  • How are those headers useful anyway?
  • The only thing I'm seeing is when client pass by some proxy for un-obvious reason but still want the website to know his ip address. Is there any other?
  • 1
    True-Client-IP is an akamai thing, so you probably should only deal with X-Forwarded-For (and tell/rewrite akamai to send that instead). That's a bad way of forcing HTTP extensions and they should feel bad about it. – grochmal Feb 11 '17 at 21:50
2

I see no huge issue triggering an self-XSS since injecting content into an existing TCP connection is already difficult enough (thanks to initial sequence numbers). And, even if an attacker would be able to inject valid TCP packets, he would be probably more interested into getting your session information directly to his IP, without going through XSS.

Things change a little, when the self-XSS is persistent. i.e. it ends stored in the DB and can be re-run at a later stage. In that case it is pretty much a full XSS, since you can, for example, give access to your account to other users who will run the XSS. But not sanitizing data provided by a user that goes into the DB should be a crime.

Still, on the questions:

While the true solution would be to automatically sanitize ip address before displaying it, i would like to know when should we really do it?

Not only the IP, but every piece of information provided by a user request. And not only in specific cases but always. If you do not sanitize every piece of information and send it back, or leave it in the DB and send it back later, you will have XSS problems.

Is there any configurations where webservers automatically change the REMOTE_ADDR to the value of one of this headers?

Webservers don't do that (although some nginx hacking allowed me to perform it, but that would be a horrible practice). Webservers pass variables to the CGI program/script. Apache's mod_cgi pass things through environment variables and STDIN (for POST content). Nginx controls the variables that are present in its configuration to go to the CGI through the scgi_params file (normally at /etc/nginx/scgi_params).

How are those headers useful anyway?

See my rant-comment about akamai and True-Client-IP, i.e. X-Forwarded-For is the correct HTTP header. X-Forwarded-For is meant for connections that go through some form of proxy (as opposed to going through a NAT).

The only thing I'm seeing is when client pass by some proxy for un-obvious reason but still want the website to know his ip address. Is there any other?

And yes, that is the main and (not considering possible dirty hacks) only use for X-Forwarded-For. That may seem not very useful but is much more common than you imagine.

Offices/datacentres often have huge proxy/firewalls to which their internal network pass through to the internet. Some of the internal machines have private IPs and depend on a NAT but other do have their own public IPs and depend on the firewall as a proxy (the firewall must be stateful to be in any way effective). This situation requires the use of 'X-Forwarded-For' to know from which part of the network a request comes.

Internet proxies (free and non-free) often use that header to ensure that you can visit websites that are tailored to your location. e.g. connecting directly to google.com I get redirected to google.co.uk (since I live in the UK). But if i use a proxy in Poland and do not set X-Forwarded-For I get redirected to google.com.pl. If I use the proxy and set X-Forwarded-For to my home IP (in the UK) I get correctly redirected to google.co.uk.

  • 2
    @Xavier59 all persistent self-xss are exploitable xss if an attacker managers to force-login a user under their account (eg via CSRF or via session fixation), which is why persistent self-xss are often not called self-xss but just xss. grochmal probably assumed a reflected self-xss (which are only exploitable under specific circumstances) – tim Feb 11 '17 at 22:58
  • 1
    @Xavier59 - Yeah, what tim, said. I need to add a detail about persistence to that paragraph. A self-XSS is dangerous if something is stored in a database, otherwise it is not a huge issue. Fixing now. – grochmal Feb 11 '17 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.