StackZero
  • Homepage
  • Categories
    • Basics
    • Cryptography and Privacy
    • Ethical Hacking
      • Web Security
      • Network Security
    • Reverse Engineering
      • Malware Analysis
  • Contacts
No Result
View All Result
StackZero
No Result
View All Result

The terrifying world of Cross-Site Scripting (XSS) (Part 1)

June 13, 2022
in Ethical Hacking, Web Security
0 0
XSS tutorial part 1
0
SHARES
84
VIEWS
Share on FacebookShare on Twitter

Cross-site scripting (XSS) is a cyber-attack where the cybercriminal injects malicious code into an already trustworthy and valid application or website so that the web browser can execute a properly crafted payload. Since the victim’s browser believes the code is from a legitimate source, it will run and execute it. The attacker’s purpose might be to acquire entry to a user’s data, such as any cookies or authentication information, to disguise as the user to do certain activities in the application, or to redirect users to a malicious website that they operate.

Before starting, just a list of articles about XSS for quick navigation:

  • The terrifying world of Cross-Site Scripting (XSS) (Part 1)
  • The terrifying world of Cross-Site Scripting (XSS) (Part 2)
  • XSS in practice: how to exploit XSS in web applications
  • Reflected XSS DVWA – An Exploit With Real World Consequences
  • How to exploit a stored XSS vulnerability on DVWA
  • How to exploit DOM XSS on DVWA

Table of Contents

  • Types of Cross-Site Scripting Attacks
  • How XSS is Used
  • The Consequences of XSS Attack
  • The case of Mutation XSS in Google Search
  • How to Prevent XSS Attacks
  • Conclusion

Types of Cross-Site Scripting Attacks

We can classify Cross-site scripting attacks into three different types: reflected, stored, and DOM-based.

Reflected XSS

Reflected cross-site scripting is also known as Type-II or Non-persistent cross-scripting. It is a cross-scripting attack where target servers reflect a malicious script. The attacker can include the payload into an error page, a search result, or the target server’s response to some request. The source of script in Type-II cross-site scripting is the request.

Whenever an internet user interacts with the malicious script, such as by clicking a link on a website or email, the malicious script travels to the infected site and then reflects the attack to the victim’s browser. Since the victim’s browser recognizes its server, it will execute the malicious script.

Stored XSS

Stored cross-site scripting is also known as Type-I or Persistent cross-site scripting. It is an attack where the hacker stores the malicious script on the targeted servers. The attacker usually tries to store the payload in the server’s persistent storage in some way. In this particular case, the effects are way more disruptive than the Reflected one.
When a user requests the data, the server delivers legit data mixed with the malicious script, making every application’s user a potential victim of this XSS attack.

DOM-Based XSS

It is also known as Type-0 cross-site scripting. It is an attack in which the malicious script alters the user’s browser’s DOM environment, causing the web page’s client-side code to run incorrectly.

Maybe is tricky to get the difference with Type-II XSS, but a simple way to understand the difference is just to imagine from where the error comes.

  • In the case of Type-II, the poor sanitization makes the server send a dangerous page,
  • In the case of DOM-Based, the error occurs inside the client. So it’s the result of a poor design in the frontend application.

How XSS is Used

Cybercriminals use XSS to trick a web application into transmitting data in a format that a user’s browser can understand. The attacker frequently provides a mix of HTML and XSS, although XSS may also be used to provide plugins, malicious files, or media assets.
An attacker can fool a web application by allowing data from an untrusted source, such as:

  • sending data input in a form
  • supply data to an API endpoint with client software

What makes it possible in these cases, it’s the bad sanitization of the input.

The Consequences of XSS Attack

Cross-site scripting assaults may be pretty damaging. Injecting code into a vulnerable application can allow data exfiltration or, in worst cases, malware installation on the user’s workstation. Attackers can employ session cookies to pose as authorized users, enabling them to do any activity with the same level of permissions as the victim account.

XSS may potentially harm a company’s reputation. An attacker can deface a corporate website by changing its content, causing the company’s image to suffer, or disseminating falsehoods. A hacker can also modify the instructions the users show when visiting the target website. This situation is challenging if the target is a government website or one that provides critical resources during a crisis.

The case of Mutation XSS in Google Search

An attacker uses a Mutation XSS vulnerability when his exploit takes advantage of the standard HTML parser.
It is tough to sanitize user input on the server due to browser variations. The server must account for any variations across browsers and browser versions. 

For example, on September 26, 2018, one of the Closure library’s developers while patching that library, deleted part of the input sanitization. Noone was aware that the commit’s consequence was an XSS vulnerability.
A security researcher found this vulnerability in February 2019 and reported it to Google.
The fix was extremely quick, and on February 22, 2019, the vulnerability was no more present.

How to Prevent XSS Attacks

  1. Sanitizing Inputs: Always sanitize the inputs, it should be a general rule when you write some applications.
  2. Implement a Content Security Policy: It is a browser-side approach for setting access rights to client-side resources like JavaScript and CSS. It instructs the browser to execute contents only from the given sources using an HTTP header.
  3. Use HTTPOnly cookie flag: this option prevents client-side scripts from accessing cookies, essentially preventing XSS attacks.
  4. Use the correct output method: ensure you’re using the correct browser API output method. Do not attempt to encode the output manually.

Conclusion

Even if so simple and if it doesn’t appear in OWASP Top 10 2021, XSS represents a real danger for users, so as a security specialist, you must know it deeply.

I suggest you go further with your readings and learn How to build an XSS vulnerable application.

How malware evasion works – 2 simple techniques in practice
Trending
How malware evasion works – 2 simple techniques in practice

Tags: domdom-based xssjavascriptreflected xssstored xssxssxss intro
Previous Post

OWASP Top 10 Breaches of 2021. What You Need to Know!

Next Post

The terrifying world of Cross-Site Scripting (XSS) (Part 2)

Next Post
XSS exploitation Part 2

The terrifying world of Cross-Site Scripting (XSS) (Part 2)

You might also like

Hack File Inclusion in DVWA: A Full Walkthrough

Hack File Inclusion in DVWA: A Full Walkthrough

January 18, 2023
How To Exploit File Inclusion Vulnerabilities: A Beginner’s Introduction.

How To Exploit File Inclusion Vulnerabilities: A Beginner’s Introduction.

December 15, 2022
What is unrestricted file upload vulnerability? And How to exploit it on DVWA!

What is unrestricted file upload vulnerability? And How to exploit it on DVWA!

November 29, 2022
How To Exploit CSRF In DVWA

How To Exploit CSRF In DVWA

November 23, 2022
CSRF intro featured

CSRF Introduction: What you need to know!

November 15, 2022
Bruteforce attack

How to Brute Force DVWA login with Python

November 3, 2022

StackZero

StackZero is a technical coding blog that focuses on cybersecurity. It mainly offers articles and tutorials that teach readers how to write security tools.
The blog covers a wide range of topics, from the basics of cryptography to the more advanced topics of exploitation and reverse engineering.

Tags

application security blind sqli blind sql injection bruteforce c certification command injection csrf csrf attack cybersecurity dom-based xss dvwa ethical-hacking exploitation file inclusion file upload hacking injection javascript kali linux local file inclusion malware malware analysis network-security penetration testing pentesting lab python reflected xss registry remote file inclusion security shellcode sql sqli sql injection stored xss virtual machine vulnerable application web application security web exploitation web security windows windows api windows virtual machine xss
  • Contacts
  • HomePage
  • Privacy Policy
  • Terms and Conditions

No Result
View All Result
  • Homepage
  • Categories
    • Basics
    • Cryptography and Privacy
    • Ethical Hacking
      • Web Security
      • Network Security
    • Reverse Engineering
      • Malware Analysis
  • Contacts

Welcome Back!

Login to your account below

Forgotten Password?

Retrieve your password

Please enter your username or email address to reset your password.

Log In