Select Website 

Recruitment Directory's Blog - Australia's #1 Recruitment Technology Blog!

Back to Menu Back to Menu

How secure is your Recruitment website? Part 5 - Cross-site scripting (XSS)

Posted By: Dmitry Kulshitsky, 8:00am Tuesday 30 March 2010    Print Article

According to OWASP, cross-site scripting (XSS) flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

XSS is the most prevalent web application security flaw. But what does it mean? Let’s have a look!


How does it work?


XSS attack involves three parties – the attacker, the victim (client) and the web site. A web site has an XSS flaw when it includes attacker supplied data in a page sent to the victim’s browser without properly validating or escaping that content. Attacker supplied data can be a piece of HTML or JavaScript code (hence – scripting). This code will be embedded into the web page by the vulnerable web application and sent to the victim’s browser.

Please note that the affected web site is NOT hacked as such. None of the web pages were modified by the attacker and all information in your database is still intact. What attacker controls is the content that gets sent back to the victim.


Consider the following scenario


You have a web page that is meant to welcome a logged in user:

http://www.YourRecruitmentWebSite.com/loggedIn.asp?name=Bill

Inside this page you have a piece of code that reads the “name” parameter from the query (URL) string and prints it back to the user:

Welcome, <%=Request.QueryString(“name”)%>

In our case the output that victim’s browser receives will be:

Welcome, Bill

So far, so good...But what will happen if we modify the name parameter to look something like this:

http://www.YourRecruitmentWebSite.com/loggedIn.asp?name=<script>alert(‘xss’);</script>

In this case the output will be:

Welcome, <script>alert(‘xss’);</script>

The victim’s browser would interpret this response as an HTML page containing a piece of JavaScript code. This JavaScript will be executed by the victim’s browser and the victim will see a popup window with the word ‘xss’ in it.

A piece of JavaScript supplied by the attacker was embedded into the web page by the vulnerable web application and sent back to the victim.

This is a cross-site scripting attack in its simplest form.


What is the impact?

An attacker can use XSS to do the following:
  • Deface web sites
  • Insert malicious content
  • Redirect users to other sites
  • Hijack user sessions (by stealing cookies/session information)
The most common method of using XSS involves tricking a victim into opening a maliciously coded page, which uses JavaScript code to open a vulnerable HTML page on the user’s local computer – often located in the directory where cached pages are stored, or perhaps a pop-up window – enabling the script to run commands with the same level of permission as the user. With this type of access, a hacker can easily corrupt a user's data, steal personal information, or take control of the user’s computer

E.g. an attacker can send a phishing e-mail to your clients purporting to be from your company asking them to change their passwords. This e-mail will contain a link to your web site with some extra code that will (by means of XSS) capture user name and password and quietly send it to the attacker’s web site.


Am I vulnerable to XSS?

Information used by your web application can arrive from multiple trusted and untrusted sources:
  • URL (query string) parameters
  • Form fields
  • HTTP headers
  • Cookies
  • Database tables
  • Web services
  • Local and remote files
If you don’t validate user input and don’t encode (‘escape’) output you are most likely vulnerable to XSS.

There are many free and commercial tools available that can assist you in finding XSS problems automatically. You can use a free version of the Acunetix Web Security Scanner can scan your web site for XSS related issues.


How do I prevent XSS?

It is quite easy to prevent XSS issues from happening. All input data has to be verified and validated to be safe. Output needs to be properly encoded (‘escaped’) before it is included in the resulting output.

Escaping is the primary means to make sure that untrusted data can't be used to convey an injection attack. There is no harm in escaping data properly - it will still render in the browser properly. Escaping simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.

Don’t reinvent the wheel. All major platforms have standard security libraries that you should use. E.g. if your web site is Microsoft .Net based then consider using Microsoft AntiXSS library.

Guest blog post by Dmitry Kulshitsky, Security Architect at SEEK.






Article URL: http://www.recruitmentdirectory.com.au/Blog/how-secure-is-your-recruitment-website-part-5-cross-site-scripting-xss-a346.html

Article Tags: cross site scripting xss insecure recruitment websites job board security how secure is your recruitment website defacement dmitry kulshitsky untrusted data

Comments Hide Comments (0)

Feel free to join in on the conversation. All comments are moderated before publishing. Comments posted by subscribers don't necessarily reflect the views of Recruitment Directory.

Your Name: * Required
Your Email Address: * Required
Website URL:
Comments: * Required
Refresh
Enter the code you see in the image above (case sensitive). Click on the image to refresh it.
 


Back to Menu Back to Menu



Random Blog Articles

CareerOne and the cookie monster
Published: 7:30am Friday 25 March 2011

SEEK increases job advert expiry to 45 days
Published: 5:34pm Sunday 17 May 2009

MyCareer OTP Advertising
Published: 8:26pm Monday 15 June 2009

SEEK mobile
Published: 5:47pm Sunday 31 October 2010

I don't care that you have more LinkedIn connections than me. You can buy them for $5
Published: 3:23pm Monday 16 April 2012