January 11th, 2004, 06:59 PM
Auditing security in development
What steps do you generally take when auditing the security for a development project you have?
What about just the source?
Is there a checklist you use of specific steps and if so what is it?
Are there certain areas of functionality you pay more attention to than others?
"When I get a little money I buy books; and if any is left I buy food and clothes." - Erasmus
"There is no programming language, no matter how structured, that will prevent programmers from writing bad programs." - L. Flon
"Mischief my ass, you are an unethical moron." - chsh
Blog of X
January 12th, 2004, 12:26 AM
Personally, I generally do the following AS I'm writing the code as well as afterward:
1. Determine if ANY input whatsoever is being taken blindly. This includes hidden form elements and option button values. Everything should be checked in the action script. Almost all issues with web software are created by improper input validation.
2. Determine if there are any design flaws which might lead to vulnerabilities. Things like race conditions, etc.. These are generally only applicable to software executed in a native environment, but complicated web dev stuff can cause them as well.
3. What steps are taken to ensure security of the data being exchanged in both directions? Ensure that there is no way you could accidentally send data to someone plaintext if you require a secure connection, things like that.
4. For web dev, ensure that acceptable measures are taken to prevent XSS vulnerabilities. There is quite a long list of potential ways XSS could affect your sites/apps, so taking measures to secure pages against these sorts of attacks can only help. A similar suggestion could be made regarding non-web applications as well, ensuring that whatever you use to communicate between two copies of said application is incapable of causing XSS-style vulnerabilities (allowing user access accidentally, etc).
In some languages, you can check for the use of certain functions vs certain other functions. Generally speaking, secure C makes use of strncpy instead of strcpy due tto buffer length checking and so forth.
I personally prefer to deal with user input in terms of security, since that is usually the single largest point of entry in most applications/pages. I'd also list file i/o up there as well, since files can be tampered with on most OSes while in use, so to prevent crashes or exceptions it generally helps.
The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
\"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
Is your whole family retarded, or did they just catch it from you?
January 12th, 2004, 01:23 AM
google around for various "Controls" both physical and logical. they should give you more ideas on what to cover. and put extra attention on Physical coz most people always miss it.
oh and it helps to expect the unimaginable. and also see the environment on what ur project is running on. i.e. the compitency of the people involved.