The current specification of the Javascript Same Origin Policy is flawed such that it creates a vulnerability under some circumstances. Only hostnames are used when evaluating whether access to content by script code should be permitted -- the IP address is not taken into consideration. If the IP address associated with a hostname were to change in DNS records, content served from a second host may be accessed by script code served from the first. This could theoretically be exploited to access content served from behind a firewall (or on an internal network). Further simplifying attack, the same origin policy allows for DOM access privileges to be inherited across subdomains, for example: script from xxxx.yyy may access content in a child window opened to zzz.xxxx.yyy. This eliminates the need to quickly change a DNS record. To exploit this, the attacker need only create a subdomain with an address behind the victim firewall.
The current specification of the Javascript Same Origin Policy is flawed such that it creates a vulnerability under some circumstances. Only hostnames are used when evaluating whether access to content by script code should be permitted -- the IP address is not taken into consideration. If the IP address associated with a hostname were to change in DNS records, content served from a second host may be accessed by script code served from the first. This could theoretically be exploited to access content served from behind a firewall (or on an internal network). Further simplifying attack, the same origin policy allows for DOM access privileges to be inherited across subdomains, for example: script from xxxx.yyy may access content in a child window opened to zzz.xxxx.yyy. This eliminates the need to quickly change a DNS record. To exploit this, the attacker need only create a subdomain with an address behind the victim firewall.