Discussions

News: MITRE - List of 2010's Most Dangerous Programming Errors

  1. The Top 25 Most Dangerous Programming Erros list is a tool for education and awareness to help programmers to prevent the kinds of vulnerabilities that plague the software industry, by identifying and avoiding all-too-common mistakes that occur before software is even shipped. Software customers can use the same list to help them to ask for more secure software. Researchers in software security can use the Top 25 to focus on a narrow but important subset of all known security weaknesses. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software. The list is the result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe. It leverages experiences in the development of the SANS Top 20 attack vectors (http://www.sans.org/top20/) and MITRE's Common Weakness Enumeration (CWE) (http://cwe.mitre.org/). MITRE maintains the CWE web site, with the support of the US Department of Homeland Security's National Cyber Security Division, presenting detailed descriptions of the top 25 programming errors along with authoritative guidance for mitigating and avoiding them. The CWE site contains data on more than 800 programming errors, design errors, and architecture errors that can lead to exploitable vulnerabilities. Review the complete list on-line, or download the PDF version.

    Threaded Messages (22)

  2. Quite a few on the list seemed to deal with memory management. Which of the entries are likely to have the greatest impact on a Java application? In particular, I'd guess the majority of us write web-based business applications with modern frameworks. Which items should we be most worried about?
  3. #1 (XSS) is extremely relevant to anyone producing HTML output. Unless you're using a technology like XSLT to generate your HTML, most web frameworks leave it up to you to use the right mechanisms to properly escape your HTML output. For instance, with JSTL you need to use c:out and the like. If you just dump characters that may have come from a client or user at *any* point in their past to the HTML output, you're risking producing an invalid (and improperly rendering) HTML document or a dangerous XSS attack. [With XSLT everything is escaped unless you go out of your way to explicitly disable this. One could thus easily have check-in or build time validation that such escape disabling is not done in any of one's XSLT and thus be sure everything is properly escaped. Of course XSLT has other shortcomings...]
  4. Quite a few on the list seemed to deal with memory management. Which of the entries are likely to have the greatest impact on a Java application? In particular, I'd guess the majority of us write web-based business applications with modern frameworks. Which items should we be most worried about?
    I you aren't using it already, I strongly suggest getting findbugs. It's far more useful than just looking at a list of bad practices. On a side note, findbugs detects a lot problems in most frameworks. For example, JAXB produces code with asymmetrical synchronization. In that case, I'm not sure it matters but don't assume that because you use a framework that you are safe.
  5. In that case, I'm not sure it matters but don't assume that because you use a framework that you are safe.
    I certainly don't think anyone assumes they're fully safe. However, it is my understanding that you would have to go out of your way to make JPA code vulnerable to SQL Injection attacks. It can definitely be done, but only by using it outside of the ways advocated by the documentation. As long as the query gets translated to a JDBC PreparedStatement, I think you're safe from that attack, correct? With details like that in mind, as a Java business developer, I would like to know what I should be worried about for my web-based business applications. We as the Java community should have a list of our own. We all want to write secure code, but translating that list into what's relevant for Java is a significant research task for most of us, as individuals. As a community, it should be easy to divide and conquer.
  6. In that case, I'm not sure it matters but don't assume that because you use a framework that you are safe.


    I certainly don't think anyone assumes they're fully safe. However, it is my understanding that you would have to go out of your way to make JPA code vulnerable to SQL Injection attacks. It can definitely be done, but only by using it outside of the ways advocated by the documentation. As long as the query gets translated to a JDBC PreparedStatement, I think you're safe from that attack, correct?
    Assuming your JDBC driver works properly, I think that's true. You can guarantee the same by simply never building SQL in code. I find that I never really need to and anytime that is done it's not worth it.


    With details like that in mind, as a Java business developer, I would like to know what I should be worried about for my web-based business applications.

    We as the Java community should have a list of our own. We all want to write secure code, but translating that list into what's relevant for Java is a significant research task for most of us, as individuals. As a community, it should be easy to divide and conquer.
    It seemed like a lot of the list didn't apply to Java but I think the XSS as noted above is a big one for web developers.
  7. I realize this may sound ridiculous to those of you who use PreparedStatements as a way of avoiding SQL Injection attacks, but in my consulting experience assisting customers in application security, you would be AMAZED at how frequently a developer uses PreparedStatements "because I'm supposed to" in which they dynamically build the SQL using Strings and then plug it into the PreparedStatement. PreparedStatements ONLY work if all dynamic elements used in the SQL statement are done using the data binding APIs associated with the PreparedStatements. Building a SQL statement dynamically with Strings and then dumping it into a PreparedStatement accomplishes nothing from a security perspective. On a related note, some people replace "PreparedStatement" with "CallableStatement" and insist that Stored Procedures prevent SQL Injection vulnerabilities. They do ... except when the Stored Procedure / Function dynamically builds a SQL statement and then uses EXECUTE IMMEDIATE to perform the operation. Erik Klein Software Security Consultant Fortify Software http://www.fortify.com
  8. Building a SQL statement dynamically with Strings and then dumping it into a PreparedStatement accomplishes nothing from a security perspective.
    I think you are saying just using PreparedStatement instead of Statement won't accomplish anything which is absolutley correct. It will basically just slow things down. If you are using prepared statements properly i.e. using parameters for input, it's possible to build the statement safely as long as the SQL statement is not built from unknown input. I think that distinction needs to be made. It's a lot harder to verify that kind of code is safe (and it's a maintenance nightmare) so I would advocate avoiding any dynamic SQL generation as a general rule.
  9. Yeah, findbugs is awesome.
  10. Most of these[ Go to top ]

    Apart from the memory related ones, all are applicable to Java. So this would be all but CWE-120, CWE-805, CWE-190,CWE-131.
  11. Re: Most of these[ Go to top ]

    Apart from the memory related ones, all are applicable to Java.
    So this would be all but CWE-120, CWE-805, CWE-190,CWE-131.
    I suppose you are right. I guess I see a lot of these as design issues and not coding issues. But yeah, it was a mistake to suggest that it wasn't.
  12. Design issues[ Go to top ]

    Not sure whether these are just design issues. Get yourself a tool such as Fiddler and try to be mischievous. It's amazing what you can do when you break the 'intended' boundaries of your application.
  13. Re: Design issues[ Go to top ]

    Not sure whether these are just design issues.
    Get yourself a tool such as Fiddler and try to be mischievous.
    It's amazing what you can do when you break the 'intended' boundaries of your application.
    What I mean is that a lot of the problems described here should not, in general, be the concern of day-to-day development. These are problems that often need to be resolved at the gateway to the application. For example, if your application is taking request data from unknown sources with an array index as part of the request, that's the issue, not whether you check that index. In general if your messages aren't structured such that there is a clear boundary between the request and its interpretation, you have already screwed the pooch. Trying to protect the system without resolving the larger design issue is a pretty Sisyphean task.
  14. Re: Design issues[ Go to top ]

    Hi James Watson, I agree with you to do security breadth-first. Securing the application boundaries/interfaces first is the way to go. george http://ethicminds.blogspot.com/
  15. Re: Most of these[ Go to top ]

    Apart from the memory related ones, all are applicable to Java.
    So this would be all but CWE-120, CWE-805, CWE-190,CWE-131.
    P.S. I would add CWE-129 to that list. Let me know if you disagree.
  16. Re: Most of these[ Go to top ]

    This one is also questionable: http://cwe.mitre.org/top25/?#CWE-754 I actually disagree at least in part with solution: "If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248)." I actually think that for unexpected conditions, dealing with the exception where it occurred is an anti-pattern. I find it's much better to handle such things in one place near the top of the call so that I can ensure all such conditions are handled. Unchecked exceptions are better for this purpose.
  17. Re: Most of these[ Go to top ]

    This one is also questionable:

    http://cwe.mitre.org/top25/?#CWE-754

    I actually disagree at least in part with solution:

    "If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248)."

    I actually think that for unexpected conditions, dealing with the exception where it occurred is an anti-pattern. I find it's much better to handle such things in one place near the top of the call so that I can ensure all such conditions are handled. Unchecked exceptions are better for this purpose.
    I agree that unforeseen / runtime exceptions should be processed at the application entrypoint ... and this means checking for java.lang.Throwable, nothing else. Everything else checked should generally be a very specific exception.
  18. Re: Most of these[ Go to top ]

    I agree that unforeseen / runtime exceptions should be processed at the application entrypoint ... and this means checking for java.lang.Throwable, nothing else. Everything else checked should generally be a very specific exception.
    To be clear, I include things like a missing configuration file or URL not available to be in the realm of 'unexpected error' even though these situations are not necessarily unlikely. To put it another way, unless you can do something reasonable to continue despite exception, there's little point in catching it. I've seen a lot of code where people try to catch errors, log the error and then let the application continue in an invalid state. This is far worse than letting the exception trickle back up to the top. If a constraint of a transaction has been violated you really can't do anything better than capture/report the failure and abort the transaction. Anything other strategy is incorrect error handling and absolutely insecure. On a side note, my understanding is that catching Throwable (without re-throwing) is not recommended. You will also be catching Error in which case you may not be able execute your error handling safely.
  19. Re: Most of these[ Go to top ]

    129 - Improper Validation of Array Index Maybe not as intended in the issue - but if it returns values based on post values, you could still make the app return data not intended for the user ....
  20. I'm not sure how they align with the list in the article, but I continue to see problems with code making the leap from "single-user-mode" on a developer's desktop to more realistic multi-user testing on a server. It is important to understand that portions of some libraries, such as the JAXB marshaller or even java.text.SimpleDateFormat, are not thread-safe so they either need handwritten synchronization or a new instance needs to be created for each thread. Along these lines, I've seen threading issues introduced in custom code built on dependency injection frameworks. DI frameworks are generally built around the Singleton pattern, but I see a lot of code with request- or user-specific data stored in member variables of types managed by the DI container. Either the types need to be configured as something other than "singleton", or the member variables need be moved to more appropriate types. Joe Parks HyperProductive, LLC Quality. Fast.
  21. I'm not sure how they align with the list in the article, but I continue to see problems with code making the leap from "single-user-mode" on a developer's desktop to more realistic multi-user testing on a server.
    The list contains 'race condition'. Maybe you could argue that this the root of all synchronization issues but it's a subject that warrants its own list. I agree that this is possibly the biggest challenge for Java developers, especially with regard to things like SimpleDateFormat which should be threadsafe but aren't.
  22. It's nice to see that Wicket is listed as helping with the top 2 of the "most dangerous programming errors". For XSS, all user input is escaped by default. And SQL injection if you are using Wicket's stateful nature means instead of seeing ?id=42, you'll get a URL that can't be easily tampered with such as ?wicket:interface=:1::: It doesn't mean a developer can't override these protections and screw it all to hell, but at least the defaults are sensible. Andrew Lombardi Mystic Coders, LLC wicketbyexample.com To our success!
  23. URL Safety[ Go to top ]

    URL that can't be easily tampered with such as ?wicket:interface=:1:::

     

    In a perfect world - perhaps, but when your client is demanding SEO perfect URLs, with no extraneous characters, it's not going to happen.

    Jamie Collins - http://www.nowthatsnew.com