What is Cross-Site Scripting?

This is the first part of a series of talks given by Veracode co-founder and VP of Research Chris Eng.

In this video Chris explains what Cross-Site Scripting is and how it enables an attacker to inject client-side script into web pages viewed by other users.

We have also transcribed the talk for your convenience:

Cross-Site Scripting (XSS) is a vulnerability that affects web applications and is characterized by an attacker being able to run arbitrary JavaScript code within the browser of the person that they are attacking. In a typical web application, you have a user sending a web request to the server, this request could be anything, sending a form for an example.

The user might submit their first name and last name in the form, the web application then responds with a page containing an echo of what the user submits in the form. This is a common thing for applications to do. The XSS vulnerability occurs if the web application takes potentially dangerous data and echoes that back to the user.

For example, if instead of a first name being entered on the form, a string that contains JavaScript is put in. This will be sent to the web application and the application is going to generate a page that will contain the string of JavaScript instead of a first name. The user’s browser will then see the script tag and will execute that code.

In a real XSS attack the JavaScript might steal a session credential, capture keystrokes or iterate across every form on the page and replace every action to the form so that instead of submitting your user name and password to the real application, the JavaScript causes your user name and password to be sent to the attacker.

The attacker can even make it so that the information gets sent to them first and then to the actual application, so that the user doesn’t know that their data is going somewhere else.

Someone is not going to type the JavaScript string into their browser, the attacker will instead usually send you a link. The link will contain the script that the attacker wants to enter into the form. The attacker then tries to get the user to click on this link. The request will then be submitted to the web application and the user will get back the response that causes the JavaScript to execute.

This link can be sent to somebody in a number of different ways. The attacker could send them an email claiming to be a bank saying that a fraudulent transaction was noticed and that you need to click on the link to login into the bank. If it looks official people will click the link without thinking.

Another way to do this is using a shortened URL. The attacker will send a message such as “Check out this cool new story that I read” with the link. The user will then click on the link to go to what they think is a newspaper site, but in reality this will re-direct you to a URL that contains an attack. With shortened URLs in Twitter and Facebook you can easily fool somebody into clicking on a link. This is one form of a XSS attack called reflected XSS.