Cross Site Scripting(XSS)

Cross Site Scripting(XSS)


WEB Attack Method XSS

  Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.

alt text

Reflected XSS, where the malicious script comes from the current HTTP request.
Stored XSS, where the malicious script comes from the website’s database.
DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code. To deliver a DOM-based XSS attack, you need to place data into a source so that it is propagated to a sink and causes execution of arbitrary JavaScript.

What is The Difference between DOM XSS and REFLECTED XSS?

  The main difference between DOM based XSS and Reflected XSS is that the DOM-based XSS is a type of XSS that processes data from an untrusted source by writing data to a potentially dangerous sink within the DOM. But, the reflected XSS is a type of XSS that occurs when an application obtains data in an HTTP request and includes that data within the immediate response in an unsafe way.

alt text

Cross site scripting attacks can do:

  • Code injected into a vulnerable application can exfiltrate data or install malware on the user’s machine.
  • Attackers can masquerade as authorized users via session cookies, allowing them to perform any action allowed by the user account.
  • An attacker can deface a corporate website by altering its content, thereby spreading misinformation.
  • A hacker can also change the instructions given to users who visit the target website, misdirecting their behavior. This scenario is particularly dangerous if the target is a government website or provides vital resources in times of crisis.

alt text

To prevent XSS, you can:

  • Run untrusted HTML input through an HTML sanitization engine.
  • Blacklist specific HTML tags that are at risk, such as the iframe, link, and script tags.
  • Prevent client-side scripts from accessing cookies

REAL LIFE XSS ATTACKS

TWITTER WORM (2009)

Execution

  A hacker used a stored XSS vulnerability in Twitter to create a worm that exploited the “onmouseover” event of links. When users hovered over these links, the worm retweeted itself, causing it to spread.

Consequences

  The worm affected numerous Twitter users and caused embarrassment for the social media platform. Twitter had to take immediate measures to address the vulnerability.

XSS ON GOOGLE’S BLOGSPOT (2015)

Execution

  A security researcher found an XSS vulnerability in Google’s Blogspot service. Attackers could execute arbitrary JavaScript code on Blogspot-hosted sites by injecting malicious code into the comments section.

Consequences

  This vulnerability allowed attackers to deface websites and potentially steal user data, damaging the reputation of Blogspot. Google swiftly patched the vulnerability.

WHATSAPP WEB XSS (2020)

Execution

  A security researcher found an XSS vulnerability in WhatsApp’s web client. The attacker could send a specially crafted message containing malicious code. When the recipient viewed the message in the web client, the code would execute.

Consequences

  This vulnerability could have allowed attackers to compromise users’ data and potentially take control of their accounts. WhatsApp addressed the issue to protect its users.
© 2024