Cross Site Scripting (XSS) attacks

How to protect web application from cross site scripting (XSS)

These are a kind of injection, where malicious of scripts are injected into otherwise benign and trusted website. When an attacker uses a web application to send malicious code, generally in the form of a browser side script, to different end user, then cross site scripting attacks occur.With the help of XSS, An attacker can send a malicious script to an unsuspecting user.

How cross site scripting works 

An attacker must first find a way to inject a payload into a web page that the victim visits, in order to run malicious code in a client’s browser.  To convince a user to visit a vulnerable page with an injected JavaScript payload, an attacker could use social engineering techniques. When an XSS attack take place, the vulnerable website needs to directly include user input in its pages. An attacker can then insert a string which will be used within the web page. It treated as code by the victim’s browser.

How to prevent

By injecting client-side script code, cross-site scripting attacks exploit vulnerabilities in web page validation. Failing to property validate input, failing to encode output, and trusting to a data retrieved from a shared database are the common vulnerabilities that make your web applications susceptible to cross-site scripting attacks. To protect your web application against attacks, all input must be malicious. All input must be constrain and validate. Include HTML character and encode all out output. You can read this include data from files and database.

Cross-site scripting attacks exploit vulnerabilities in web page validation by applying its code. The script code is sent back to an unsuspecting user. The browser has no way to identifying that the code is not legitimate because the browser downloads the script code from a trusted site, and Microsoft Internet Explorer security zones does provide any defence. These attacks are also work over http and https connections.

XSS is not the user’s problem

On a web page if an attacker can abuse a XSS vulnerability to execute arbitrary JavaScript in a visitor’s browser, the security of the website and its users has been compromised. Like any other security vulnerability, if affecting your users then it is directly affect you. So, you can say that XSS is not the user’s problem.

The structure of Cross site Scripting attack

There are three actors in XSS – the website, the attacker and the victim. It shall be assumed that attacker’s goal is to impersonate the victim by stealing the victim’s cookie. The attacker controls can be achieved in a verity of ways by sending the cookie to a server.

The following figure illustrates a step-by-step walkthrough of a simple XSS attack.

  • The attacker injects a payload by submitting a vulnerable form with some malicious JavaScript.
  • From the website the victim requests the web page.
  • The website serves the victim’s browser as part of HTML body.
  • Inside the HTML body, the victim’s browser will execute the malicious scripts. It would sand the victim’s cookie to attacker’s server and the attacker now needs to extracts the victim’s cookie. After that, the attacker can use the victim’s stolen cookie for impersonation.

Leave a Reply