funkatron.com

ONLamp.com: Securing Web Services with mod_security

On the front page of ONLamp.com, this article has the tag line “Protect your applications without recoding them.” In principle and practice, I strongly disagree with this statement.

I love mod_security. It’s a fabulous tool. But it should never be used as your only line of defense against malicious input. It’s a bad, bad, bad idea to put all your security eggs in one basket, simply because if we’ve learned anything in the past 50 years of computing, it’s that everything is flawed, and people can and will find and exploit that flaw.

Proper security is a multilayered, multi-approach thing. And I think the author is doing a real disservice to those who are trying to educate the development community about secure practices with statements like:

Solutions can take many different forms, ranging from secure coding practices to proper input validation. One approach is to perform content validation for each incoming request and compare it with predefined rules.

No, no, no! Solutions (plural) is just plain wrong. The solution (singular) is to implement all of these approaches. To not do so is either naive (if you’re relying on something someone else developed), arrogant (if you’re relying on something you developed), and in either case very dangerous.

Ethical Hacking and Computer Forensics - ” Secret Service hacker, how did he do it?” (thanks Clint)

Interesting piece that starts off talking about the guy who had broken into a number of T-Mobile accounts, and how he may have done it. The author tests a number of basic code injection attacks, and finds that even after the fact, T-Mobile has left numerous holes in their system:

To further corraborate that Nick used a web application hack, most likely SQL Injection (a little research shows that the T-Mobile site uses IIS/ASP/SQL Server, which happens to be the easiest and most well documented platform for SQL Injection attacks), we can check out the website and try to put some invalid input into the T-Mobile login page. I was very surprised with the results, we can still put all sorts of crazy input into the login page! It is still vulnerable, even after one of the largest, most well known, and high profile hacks in the last couple of years!

Perplexing and sad that a company with the resources — and recent embarassment — of T-Mobile apparently can’t or won’t address basic web app security.

A parent’s primer to computer slang

It’s important to remember that the leetspeek community encourages new forms and awards individual creativity, resulting in a dynamic written language that eludes conformity or consistency. However, there are a few standard terms. The following is a sample of key words that haven’t changed fundamentally (although variations occur) since the invention of leetspeek. The first series is of particular concern, as their use could be an indicator that your teenager is involved in the theft of intellectual property, particularly licensed software.

The Seattle Times: Business & Technology: Study finds Windows more secure than Linux

Ford said the idea was to represent what an average system administrator may do, as opposed to a “wizard” who could take extra steps to provide plenty of security on a Linux setup, for instance.

Actually, this doesn’t entirely surpise me. The key here is “average system administrator,” and believe me, what passes for a sysadmin these days is often pretty scary. Windows’ ease of use certainly is going to benefit folks like this.

I’d be very curious to see a similar comparison between OS X Server and the other two, as (to simplify matters way too much) OS X would seem bring the best of both worlds.

Chris Shiflett: More on Filtering Input and Escaping Output

I found this post quite educational, especially about what items in the various superglobals ($_GET, $_POST, $_SERVER, $_COOKIE, $_SESSION) are tainted. Basically, the gist is that $_GET, $_POST, and $_COOKIE are always provided from the user, and therefore have to be considered tainted. $_SESSION is stored by the server, and shouldn’t be tainted if you did your job right (i.e., you didn’t store any tainted data in the session). $_SERVER, though, is more complex, because some of the values in that array come from the web browser, despite the name of the array. Check the comments for more detail.