Basic XSS
Let’s demonstrate basic XSS with a simple attack
against the OffSec WordPress instance.
The WordPress installation is running a plugin named
Visitors that is vulnerable to stored XSS.
The plugin’s main feature is to log the website’s visitor data,
including the IP, source, and User- Agent fields.
If we inspect the database.php file,
we can verify how the data is stored inside the WordPress database:
This PHP function is responsible for parsing various HTTP request headers,
including the User- Agent, which is saved in the useragent record value.
Next, each time a WordPress administrator loads the Visitor plugin,
the function will execute the following portion of code from start.php:
We’ll notice that the useragent record value is retrieved from the database
and inserted plainly in the td HTML tag, without any sort of data sanitization.
As the User-Agent header is under user control,
we could craft an XSS attack by inserting a script tag
invoking the alert() method to generate a pop-up message.
Given the immediate visual impact, this method is very commonly used
to verify that an application is vulnerable to XSS.
With Burp configured as a proxy and Intercept disabled,
we can start our attack by first browsing to /offsecwp/ using Firefox.
We’ll then go to Burp and send the request to Repeater.
We can replace the default User-Agent value
with a script tag that includes the alert method.
If the server responds with a 200 OK message,
we should be confident that our payload is now stored in the WordPress database.
To verify this, let’s log in to the admin console.
If we navigate to the Visitors plugin console,
we are greeted with a pop-up alert, proving that our code injection worked.
Excellent.
We have injected an XSS payload into the web application’s database
and it will be served to any administrator that loads the plugin.
A simple alert window is a somewhat trivial example
of what can be done with XSS,
so let’s try something more interesting,
like creating a new administrative account.