Select Website 

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

Back to Menu Back to Menu

OWASP Top 10 and your Recruitment Website - Part 1

Posted By: Dmitry Kulshitsky, 8:30am Monday 09 August 2010    Print Article

OWASP has recently updated their list of the top 10 most prevalent security vulnerabilities. Since this list covers all major aspects of computer security it is interesting to check what are the issues that are relevant to a typical recruitment website or job board and (exercising the 80/20 rule) what are the key questions we should ask ourselves (or our IT/security staff) to be sure that we don't miss anything critical.

The recommendations below are just for your reference and are not meant to replace a proper security audit process, but they are a good place to start the conversation about the state of security of your website.

A1 – Injection
  • Relevance: High
  • Impact: Severe
The first thing that comes to mind here is SQL injection, which we have covered before. But make no mistake – this class of vulnerabilities includes all types of injections not just SQL (e.g. LDAP, shell command, XPath etc). A typical developer will probably be aware of SQL injections but not about other ones.

OWASP puts injections at the top of the list. Recruitment websites and job boards contain sensitive data (e.g. usernames, passwords, resumes, addresses, phone numbers etc), so it should come as no surprise that the relevance is set to high.

Questions to ask:
  • Do we test our web site for injection flaws as part of the QA process?
  • Have we performed any automated/manual scans recently to identify these flaws?
  • Do we validate data both on client and server sides? Do we check for parameter lengths? Failure to do this will most likely to lead to injection flaws.
  • Do we use dynamic SQL queries? Strongly consider banning them. Use parameterised queries/stored procedures instead.
Quick tests to perform:
  • How does our site handle input from this list?
  • As a bare minimum - how does our site handle input that consists of:
    - a single apostrophe (covering at least the most commonly used enterable fields – e.g. keywords)? Do I get any error messages?
    - a closing bracket: )
  • If your web site uses numeric Job IDs, Resumes IDs, User IDs etc  – what happens if you append an apostrophe to one of these IDs: http://yourrecruitmentwebsite/showjob.php?jobid=123’

A2 – Cross-Site Scripting (XSS)
  • Relevance: High
  • Impact: Moderate
We have covered cross-site scripting (XSS) before. For recruitment websites and job boards there are 2 relevant major issues that may arise:
  1. Stealing cookies – this will allow an attacker to impersonate your clients and login to their accounts
  2. Embedding unauthorised HTML/JavaScript/frames. See previous article on hidden iframe injections
Questions to ask:
  • Do we test our web site for cross-site scripting flaws as part of the QA process?
  • Have we performed any automated/manual scans recently to identify these flaws?
  • Do we validate data both on client and server sides? Do we check for parameter lengths?
Quick test to perform:
  • How does our site handle input from this list?
  • As a bare minimum - how does our site handle this input:
    - a single backslash: \
    - this string: “><script>alert(123);</script>
    - this string: ‘;alert(123);//

A3 – Broken Authentication and Session Management

Relevance: Medium-High
Impact: Usually Severe

A typical recruitment website or job board has a login function for job seekers and advertisers. If authentication and/or session management mechanisms are broken, this could result in attackers getting access to your clients’ accounts.

Questions to ask:
  • Have we implemented our own authentication or session management mechanisms? If you have – you have probably done it wrong.
  • Do we store passwords in clear text? Passwords should be stored in hashed or encrypted format to prevent unauthorised access to password information
  • Do we have a “password reminder” feature? How is it implemented?
  • When a user clicks logout – what happens to the session? Session information should be deleted or rendered not reusable.
  • How does our session ID look like? Do not use consecutive integer values – they are very easy to guess/predict.
  • Have we implemented a session timeout feature? The session should timeout after a certain period of inactivity.
  • How do we send usernames/passwords and authentication cookies? Ideally you should be transferring them via HTTPS (secure communication)
  • Do we use “secure” and “HttpOnly“ flags for session cookies? While not compulsory this is a recommended practice.
  • Do we verify that the user is authenticated and has proper permissions in every step of a multistep process? Failure to do so may allow an attacker to bypass the authorisation mechanisms and access information that belongs to other users or restricted areas of the web site.

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

Article URL:

Article Tags: dmitry kulshitsky security recruitment website job board owasp sql injection xss cross-site scripting broken authentication session management login form design hacking website security user authentication

Comments Hide Comments (2)

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.

 Jim Manico (5:28pm Monday 09 August 2010)

Please note that the primary defensive solution for XSS is output encoding

 DmitryK (6:06pm Monday 09 August 2010)

Jim, you are absolutely right. We've covered this previously in this article: (see the last paragraph there)

Since OWASP Top 10 coverage is so broad, the focus of the current blog post was mainly on what each of the vulnerability classes means *specifically* to a typical recruitment web site and what are the quick questions someone can ask to get an assessment of the "security health" of the web site they own/manage/support (80/20 rule).

Like I said in the intro - this is a very quick test and it should not replace a proper security analysis/penetration testing process. Instead, if you see errors/unexpected behaviour using one of the examples provided or if you ask your IT staff a question and the answer is "We don't know" then I believe this is a good place to start a conversation about the application development processes, security practices etc in this organisation.

Hopefully the readers of this blog will find this information useful. Please share your success stories (without going too much into details) if you can.

Your Name: * Required
Your Email Address: * Required
Website URL:
Comments: * Required
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

From a Harvard Idea to the YouTube of Recruiting
Published: 5:53pm Sunday 18 January 2009

This job has been sourced from...
Published: 9:00am Monday 15 December 2008

Login with LinkedIn buttons
Published: 2:05pm Thursday 29 April 2010

Job contest lets bloggers become pilots
Published: 3:50am Thursday 02 April 2009

Creating an Effective Social Media Strategy, Part 2 - Take Time to Listen, Don’t Just Jump In
Published: 8:00am Tuesday 28 July 2009