Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Mon May 11, 2009 9:41 pm Post subject:
The mainframe, at least with standard COBOL and CICS, is not a stack based architecture so if you are thinking about junk like buffer overruns, code injection, cross site scripting and other workstation based nonsense, it probably won't happen in your code. Theoretically I suppose it is possible to exploit problems in runtime modules, authorized code and system level stuff like SVCs and exits but you'd have to work at a system level to write code that vulnerable. I do know of examples where people have written SVCs that exposed fetch protected memory, and I suppose one could modify a return register in a save area to branch to unintended code -- wait -- I've done that so I know it is possible. Just be smart and never write data to a place you do not know has system level security in place (like temp files that aren't RACF protected and automatically scratched, off site FTP or web sites, your local PC, etc). Don't write sensitive data to any logs or debug files (dumps are another matter). Use compiler features like array subscript checking if you can. And never confuse the presumed ignorance of your user with "security" (by that I mean "if he doesn't know about this parameter that
brings down the system, then he can never use it"). For what it is worth, I am guilty of doing several of these exploitable things over the years but never in anything that could be considered a mission critical or secure system. Basically, if you ever get the nagging feeling that something you are working on has some vulnerability, it almost certainly does; find it and fix it or redesign it.
Security exposures your code will face are more likely beyond your control. Unencrypted transmissions, poor firewalls, "social engineering", lost data backups, and bad site and/or data security are more likely to cause problems than bad COBOL coding. If you want to get into data encryption, access authentication, and other traditional security technologies, there are better places to look than a platform specific bulletin board, but most likely your site has whole departments already dedicated to those issues.
If by "online" you mean web based, then you should read as much as you can about how web based applications can be tampered with (scripting tricks, method overriding, spoofing, AJAX, etc), but as the person programming the 'back end' applications, even that stuff is outside of your control. Just be aware of verifying a requester's credentials in any questionable situation IF that is your responsibility. Again, more than likely all of the access controls should already be in place based on the userid assigned to your transactions or programs.
Obviously, I have no idea what I'm talking about, but if you need instruction in data security and potential pitfalls, you should hire some expertise from a security firm or IBM to give you formal instruction. I know IBM has (or at least used to have) people dedicated to helping people avoid security problems in system code and, one would assume, application code. At the very least, contact your system security people, talk with your boss (he or she should thank you for asking!) and find the most experienced people you can in your organization to ask them about horror stories, rumors of past problems, and their own practices. _________________ New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.
If you check out https://www.securecoding.cert.org you will find out secure coding standard for C and Java. Smilarly I need to find secure coding standard for COBOL and use them in my coding. If some one of you have secure coding standard for COBOL please share it with me.
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Tue May 12, 2009 12:58 am Post subject:
Great site. Thanks for that.
I have seen some publications that have similar info for mainframe languages. The security and program loading environment is very different than, say Java but there certainly are concerns analogous to the ClassLoader problems (and similar problems) mentioned. In the MVS case, the system does a very good job of insuring that you can't inject unauthorized code among authorized code, for example, but since your code is probably not going to run authorized it is a good idea to understand the loading process (how load modules are found and loaded).
As for coding techniques like data conversions, initialization, precision loss, immutability and the like, the manuals IBM provided with the compilers, specifically the ones called Programmer's Guide (or similar, as opposed to language reference) often have these kinds of guidelines in them. I don't know exactly where you'd find the broader system or application guidelines such as program search orders, etc, but the authorized assembler services guide used to have a lot of the minutia and some security guidelines.
And of course, most of the rules at the site you pointed us to probably have corresponding rules in any system that just differ based on the language, runtimes or operating system (stuff like conversions or avoiding XML or SQL injection). _________________ New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.
A few things to think about vis-a-vis COBOL / Security:
1) If you feel that there is a need, "obfuscate" your COBOL source by substituting non-intelligible labels for all references, etc. ( note: you can purchase vendor packages to accomplish this ).
2) Unless necessary, do not specify BY REFERENCE, either implicitly or explicitly, on a CALL...USING... statement. This will prevent a CALLED program from obtaining an address in the CALLING program's Working-Storage or Linkage section(s).
3) If necessary, insure that the executable module is placed into a library marked "execute only", to prevent attempts to read the executable module and reverse-engineer it. _________________ A computer once beat me at chess, but it was no match for me at kick boxing.
Joined: 02 Dec 2002 Posts: 151 Topics: 3 Location: Perth, Western Australia
Posted: Mon May 18, 2009 2:52 am Post subject:
All brilliant answers by semigeezer.
I don't think that an LE COBOL program can run authorized. LE is designed for key 8 programs and would choke when initializing the environment. AFAIK, the only way to call an authorized LE program is to use CEEPIPI to create an authorized environment and then jump through lots of hoops. _________________ Dave Crayford
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
