Top 25 Most Dangerous Programming Errors

The MITRE Corporation hosts an excellent document, entitled 2009 CWE/SANS Top 25 Most Dangerous Programming Errors, of what they, in collaboration with other organizations in the US and Europe (e.g. SANS Institute, and sponsored by National Cyber Security Division of the U.S. Department of Homeland Security), consider to be the top most dangerous programming errors.

Here's snapshot of its contents:

• Improper Input Validation
• Improper Encoding or Escaping of Output
• Failure to Preserve SQL Query Structure ('SQL Injection')
• Failure to Preserve Web Page Structure ('Cross-site Scripting')
• Failure to Preserve OS Command Structure ('OS Command Injection')
• Cleartext Transmission of Sensitive Information
• Cross-Site Request Forgery (CSRF)
• Race Condition
• Error Message Information Leak
• Failure to Constrain Operations within the Bounds of a Memory Buffer
• External Control of Critical State Data
• External Control of File Name or Path
• Untrusted Search Path
• Failure to Control Generation of Code ('Code Injection')
• Download of Code Without Integrity Check
• Improper Resource Shutdown or Release
• Improper Initialization
• Incorrect Calculation
• Improper Access Control (Authorization)
• Use of a Broken or Risky Cryptographic Algorithm
• Hard-Coded Password
• Incorrect Permission Assignment for Critical Resource
• Use of Insufficiently Random Values
• Execution with Unnecessary Privileges
• Client-Side Enforcement of Server-Side Security

Enable Firefox to Open Local Files Linked From an Intranet Website

Often an Intranet website will have links that reference files (such as Word documents, PDFs, Excel spreed sheets) located on mapped network drives (such as file://N:/share/myword.doc). In Internet Explorer, clicking on such links will download the referenced file to the client and open it. Unfortunately, this does not work in Firefox without some manual configuration. My understanding is Firefox has disabled this feature by default to prevent malicious web sites from trying to link to and open files in your local directories (a security policy that Internet Explorer choose to ignore).

You can configure Firefox to download and open files linked from explicitly specified websites to the client's local drive (and mapped drives) by adding the following to the file user.js (create this file if it doesn't exist) in Firefox's profile directory (which should be something like: C:\Documents and Settings\Caleb\Application Data\Mozilla\Firefox\Profiles\abcde123.default, where abcde123 could be any sequence of characters):

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites",
   "http://web.intranet.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled",
   "allAccess");

You can specify more than one web site by separating each address with a space. For example, to add both http://web.intranet.com and http://web, use:

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites",
   "http://web.intranet.com http://web");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled",
   "allAccess");

I'm using Firefox 3.0, but I believe the above is true for all versions of Firefox greater than 1.5.

Website SSL Certificates

Understanding Web Site Certificates [1] has a nice succinct description of website certificates. In summary, a website certificate is used to identify a secure web site, in the sense that it is a trusted web site (e.g. not a phishing site), and data being transmitted and received to and from your browser is secure (e.g. encrypted using SSL). Trusting a certificate means you are trusting one authority from a list of certificate authorities known by your browser to have verified the web site you are visiting is legitimate and secure. Although rare, this process has been known to fail. Brian Krebs in The New Face of Phishing [2] described a sophisticated phishing scam that used a valid SSL certificate issued by a "trusted" authority. If you visit a website that has a certificate signed by an organization untrusted by your browser or the certificate contains an error (e.g. certificate has expired), the browser displays a dialog prompting you to decide if you want to accept the certificate [1]. Before accepting a certificate, ensure it

• has a valid and trusted issuer, such as Verisign,
• has not expired, and
• has been assigned to the web site organization you are visiting.

If this dialog is not displayed, say because your browser accepts the certificate, you can still manually examine the certificate if you wish. Normally this can be done by clicking on some visual indicator on your browser while you are on the protected site. Don't just assume that because a website is protected by a certificate that site must be legitimate. Some phishing sites have used self-signed certificates to create the illusion of legitimacy [3]. It is the site authors hope the unwary visitor would be tricked into believing that because they have been given a certificate, the site is secure so they can safely submit their personal information. A web site who issues a certificate to itself should always be viewed with some suspicion [4]. Do you need SSL certificates for intranet (internal only) websites? If you are transmitting sensitive information between browsers and servers that some employees should not see (e.g. passwords), then yes. This assumes you believe your employees are malicious enough to start snooping for such confidential information. What about phishing? This may be less of an issue because the phisher would need to know the look and feel of your internal website in order to mimic it convincingly. But if such information can be obtained, then SSL certificates would be useful. References

[1] Mindi McDowell and Matt Lytle, National Cyber Alert System, Cyber Security Tip ST05-010, Understanding Web Site Certificates, Carnegie Mellon University, 2008 [2] Brian Krebs, The New Face of Phishing, The Washing Post, 13 Feb 2006 [3] Bill Brenner, Phishers' latest hook: SSL certificates, The New Sendmail, 27 Sep 2005 [4] Jack Schofield, Website certificates -- don't go there?, 2007

Top 10 Web Application Security Vulnerabilities

If you are developing web applications, and don't know the meaning of and how to prevent the following 10 security threats, OWASP Top 10 is good reading material.

• Cross Site Scripting (XSS)
• Injection Flaws
• Malicious File Execution
• Insecure Direct Object Reference
• Cross Site Request Forgery
• Information Leakage and Improper Error Handling
• Broken Authentication and Session Management
• Insecure Cryptographic Storage
• Insecure Communications
• Failure to Restrict URL Access