Top 25 Software Security Errors

Experts from a coalition of over 30 US and international cyber security organizations jointly released a list of the top 25 programming errors that lead to the majority of security bugs plaguging the software industry. According to the SANS institute in Maryland, just two of these led to more than 1.5 million website breaches last year.

The top programming errors are listed below with a brief summary - well worth having a check to ensure you're aware of what to look out for in your current software projects!

Insecure Interaction Between Components

• CWE-20: Improper Input Validation. Ensure your input conforms to expectations - if you're expecting an integer, you'd better make sure it's an integer!
• CWE-116: Improper Encoding or Escaping of Output. This is at the root of all injection based attacks. Make sure you can seperate your data from your commands.
• CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection'). Ensure you're using parameterised SQL queries so attackers can't modify your queries to steal data, destory it or bypass your authentication checks.
• CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting'). Watch out for routes where attackers can inject Javascript (or other executable code) into a page that you generate. There are multiple possible attack vectors here, including JSON requests and failing to check for script tags in user-generated content.
• CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection'). If you're feeding parameters into OS-level commands, be sure you can trust the inputs you're passing it.
• CWE-319: Cleartext Transmission of Sensitive Information. Sending sensitive information (such as authentication credentials) in cleartext, if an attacker controls a single node between you and the final destination, they can simply observe the data in transit.
• CWE-352: Cross-Site Request Forgery (CSRF). A HTTP request that is sent to your site that looks like it came from a user (possibly authenticated!) rather than the attacker.
• CWE-362: Race Condition. If an attacker can obtain full control over a single process, they can exploit race conditions to cause chaos resulting in denial of service or corruption of data.
• CWE-209: Error Message Information Leak. Be wary of what information you offer to users when something goes wrong - they could reveal a wide range of valuable data for attackers.

Risky Resource Management

• CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer. A source of many high-profile vulnerabilities, generally affecting non-managed languages such as C - involving failures to check that data can fit within the memory buffer allocated. But don't think you're safe with your cozy higher-level languages. What do you think your OS runs on?
• CWE-642: External Control of Critical State Data. If you store your user state data in a place an attacker can modify, you open up another area for attack - this is open by default when using HTTP as an attacker has full control over the inputs being sent to your application.
• CWE-73: External Control of File Name or Path. Using an outsider's input while constructing a filename could result in an attacker reaching outside your expected directories and enable them to read files (or possibly perform other operations) you had no intention of making available.
• CWE-426: Untrusted Search Path. If a path where your application could load resources or assemblies from is compromised, the attacker could point it to resources of their own choosing.
• CWE-94: Failure to Control Generation of Code (aka 'Code Injection'). If external inputs drive the code that gets executed, or are fed directly into the code itself this can become a serious vulnerability.
• CWE-494: Download of Code Without Integrity Check. Any code you download could have been modified before it reaches you if it's integrity hasn't been verified. Just because you trust the source of the application doesn't mean it's safe.
• CWE-404: Improper Resource Shutdown or Release. Ensure you properly dispose of your resources after use so attackers cannot maintain control of these after you've finished with them.
• CWE-665: Improper Initialization. If you don't initialize your data, your attacker might be able to!
• CWE-682: Incorrect Calculation. Math errors when attackers can control inputs to your calculations could result in divide-by-zero exceptions or breaking business logic (such as negative prices).

Porous Defenses

• CWE-285: Improper Access Control (Authorization). ensure your software's users are only doing what they're allowed to.
• CWE-327: Use of a Broken or Risky Cryptographic Algorithm. Cryptography is hard. Don't attempt it. Use a well known algorithm that's currently considered strong, and a widely used implementation.
• CWE-259: Hard-Coded Password. If a hard-coded password is ever revealed, then any customer or website using that code is instantly vulnerable - and because it's hard coded, a huge effort to fix.
• CWE-732: Insecure Permission Assignment for Critical Resource. Beware of default permissions on your data or configuration files that make your resources accessible to the world.
• CWE-330: Use of Insufficiently Random Values. Ensure your random values (such as those being used for session identifiers or temporary files) are genuinely random. Attackers could guess the next random number often enough to launch a successful attack after a relatively small number of tries.
• CWE-250: Execution with Unnecessary Privileges. Whenever your application runs with elevated privileges, attackers could potentially exploit these - so hang on to them for as little as possible.
• CWE-602: Client-Side Enforcement of Server-Side Security. Don't ever rely on client-side validation of inputs. HTTP requests can be easily faked and client-side code modified. Always validate your inputs on the server.