Cross site scripting attack and types. How to prevent web apps from XSS?

What is Cross Site Scripting(XSS)?

XSS attacks are a type of code injection attack in which an attacker injects malicious code onto a trusted website. The script is sent via a web application, a browser-side script, or an injected link. When the user clicks on the link, the script is executed by the browser. However, if the attack is successful, the attacker will be notified and will be able to use this information to gain control of the site.

A typical XSS attack is a type of code that a website can run on its own. Usually, the attacker will attempt to inject the script into a website that is already running. This code will be stored on the victim’s computer and will be executed by their browser. This is dangerous as it allows hackers to access sensitive information on the victim’s computer. It can also be used by attackers to steal confidential information.

Types of XSS Attack?

The main three types of XSS attack are:

Reflected Cross Site Scripting

Reflected XSS attacks occur when any malicious script is reflected in a request or response of a website, like in search fields and their responses via alert boxes. In this type of attack, the input is needed each time the attack needs to execute.

<script>/*+attack here...+*/</script>

Since developers use various mechanisms like blacklisting or even WAF to mitigate this attack, we can still bypass the WAF using different payloads or encoding methods. Few of the popular payloads used to bypass this are:

<ScRiPt>alert("hacked")</script>
<scr<script>ipt>alert("hacked")</script>
<scr<script>ipt>

Stored Cross Site Scripting

Stored XSS attacks are when the payload is inserted into the server in a manner that whenever the page is loaded, payload executes each and every time.

Where We can try for stored XSS

1. Comments
2. Messages
3. FAQ
4. Form
5. RSS Feeds

<script>/*+attack here...+*/</script>

DOM based Cross Site Scripting:

More like runtime hacks occurring in the Document Object Model of any website.

In this type, the data is not send to the server, but it is updated dynamically.
There are 3 entities vulnerable in DOM Based XSS
1. document.url
2. document.location
3. document.referal

 <img src=1 onerror='/* Attack here... */'>

This involves malicious code injected into a website. This code can be delivered to another user’s browser through a search engine, which is not encrypted. The attacker can also use the stolen session cookies to impersonate a legitimate user. Some attacks are far more advanced than others. For example, one variant may include social network worms and malware, as well as defacement and phishing of websites. Alternatively, the attacker might rewrite HTML page content, which will send sensitive information to an attacker’s server.

The most common forms of XSS are reflected, and stored. The attack sequence is the same for all three types. Once a malicious script is installed on a website, it will run in the user’s browser and execute on the victim’s computer. Depending on the level of sophistication of the attacker, a successful attack could cause serious damage to an organization’s reputation and finances. A recent example of a successful XSS attack involved a credit card skimming malware known as Magecart. This ransomware used an internet check-out vulnerability to download a user’s credit card details to an attacker’s server. The information could be used for fraudulent purchases.

DOM Based XSS is called “type-0 XSS”. Here, the attack payload gets executed as a result of modification of DOM “environment” in the victim’s browser used by original client side script, and it makes the client side code runs in an “irregular” way. The page itself (HTTP response) does not change, but client side scripts in the page runs differently due to malicious codes in the DOM environment.

Some Common payloads that can help in bypassing various firewalls are

" onmouseover=alert(9205) bad="
"/>jaVasCript:/-//*\/'/"//(/* /oNcliCk=prompt() )//%0D%0A%0d%0a//\x3csVg/\x3e jaVasCript:/-//*\/'/"//(/ */oNcliCk=alert() )//%0D%0A%0d%0a//\x3csVg/\x3e
" onclick=alert(1)// */ alert(1)//
jaVasCript:/-//*\/'/"/*/(/ */oNcliCk=alert() )//%0D%0A%0D%0A//\x3csVg/\x3e
';alert(String.fromCharCode(88,83,83))//';alert(String. fromCharCode(88,83,83))//";alert(String.fromCharCode (88,83,83))//";alert(String.fromCharCode(88,83,83))//-- >">'>
' " onclick=alert(1)// / alert(1)// ">>" ><script>prompt(1)</script>@gmail.com<isindex formaction=javascript:alert(/XSS/) type=submit>'-->" ></script><script>alert(1)</script>"><img/id="confirm&lpar; 1)"/alt="/"src="/"onerror=eval(id&%23x29;>'"><img src="http: //i.imgur.com/P8mL8.jpg"> /</em>--&gt;]]&gt;%&gt;?&gt;</object></script></title></textarea></noscript></style></xmp>'-/"/-alert(1)//&gt;<img src=1 onerror=alert(1)>'<br /> javascript://'/</title></style></textarea></script>--&gt;<p" onclick=alert()//><em>/alert()/</em></p></plaintext></em></button></p>

Other Methods to try XSS

Moreover, the exploitation of input vectors is another method of XSS. The input vectors are the elements that trigger responses in a browser. A list of these test inputs can be obtained from the Open Web Application Security Project. Once the SS vulnerability has been identified, the tester should analyze the results to determine whether it affects the security of the application. Similarly, if the attacker uses HTML special characters, he can create vulnerabilities in the website.

Another example of XSS is a defacement attack. An attacker can inject malicious code into a legitimate website and change its contents, or redirect a user’s browser to another web page. The injected scripts can access any object on the web page and can also get the user’s cookies. These cookies are typically used to store session tokens for login. If the attacker gets access to them, they can perform a variety of malicious activities such as tracking their movements.

Among the most common ways of a cross site scripting attack, JavaScript is often used by attackers to insert malicious code into a website. The attacker can also use HTML tags to disguise malicious code and hide their identity. Most of these attacks depend on the coding language of the website. The underlying PHP language is a good choice for cross-site coding. This will prevent the malicious code from affecting other visitors’ browsers.

Real example situation

In a cross-site scripting attack, an attacker can send a malicious script to the target’s browser. Unlike HTML, the attacker’s payload can remain hidden on the victim’s computer. For example, they could use feedback forms to send malicious scripts to the website. Then the victim would open the form and the attacker’s payload will be executed. Unfortunately, blind XSS attacks are harder to detect in a real-world scenario. To practice this kind of attack, XSS Hunter is a great tool.

XSS is a serious threat and should be avoided. Anywhere where malicious users can post unregulated content is susceptible to a XSS attack. Bulletin-board websites are an example. They are web-based mailing list style applications. An XSS attack may be exploited to retrieve sensitive information from a website. This is one of the most common types of XSS. Once the attacker has gained control of the bulletin-board, it can extend to the server side and cause havoc.

How to prevent a website from XSS attacks

1. Whitelisting the inputs to avoid script or malicious code injected
2. Content security policy header. (.htaccess file in apache servers and NGINX directives in NGINX servers)

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

Proof of Concept EXAMPLE FOR XSS