Hunting begins

To first understand and get to know all the features and services being offered, I signed up on recruiterbox.com and started exploring their features and functionalities while inserting payloads at every possible place. That’s how every attacker starts, I believe.

Impressive, Escaping HTML entities at every possible place I’ve tried. Good job peeps.

Without wasting much time, I realized that even if there is any part vulnerable to cross-site scripting, it would allow only recruiters to attack each other. Not interesting, right ? How cool it would be if a user applying for a job can insert payload in his personal details. I gave it a try with no luck.

Wait.

There was something interesting which got my attention while looking at the “Apply for this position” with an option to upload a resume. File Upload is something which interests the security researchers the most.

And more importantly, I can upload a resume in HTML. That’s gonna be interesting.

Let’s try to inject some scripts.

The script tag got removed. Well done, Devs.

Now, let’s try to put the script tag inside the body, other than the head.

No, it’s not working.

Okay, How about this :

…Is it a bird, is it a plane? Bingo. It’s XSS.

When I try to view my resume in the dashboard, both the payloads got executed.

How to Exploit ?

This way an attacker can upload a malicious resume and try to inject script in the recruiter’s browser to perform a malicious action.

I created an exploit which changes my job application status from “Rejected” to “Hired” and thus, I’d be able to land a job in any company.

Sounds so cool, But a real attacker would add himself as an admin to the company’s recruitment program using this vulnerability and then can do any harmful action.

Recruitebox fixed this vulnerability using Iframe’s sandbox attribute.

I demonstrated this vulnerability during my talk at JSChannel Conference’16 with the help of an intercepting Proxy, Burp Suite.

In my preparation for the talk, I found out that the fix deployed was broken again with improper usage of the sandbox. “allow-scripts” was being used which broke the initial fix and was vulnerable once again.