Cross Site Scripting OR XSS:
Cross site scripting, commonly known as XSS is still one of the major attack which targets majorly IT and Finance companies. Report which is related to web application attacks, states that the attack which occurs at highest percentage on web applications is cross site scripting and it’s relative percentage is nearly 35.1%. According to research of Precise security, online cyber attacks in 2019 with cross-site scripting used in 40 percent of incidents hit around three quarters of large companies in Europe and North America
What is Cross-site Scripting (XSS)?
Cross-site Scripting (XSS) is a type of attack, where the attacker can execute or inject javascript code on a web application or website from the client-side. If the vulnerability exists then the aim of the attacker is to execute malicious javascript code in a web browser in the victim’s computer in a web application or web site or web page. After injecting the malicious javascript code into that web application then whenever the web application runs in the web browser of the victim’s computer, at that time the attack starts. Actually, the attack occurs by the web page or web site. Actually, the web site becomes a medium to run the malicious code to the browser which is running on that device which is being used by the victim. The vulnerable web application are the mediums which are commonly used by the attacker to infect the victim to be infected.
A web application or a web site is vulnerable to XSS if does not filter the user input in output which is generated by it. The main reason for this vulnerability is for the unvalidated data in an HTTP response. This unvalidated data is then parsed into the victim’s browser. XSS can allow an attacker to run VBScript, ActiveX, Flash and CSS and JavaScript. From these languages, JavaScript is the most language for the XSS attack. The main for this is JavaScript is the basic Scripting language used in the internet browser
Is Cross-Site Scripting the problem of users?
If an attacker abuse an XSS vulnerability on a web application or a web page to execute malicious JavaScript code then the malicious codes will be run in the user’s internet browser. The result of the attack is the vulnerable website or the vulnerable web application security and the user’s security also be compromised. So, XSS is not the problem of user like vulnerabilities that are found in a web application. And yes users are affected by this vulnerability but if users are affected then it’s affecting you.
Instead of targeting the users of a website or a web application, Cross-Site Scripting may also be used to deface a website. The attacker can use JavaScript code to change the content of the targeted website or maybe redirect the URL to another web page. The redirected web page can contain malicious code.
What can be done with JavaScript code by the attacker?
The XSS vulnerability is accepted as less dangerous than are most found in a web application which is injection and SQL injection is the most common attack in injection attack. The impact of the XSS vulnerability may not be so dangerous to execute JavaScript code on a web page for the first time it is known by an attacker. Most of the web browsers allow JavaScript code to execute. JavaScript does not have full control of the user’s operating system and the user’s files. But, still, JavaScript can be so dangerous if the attacker has a strong knowledge of JavaScript then the attacker can maliciously use a simple JavaScript code.
-> The objects of vulnerable web page has access to anything on the system, the malicious JavaScript code also has access through the objects. This allows an attacker to access a user’s cookies. Cookie is mostly used to store session tokens. If an attacker once gets the user’s session cookie, then the attacker performs another attack called session hijacking that means attackers can do anything on behalf of the user. Not only these, but attackers also obtain the user’s sensitive data from the system.
-> JavaScript can read the browser DOM and random modification is possible to it. But luckily, this modification is only possible where the JavaScrip]t is executing within the page.
-> JavaScript is capable of sending an HTTP request using XMLHttpRequest object with arbitrary content to an arbitrary destination.
-> In modern browsers JavaScript can use HTML5 APIs. As a result of this feature through JavaScript code, an attacker can get the user’s geolocation, webcam, microphone, and also the user’s specific file to the user’s file system. This could be dangerous but there is another feature that to do such attacks, most of these APIs require user opt-in, but the attacker can use social engineering to get access.
The combination of the above attacks the attackers can perform advanced attacks like cookie stealing or session stealing, planting trojans, keylogging, social engineering and many more. Hence, the XSS vulnerability allows an attacker to perform a massive affecting attack on one or many victims. XSS vulnerability can also be allowed to perform CSRF (Cross-Site Request Forgery) attack by an attacker.
How Cross-Site Scripting works ?
There are two stages of Cross-site Scripting attack:
⦁ To run or execute a malicious JavaScript code in the internet browser of the victim, an attacker must find a way of injecting malicious into the web application or web page that the victim may visit or regularly visits.
⦁ After that attack the victim will visit the web page with malicious code injected into that page. Not only this, if the attack is targeted at a single victim the attacker can send the victim a malicious URL to infect.
Types of Cross-site Scripting (XSS)
The Cross-Site Script (XSS) attacks are classified into three vectors. Such as
i) Stored/persistent XSS,
ii) Reflected/non-persistent XSS,
iii) DOM-based XSS.
i) Stored/persistent XSS
The most dangerous and damaging type of XSS. An attacker uses this vulnerability if exists in the application to inject malicious code into the server of the web application or web page. Once an attacker injects the malicious JavaScript code into the server with XSS stored vulnerability then the malicious JavaScript code is stored into the server then all the visitors of that affected web page is the victim of that attack.
ii) Reflected/non-persistent XSS
The most and the most common type of Cross-site Scripting attack. With this attack the attacker’s malicious code is reflected to the request to the server. Then this request is reflected back as an HTTP response and includes the malicious JavaScript code. This malicious link is sent to the victim by the attacker by phishing.
iii) DOM Based Cross site scripting :
DOM-based XSS occurs at the time when an application is having few client-side JavaScript which processes data from a source which is untrusted and not in a safe way, usually by writing the data back to the DOM which is a document object model.
In the example mentioned below, an application which uses some JavaScript to read the value from an input field and write that value to an element within the HTML:
var search = document.getElementById(‘search’).value;
var results = document.getElementById(‘results’);
results.innerHTML = ‘You searched for: ‘ + search;
If the value of the input field can be controlled by an attacker, they can easily construct a malicious value that causes own script developed by them to execute:
You searched for:
<img src=1 onerror=’/* Bad stuff here… */’>
In an usual case, part of the HTTP request would populate input field , such as a URL query string parameter, which allows the attacker to deliver an attack using a malicious URL, same as reflected XSS.
Test to find whether Your Website or Web Application is Vulnerable to Cross-site Scripting :
one of the most common web application vulnerabilities are cross site scripting. The OWASP organization (Open Web Application Security Project) lists XSS vulnerabilities in their OWASP Top 10 vulnerabilities document
It’s comparatively easy to check if your website or web application is vulnerable to XSS and other vulnerabilities. There are different web scanning tools you can use like Acunetix scanner which scans vulnerabilities and having specialized XSS scanner in it. You can also use nessus, nikto scanner, Burp Suite’s web vulnerability scanner can also find XSS vulnerabilities quickly and reliably
You can also perform manual testing for reflected and stored XSS , if you want to study it practically, you can opt for any of the best ethical hacking institute in pune or can approach any of the top mentor who finds such vulnerabilities and patch those, manual testing which normally involves submitting some simple unique input (such as a short alphanumeric kind of string) into each entry point in the application; to identify each location where the input which we submit is returned in HTTP responses; and verifying each location one by one to know if we can use suitably crafted input to execute arbitrary JavaScript.
Plus, other types of DOM XSS are harder to determine. DOM-based vulnerabilities can be found in non-URL-based input (such as document.cookie) or non-HTML-based sinks, there is no substitute for checking JavaScript code, which is very time-consuming.
How to secure yourself from Cross site scripting (XSS) ?
Preventing cross-site scripting is important in few cases but can be comparatively harder which is decided on the complexity of the application and the ways in which user-controllable data is handled by it.
Generally, effectively preventing XSS vulnerabilities includes some of the security measures like to turn off HTTP TRACE support on all web servers. Cookies can be stolen by an attacker from Javascript, it is possible even when document.cookie is disabled or not supported by the client. When a user posts a malicious script, this attack is mounted to a forum so when any other user clicks the link, it triggers an asynchronous HTTP Trace call which collects the user’s cookie information from the server, and then sends it over to any other malicious server that collects the cookie information because of which the attacker can mount a session hijack attack. This can be made less severe by removing support for HTTP TRACE on each web server.
Also, there are multiple ethical hacking institutes in pune which work in real world to patch these vulnerabilities so you can choose any ethical hacking institute or any one of the top mentor who work on these vulnerabilities to get clear idea about how to prevent this practically.
