Udooz!

Sans Institute, the largest information security firm in association with software and security giants including Microsoft, Symantec, McAfee, published a hot 25 programming errors under three categories:

• Insecure interaction between components (9)
• Risky resource management (9)
• Porous defenses (7)

Insecure interaction between components

1. CWE-20: Improper Input Validation
2. CWE-116: Improper Encoding or Escaping of Output
3. CWE-89: Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)
4. CWE-79: Failure to Preserve Web Page Structure (aka ‘Cross-site Scripting’)
5. CWE-78: Failure to Preserve OS Command Structure (aka ‘OS Command Injection’)
6. CWE-319: Cleartext Transmission of Sensitive Information
7. CWE-352: Cross-Site Request Forgery (CSRF)
8. CWE-362: Race Condition
9. CWE-209: Error Message Information Leak

Risky resource management

1. CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
2. CWE-642: External Control of Critical State Data
3. CWE-73: External Control of File Name or Path
4. CWE-426: Untrusted Search Path
5. CWE-94: Failure to Control Generation of Code (aka ‘Code Injection’)
6. CWE-494: Download of Code Without Integrity Check
7. CWE-404: Improper Resource Shutdown or Release
8. CWE-665: Improper Initialization
9. CWE-682: Incorrect Calculation

Porous defenses

1. CWE-285: Improper Access Control (Authorization)
2. CWE-259: Hard-Coded Password
3. CWE-732: Insecure Permission Assignment for Critical Resource
4. CWE-330: Use of Insufficiently Random Values
5. CWE-250: Execution with Unnecessary Privileges
6. CWE-602: Client-Side Enforcement of Server-Side Security

Our responsibility is to literate these top 25 errors to your colleagues, friends and follow these guidelines during your product development.

More details about the list, visit here.

Design by contract is a popular approach to designing software. This approach prescribes the software designers should define formal verifications, specification of every components in an application. These verifications and specifications should answer the following questions:

1. What does it expect?
2. What does it guarantee?
3. What does it maintain?

These can be achieved by contracts or assertion which can consumed at method level. These contracts normally contains:

• Acceptable inputs for an operation (method/procedure)
• Pre and Post-conditions
• Return value
• Exceptions
• Side effects
• Invariants (for sub-classes may strengthen)

To use this approach in .NET, Microsoft Research Lab released “Code Contracts” for .NET.

There are three components available in this release. These are:

• Contract Framework APIs
• Binary Rewriter
• Static Checker

The first two are for runtime checking.

Contract Framework APIs
Contract.Requires() – Pre condition
Contract.Ensures() – Post condition (additional helper methods: Contract.OldValue(), Contract.Result())
Contract.Invariant() – Invariants
ContractInvariantMethodAttribute – Method level attribute, so that we can put all invariant objects into a method.

Binary Rewriter
Normal IL code for the above mentioned APIs cannot be executed at runtime. To provide runtime checking for contracts, you have to use binary rewriter which takes the IL and transforms the contracts so that contracts are executed at the exact programming points.

Get a copy of CodeContract here and user manual here.