|
|
Re: SANS Compiles Top 25 Most Dangerous Programming Errors
|
Posted: Jan 15, 2009 6:58 AM
|
|
The errors are due to bad tools, not human stupidity:
* Improper Input Validation
On the UI level, there is no API that automates the editing of the data structures inside programs. The programmer should say "I want to edit this number that has a range from 10 to 20", not "textBox.toString().toInteger()".
On the programming language level, the use of fundamental data types (integers, floats, etc) is wrong. When a function requires a number in range 10..20, it's wrong to use a 32-bit integer or even a byte. But no programming language allows for that.
* Improper Encoding or Escaping of Output
End-to-end encryption is needed for all electronic communications on all protocol levels.
* Failure to Preserve SQL Query Structure (aka 'SQL Injection')
If the edited data were not strings but actual data with a type, then SQL injection would be impossible.
* Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
Also a result of non-encrypted communications.
* Failure to Preserve OS Command Structure (aka 'OS Command Injection')
The security model of existing operating systems is wrong. Just like you don't invite any stranger into your house, but only the ones that you have called, the operating systems should not allow execution of anything unless this anything has been 'invited'.
The security that hardware provides is also wrong: CPUs offer an all-or-nothing security model, i.e. the only security is at the process level. Within a process, there is no security between different components.
* Cleartext Transmission of Sensitive Information
Also a result of non-encrypted communications.
* Cross-Site Request Forgery (CSRF)
Encryption would solve this problem as well.
* Race Condition
The methods of accessing state in a multithreaded environment are not enforced mathematically in programming languages.
State shouldn't be shared between threads or processes, unless there is a logic that is validated as secure by a mathematical model.
* Error Message Information Leak
That's because programming languages do not force the programmer to handle all error cases, and therefore the information from thrown exceptions is sent to the client.
* Failure to Constrain Operations within the Bounds of a Memory Buffer
C and C++ are evil! Not even operating systems should be written in those languages.
There are (or can be) much safer alternatives.
* External Control of Critical State Data
Encryption and a better security model can fix this problem.
* External Control of File Name or Path
Better data input validation and better encryption can fix this problem.
* Untrusted Search Path
Encryption and a better security model can fix this problem.
* Failure to Control Generation of Code (aka 'Code Injection')
A better security model can fix this problem. Attackers may inject any code they like, but it would not do anything harmful.
* Download of Code Without Integrity Check
End-to-end encryption would solve this problem.
* Improper Resource Shutdown or Release
Resources are limited, but tools behave as if resources are unlimited. In most tools, there is no provision for the case when resources are low.
And the problem of error handling is at work here: resource allocation errors are not handled properly, and the tools do not force programmers to handle errors appropriately.
* Improper Initialization
More problems with tools:
1) programming languages allow data to be uninitialized (C/C++).
2) programming languages allow initialization to be skipped when errors happen.
* Incorrect Calculation
More typing and error handling issues.
* Improper Access Control (Authorization)
Bad security model. Capability-based security should be used.
* Use of a Broken or Risky Cryptographic Algorithm
End-to-end encryption would solve this problem: since everything would be encrypted by default, there would be no need to invent encryption.
* Hard-Coded Password
A programming language with a proper type system and a prohibition of hard-coded resources (perhaps enforced externally by a tool) would solve the problem.
* Insecure Permission Assignment for Critical Resource
Bad security model.
* Use of Insufficiently Random Values
Random numbers should be created by hardware random number generators.
Modern computers usually don't come with one.
* Execution with Unnecessary Privileges
Bad security model.
* Client-Side Enforcement of Server-Side Security
Encryption and a better security model can fix this problem.
Conclusion
I do not dismiss entirely current tools (operating systems and programming languages), but they are far from optimal.
All the above faults are the results of lack of proper typing, security model, error handling and communication encryption.
Computers were invented to automate tasks, so why typing, error handling, security and encryption are not fully automated?
Why do we blame the programmers for not doing their job correctly, and not blame the tools? after all, one of the reasons higher level languages were invented is to reduce the error rate of programs written in raw assembly.
We clearly need better tools, and these tools can exist, as research has shown.
I know that, in the end, it's all about economics, and it's not viable to replace everything we have with something new for economic reasons, but we have to ask ourselves:
For how long would we have to put up with billions of dollars of losses just because we can't spend a certainly smaller amount of money to improve our tools?
|
|
Previous Topic
