Do you know if a website has any malicious scripts that could harm you or other users when visiting it? If you’re not sure, then continue reading to find out how to test XSS vulnerability online.
Cross Site Scripting (XSS) attacks occur when malicious scripts are injected into otherwise unsuspicious and trusted websites. According to OWASP, an online community dedicated to web application security, XSS attacks consistently rate as one of the Top 10 Most Critical Web Application Security Risks.
What is Cross Site Scripting?
Basically, an attacker injects malicious code – usually in the form of a browser side script – onto the page of a website that will be executed on the computers of other users who subsequently open this page.
The end users’ browser automatically assumes the script can be trusted and so will execute the script. This is a problem because XSS can be used to acquire authorization credentials of a user and their extended rights to a web application.
When malicious JavaScript code is executed within a web browser, it has access to multiple objects and functions that cybercriminals can leverage to cause problems for unsuspecting users. For example:
- HTML5 APIs to access the webcam, microphone, geolocation, and specific files from the victim’s device. If combined with social engineering tactics, cybercriminals can trick users into agreeing to their demands.
- Access to cookies that store session tokens. If a user’s session token is stolen, attackers can impersonate that user.
- The capability to send unlimited types of HTTP requests to virtually any destination. This provides attackers with various methods and tools to commit additional malicious acts.
Types of XSS Attacks
Most XSS attacks go undetected, but experts have been able to discern a few types. We break down the 4 sub-classes of XSS attacks. Some bear similarities to one another, but they each have distinct attack vectors.
Reflected XSS
An internet user may experience this type of XSS attack when they make a site request and the web server sends back an invalid response to the user’s browser. This could be injected code that is “reflected” off the web server, such as in an error message or any other response that includes some or all of the input sent to the server as part of the request.
This is usually the first sign of a reflected XSS attack and it is only active during that specific request. The next step requires the attacker to follow up with a means of distribution, such as an email message or link to a malicious site, to trick the unsuspecting victim.
If the targeted user can be convinced to click on a malicious link or submit a specially crafted form, the injected code travels back to the vulnerable website, giving the attacker control over the content of that page the user was visiting. The user’s browser will execute this code because it is automatically assumed it came from a “trusted” server.
Stored XSS
Known also as persistent XSS, this type of vulnerability is encountered when suspicious or unverified user input is stored on a target server. To get users to view malicious content implanted via this method, attackers will target common website features such as message forums or comment fields.
For example, publicly visible profile pages like those found on social media sites are a desirable target for a stored XSS attack. The attacker enters malicious scripts in the profile boxes, and when other users visit the profile, their browser will execute the code automatically.
What makes this type of XSS vulnerability quite difficult to detect compared to other ones is that the attacker’s input can be saved by the server and is only executed after a long period of time when a user visits the affected feature(s). The payload can stay hidden for hours, days, or even weeks until it is executed.
Blind XSS
Blind XSS attacks are actually a variant of stored XSS. The only difference is that they occur when the attacker’s input is saved by the server and executed in a part of the targeted web application or in another application entirely.
For example, an attacker injects a malicious code into a contact/feedback page, and when the application’s administrator is reviewing the feedback entries, the payload will be executed. It’s even possible for the malicious code to be executed in a completely different application (ex. an internal application where the administrator reviews the site’s access logs).
There are so many vulnerable web applications and pages where blind XSS attacks can occur:
- Contact/feedback pages
- Log viewers
- Exception handlers
- Chat applications/forums
- Customer ticket applications
- Web application firewalls
DOM-based XSS
DOM (Document Object Model) is a browser’s data set and contains data that has been inputted by the user (i.e., name, address or other information) among other things.
When a user connects to a website, their browser will generate some of the code that it will execute. Essentially the representation of a website within a browser, the data within the DOM is used by the browser to generate said code.
In a DOM-based XSS attack, malicious scripts are injected directly into the DOM itself and the browser’s environment is modified in such a way that it results in the creation and execution of malicious code. This attack targets the inability of vulnerable sites to ensure JavaScript already working on the page is legitimate.
The Impact of XSS Attacks
When attackers successfully exploit XSS vulnerabilities on websites, they can gain access to users’ account credentials. This can cause a variety of problems for end users that can range in severity. Anybody that uses the aforementioned XSS attack methods can perform malicious actions, such as:
- Hijack an account using the user’s session cookie
- Disclose and steal end user files
- Redirect users to a malicious page or site
- Install Trojan horse programs
- Modify content on the page or site
- Spread web worms
- Access browser history and clipboard contents
- Control the browser remotely
- Scan and exploit intranet appliances and applications
Use A Security Scanner to Test XSS Vulnerability Online
Whether it’s at the vulnerability level or at the actual attack level, organizations cannot ignore the constant threat of XSS attacks. The signs of XSS vulnerabilities in web code have already been determined, but unless you’re an expert in web application security, you’ll need a way to easily test XSS vulnerability online.
Fortunately, there are some FREE online penetration testing tools that have the necessary capabilities to do just that. One of the tools you can use to test XSS vulnerability online is Scantric.io’s XSS Vulnerability Scanner.
All you need to do is copy and paste the URL link into the blank field after the page loads. Then, choose to run either a Quick Scan or a Full Scan. The difference between both types of scans is that Quick Scan takes only a few minutes or hours, whereas Full Scan may take 1-2 days to complete.
If Full Scan is chosen, the scanner will perform a very detailed analysis, so you will not only discover any existing XSS vulnerabilities but also other possible threats to your website. Depending on the scale of your website, it can take a lot of time to scan the entire website and prepare this comprehensive document.
Having received your report, if there are any issues, you can then get in touch with Primary Guard for assistance with a ready-made solution to eliminate these errors in your website’s code.