<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel>
		<title>a guide to secure TYPO3 hosting</title>
		<link>http://secure.t3sec.info/</link>
	<description>Latest information on TYPO3 Security</description><language>en-en</language><generator>Blog RSS export running on TYPO3 CMS</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><copyright>2010 TYPO3 Security</copyright><managingEditor>marcus#exp2010@t3sec.info</managingEditor><webMaster>marcus#exp2010@t3sec.info</webMaster><image>
		<title>a guide to secure TYPO3 hosting</title>
		<url>http://secure.t3sec.info//typo3conf/ext/t3blog/icons/rss.png</url>
		<link>http://secure.t3sec.info/</link>
	<description>Latest information on TYPO3 Security</description></image><item>
	<title>TYPO3-SA-2010-020</title>
	<author>marcus#exp2010@t3sec.info (Marcus)</author>
	<link>http://secure.t3sec.info/blog/post/2010/10/05/typo3-sa-2010-020/</link>
<guid>http://secure.t3sec.info/blog/post/2010/10/05/typo3-sa-2010-020/</guid>
<pubDate>Tue, 05 Oct 2010 22:47:00 +0200</pubDate>
<description> TYPO3-SA-2010-020 Tomorrow, advisory TYPO3-SA-2010-020 will be published together with new TYPO3 packages. Some of you will certainly complain about a security fix again.But keep in mind that there </description><content:encoded><![CDATA[ TYPO3-SA-2010-020 Tomorrow, advisory TYPO3-SA-2010-020 will be published together with new TYPO3 packages. Some of you will certainly complain about a security fix again.
But keep in mind that there are also security fixes for your desktop software (browser, plugins like flashplayer, office software, etc..). Keeping software up-to-date is necessary to stay secure nowadays.
Instead of complaints you should really appreciate the work we do. Security fixes are the visual results of the TYPO3 Association's effort to deliver not only a functional but also a secure CMS.
I'd like to say thanks to all those who report vulnerabilities and such help to have a secure CMS. Especially thanks to all who communicated, evaluated reports, created patches or reviewed them - members of the TYPO3 Security Team and TYPO3 Core Team. Only these teams really know the huge amount of time and efforts that are put in such security fixes.
Besides, I'd like to highlight that you, user of TYPO3, have a really professionally working and highly dedicated TYPO3 Security Team. Be proud of this! I'm personally very satisfied with the composition of the team a.k.a team members, the way we work, the things we have achieved and our tasks in the near future.
So please install the security fixes and think about an improved installation instead of "again a security fix". Better install security fixes now than clean up a compromised TYPO3 installation later due to missing security patches.
A friendly reminder: TYPO3 is open source and the TYPO3 Association non-profit. Only with your donations or memberships you help to keep this great CMS alive and secure.]]></content:encoded></item><item>
<title>Marketing-FUD vs. real world: Security vulnerabilities discovered in bilobaCMS</title>
<author>marcus#exp2010@t3sec.info (Marcus)</author>
<link>http://secure.t3sec.info/blog/post/2010/08/26/marketing-fud-vs-real-world-security-vulnerabilities-discovered-in-bilobacms/</link>
<guid>http://secure.t3sec.info/blog/post/2010/08/26/marketing-fud-vs-real-world-security-vulnerabilities-discovered-in-bilobacms/</guid>
<pubDate>Thu, 26 Aug 2010 11:07:00 +0200</pubDate>
<description> Security vulnerabilities discovered in bilobaCMS Update (Sept. 3, 2010): Originally, there was an other URL referenced for the below mentioned press article. This was no longer available and the link</description><content:encoded><![CDATA[ Security vulnerabilities discovered in bilobaCMS Update (Sept. 3, 2010): Originally, there was an other URL referenced for the below mentioned press article. This was no longer available and the link replaced by an article hosted at another domain.
On August 18, 2010 Biloba IT, vendor of a CMS called bilobaCMS, published a press article (DE) to promote its Content Management System.
Oddly enough, they mention that Microsoft recently has stopped support for IE6 and TYPO3 Association support for 4.1 branch. Don't ask me why they mention a browser at all! Version 6 of Internet Explorer appeared in August 2001 which means Microsoft had provided support for remarkable 9 years. In the meantime Internet Explorer 7 and 8 are available. TYPO3 4.1.0 appeared in March 2007 and therefore TYPO3 Association had provided more that 3 years of support. Successors are TYPO3 4.2, TYPO3 4.3 and TYPO3 4.4. Declaring end of life for a product is just a normal part of its lifecycle.
Surprisingly, the vendor of bilobaCMS claims that software quality and security of (proprietary) CMSs is higher than Open Source systems because development is done by a company.
As you know, I'm interested in software security and therefore was curious how much "higher" security of bilobaCMS is.
Dear readers, calm down! bilobaCMS not surprisingly suffers from the same typical vulnerabities like other CMS (also Open Source), too.
On August 19, 2010 I checked out their demo system (bilobaCMS 5.0) and quickly discovered a reflective Cross-Site Scripting vulnerability in the search form and a persistent Cross-Site Scripting vulnerability in the gallery feature. These vulnerability were disclosed to the vendor on the same day. Some hours later, the vendor replied and stated that the reported vulnerabilities have been fixed, customers informed and patches rolled out. Sadly, vulnerabilities and their fixes are not communicated through the vendor's website so that website visitors are not aware of such issues.
I'd like to highlight that the vendor obviously provided patches in a very short period of time. This is something to be proud of and worth to mention in press articles instead of blaming Open Source for no reason.
What we have learned: Choosing a proprietary software over a Open Source one does not necessarily provide higher security standards!]]></content:encoded></item><item>
<title>Password policy for user accounts</title>
<author>marcus#exp2010@t3sec.info (Marcus)</author>
<link>http://secure.t3sec.info/blog/post/2010/03/18/password-policy-for-user-accounts/</link>
<guid>http://secure.t3sec.info/blog/post/2010/03/18/password-policy-for-user-accounts/</guid>
<pubDate>Thu, 18 Mar 2010 04:18:00 +0200</pubDate>
<description> Drafting an ideal password policy My situationYou might have heard that I've lost my beloved smartphone. Due to this, I assume the person that found it might have got hold of several user accounts o</description><content:encoded><![CDATA[ Drafting an ideal password policy My situation
You might have heard that I've lost my beloved smartphone. Due to this, I assume the person that found it might have got hold of several user accounts of mine.
In the last days I've revoked several SSH keys, changed credentials of server accounts and changed passwords of several accounts on websites.
If you ever come into this situation, you should start with your e-mail accounts. They usually contain your most private information, confirmations of account creations and perhaps passwords of user accounts. Then move on to e-commerce websites and change passwords there. Finally, change passwords of any other user account.
Of course, you should not have one password for all of your accounts. Before you ask, no I haven't had a one and only password for all of my accounts.
A draft of an ideal password policy
By changing my credentials, I stumbled over websites that have not any user interface to change passwords (contact support), websites that hide the user interface in the FAQ section, websites that allow only alpha-numeric passwords and nearly perfect websites in regards to password policy.
If you're building websites with user accounts, following suggestions will help you to make password policy user friendly.
If the account requires an e-mail address, do not allow the user to change the address via an user interface! Such change should always require the user to contact the support. The support should verify the identity of the user requesting this change and might wait mandatory three days before applying the change. The support should send a notification mail to the old e-mail account that informs about the planned change of e-mail address. This period allows the account holder to interfere in case of credential compromise when the change request was initiated by the bad guy.Do not hide the user interface for changing the password. It should be part of a account/settings webpage reachable via one click!The interface of the password change should consist of one field for the old password and two fields for the new one (one for confirmation preventing spelling errors).Allow alphanumeric AND special characters for the password!Put a description text to the password fields that tells the user what kind of characters are allowed.Divide possible characters in four classes: numeric characters, lowercase alphabet characters, uppercase characters and special characters. Require at least three classes to be chosen from for the password and a minimum length of the password string.Put a graphical representation of the password strength next to the password field. This should calculate the mathematical entropy of the password string. Red, orange and green are nice colors to represent the strength.Inform the user via mail about the change of his password along with the IP address of the host that initiated the change!Do not send passwords via mail!
I've found out that Amazon and Ebay are nearly perfect in regards to password policy. It's up to you to take my suggestions and improve your website!
I'm awaiting your comments; any important point missing?]]></content:encoded></item><item>
<title>No preannouncements for TYPO3 security advisories</title>
<author>marcus#exp2010@t3sec.info (Marcus)</author>
<link>http://secure.t3sec.info/blog/post/2010/03/04/no-preannouncements-for-typo3-security-advisories/</link>
<guid>http://secure.t3sec.info/blog/post/2010/03/04/no-preannouncements-for-typo3-security-advisories/</guid>
<pubDate>Thu, 04 Mar 2010 23:37:00 +0200</pubDate>
<description> Why are there no general preannouncements for TYPO3 advisories Every once in a while the TYPO3 Security Team is being asked to generally use preannouncements. Such preannouncements, to be published d</description><content:encoded><![CDATA[ Why are there no general preannouncements for TYPO3 advisories Every once in a while the TYPO3 Security Team is being asked to generally use preannouncements. Such preannouncements, to be published days before the actual TYPO3 Security bulletin, seem to be a nice way to be prepared for a necessary update of the TYPO3 Core, the base platform.
We discussed this suggestions but came to the conclusion that we better stick to the current procedure. Following is a list of points you need to understand.
Preannouncements for third-party TYPO3 extensions seem to be not necessary. Most time, you won't be affected by extension issues as you aren't using any of the mentioned extensions.We believe and know that upgrading (w/o testing) alone of the TYPO3 Core won't take longer than 5 minutes per server.We are not aware of any other Open Source project that has preannouncements in general use.Preannouncements will become useless again, if we need to late-postpone or pre-release a new TYPO3 Core version. Valid reasons would be regressions or exploits in the wild.Your TYPO3 installation might not be vulnerable because of not using an extension in question (recent openid vulnerability etc..) or the exploitability risk is very low (e.g. XSS in the backend with another vulnerability as mandatory prerequisite).
Last but not least, preannouncements would be another task to be done by the TYPO3 Security Team. The creation/review/publication of the bulletin takes hours (not taking any work on the issue itself into account). We're mostly interested in reducing our work load; after all, most of us do this work for free. However, preannouncements would mean the contrary and the overhead does not compensate the to be expected benefits.
Nonethless, for critical security issues we will of course proceed with preannouncements which has been done several times in the past.]]></content:encoded></item><item>
<title>TYPO3 as good as its competitors in web application security</title>
<author>marcus#exp2010@t3sec.info (Marcus)</author>
<link>http://secure.t3sec.info/blog/post/2010/03/01/typo3-as-good-as-its-competitors-in-web-application-security/</link>
<guid>http://secure.t3sec.info/blog/post/2010/03/01/typo3-as-good-as-its-competitors-in-web-application-security/</guid>
<pubDate>Mon, 01 Mar 2010 23:17:00 +0200</pubDate>
<description> Covering XFORCE 2009 trend and risk report IBM has recently released its X-Force 2009 Trend and Risk Report. This report summarizes reported web application vulnerabilities in 2009. TYPO3's overall &quot;</description><content:encoded><![CDATA[ Covering XFORCE 2009 trend and risk report IBM has recently released its X-Force 2009 Trend and Risk Report. This report summarizes reported web application vulnerabilities in 2009. TYPO3's overall "performance" is as good as its Open Source competitors like Drupal, and Joomla!. The number of vulnerabities in the CMS cores are more or less equally; when taking third-party addons/extensions/modules into account choosing TYPO3 seems to be slightly better than Drupal or Joomla!. However, this might also be caused by different total numbers of available third party plugins.
Percent of all vulnerability disclosures in 2009ProductBase PlatformPlug-insTotalDrupal0.2%2.5%2.7%Joomla!0.2%2.5%2.6%TYPO30.3%1.2%1.5%
The report additionally considers vulnerabilities w/ and w/o patches. In regards to this, TYPO3 numbers seem to be odd. I'm not aware what IBM considers as unpatched. For TYPO3 core there weren't and aren't vulnerabilities disclosed for the base platform without providing patches. Either IBM is taking versions into account that aren't officially supported any longer or wrongly considers a non-issue issue I covered in a previous blog post.
Percent of vulnerabilities without patches in 2009PlatformBase PlatformPlug-insDrupal18%13%Joomla!8%80%TYPO35%51%
We see a relatively high percentage of unpatched vulnerabilities in plug-ins (Joomla! and TYPO3 specifically). At least for TYPO3, this can be explained. TYPO3 is on the market for years now. Plug-ins are an essential part of a TYPO3 installation to bring missing functionalities. Therefore we have really old and no longer maintained plug-ins in the TYPO3 extension repository. Besides, security awareness wasn't that good in the good old days.
There's a high change that extensions with unpatched vulnerabilities are no longer in use or even aren't working anymore. Also, if the maintainer decides to stop support for an extension, TYPO3 security team won't provide patches. Providing patches in such cases would mean that the TYPO3 Security Team is responsable for these extensions forever and ever. Nonetheless, we encourage the TYPO3 community to contact the TYPO3 Security Team to take over maintainership of unpatched vulnerable extensions. Then a fixed version of the extension might again appear in the TYPO3 extension repository.
Still, I'm curious why Drupal has a significantly lower number of unpatched vulnerabilities in their plugins. Enlighten me!
Providing third-party plugins is always a tradeoff between security and user-friendlyness. You want to keep burdens low to provide additional functionalities and so help spreading the product. Then, overall quality of third-party plug-ins is definitely not as good as the base platform. So choose your plug-ins wisely and make a basic check by having a first or second glance on the code.
What I believe is more important, all mentioned CMS vendors above have professionally working teams that take care of security in the base product and third-party plug-ins. Every software product contains bugs. If you need to choose one CMS over other ones, check out the vendor's security awareness. If there's one CMS product without any disclosed vulnerabilities, it's either brand-new, not widely spread or doesn't care of security issues. If in doubt, better avoid such product.
In regards to security, Drupal, Joomla! and TYPO3 seem to be equal. In the end, functionality matters. You won't make a security mistake by choosing one over the others.
I'd like to take this posting as a change to say thanks to the TYPO3 Association. The Association cares about the security in their baby at least as much as the TYPO3 Security team does. They are giving us - the TYPO3 Security Team - a decent budget to cope with security issues. Thanks again. By being a TYPO3 Association Member you help to have a secure CMS. If you ever asked yourself, where your fees are spent on - not only on development but also partly on the TYPO3 Security Team. And it's definitely worth it.
One additional figure from the TYPO3 Security Team:In 2009 we have handled 317 reports in total; starting with suggestions on how to improve security, over support requests on hacked servers and of course vulnerability reports in third-party plug-ins and TYPO3 core. That's an impressive number considering the small number of security team members.

Disclaimer:X-Force statistical data are used as are. I personally do not warrent their correctness. IBM and X-Force are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.]]></content:encoded></item></channel></rss>
