Advanced Cyber Security

You are here: SecPoint Cyber Security News

What is Reflected XSS (Cross Site Scripting)?

Have you ever wanted to know what is reflected XSS (cross site scripting)? 

Before we start to tell you more about what this is and how it works, it's important to understand how grave these vulnerabilities are. Since 2012, practically 50% of all vulnerabilities have been based on XSS.

In this article, we will cover everything you need to know about XSS and what XSS attacks look like, and how they work.

So whenever you're ready to dive deep into the world of common data hacks, keep reading and get your notes ready.

What is Reflected XSS Cross Site Scripting

Cross Site Scripting (XSS): The Basics

Not only are XSS vulnerabilities the most common, but they're also one of the easiest to exploit. Ultimately it's just another form of injection. However, this time on a webpage rather than into an API.

All you need is some JavaScript and HTML that find its way onto your site or app through means like phishing scams, social engineering attacks, or even completely valid user interactions (like comments).

The attacker places their malicious code in plain sight for users to see. This is because no input sanitization takes place, any visitors who load these pages will be at risk too!

It works by inserting dynamic scripts. This changes things behind the scenes without breaking how actual content looks on screen.

This includes assets like images and CSS files. This also includes user input, cookies, and more.

First off, you're going to need an application that one can compromise. Preferable to something reachable on the Internet that allows for open or anonymous access - like a public web app or shared hosting plan (not home-brewed code running locally). If your server doesn't allow any form of HTML injection should be fine, too, though!

GET vs POST

There are different types of attacks based on how the site sends data over GET vs. POST requests. Look at if it uses either method to send information about what was requested.

Whether you could actually modify anything behind the scenes depends on whether actual pages are being served up as well. This varies between apps/sites.

The attack's goal is to inject code that will be executed by users who load the page. This can range from annoying pop-ups, redirects to malicious sites, stealing user data (like passwords), or even use their browser as part of a botnet!

The following are some examples of what you could do with XSS:

  • Mess around with how the web app looks, turn links into other ones, show ads for fake products
  • Change content behind-the-scenes like updating prices/review counts
  • Put up messages saying that your site has been hacked and spread malware through visitors' browsers
  • Redirect people to phishing websites where they'll have their details stolen 
  • Steal users' cookies which one can use for impersonating them

What Is Reflected XSS (Cross Site Scripting)?

Reflected Cross-Site Scripting is the trickier attack style because it requires an attacker to make a user load their script rather than injecting it directly through the web app itself. This limits its reach but also means that there are multiple ways to pull this off!

Before we go into these, though, let's quickly cover what exactly reflected cross-site scripting actually is. Let's also take a look at how websites can accidentally throw up pages containing malicious code without even realizing themselves.

The two main things you'll need here are some input from visitors and a way to send content back on screen. That's it! If you can do either work, then you can launch an attack without any form of user interaction (like clicking on a link).

The first one is usually done through forms but could also be part of how the app works, like using comments to let people submit their own content or similar cases.

Other Forms of XSS

For example: Imagine that there's some input field for users to enter in keywords that will help them find posts relevant to what they're looking for. No validation takes place, so if somebody enters JavaScript code instead, this gets sent back displayed by the webserver.

This means that visitors get to see it themselves when visiting your page. Though this would never happen during normal because browsers won't execute scripts from other sites!

In the example above, if someone visited a page with the keyword "javascript: alert('test')," this would be executed in their browser. This results in them seeing an alert pop up below it which says test.

The second form of XSS is when you can use redirects instead of sending users wherever you want. One can require that they click on something first before being sent there.

If your site uses any URL system where keywords are automatically changed into links (and these get clicked by visitors), then this could work perfectly for sending people onto your malicious content rather than what they were originally looking for too!

Is Reflected XSS More Common Than Stored?

It's not always easy for visitors to launch reflected XSS attacks on websites.  This doesn't mean that it isn't the most common form of cross-site scripting!

This is because sites can be made up of multiple pages. This is all interconnected with one another. So when somebody gets sent somewhere depending on what they requested, you could get situations where the malicious code ends up being executed unintentionally.

Some examples include:

Sending people onto an eCommerce store where prices change after a certain period (like every day). If you were selling something like socks and had these sorted by color, somebody could request a red pair. This would get redirected to the dedicated page for black socks instead.

Any comment system where visitors can submit their own content doesn't go through moderation first!

For example, if someone could post JavaScript code onto your site, this would run whenever people visited that specific thread if they were authenticated users too (as long as their account hasn't been deleted).

How Can I Prevent This From Happening?

There are several different ways to prevent reflected XSS from being an issue on your website. One of the most common ones is by only allowing trusted sources into forms and similar places so that these cannot be edited or changed.

Also, remember not to use GET requests for anything. This changes data (like deleting an account).

Always make sure to use POST instead. The former can be bookmarked and directly linked to, while this isn't possible with the latter! Furthermore, you should always make sure to validate data before it is sent back and stored.

If you're looking for a free method, then this could be done by checking if the provided values are of valid types (like integers or strings) using JavaScript. There might also be tools available that can help with preventing XSS from being an issue too!

Prevention is the cure. We cannot stress enough the importance of testing your systems in advance and discovering the vulnerabilities as soon as possible. If you can do this, you will be able to prevent the majority of attacks from happening.

How Can I Test for It?

If you want to test your website to find out if it's susceptible or not, then there are a few different options available. However, one of these includes using Burp Suite by PortSwigger Web Security!

The only real downside here is that you'll need some proxy extension into your browser to intercept traffic sent between them both when testing. Another option would be installing OWASP Zap on Kali Linux, as this already comes complete with everything needed to test for reflected XSS.

In conclusion, if your site uses GET requests, reflected XSS will likely be an issue. These are becoming more commonplace as time goes on!

If you're able to prevent visitors from being redirected elsewhere using malicious code (like JavaScript), then this should help with keeping everybody safe online while also not losing out on potential customers either.

Out of all three types of cross-site scripting vulnerabilities I've mentioned here today, reflected XSS is definitely the most common one. This gets exploited by hackers due to its simplicity when compared to other methods available.

By following some tips above, though, you should be able to reduce the chances of this ever happening on your website. That's only a good thing!

How Can I Protect Myself?

The best thing you can do to protect yourself against reflected XSS vulnerabilities then is by using a good web application firewall (WAF). This scan all requests switching between different places for any malicious code inserted.

This way, nobody can attack you without being detected first! However, if this isn't possible, make sure to use data validation before accepting anything from users. This is especially true they're going through forms on your site!

Even something as simple as ensuring that somebody entered a valid URL could help block some of these attacks from ever getting started. Always remember that prevention is a lot better than cure!

Furthermore, always make sure that you're using the latest version of PHP before continuing with any development work. This is because older versions are definitely more susceptible to reflected XSS vulnerabilities than newer ones.

And lastly, if your website uses GET requests for anything that changes data (like deleting an account), it's best not to bookmark or direct link to them so easily either!

Once again, remember that prevention is a lot better than cure and should be used whenever possible to reduce risks as much as possible!

What to Do After a Reflected XSS Breach

As always, prevention is better than cure. But what exactly should you do if somebody does manage to exploit this type of vulnerability on your website then?

This could include anything from stealing customer details or defacing the homepage with something malicious if that happens! Well, there are a few things that one can do to resolve any issues. Firstly, it's worth checking for any signs of infection (like rogue JavaScript files) using grep or another command-line tool like find.

You might not notice anything at first glance, though, so make sure to check every javascript file, too, by opening them up one by one and rerunning the same command just in case. Alternatively, if you're using a WAF, this should automatically block any requests going through that contain malicious code.

If not, though? Then it's worth looking into the source of where that came from and removing them once found. It can be used to prevent access entirely until resolved!

You might also want to check for compromised passwords if your website uses password-based authentication to log in. This way, nobody will ever get past what was used before, so make sure they reset these as soon as possible instead of afterward, too!

Your Site Protected

In the end, reflected XSS vulnerabilities can be a big problem for any website out there. However, that doesn't mean you need to sit back and watch it happen either!

Now that you know what is reflected XSS (cross site scripting), make sure to follow all of these tips above to protect yourself against them.

If you're interested in foolproofing your business against XSS attacks, you will need to use a vulnerability scanner. Fortunately, you're in luck. At SecPoint, we provide a great tool to help you discover all of your present XSS issues.

So get in touch with us now, and we will happily accommodate your pressing security needs.


Pricing Click Here ->

Buy from a VAR or VAD Click Here ->

Get a Free Vulnerability Scan Click Here ->


Ingenco2 Trustmark SecPoint Trustpilot Emaerket