Updated: December 8, 2020 by Agnes Talalaev
In this article, you can learn about what is XSS or cross-site scripting. There is also an example of cross-site scripting vulnerability in WordPress.
Cross-site scripting or XSS is one of the most popular vulnerabilities among web applications or websites today. When developing any kind of web application of software, you should be aware of the seriousness of XSS vulnerabilities.
Cross-site scripting or XSS for short is a security vulnerability typically found in web applications. It is basically allowing an attacker to execute potentially malicious script code in the website visitor’s browser.
This vulnerability has been around for decades and it is has been still growing in the last few years. According to HackerOne, XSS is still a major threat vector. With the continuous development of new web technologies, it is easier to migrate to this vulnerability.
Computerphile has explained XSS really nicely in his Youtube video and he said that to understand how XSS really works, we should go back to the roots.
The web is based on HTML (HyperText Markup Language) and that means we have tags. An HTML document starts and closes with angle brackets as you see in the example below.
<!DOCTYPE html>
<html>
<body>
<h1>My First Heading</h1>
<p>My first paragraph.</p>
</body>
</html>
Anything that stays between the brackets is an instruction. So if you want to write a heading you put a <h1>
tag and end it with </h1>
and the text inside the tag becomes a heading. When you want to put an angle bracket into your document you do something called escaping.
Escaping is when instead of sending an angle bracket, you send an ampersand &
(The ampersand is the logogram &, representing the conjunction “and”.) then an lt
(for less than) and a semicolon ;
. That means when the user reads the document, it will become an angle bracket. Looks like that: <
.
This all meant that in the old days of the world wide web, you could send a request, and the document would come back perfectly, without the angle brackets messing it up.
So then the invention of Javascript comes. (Here is a brief history of JavaScript if you like.)
Javascript is a programming language that sits in the middle of web pages. So it means that inside HTML there is another language with variables, calculations, and more. See the example below.
<script>
document.getElementById("demo").innerHTML = "Hello JavaScript!";
</script>
That Javascript language affects the document. Javascript is the way that everything interactive works on the web now, so it was an amazing invention from Brendan Eich.
But now we come to the danger zone. The problem with Javascript is that it is dangerous.
As I mentioned before Javascript is the way everything works. Imagine, you can use it to do everything you want. Let’s say you have a website that is collecting credit card information or usernames and passwords in the login page. With Javascript, you can send the credit card details of login data to someone else.
And that someone can be a very bad person – let’s say a blackhat hacker. The worst part is that the user who just entered his or her login information doesn’t even know that the data went to a hacker.
When you, for example, have a website with a search bar. A simple blog where you can search topics via the search bar added to the website. You can insert any type of text there, right. You can even insert HTML code or Javascript code there.
Whatever you type there will appear on the website. If you, for example, search for a <b>
tag, it won’t make the website all in bold. But why?
When a website is being sanitized correctly it means that whatever the text, code or script will be inserted into the search bar the <
will convert it into less-than.
If you for example type <script>
and after that, you add some valid code and you have not used the <
in your code, the script will run. This is how it is possible to trick our website into doing something else.
XSS vulnerabilities are very popular, there have been many instances when very big companies have had these issues. Like passwords and user information has been quietly stolen and so on. Facebook, Youtube, Gmail, and many other big companies have had XSS vulnerabilities.
Now if you are a developer, you want to read this: if you forget to add the less-than somewhere on your site, in any user input, it will make the whole site vulnerable. If you forget to escape a small search box and someone types code there, your website becomes vulnerable.
A while back, WebARX security researcher did research on WordPress 4.8 and he discovered that $file_description
and $description
from wp-admin/theme-editor.php
are not filtering the name of the template allowing an attacker to execute an XSS attack in WordPress.
Here’s the full write-up of the WordPress XSS vulnerability and how it was discovered.
$file_description = get_file_description( $filename );
You can see it’s getting file description, using “get_file_description” which is defined inside wp-admin/includes/file.php and it is getting template name from the file comment.
$file_description = get_file_description( $filename );
if ( $filename !== basename( $absolute_filename ) || $file_description !== $filename ) {$file_description .= '<br /><span class="nonessential">(' . $filename . ')</span>';
}
if ( $absolute_filename === $file ) {
$file_description = '<span class="highlight">' . $file_description . '</span>';
}
$previous_file_type = $file_type;
?>
<li><a href="theme-editor.php?file=<?php echo urlencode( $filename ) ?>&theme=
<?php echo urlencode( $stylesheet ) ?>"><?php echo $file_description; ?></a></li>
<?php
endforeach;
?>
From this code, we can see that $file_description = get_file_description( $filename );
is getting declared and later on under <li><a> tags template name is printed on the page ...<?php echo $file_description; ?></a></li>
$file_description
htmlspecialchars()
If the victim clicks on the file that contains XSS payload, XSS will be executed because $description = get_file_description( $relative_file );
is displaying name of the active file the person is editing.
So what if we insert XSS payload after “Template Name:”
Jackpot!
/* Template Name: <script>confirm(document.cookie);</script> */
Most of the popular and modern web development frameworks are using template engines that come with XSS protection out-of-the-box. They also have options for developers to allow execution of script code and that is where XSS occurs. WordPress is a nice and useful CMS without any real competitor on the market.
This vulnerability was reported to the WordPress team by following responsible disclosure policy. It is patched in version 4.8.2.
When hunting for bugs in open source projects, understanding its code is a big plus. Having messy code is also beneficial for security researchers. If It’s hard to read, it must be hard to maintain.
Cross-site scripting or XSS for short is security vulnerability typically found in web applications. It is basically allowing an attacker to execute potentially malicious script code in the website visitor’s browser.
XSS vulnerabilities are very popular, there have been many instances when very big companies have had these issues. Like passwords and user information has been quietly stolen and so on. Facebook, Youtube, Gmail, and many other big companies have had XSS vulnerabilities.
Look at The article WebARX has written about XSS and find a good example of XSS vulnerability in WordPress 4.8.
Cross-site scripting is a security vulnerability which is basically allowing an attacker to execute potentially malicious script code in the website visitor’s browser.
Cross-site scripting is very dangerous because it is not visible for the user. Users can accidentally trigger the XSS payload if they visit an affected page.
Protect your websites from malicious traffic - set-up in under 3 minutes.
WebARX is compatible with the following platforms: