Itschak Mugzach wrote:
I am looking for some rules of Thumb regarding what is improper to code in a
program (say Cobol, but in general, any language) from security point of
view. Are there any resources on that any where? Some examples:
- Do nit use literals of variables containing Account numbers, SSNs, Etc. in
your program.
- Use pure programming (impure is a program that modifies it self)
Any other ideas?
Although I instinctively understand the 1st one, I'm having problems
understanding the second one.
What are the security implications of self modifying code (then again,
it's hard to actually define "self modifying code").
I understand that Virii, Annelids & Western Anatolian equines are
species that sometimes do that, but does it mean that all programs that
do so have malevolent intents or present a security risk ?
Then again, depending on the scope of the 'self modifying' definition,
it is very common use.. An operating system may alter portions of
storage through I/O operations and then eventually alter (runtime
link/edit) that storage area before transferring control to it.. A java
program doing some reflection may load an arbitrary class from within
that same program and again transfer control to it.. Even something as
common as a 'bootstrap' or IPL program has to do that.
However, here is my little catalog of 'bad practice' security wise
(these are not really mainframe specific though !)
- Assuming externally acquired data is safe, correct and reasonable
- Using fixed buffer sizes with no boundary checking
- Relying on obfuscation to implement security features
- Leaving debugging back doors/test admin credentials
- Logging too much information about incorrect credentials (ex: logging
user name for an unknown user.. oops.. he typed his password instead of
his user name !)
- Relying on obscure and undocumented API behavior (it WILL change
eventually.. And when it happens.. buffer overflows & whatnot will happen !)
- Assuming you can be lax because you are protected by a 3rd party
protection mechanism (which never fails.. right ?)
- Assuming in-storage data is private (of course, you will need to have
sensitive data in storage at one time or another.. just discard/wipe it
ASAP when you're done with it)
- Generally, assuming a client will behave
- Not testing for errors and ignoring exceptions
- Giving too much authorization to a program because it is more practical
There are probably 100s more.. but that are the one that I could think
of at this moment.
--Ivan
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
