OWASP Top 10 and your Recruitment Website - Part 2

Posted By: Dmitry Kulshitsky, 4:37pm Thursday 09 December 2010

In part 1 of this series we started a conversation about the OWASP Top 10 most prevalent security vulnerabilities and how relevant these issues were to a typical recruitment web site. In the 2nd part we will review the next 2 items from this list.

A4 - Insecure Direct Object References
Insecure Direct Object References are third (after cross-site scripting and injections) in our series of security risks for the recruitment websites.

As the name implies an attacker tries to directly reference (or access) some kind of object on the web site. In this context ”object” means a resource (e.g. file, directory, database field etc). The actual weakness here is that a web application doesn’t always perform a check that the attacker is authorised (has permission) to access the requested resource.

The word “direct” is important and is used to highlight the fact that this request is specifically crafted and made “directly” to a resource in question bypassing the normal web application flow.

To make it clearer we will review five examples. Think of them as five different faces of the Insecure Direct Object Reference problem. Some of these examples are real incidents that happened to real companies (or something that we have seen in our logs as failed attempts) while others are more theoretical in their nature (“what can happen”) and may or may not be relevant to your particular situation.

1. Direct access to a database or a database backup

There was a real incident documented as WHID 2000-2: IKEA exposes customer information on catalog site

The Error message revealed a database file location, which could be downloaded.

If a database (or its backup!) is accessible via the web server (or FTP) then attackers don’t even need to ‘hack’ the web site to get to your data. Instead they can just download the database and have access to ALL your information at once including passwords, resumes, client details and anything else that is stored there.

A similar issue that has been recently disclosed, allows attackers to quickly work out the directory and file name of the WordPress database backup.

2. Access to a sensitive file on a web server

Some files may contain sensitive information and should not be freely accessible by anyone who visits your web site. Make sure these files are protected and cannot be viewed by directly requesting them from the web site:
You might also want to consider the following two scenarios that fall under the same category:
There are 2 common weaknesses exploited here:

3. Tampering with the web request parameters

This is quite a popular attack judging by what we see in SEEK logs. This is a simple attack that targets business logic of your web application. Reliance on untrusted input is one of the security sins. Attackers can tamper with any information supplied by the client back to the web site including:
Pay special attention to any sequential IDs that you use in your system (e.g. UserID, ClientID, SessionID, ResumeID, CoverLetterID, ApplicationID, EmailID etc) – they are easy targets!

In its simplest form this attack will look like this: Let’s say your recruitment web site allows jobseekers to download their resumes stored in the system via a URL like this:


An attacker can modify the value of the resumeID parameter (123456 -> 123457) to try to download someone else’s resume. This process can be automated to iterate through a large range of IDs to download all available resumes.

If your web site allows downloading files like this:


It is potentially risky to allow direct referencing of a file by its name. It might be possible for an attacker to supply a different file name to download a sensitive configuration file...


or source code of a web page..


The best defence against this type of attacks is to reference files by unique IDs (even better – GUIDs) and perform a lookup for the corresponding file name on the server side.

4. A directory traversal attack

It happens when an attacker tries to access system files by attempting to navigate outside of the web site root:

http://yourrecruitmentwebsite.com/../../../../../ etc/passwd
http://yourrecruitmentwebsite.com/../../../../../ system32/cmd.exe

Also see Apache Tomcat directory traversal vulnerability

For a Windows/IIS based web site I would recommend:

5. Old code left on the web site

Although it might not be 100% correct but I would still classify this scenario as an Insecure Direct Object Reference. Imagine a situation when a functionality provided by the oldpage.php has been migrated to another page called newpage.php. The big question is: what happens to the oldpage.php! Old content implies the existence of files that:
Removing old content from your web site should become part of your maintenance routine.  Web logs parsing, data aggregation and analysis steps allow a site owner to see which pages have not been requested from the web site for a given period of time. These are good candidates for removal.
Questions to ask:

A5 – Cross-Site Request Forgery (CSRF)

Relevance: Low-Medium
Impact: Moderate

CSRF is a relatively new issue. And yet the majority of the web sites are vulnerable. I set relevance for the recruitment web sites to “Low-Medium” purely because there are juicier targets (banking sites, online auctions, booking systems). But don’t underestimate it either. This “sleeping giant” can cause a lot of damage – like stealing or modifying your clients’ data, deleting resumes or posted jobs, sending your candidates offensive e-mails or e-mails containing viruses etc.

For the CSRF attack to be successful we need 2 things:
In this case, when a victim loads a page from an attacker’s web site, this page can make hidden requests to your recruitment web site. These requests (since the victim is logged in!) will be executed as part of the victim’s session on your web site under this user’s identity.
How do attackers do that? In its simplest form it can either be an IMG tag or an IFRAME embedded in the attacker’s web page:

<IMG SRC=”http://yourrecruitmentwebsite.com/Account/DeleteUserAccount.php”>

<IFRAME SRC=http://yourrecruitmentwebsite.com/PostNewJob.aspx?Title=Eviltext&JobAdText=Eviltext2>

It can also be a link that a victim needs to click:

<A HREF=”http://yourrecruitmentwebsite.com/EditAccount/[email protected]>OMG! Dancing pigs!</A>

Multi-step operations or submitting forms (POST request) can be easily achieved by a simple JavaScript code on the attacker’s web page.

Questions to ask:
- Do not rely on the referrer header – it can be spoofed!
- ASP.Net – consider adding SessionID into the ViewState.
- ASP.Net MVC - consider using Html.AntiForgeryToken() - This is NOT a fix, but it will make it slightly more difficult for a hacker to mount such attack. Focus on pages that perform sensitive operations.

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