Recruitment Directory's Blog - Australia's #1 Recruitment Technology Blog!
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 ManagementRelevance: 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: http://www.recruitmentdirectory.com.au/Blog/owasp-top-10-and-your-recruitment-website-part-1-a390.html
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 
Hide Comments (2)
Back to Menu
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.