Hacker News Reader

Comment by pelasaco | Hacker News Reader

I worked in a finance institute, when I was responsible for the mainframe and mainframe security. I was 24, and I was surrounded by senior engineers, already over their 50s. I had to go back home, back to my father, to ask for help. He is still today teaching COBOL in the university. Was a pleasure to learn this language that to me was a kind of "Cucumber" from the 60s. However, looking into the details of the whole workflow from COBOL applications, I wasn't that happy looking from the security point of view. The code and solutions predates any security best practices that we have today.

View on HN

In what way does the security best practices of the programming language are different?

(I've worked at a security related startup that worked with mainframes which used cobol... The security practices of the runtime do not seem to me less advanced than what we do in other languages.)

cobol (on mainframes, no clue if this applies elsewhere) is more than just a langauge, its a whole stack and set of tools for writing terminal UI programs basically that take inputs and do a lot of processing based on said inputs. You can easily run into cobol code that assumes (rightfully so in most cases) that people will be nice and not do bad inputs or try to do the equivalent of sqli. the attitude around safe and secure code just wasnt there when a lot of the cobol codebases ive ran into were initially written

That doesn't match my experience.

Over half of the code I worked with was input validation (format validity, value plausibility, authorisations).

Most of the rest was post-facto batch checks for the same sorts of things, except more.

Any CRUD code base that has been in use for a while is mostly this kind of thing.

exactly at least until 2000s, there was no secure copy, but anonymous ftp or reading password from a plain text. Processed data was being pushed to some public areas from where other job would read it..A nightmare.. but worked.

AFAIK, there is a little database embedded in COBOL, known as ISAM.

I don't think there are any SQL-style grant/revoke directives within COBOL, and mainframe developers in decades past likely did not spend too much time worrying about system security when the best I/O was a dialup modem.

And now we attach this old code to the internet.

https://en.wikipedia.org/wiki/ISAM

> AFAIK, there is a little database embedded in COBOL, known as ISAM.

That is not a COBOL feature, it's a operating system level feature. IBM System/390 and newer store data in a indexed, record-based manner.

> I don't think there are any SQL-style grant/revoke directives within COBOL

I don't think there are any SQL-style grant/revoke directives within any language that is not SQL, Ada or Rust.

To be fair, code dealing with grant/revoke should be done in migrations, not in the application code. If application code can do SQL grant/revokes by itself you have bigger issues anyways.

Reply on news.ycombinator.com