Demise of BlueSecurity

According the Register, Blue Security has decided to close up shop. http://www.theregister.co.uk/2006/05/17/blue_security_folds/ The problem with Blue Security’s model is that a single attacker with sufficient resources can bring it down. Blue Security had it nearly right – if enough people took the spammers up on their offer to de-list users from spam registries, then the […]

Service Orientated Architecture (SOA) Security

Recently, I’ve been doing a fair amount of work in the SOA area. It’s funny how many folks want to expose ancient code directly to untrusted third parties. All is not well in the SOA space, and it’s important to understand the risk of web service enabling calls to “trusted” systems. That code is generally […]

greebo.net blacklisted by various terrorist organizations

I am pissed. My server has been blacklisted by various spam blacklist sites… because my nameserver (something I do not control) and my netblock is owned by someone the RBLs don’t like. I found out today that our hoster, Quantum Tech, is owned by a convicted spammer. But unless you rub shoulders in the dark […]

PHP Security Architecture: SABSA approach

There are only a few acknowledged industry security architectures. SABSA (best documented in Enterprise Security Architecture by Sherwood, Clark and Lynas) is probably the best known. The various artifacts from this architecture include: Each of these layers needs to be thought about in a considered way: (Business) Drivers Why do you want X / How […]

PHP Security Architecture – Contextual Overview

Overview The problem with PHP is that it has no security architecture. What do I mean by security architecture? A single pervasive vision for security, which will last for approximately five years with little or no design maintenance. A robust security architecture creates a balance between functionality and risk, and ensures that by default, simple […]

PHP Insecurity: Failure of Leadership

About a week or so ago, I wrote to webappsec in response to Yasuo Ohgaki (書かない日記) post about some issues with PHP’s security model. For some time, I’ve been worried about the direction of PHP. As many of you know, I helped write XMB Forum and now help write UltimaBB. XMB in particular is an […]

PHP Insecurity: File handling and remote code execution

One of the reasons that PHP applications feature so prominently on bugtraq is not particularly developer focussed, it is PHP’s fault. Today we look at the top reason: the semi-hidden world of allow_url_fopen, wrappers and pretty much all file orientated functions. The extraordinarily bad decision to make allow_url_fopen the default AND enable a host of functions to automatically “benefit” from these features causes the #1 security defect of 2005 – remote file inclusion. Read on for this rant. Warning – no solutions contained within.

“Enterprise” levels of insecurity

Why is it that “enterprise” applications have the worst security? If VXers researched this area, they could bring corporates all over the world to their knees. Typical mistakes include: clear text management protocols clear text authentication, if performed at all excessive privileges required to do their tasks poorly written and tested – it’s usually trivial […]