security silver bullet

Posted by anton
on Sunday, December 02, 2007

i am still on the lookout for quality podcasts. one of the series i’ve been really enjoying lately is silver bullet security podcast by gary mcgraw.

i am a bit of a fanboy – i’ve got all three of his software security books, and i have been following him for a while – listening to the interviews and reading the articles.

i go through a lot of podcasts on regular basis, and “silver bullet” is one of the most impressive ones. first of all, the sound quality itself is pretty damn good. having suffered through some badly-recorded, non-normalized audio in the past, i am happily listening to articulate, passionate folks that actually sound good. perhaps the sound quality it is due to gary mcgraw’s music career.

secondly, he manages to pull together an impressive array of people that have proven themselves over the years in the field of security. in most cases they’ve been at it for decades, and it shows.

since security is a relatively new field, most of his guests come from different backgrounds, which makes interviews all the more interesting. gary mcgraw himself did his undergrad in philosophy, while his phd was in CS and cognitive science under douglas hofstadter (in fact, gary mcgraw contributed a chapter to Fluid Concepts and Creative Analogies).

having read his books, there is not much new in the podcast, but it really helps to clarify and reinforce the basics as well as acquire the vocabulary to be able to discuss these topics. this is why i am on my second round re-listening to the podcast.

one of the main insights i got from listening to the podcast came from its title. “silver bullet” is the famous essay by brooks where he argues that there are inherent complexities in software development that will not magically disappear by introducing better tools or practices.

security is complex. there are accidental complexities, that could be (and are) addressed – get rid of languages with memory overflow problems, introduce address space layout randomization, use static analysis tools, etc.

at the same time there are inherent, essential complexities to security that will always be in place due to new applications that create new attack vectors simply by the virtue of their functionality.

thus it is logical to see security overlapping with QA (QA being quality assurance as a process, which deals with ensuring that quality happens, as opposed to testing which is simply one aspect of it). given this approach, a lot of things about security fall into place: “security means risk management”, “security is a process, not a product”, “there is not absolute security”, “security faults are quality faults”, “it is harder to build a secure system than to break one”, “one cannot sprinkle some magic security dust at the end of the project”, usefulness of “badness-ometers” as gary calls them, etc (these one-liners have such a nice ring to them and stimulate thinking in the right direction; they are butchering the contents of the books though, so read them for the facts!).

since podcast series are not that technical at all (although most of the participants are quite hardcore hackers), i would wholeheartedly recommend them to the broadest audience.

for fun and profit

Posted by anton
on Thursday, September 27, 2007

if you enjoyed everyone’s favorite upside-down-ternet way of making new friends, this whimsical bit is right up your alley.

it is based on cross-site request forgery (CSRF) attack.

briefly, these are the attacks that trick you into submitting a potentially damaging request to the application you are logged in to. so if you receive an email with a link to, which you press, it will set your google language preferences to irish.

thus you could try to impress those inquisitive souls looking for things on your site with the following apache config directive:

RedirectMatch \.(php|phtml|phps|php3)$

therefore any request to a booby-trapped url on your site (in this case anything that ends in php) would set their google search language to klingon.

(stolen from here)

of course, it does not have to be an explicit server-side redirect – similar behavior can be triggered with javascript, iframes, etc.

how do you protect from it? the app has to use unique tokens in the form presented to the user (or one can start lugging around those encrypted URLs again – anyone remembers IBM’s Net.Commerce?)

since i am (somewhat reluctantly and half-asleep) reading gibson’s latest, and since these days i mostly appreciate him for sensing the zeitgeist and popularizing new art forms, i cannot shake off the feeling that there is an art piece lurking in here.