
Opencats Applicant Tracking System - brudgers
http://www.opencats.org/
======
frompdx
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...](https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca93874d02c7288728df0f87/db/cats_schema.sql#L432)

\- Uses mcrypt (not for passwords), which is deprecated and also abandonware.
[https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca...](https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca93874d02c7288728df0f87/lib/Encryption.php#L43)

\- Passwords appear to be stored as md5 hashes.
[https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca...](https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca93874d02c7288728df0f87/lib/Users.php#L840)

\- Yep, md5.
[https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca...](https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca93874d02c7288728df0f87/lib/Users.php#L93)

~~~
randtrain34
and fun XSS vulns
[https://github.com/opencats/OpenCATS/issues/406](https://github.com/opencats/OpenCATS/issues/406)

------
twunde
So if you look at the copyright, it was from 2005-2007:
[[https://github.com/opencats/OpenCATS/blob/develop/constants....](https://github.com/opencats/OpenCATS/blob/develop/constants.php)].
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?)

~~~
lucb1e
> 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.)

~~~
twunde
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

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

1\.
[https://github.com/opencats/OpenCATS/blob/develop/lib/Candid...](https://github.com/opencats/OpenCATS/blob/develop/lib/Candidates.php#L1310)

2\.
[https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca...](https://github.com/opencats/OpenCATS/blob/77c1f2bcf1bc92f4ca93874d02c7288728df0f87/lib/DatabaseConnection.php#L480)

~~~
frompdx

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

Not off to a good start.

------
rhc2104
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](https://github.com/rhc2104/hiringhats/issues/1)

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

~~~
rgj
“Working towards full PHP 7 compatibility”

PHP 7.0 was released in December 2015...

------
loa_in_
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.

~~~
t0astbread
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.

~~~
lucb1e
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.

~~~
bastawhiz
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.

------
ab_testing
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.

