FurHire - Second Order SQLi
FurHire is back with an pretty difficult lab, second order sqli is our hint.
I ended up reading some writeups from other people before I actually cracked this one. Although it was a though one, I learned a lot!
Our journey begins at posting a job. When we give the title a value of valid SQL syntax, and apply on a job, the applicant is shown.

But if the jobtitle were to be test2' or 1=2-- - , there are no candidates loaded, even though I'm sure my test client applied for this job!

So this is a big tell that there is something fishy going on.
And here is where the writeups from others came into play, I was able to proof SQLi, but had no real impact. Let alone find that damned flag!
With 'or(SELECT 1 FROM config)-- - and seeing results, I proofed that there was a config table.
With ' OR EXISTS(SELECT 1 FROM config WHERE key='flag')-- - I was able to proof that there was a flag key inside that table.
And with ' UNION SELECT * FROM (SELECT value FROM config WHERE key='flag') JOIN (SELECT 2) JOIN (SELECT 3) JOIN (SELECT 4) JOIN (SELECT 5) JOIN (SELECT 6) JOIN (SELECT 7) JOIN (SELECT 8) JOIN (SELECT 9) JOIN (SELECT 10) JOIN (SELECT 11) JOIN (SELECT 12) JOIN (SELECT 13) JOIN (SELECT 14) JOIN (SELECT 15)-- - I got a payload that would retrieve the flag.
I submitted the job listing, applied to it with my user account, went back to my hiring profile and inspected the /api/job/:id/applicants request.

And luckily, I found my flag there 🇧🇪
Proofing SQLi and actually doing something meaningful are two completely different things! Blind SQLi is something I need to practice on!
Last updated