about
blog
tutorials
Currently the posts are filtered by: TYPO3
Reset this filter to see all posts.
Policy of least disclosure explained
Posted in advisory/TYPO3/ on July 24, 2009 by .
On the TYPO3 Security Team website section you'll find a paragraph on incident handling. There it is mentioned that the TYPO3 Security Team does follow a policy of least disclosure. Have you ever asked yourself what this actually means?
For the TYPO3 Security Team this means that the team will publish bulletins/advisories for every vulnerability in TYPO3 Core or in TER listed extensions that has been reported and finally fixed. The bulletin itself will only contain the least necessary facts of vulnerabilities that are needed to know if a user might be affected and what the possible impact would be.
The TYPO3 Security Team will not publish exploit or proof of concept code; such critical information is only exchanged between the reporter of the vulnerability, the TYPO3 Security Team itself and either the TYPO3 Core Team or the extension maintainer.
The benefits for TYPO3 user:
By subscribing to the announce mailinglist (more on basic steps in my first things first blog post) you'll be informed about any vulnerability found in TYPO3 Core or TER listed extensions. There's no ready-to-be-used exploit code which means that a Black Hat needs to put some efforts in thinking and coding before he's able to exploit a vulnerability.
Needs and expectations by the TYPO3 Security Team:
In order to maintain this least disclosure policy, the TYPO3 Security Team expects to get involved in every vulnerability fixing process. So please contact us if
- you've discovered a vulnerability in TYPO3 Core or a TER listed extension
- you've been reported or found by yourself a vulnerability in your own extension
The TYPO3 Security Team has created an Extension Security Policy some time ago. Please make sure you've read it!
New TYPO3 releases (patch versions)
Posted in TYPO3/ on July 16, 2009 by .
No security fixes but security improvements
By today, new TYPO3 releases (patch versions 4.0.13, 4.1.12, 4.2.8) have been published.
Although there are no security fixes in them, they contain desirable security improvements as listed below:
- file deny pattern is applied to jumpurl (4-0, 4-1, 4-2)
- automatic deletion of ENABLE_INSTALL_TOOL file (4-1, 4-2)
Before, jumpurl allowed to download any file ressource (if you provide the correct validation hash). Now, by default PHP files are no longer able to be downloaded and access to files below typo3conf directory is completely denied.
A lot of TYPO3 admins forgot to delete the ENABLE_INSTALL_TOOL file after using the install tool which exposes a risk. I've covered that by a blog post and recommended to set up a cronjob for it. Now, this file is automatically deleted if it's older than one hour. During development you can suppress this behaviour by setting the file content to "KEEP_FILE".
Update: Michael Stucki has written a nice posting about this new behaviour on buzz.typo3.org.
Restructured team pages on typo3.org
Posted in TYPO3/ on July 05, 2009 by .
Some days ago, we've restructured the TYPO3 Security Team section on typo3.org. In specific we reduced the number of menu items to a minimum. Additionally there's a new page called Resources with all kind of helpful information for TYPO3 administrators and developers. You'll find, among others, references to security related tutorials, slides and videos.
If you are interested in TYPO3 security this page is now a nice starting point.
What's your opinion? What is still missing? Are there any resources on the internet that should be referenced to from the TYPO3 Security Team pages? Also helping hands on improving the (slightly outdated but still valid) Security Cookbook are highly appreaciated.
Please help us to support you on TYPO3 security!
Tell me your password
Posted in TYPO3/ on May 18, 2009 by .
Move credentials outside of the webroot
I've created a new tutorial that shows how to move credentials outside of the webroot. By default TYPO3 stores any kind of configuration into file typo3conf/localconf.php. Besides graphics configuration, etc... also database username/password and the encryption key is stored in there.
Although there's no way to get hold of this data as website user, I personal don't like the approach to store data that is intented to kept private inside the webroot.
The tutorial does explain the reasons in more detail. Have a look!
RSA Authentication for TYPO3 4.3
Posted in TYPO3/ on April 30, 2009 by .
Asymmetric Encryption for authentication - a major security improvement
Today, TYPO3 made a huge step forward in regards to security. Dmitry Dulepov has sent a patch (#11016) to the TYPO3 Core mailinglist that implements RSA authentication for TYPO3 Backend and Frontend.
RSA is a method of asymmetric encryption - something you might already know if you are using GnuPG or PGP. A key pair (public and private key) is created and then, a message can be encrypted using the public key. Only the owner of the private key is later able to decrypt the message.
In case of TYPO3, TYPO3 itself will create a key pair for each login attempt. The public key is given to the client (your browser) which will use it to encrypt you password. So sniffing your traffic will not reveal the password and you are able to login to your TYPO3 installation in an unencrypted wireless LAN without having second thoughts on a possible compromise later.
TYPO3 will then decrypt the message with the private key so that the plain-text password is again available on TYPO3 side.
Having plain-text passwords available on TYPO3 side (not only hashed ones like currently) will enable the possibility to apply arbitrary complex transformations on (original) plain-text passwords before being stored into the database. You might even consider to encrypt your passwords in the database.
The next step and also planned to be shipped with TYPO3 4.3 are salted hashed passwords for FE and BE user accounts. An already existing extension (t3sec_saltedpw) will therefore be integrated in TYPO3 Core.
RSA authentication will replace the currently used superchallenge authentication method. However, if you are already using SSL to secure authentications for FE or BE ("normal login method"), there's no need to use RSA.
Give TYPO3 4.3 a try; test and review the upcoming alpha3 release! You won't regret it.
Thanks to Dmitry for his efforts. "Inspiring people to share" at its best!
