AlbusSec:- Penetration-List 05 Cross-Site-Scripting (XSS) — Part 2

Hello Everyone, I hope you liked our previous article that was Cross-Site-Scripting (XSS) — Part 1, On that article, you learned about Basic XSS, a short summary of types of XSS, and the impact of XSS, However In this article, you’ll learn the depth summary about types of XSS. So, before we start our article, I would like to introduce myself, So I’m Aniket Tyagi and I’m an Information Technology officer at the 5f eco foundation of India, an Information Security Researcher, and the founder of Albus Security.

Non-Persistent or Reflected-Cross-Site-Scripting(XSS):-

Reflected-Cross-Site-Scripting

Reflected Cross-Site-Scripting is also known as non-persistent, Reason when an attacker sends malicious javascript through input to a web server then, web applications will respond immediately, adding attacker given malicious javascript to the page, then the web browser assumes that the code came from the web server and executes it. And the reason why this vulnerability has arisen is due to insufficient sanitization of user-supplied data in URL. Therefore, The first step is to find a Reflected-XSS is that you’ll take a look at how websites can accidentally throw up pages containing your malicious code. Second, choose the right payload to execute Reflected-XSS, for this, You’ll use the portswigger cheatsheet that contains many events/tags combinations that can help you bypass WAFs and filters. However, Albus Security will provide you lots of payloads only for bypass so check our GitHub Repository Also.

Stored-Cross-Site-Scripting(XSS):-

Stored-Cross-Site-Scripting

Stored-Cross-Site-Scripting, also known as Persistent Cross-Site-Scripting, when an attacker sends malicious javascript through input to a web server then web applications will respond immediately and store that malicious content page on the server-side, basically in a database, Whenever other users visit that page, then the injected payload is also executed by the attacker because whenever attacker inject malicious javascript file then the application will store on the web page, therefore that payload also execute whenever anyone can visit that page. Stored Cross-Site-Scripting affects multiple users without any further interruption by the attacker. Imagine You were testing on a website where there was a comment section so whenever the user will comment on something then the application will store user input value on that page without sanitization what kind of value was input by the user. An attacker will inject some malicious javascript code into that webpage by commenting something javascript code then the application will procedure that value without filtering it and store it on the web page. The above malicious JavaScript will be triggered every time whenever any user visits that Comment page. In some cases, like User bio, feedback pages so can spread just like a virus because that malicious javascript would trigger for every user who opened that page and people who share the link to open that attacked crafted page

Document Object Model(DOM)-Cross-Site-Scripting (XSS):-

Dom-Cross-Site-Scripting

Before We’ll learn about DOM-XSS, firstly I’ll explain to you about the Document Object Model (DOM) it is a language-neutral interface that allows a web application to dynamically access and update the web page. When a web page has loaded in the browser it creates a Document-Object-Model of the page. In simple words, DOM is a standard for how to get multiple web pages, change, add or delete html elements. DOM defines the properties of all HTML elements, the method to access all html elements. Now, we’ll learn about DOM-Cross-Site-Scripting as an attack wherein an attacker payload is executed in the Document-Object-Model of a web application rather than in html. In reflected or stored XSS, You can see that your malicious javascript on the response web page, but In DOM-Based XSS, the response web page will be the same meaning the payload cannot be found in the response, However, the question is why Malicious Javascript code was executed so the reason is the response web page executes differently due to the malicious modifications by an attacker that have implemented in the DOM environment. But You’ll see your malicious javascript through the DOM of the page.

I hope you understand all types of XSS, In our next article, we’ll learn the XSS Bypass technique in depth. However, Keep supporting us we’ll do our super hard work to give the best quality. Thank you for reading.

--

--

--

Privacy Is The Best Freedom

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Coins MarketCap live 24/7

Coins MarketCap live 24/7

Password Encryption

{UPDATE} Emoji Clickers Hack Free Resources Generator

Digital ID Profiling and The Future of Credit Scoring

digital ID profiling in credit scoring — cover

{UPDATE} Merge Miners: Idle Tycoon Hack Free Resources Generator

“The Colonial Pipeline Attack Is a Dark Omen:

Book shelves stacked with books.

Give me 20 seconds to enter a 9 digit code with my fat thumb

{UPDATE} Heroes Empire: TCG Hack Free Resources Generator

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Albus Security

Albus Security

Privacy Is The Best Freedom

More from Medium

CNAME Cloud Subdomain Takeover [advanced]

My Pentest Log -7- (Horizontal/Vertical Privilege Escalation)

BUG BOUNTY CHECK LIST BY C1

Kioptrix Level 4 — VulnHub