–

The issue

In a nutshell: a typical API request, with data returned as “js”, the job publisher’s email address is revealed, as well as the secret “auth” hash used for editing/deleting jobs (without an account). A typical API request:
/api/api.php?action=getJobs&type=0&category=0&count=5&random=1&days_behind=100&response=js
e.g. http://www.jobberbase.com/api/api.php?action=getJobs&type=0&category=0&count=5&random=1&days_behind=100&response=js

Inside the jobs array/JSON, you’ll see that each job has 2 fields that shouldn’t be there: auth and poster_email.
*auth* is the auth string used in URLs for editing and deactivating job ads.
*poster_email* is the actual email address of the advertiser.

Bad.

The fix

In your _includes/class.Job.php:

a) Search for method ApiGetJobs. On line 501, there should be a while-loop after the big SELECT for jobs. Replace the contents in that while-loop with:
$current_job = new Job($row['id']);
$job = $current_job->GetInfo();
unset($job['poster_email']);
unset($job['auth']);
$jobs[] = $job;

b) Do the same for method ApiGetJobsByCompany (while-loop should be on line 541 after you made the change on 2a).

====

We’re sorry for not picking this up earlier and we hope your site wasn’t affected in any way by this breach.

If you have any further questions about this issue or other security concerns, please don’t hesitate to write back!

–

Hi guys,

We discovered a potential security breach in the jobberBase codebase, which would allow an attacker to mess with the database.

This affects versions 1.9, 1.8 and possibly 1.7.

Therefore, if you run a jobberBase site, we ask that you send us an email to hello@jobberbase.com, tell us your site’s URL and prove that you own it. Then, we’ll tell you what the problem is and offer you several ways to fix it.

We’ve chosen to tackle this problem like this because it’s quite sensitive — a public announcement of the issue could have negative effects on jobberBase-powered sites.

Thank you for your understanding!

Well, I’ve created a page that displays some useful overall information about the site.
Assuming your URL is http://localhost/jobberbase/, the stats can be accessed at http://localhost/jobberbase/stats/.

You probably don’t want other people to see them, so you might want to protect the page somehow. On jobber.ro, I use an extra param (/stats/EXTRA_PARAM/) based on which I perform a basic authentication (if EXTRA_PARAM exists, display page). :p

What stats are available?

• A list of the latest job applications + total no. of apps + maximum apps per day, in the past 30 days + average apps per day, in the past 30 days.
• List of performed searches on the site + total no. of searches + max searches per day in the past 30 days + avg apps per day in the past 30 days.

On jobber.ro we also track the site widgets, like this:
Whenever someone clicks on a job ad she sees on a 3rd party site (that displays the jobber site widget), we save the referrer. This way, we know EXACTLY how many people actually used the site widget and how popular it is on their sites .

Metrics is always good!
Enjoy!

Default maintenance

For now, what the maintenance script does is delete temporary and inactive job ads.

What else can you do

The standard job-board behavior is to allow an ad to be active for a number of days (30, for most of them). If you wish to implement this in your jobberBase-based site, you could use the cron_maintenance.php to deactivate older ads and/or notify publishers with 2-3 days before this deactivation…

I’m guessing that an OPTIMIZE TABLE jobs; would also be useful, from time to time .

RewriteEngine on
Options +FollowSymlinks

ErrorDocument 404 /page-unavailable/

Additionally, I’ve added a htaccess.txt file in the distribution, so you can rename it into .htaccess.

Does this work for you?
Do you have a special environment that needed extra tweaking? Would you like to share?

So let me draw it for you:

And this is what it means:

1. You post a job ad.
2. The system checks if there are any other ads you’ve previously posted with the same e-mail address.
3. If there aren’t any, your ad goes into “pending” mode and the administrator receives an e-mail with this new ad. He has to manually activate it, in order for the ad to be published.
4. If, however, your address is found in the database, this new ad will be published instantly.

I chose this solution because it was very fast to implement and it still is very efficient. Most database administration operations are done directly in phpmyadmin, but others (activate/edit/deactivate) from the e-mails jobberBase sends to the admin.

However, the system is pretty flexible once you get the hang of it.

Have fun!