They are not allowed to!

Maybe some of you have read RSnakes blog item about these Google files that were discovered and open to the public some days ago. I don't want to talk about that issue now but let me quote one statement of RSnake:

"Google has a responsibility to be better about this than most people. Why? Because they have more market share. The cannot mess up. They don’t have the right to.

If some tiny mom and pop web-store has this issue it’s bad. If Google has it, it could affect hundreds of millions of people. Sorry, that’s just not allowed."

Exactly that is what I thought a lot of recently. Big sites accountability to it's users. I'm certainly not an anti Google zealot as RSnake is but this is worth a thought anyway.

Now lets go back to security. As a matter of fact, Googles whole security model is based on not finding a single XSS vulnerability. Their Single Sign On implementation can be fully compromised by only one insufficiently sanitized input field. Thats why those guys are so fast in fixing such vulns as soon as any are disclosed. So one may assume that they are aware of the great danger.

Back in October 2006, Google bought YouTube. Pretty much the biggest social networking site with millions of users every day. Everyone is allowed to upload videos, to build groups and to have a public viewable profile.

YouTube in fact enjoys a very good reputation from the open public, except of a few copyright issues that occur from time to time but that's actually of no real significance.

Another popular social networing site is MySpace. In October 2005, the latter was infected by the Samy Worm, which became the first major web worm based on XSS vulnerabilities for it's propagation. Samy altered over a million of MySpace user profiles in one single night.

Unlike other types of worms, these web worms propagate on condition that a user interacts with them. So if a user opens an infected page, the worm will propagate and infect another page. That means to more users the exploited platform has, the better the worm will work. It grows exponentially.

Given that, Social Networking sites seem to be the best target due to their high traffic.

Now what would you think would run through all kind if media if such a worm was released on YouTube and not only infected the users profiles but also steal their login credentials plus those that they use to login at Googles services? That is all trivial work for a well versed attacker.

Trust me I am not kidding, that could happen any day and surely will if YouTube developers don't change the way they treat security. While researching, I identified dozens of vulnerabilities. Due to the high amount, I neither counted them nor did I prepare PoC's but it was about 20 to 25 reflective and around 10 persistent XSS vulnerabilities. Additionally it appears that CSRF is a foreign word to them.

I informed them about it but actually I do not expect an answer. Apparently they didn't learn anything from Samy.

Anyway, if that happened one day, THEN we would have a real problem.

Complexity vs. Security

Yesterday, Ronald van den Heetkamp wrote a blog entry entitled "Simplicity" in which he points out that in the long run applications can only stay secure if they keep a certain degree of simplicity because developers would otherwise loose sight the more the complexity of an application grows.

I think on that matter Ronald is perfectly right but now the remaining question is how code can be kept simple and secure in a Web 2.0 world where new technologies, ideas and features become public on a regulary basis. I do not think we can achieve security by simplicity in the sense of removing unnecessary technology. Thats what Ronald essentially means in the very beginning when he talks about application darwinism.

In my view that comparison is somehow flawed because as far as technology is concerned we will probably never experience a decline. It is rather the opposite.

So, I personally see the future for both simplicity and security only in frameworks. When using such, most software developers intention might be to have a well designed, well performing and well working application. However at the same time applications are likely to become much more secure since development frameworks we have today pay more and more attention on that.

For instance as a PHP developer working with the Zend Framework it becomes very easy and comfortable to prevent most common vulnerabilities such as Cross Site Scripting, SQL Injection or Remote File Inclusion.

Consider this as my two cents. I see Jeremiah Grossman having had the same thought back in 2006 and I would like to finish with his words:

When developers find that its WAY easier and WAY better to do RIGHT by security, then we'll get somewhere.

Fun with GMX Mail Service

When I came back home today and looked through the news, I stumbled over an entry on heise security dealing with a security issue on GMX. I had a lot of fun reading it.

The posting essentially claimed that a severe security issue has been discovered which allowed access to anyones opened mailaccount if the session_id gets copied from the URL of one browser and pasted into a different.

Ehm, does that writer have a clue about what a session actually is? I guess not.

Anyway, as far as security is concerned, it is a bad idea to use GMX mail service though since there are dozens of XSS vulnerabilites on their sites. For example here, here or here.

So please, if you want to use free mail service, how about switching to gmail?

Holes in most strip_tags() filters

This is actually nothing really new but it seems that there is a common misunderstanding of PHP's strip_tags() function.

A lot of developers rely on this function to protect their applications against Cross Site Scripting attacks. They especially like it because of it's second parameter allowable_tags, apparently without knowing what it actually does.

As even highlighted in the PHP manual, this function does not modify any attributes on the tags that you allow using allowable_tags, including the style and onmouseover attributes that a mischievous user may abuse when posting text that will be shown to other users.

That means when using strip_tags() in combination with it's second parameter, which is often done to allow harmless appearing tags like <*i>, <*b>, <*a> and so forth, every kind of protection simply gets lost.

One can inject arbitrary Javascript code using the style attribute plus -moz-binding in Firefox and color:expression in Internet Explorer.

Therefore I recommend to use htmlspecialchars($var, ENT_QUOTES, $charset) only.

The real effectiveness of current WAF

While thinking about the recently discussed PHP IDS and other similar Web application firewalls (WAF) like mod_security or mod_parmguard, it seemed to me that quite a lot of people aren't aware of how effective such solutions in fact are.

Basically I agree that diffrent layers of protection is always a good idea to get at least close to a status that can considered to be secure. That's why people even started thinking about WAF. Nevertheless these solutions are actually doomed to fail by design, or to phrase it more precisely they are simply not suitable for every underlying scripting language, e.g. Perl, Ruby, PHP - whatsoever.

The reason lies in the way they parse incoming HTTP requests. Although the latter might be conform to RFC defined standards, it is in fact different from the way HTTP parsers work in application / scripting languages. Because of these differences it's quite easy for an attacker to sniff malicious variables through a WAF like lets say mod_security. An example has been provided by Stefan Esser during the MOPB.

So unless a Web application firewall is implemented exclusively for a specific language, it is very likely to be insecure and therefore using them should be well considered.

PHP based Intrusion Detection System

During the last few weeks a friend of mine and myself spent some time working on a PHP based Web application IDS, which essentially is designed to be an additional layer of protection for any website it is used on.

It's not officially published yet since we're still changing some parts but I'd like to hear other peoples opinion on this prior contributing it to PEAR, which is what we are intending to do in near future. You will find the project including a Subversion repository temporarily on http://code.google.com/p/phpids/

The detection system is pretty simple and based on a set of various upgradeable regular expressions that will be cross-checked against any variable passed to the systems main class, named IDS_Monitor. In addition we provide an easy extendable logging mechanism that allows storing detected results in files, sending them via email and things like that.

Here's an example of use:

<*?php

try {
$storage = new Filter_Storage();
$storage->getFilterFromXML('phpids/default_filter.xml');

$get = new IDS_Monitor($_GET, $storage);
$result = $get->run();

// display results
print_r($result);


//Or store the data using IDS_Log_Composite and
// Log_File
require_once('phpids/log/log_file.php');
require_once('phpids/log/log_composite.php');

$compositeLog = new IDS_Log_Composite();
$compositeLog->addLogger(
Log_File::getInstance('results.txt')
);

if (!empty($result)) {
$compositeLog->execute($result);
}

} catch (Exception $e) {
printf(
'An error occured: %s',
$e->getMessage()
);
}

?*>

Obviously the effectiveness of the IDS is dependent on the quality of patterns that are used, therefore the system is supplied with a bunch of default patterns, mainly written by .mario who is one of the versed people dealing with filtering I've ever met. Moreover to mention is Ronald (better known as Jungsonn), who also shared his thoughts and expertise. Thank you.

So I think very most XSS and SQL injection vectors (being trivial or advanced) should be covered.

Are there any comments or suggestions?