Giblets aren’t just the disgusting parts of the turkey, the foul (or fowl if you are no stranger to puns) organs that your grandma likes to try to fool you into eating for her own perverse amusement. In certain parlance they also refer to the external code that your applications is dependent on- source code for which you have little or no control. Giblets are typically libraries, assemblies, jars, or other such modules that a third party, whether it is an external company (for example, the excellent looking Elegant Ribbon), another internal team, a vendor, etc. wrote. They are also a huge security concern as you usually have little insight into what security was incorporated in the giblets’ development cycle, nor a great deal of control when vulnerabilities are discovered in the giblet. You can make your own code rock solid, but still find your application exploited because of Giblet code. MS Office has been hit by this a number of times, as legacy and third party file filters continue to be vulnerable despite the dramatic re-engineering of the Office file formats (.docx, .xlsx, etc) with security in mind.

Recently my colleagues and I have been playing around with several different HTML Encoders in Java. Despite what OWASP has posted on the subject for an international enterprise it is not as simple as encoding everything that isn’t A-Z,a-z,0-9 (though I don’t think OWASP is making any claim at the robustness of their recommendation). Having all of your Chinese radicals all of a sudden converted to full character encoded values is going to dramatically increase page size, especially on anything like a blog or other large text field with copious blocks of user input that gets echoed to the screen. Most people don’t want to figure out how to implement their own character set aware, internationalized Entity Encoder, and so naturally prefer to use canned solutions. The desire to use a canned library is by no means unique to HTML Entity Encoding; for any number of functions this makes sense, since many functions take specific expertise (do you think your average PHP programmer wants to worry about image manipulation implementations for example). However in this specific case it easily demonstrates why Giblets are a big fat bag of security suck. What happens when there is a flaw in the Encoder giblet? You really don’t know what the inside of it looks like- you don’t know how well written it is. You trust that it works, but if your output encoder isn’t encoding all output properly your defense against XSS is now vulnerable.

Really any giblet that processes or transforms external data is a point of concern. To some extent open source giblets can be better, as you can at least look inside and see how well written something is (though I suspect that the number of people who do so are probably in the minority), but for enterprises this can actually be a liability, as legal departments worry about license compliance and IP taint. For all other Giblets, there are a couple of recommendations to make you safer -

1) Ask for details about the Giblet Developer’s secure development lifecycle, vulnerability history, mean time to patch, and other useful behavioral questions about their security posture. It might be worth going with a giblet that has a bit less functionality if the security posture of the developers seems higher.

2) External, Vendor, or Internal, get an SLA in place that clearly defines obligations. Include obligations to patch vulnerabilities of various criticality ratings, time frames for said patches, agreed upon criticality scales (do you consider SQLi to be critical while they think it high?), and maintenance length (if a vulnerability is found five years after you purchased the giblet, are you out of luck getting a fix). This is often overlooked when working with internally developed code from other teams; however just as with external developers your security vulnerability may not be the internal teams priority. You need a commitment to address vulnerabilities in a timely fashion.

For non-commercial giblets, especially open source, you probably won’t get an SLA, so explore the ramifications and practicality of fixing the flaw yourself (see afore mentioned worry about license compliance and IP Taint). Non-commercial, non open source giblets (freeware) are very dangerous as you have no assurance concerning timely fixes, nor the capacity to fix them yourself.

3) Try to validate/sanitize all data before passing it to a giblet anyway, even if the Giblet developer has a great security posture and a very aggressive SLA. An added layer of defense is never a bad thing.

4) If the Giblet is consumed by a client, make sure any agreement with the Giblet developer includes the rights to distribute updated versions to the client.

Most importantly though, just keep in mind that third party code is a risk. Security should be as much a consideration as features when incorporating third party code and all of the security effort you put in may be for naught if your 3rd party code is vulnerable. When I draw threat models I like to label Giblets as External Entities even if they are processes or libraries consumed on the same box, as I have no control over them. It just helps to draw out the ramifications of their use.

~ Joshbw