Secure coding guides/standards for Cobol programming

Have got some links/guides from BTan previously for OWASP & Java.

Q1:
I'll now need secure programming guides/standards for Cobol (the ones used in IBM mainframes/AS400)
esp those with good practices like:
a) proper input validation (eg: to mitigate against XSS & injections)
b) avoid hardcoding passwords &  IP addresses in the codes
c) enforcing session timeouts (session idle is forced to logout)
d) exceptions handling (so that under exceptions, the program doesn't bomb out, possibly to OS)
e) ...

Q2:
For .Net & Java, we used Fortify to scan the codes;  is there equivalent scannners for Cobol?


========================  Past links I got from EE BTan =====================================

https://www.sans.org/security-resources/posters/securing-web-application-technologies-swat-2014-60

https://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#J2EE_Security_for_Developers

 The most common is use of OWASP recommended ESAPI in various lang for secure coding adopted by organisation practices https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
sunhuxAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
I don't think there is secure coding guide for COBOL in specific - it has been asked by many in the past
I have two thoughts though, first:

1. The ones I viewed in the Java/C/C++ sub-pages were mostly "Best Practices" - and didn't have THAT much to do with Secure - as in Security
2. IBM COBOL - running under AIX, z/OS, IBM i, etc. represents back-end functionality - not directly address-able through hacking techniques like "SQL Injection" (which should be caught by Java, EGL or .NET front-ends

In summary, secure programming concepts and recommendations are language independent. Putting concepts into practice is very much language dependent, and when to employ which practices very much depends on the architecture, design, and interface points of the application itself. Those programmers familiar with Java and/or C and COBOL should be able to apply the examples from Java and/or C to their COBOL programs.
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014509420

Even CERT did not look into this language - https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards

As for the tool you may explore on below (no free scanner)
- Raincode Checker http://www.raincode.com/raincode-checker/raincode-checker-for-cobol/
- SonarQube http://www.sonarsource.com/products/plugins/languages/cobol/
Other more from the list of scanner (Appscan, Fortify, Compuware Topaz) https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

there is some talk on simulation of COBOL control flow but it is more of tracer and suited for logic workflow of the data and control employed in the program, and may be more useful as error and troubleshooting kit. https://www.ibm.com/developerworks/community/blogs/31c890c6-ace1-4eeb-af6b-5950f3a1a5d1/entry/rdz_and_static_control_flow_program_analysis?lang=en
sunhuxAuthor Commented:
Excellent, the sonarsource link has quite an extensive good practice constructs for cobol though nothing mentioned on cross site scripting, injection handlings.

So can we safely say Cobol is not susceptible to  cross site scripting n injection vulnerabilities due to the nature of the language?
btanExec ConsultantCommented:
Partially as SQL injection is still applicable those the XSS is mostly targeting the Web front dealings. Most of the time, Cobol does  only alot of backend processing with SQL  statements. So input validation is still important for Cobol against injection of malicious statement.
PMI ACP® Project Management

Prepare for the PMI Agile Certified Practitioner (PMI-ACP)® exam, which formally recognizes your knowledge of agile principles and your skill with agile techniques.

Member_2_276102Commented:
SQL injection is a "SQL" vulnerability, not "COBOL" as such. Of course, embedded SQL within COBOL is effectively equivalent to SQL embedded in C or Java or javascript or C# or perhaps any other language. That is, coding against the vulnerability employs practically the same methods mostly independent of language. That is, COBOL is not susceptible to SQL injection, but SQL embedded in COBOL is. Whether any such SQL is exposed for external manipulation is questionable.

We might say similar things about XSS depending on how COBOL is involved. It can hardly be considered as any part of "scripting" in the environments that you mentioned, though technical possibilities do exist. It's hard to imagine why anyone would want to go to the effort required given the alternatives. Any examples that I can realistically think of would involve (probably) deliberate coding by a developer at the site. Protection against that should involve fairly standard controls over who installs what.
btanExec ConsultantCommented:
Thks tliotta.

Programming COBOL applications that issue SQL statements should be subjected to injection inputs checks too.
https://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/com.ibm.db2z11.doc.apsg/src/tpc/db2z_sqlstatementscobol.html

In fact there is also instances of COBOL Web Services with the Microsoft SOAP Toolkit. In this sense even Web attacks are possible.
https://supportline.microfocus.com/documentation/books/rd60/dwwkit.htm

The terminology are of concern but the intent through those vectors or carriers are still applicable collectivity. Proper Verification and Validation will be the revelations of how assure the codes are having a reduced attack surface. It really depends ob the nature of the dynamic and static codes in the Cobol driven environment.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
btanExec ConsultantCommented:
thanks for sharing.
Indeed exception handling is part  of coding practices too, there should not be unknown return state in function calls or undetermined values of return values of the parameter pass in to the function etc..Developer hygiene as basic - this is not even secure coding (yet) but guidelines for completeness to address all scenarios during interaction and exchanges of the program flow. Control flow checks are critical and form the major focus for capturing deviated unlegit behaviours in the program during its execution.
sunhuxAuthor Commented:
One last query (hopefully):
does Cobol call Java or .Net  (just like Cobol call SQL) ?
btanExec ConsultantCommented:
Treat Cobol as a object oriented language. It will normally call Java or. NET objects or vice versa - Not only one way call from Cobol only.
Java is supported through a Java domain in Object COBOL. The Java domain enables you to declare Java classes inside a COBOL program. You can then send messages to the Java classes. You can also send messages from Java classes to COBOL
https://supportline.microfocus.com/documentation/books/nx31sp1/opjafc.htm
This article explores calling a standard procedural based COBOL program from C#. It also provides an example of calling an object oriented COBOL class from C#
http://www.c-sharpcorner.com/UploadFile/RSM50/calling-cobol-from-C-Sharp/
Member_2_276102Commented:
Your original question referred to "IBM mainframes/AS400" and your latest comment asks about "Java or .Net". Since .Net and Java are very different with very different interfaces and can run on very different platforms (Java runs on "IBM mainframes/AS400" but .Net doesn't), it's not clear what your latest question is asking.

For example, for "AS400" COBOL calling Java, you might review Calling Java Methods from a COBOL Program. But that's all about "JNI" rather than "RMI", so it takes some work to bridge the gap. And it doesn't do much for COBOL calling .Net; for that you might need to look into cross-platform technologies (I'm far from experienced in calling .Net from that direction).
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Mainframe Languages

From novice to tech pro — start learning today.