3 ms·

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 afra

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 6y ago
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 6y ago
  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.

3 ms·

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 afra

by t0astbread 6y ago

lucb1e 6y ago
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 6y ago
  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.