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
- Relevance: Very High
- Impact: Severe
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:
- .Net based web applications: *.config files (especially web.config)
- WordPress: wp_config.php
- Joomla!: configuration.php
- Drupal: settings.php
You might also want to consider the following two scenarios that fall under the same category:
- You generate reports into separate files, which your clients can download from the web site. If your web application generates these reports with the predictable or easy to guess names and fails to correctly limit access to this information then an attacker can download reports that belong to other clients of yours.
- A jobseeker applies for a job and the uploaded resume is temporarily stored in a location that is accessible from the outside (e.g. /upload/temp/CVs). In this case an attacker can potentially download all resumes stored in this location.
There are 2 common weaknesses exploited here:
- Predictable or easy to guess path to a sensitive resource on the web site
- Files stored inside the web site directory structure (hence accessible from the outside) and a lack of access controls
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:
- Query string parameters (GET request)
- Form field values (POST request) including hidden fields
- Cookies
- HTTP headers
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:
http://yourrecruitmentwebsite.com/getResume.asp?resumeID=123456
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:
http://yourrecruitmentwebsite.com/getFile.asp?fileName=MonthlyReport.pdf
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...
http://yourrecruitmentwebsite.com/getFile.asp?fileName=MyVerySecretConfigFile.config
or source code of a web page..
http://yourrecruitmentwebsite.com/getFile.asp?fileName=getFile.asp
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:
- Checking the “parent paths” option (which is disabled by default in IIS6) – ideally it should remain disabled
- Keep webroot on a different drive from the OS files. E.g. if Windows is installed on C: then have webroot on D:
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:
- Can still be accessed by anyone http://yourrecruitmentwebsite.com/oldpage.php
- Is never going to be tested by QA again (because it is not part of the site anymore from the functional perspective!)
- Is still known to the search engines
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.
- A similar process exists for database objects (tables, stored procedures) by using SQL server usage statistics to identify potential candidates for removal.
- Deploy to production systems and monitor the system behaviour (e.g. missing files)
Questions to ask:
- Do we store backups inside the web site root? Consider relocating these backups to a different directory not accessible via the web site.
- Are there any *.bak, *.old files on the web site? Why?
- Have we secured our configuration files? Use examples from section 2 (e.g. http://yourrecruitmentwebsite.com/web.config). You should NOT be able to see the contents of these files.
- Have we taken specific measures to prevent tampering with the web request parameters?
- Do we use sequential IDs as object references?
- Do we have proper authorisation checks in place?
- As a bare minimum select a few critical pages and try modifying data submitted via GET (in URL) and POST (form field values) methods.
- Do we have Parent Paths enabled? Is our webroot located on a different drive from OS files?
- How do we deal with the old code that is no longer used?
- Does it stay on the web server?
- Is there a process to remove this code from the web server and source control?
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:
- A victim needs to be logged in to your web site (or have an auto-login feature enabled)
- A victim visits a web site controlled by an attacker
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 we employ any anti-CSRF defences (e.g. anti-forgery tokens, adding per session nonce etc)? If not the probability is quite high that the site is vulnerable to CSRF.
- 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()
- Do we have any XSS (cross-site scripting) vulnerabilities? They will allow attackers to defeat some CSRF defences (e.g. read anti-forgery token and use this information to forge a new request)
- Are we running the latest version of a framework? Many popular frameworks have been updated to include anti-CSRF measures – please check release notes.
- Have we performed any penetration testing scans recently to identify CSRF flaws?
- Since GET requests (parameters passed in the URL string) are the easiest targets – can we consider switching to POST instead?
- 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.