Opencats Applicant Tracking System | Hacker News Reader

Opencats Applicant Tracking System

opencats.org

26 pointsbrudgers16 comments

I hate to judge a project by the technology choices but no SSL on the landing page and PHP is just the tip of the iceberg here.

- Every table uses MyISAM. Interesting choice, but maybe the fancy features of InnoDB aren't really needed.

- HTML in the database for storing page templates. The entire workflow in terms of HTML views of the application process are stored in the database. That's got to be rough to maintain. https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca...

- Uses mcrypt (not for passwords), which is deprecated and also abandonware. https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca...

- Passwords appear to be stored as md5 hashes. https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca...

- Yep, md5. https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca...

and fun XSS vulns https://github.com/opencats/OpenCATS/issues/406

So if you look at the copyright, it was from 2005-2007: [https://github.com/opencats/OpenCATS/blob/develop/constants....]. Maintaining and upgrading PHP from that long ago is a real challenge and typically involves several major rewrites of the core. For anyone reading through the code, this is where a significant portion of the code smell comes from especially since some of the updates were never finished (an example is that namespaces are setup to allow autoloading, but the files I looked at also had include_once in the files). The global $_SESSION['CATS'] is almost certainly from the 2005-2007 era. Then there is the faux security fixes (sprintf'd sql instead of parameterized queries.). FYI, the age of the codebase also explains why they're using MyISAM instead of InnoDB.

This gives me flashbacks of early career codebases. I've seen so many of the mistakes here (including the HTML in the db. God, I remember the original dev being so proud of that mistake. 2 devs working on the same page? Who's going to overwrite the other's html?)

> The global $_SESSION['CATS'] is almost certainly from the 2005-2007 era.

How would you do it nowadays? I still write a lot of small scripts and rarely have more state to maintain for a user session than conveniently fits in PHP's session mechanism. It's usually $_SESSION['loggedin']=bool, ['userid']=x, and perhaps a few convenience fields that are shown on every page to avoid unnecessary database roundtrips like name and anti-csrf token.

It's file-based so it probably doesn't work on multiple servers (I think you can also configure it to be database-backed, but from what I remember that's nearly as much work as just writing a proper solution yourself if you need that sort of scale), but until your software doesn't fit on a single, medium-beefy server anymore, is there an issue with this session global?

(Assuming you don't have a runaway dev that thinks they need to replicate every vaguely user-related field into the session or something. I never saw that, but with php being a common beginner's language, I could see how some people here might have run into that or have a similar argument. I think you'd have issues with such a guy/gal no matter what.)

It's much rarer to see $_SESSION or $_COOKIE nowadays. Most frameworks have session libraries that have some validation checks built in, handle csrf/flash messages and easily plug into backends (being able to have sessions use redis, etc in 2-3 lines of config makes session handling soooo much easier. And you're less likely to run out of disk space :P).

The main issue with $_SESSION was that it is very easy to create a giant multidimensional array and have inconsistent logic creating fields. Another advantage is to bring the session variable in line with that of other languages so that devs switching languages won't be WTF as often

Looks dead, and the code looks.... yeah[1]. Bonus[2]

1. https://github.com/opencats/OpenCATS/blob/develop/lib/Candid...

2. https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca...

  FIXME: Security issue, this function is not enough for sanitizing user input.

Not off to a good start.

Hi y'all. Some of the comments here are mentioning some of the technical issues that this system has.

In addition, the license that it uses has restrictions and is not OSI approved, so some people wouldn't call it Open Source.

Is there demand for an Open Source Applicant Tracking System to be created?

If you would be interested, please comment here: https://github.com/rhc2104/hiringhats/issues/1

PHP and no SSL available on the main site? Pass.

“Working towards full PHP 7 compatibility”

PHP 7.0 was released in December 2015...

While the project's implementation is outdated, it still is easier for brave souls to maintain and extend it than start your own from scratch. The project is on GitHub. The link is on the website.

True, although if I were tasked with inheriting a project like that I'd probably still do a total rewrite with the old code as a basis. I'd just be way too afraid of letting a security issue slip through, especially if I don't have tools to check.

While I generally agree, it might also be worth pausing to think about the threat model before the baby out with the bathwater.

Consider who uses this -- and I don't mean that recruiters have zero technical knowledge (rumor has it that some do) but rather that an applicant will see very little if anything of this. If you test and secure those public fields properly and make sure the rest is behind basic auth with individual user credentials, you probably covered your threat model. XSS/CSRF vulns potentially cause you to lose track of who put that exploit in (one user could have put an exploit in that makes another do something), so you know it was an insider, just not who. Once you have your update management figured out (at least for public systems) and people no longer click attachments to invite ransomware (I have yet to see a single client with these two boxes ticked), rewriting your internal limited-to-recruiters applicant system might be the next thing to tackle.

I strongly disagree. If you miss one meaningful vulnerability (SQL injection seems to be a known issue) and a bad actor takes a crack at it, you've suddenly leaked the PII for hundreds or thousands of individuals. "Limited to recruiters" is easy to say in the abstract—if you're the sort of person who's building off of a piece of software written in "old PHP" that hasn't seen many (any?) meaningful updates in the last decade, you're probably not the sort of person who is up-to-snuff on the right way to secure the application.

How much usage would there be if a simple Open Source ATS were built from scratch? I think it would be a fun project.

Does it create a public url for the job where a non registered user can create an account and apply for a job?

I went though the demo application and it looked like that functionality is not present.

Reply on news.ycombinator.com