Websites are under constant threat, with hackers looming around every corner, the probability of enhancing data vulnerability is more. Same origin policy is one such strategy which effectively protects the contents of a website from possible vulnerabilities. Even though websites are shielded by such access control policies, a new path was introduced to break those shields.
What is Same Origin Policy?
A security model for web applications, here the origin refers to website’s URI scheme, host name, and port number. Under SOP, the web browsers permit the script from first web page to access the information or data present on the second web page provided they have the same origin.
Through this strategy, the probability of injection of malicious scripts is less as the same origin policy makes use of Document object model on each page. So, under SOP concept, the possibility of web pages being under attack can be completely minimized. To understand this concept more precisely let us go through an example. The web page, https://abc.com/index.html can easily access https://abc.com/features.html, whereas https://attacker.com/index.html will be completely denied to access https://abc.com/features.html.
Targeting the Same Origin policy
Since access to sensitive data was not possible under this policy, attackers started targeting this shield through (XSS) cross-site scripting attacks. The impact of such attacks is dependent on the degree of sensitiveness of data. Once getting access to session cookies or content, the chances of data exploitation is greater.
Cross-scripting attacks can be given a name of code infection, where on injecting a code to the target; the execution process will be completely under the control of an attacker. Under this kind of approach, the pluggins or servers are used as a medium to execute the attacks. Once a possible website is compromised with security, the actions will be controlled through this code rather than the website. The most common type of XXS attacks are Reflective or non-persistent XXS, persistent XXS, Self XXS, and many more.
- Reflective or Non-persistent XXS– Considered as one of the most common types of attacks, reflective XXS makes use of the flat, serial structure of HTML. These HTML structures can be easily injected as they mix control statements or any non-validated data without encoding. So any website with XSS vector can easily target these kinds of vulnerable websites.
- Persistent XSS– The need for a third party website to attack is void here. Under this method, the attacker’s script is automatically on the server, resulting in the script imitating the actual web page.
- Self-XSS– Under this kind of attacks, a user will be deceived to execute the malicious code to their browser. The Self-XSS makes use of social engineering to perform the act.
Wakeup call through X-XSS-Protection
As the attacks are getting better, the approach to counter them should also advance. It is truly a wakeup call for the developers to make sites more secure from such flaws. Modern websites are defended from such malicious activities through an XSS filter. Under this process, the X-XSS-protection header blocks any of the malicious scripts in the event of attack.
X-XSS-protection: 1; mode=block
X-XSS-protection header can be easily enabled through performing some basic configurations to the web servers.
The Bottom Line
Stringent of attacks are being carried on websites, compromising the integrity and functioning of sites. X-XSS-protection does not completely sanitize the script, but reduces data vulnerability. Since client-side scripts have an easy access to cookies, the possibility of making them more susceptible to such attacks is greater. XSS attacks are evolving, but more defensive tools are also emerging like Content Security Policy, Javascript sandbox tools, and auto-escaping templates with a promise to provide secure operating environments.
