OWASP Top 10 and your Recruitment Website - Part 1

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

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:

Stealing cookies – this will allow an attacker to impersonate your clients and login to their accounts
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.