about
blog
tutorials
Currently the posts are filtered by: TYPO3
Reset this filter to see all posts.
Service announcement - Updated blog software
Posted in TYPO3/ on February 05, 2010 by .
Dear readers!
I've updated the TYPO3 extension T3BLOG to the latest version, have fixed some bugs (patches are in the mantis bugtracker for project t3blog) and made further modifications on it to fix my special needs.
If you still encounter any bugs, please drop me a note.
In addition, the feed url has changed. It's now http://secure.t3sec.info/feed/rsstype/2.0/rsscontent/post/pagetype/100/. However, the old url stays valid. Bonus: Now, the feed is a full text one (without any html structure).
Thanks to Dmitry Dulepov for his great work on TYPO3 extension T3BLOG. This extension has undergone a complete security review and now it's really safe to use.
No re-use of version numbers in software development
Posted in TYPO3/ on January 30, 2010 by .
You certainly know that in software development, version numbers (e.g. 0.2.27) are used to identify a specific development version of a software product.
We, the TYPO3 Security Team recently had to work on an issue where the TYPO3 extension developer thought to be very smart in regards to the version number of his extension. We contacted him and reported a specific version number (like 0.2.27) to be vulnerable. After a few days, we faced a "new" version 0.2.27 of his extension cleaned up from vulnerabilities in the TYPO3 extension repository (TER).
Unfortunately, this happens quite occasionally in the TYPO3 world. It's a pity that the TYPO3 infrastructure (TER) does not prevent such overwritings of extension versions.
This is really bad development style. Let's assume you maintain a software product in which a bug occurs in version 1.3.15. You fix it, overwrite this version and now 1.3.15 is clean. A new report comes in again reporting 1.3.15 to be defective. You now face a problem. Which version contains the bug, the originally one or the modified one?
Additionally, in the TYPO3 world there's another drawback. The TYPO3 CMS has a so-called extension manager that allows to install/remove/update third party modules within the administration interface. This manager will not report a to be updated extension if you simply overwrite an already existing version.
Finally, considering security incidents, things get even worse. There are a lot of security service providers like Secunia that keep track of security advisories and so keeps you up-to-date on security vulnerabilites in products you might have deployed. Furthermore, there are "vulnerability databases" like NVD that describe and rate vulnerabilities in software products.
So in an security advisory you obviously want to clearly state that version 1.3.15 is vulnerable and version 1.3.16 is the fix for this vulnerability. You don't want to say that version 1.3.15 published until January 15, 2010 is vulnerable and any later available version of 1.3.15 is safe to use. This make things unnecessary complicated.
Do proper software development, do not overwrite version numbers! There are unlimited numbers to be used in version numbers; don't get stingy with new version numbers, you won't use them all up!
Who is trustworthy?
Posted in TYPO3/ on December 05, 2009 by .
Interesting question, isn't it?
First let me explain which roles interact with a TYPO3 installations.
- TYPO3 installation administrators
- website editors a.k.a. backend editors
- privileged website users a.k.a. frontend users
- unprivileged website users
Most of us will agree that last two roles are not trustworthy. This is obviously the case for unprivileged website users as a nobody knows who will finally access the website in the internet. A frontend user registration in most cases will accept any user. Registering process consists of filling form fields with user data (email address), following a confirmation link in a mail generated by the TYPO3 system and you're done.
Now we're getting to a more disputable role, backend users. During incident handling in the TYPO3 Security Team we see a lot of TYPO3 extension developers making false assumptions. They assume that all backend users are good guys and therefore will gracefully accept any input (e.g. plugin configuration).
This might be true for a website of a kindergarten located in a small village where one kindergarten teacher takes care of the website as backend editor.
Please think bigger! TYPO3 is considered to be an Enterprise CMS. TYPO3 is used for educational institutes (universities) with dozens of website editors (professors, employees, student employees). It is used for huge NGOs and for multi-national companies with distributed departments worldwide. Then you are dealing with hundreds of backend users.
In case of such huge deployments it's simply impossible for an admin or a team of admins to know everybody personally. Decisions which one to grant editor rights are most likely not to be taken by admins any more.
It does take only one curious guy who's trying to exploit a vulnerability to get admin rights, too.
So please, dear extension developer, assume that website editors a.k.a backend editors are not trustworthy! Validate their input, do plausibility checks!
TYPO3 admins might be considered as trustworthy as they are able to do anything anyway.
TYPO3 extension developers:
Remember one important rule: do not trust user input!
TYPO3 admins:
TYPO3 allows extensive configuration of what specific roles are allowed to do and what is disallowed. Use it! Only grant the least necessary rights that are really needed. Be careful with allowing HTML or TypoScript configuration for website editors.
TYPO3 security improvement in v4.3: HTTP only cookies
Posted in TYPO3/ on October 19, 2009 by .
Together with the previously mentioned feature (secure cookie transfer) an additional security enhancement has found its way into TYPO3 Core v4.3:
There's now the possibility to access FE/BE session cookies via HTTP only. With that enabled, it's no longer possible to access these cookies via JavaScript and e.g. retrieve session IDs from them. Current browsers support such declaration and will prevent the JS access to the cookies.
In the past it had been possible for a malicious person to find and exploit a Cross-Site Scripting vulnerability, to get hold of session IDs via JavaScript and to try to authenticate to a TYPO3 installation using these session identifiers.
It is expected that some TER-listed extension might stop working. Therefore, this feature is currently disabled by default. Nonetheless, it will be activated by default at a later point in time. Therefore, you might want to test your installation already today:
To enable and use this new security feature, put
$TYPO3_CONF_VARS['SYS']['cookieHttpOnly'] = true;
into your localconf.php file!
TYPO3 security improvement in v4.3: Secure cookie transfer
Posted in TYPO3/ on October 16, 2009 by .
If you are running a TYPO3 installation that makes use of SSL, following new feature will enhance your website's security (starting with upcoming TYPO3 version 4.3):
You probably know that the HTTP protocol is stateless and therefore sessions try to solve that "problem". TYPO3 uses cookies to exchange session identifiers between server and client.
Currently, if you are running e.g. the TYPO3 Backend (BE) with SSL (HTTPS) enabled and call the BE, the server will issue a cookie with the session ID. This cookie will be transferred over an secured/encrypted channel that prevents an eavesdropper to read the session ID from the cookie. If you call the BE again using standard (insecure) HTTP, your client will transfer the same cookie with the session ID exposed in plain-text for everyone who is sniffing your traffic.
Now, with feature #7461 ("Transfer cookies via SSL only whenever possible") implemented in upcoming TYPO3 v4.3, you can decide if TYPO3 should transfer created cookies only over a secured/encrypted channel or if cookies, initially issued by the server over a secured/encrypted channel should again only be transferred (by the client a.k.a. your browser) over a secured/encrypted channel.
This is done by setting a specific cookie declaration that current browsers understand and therefore will apply to your client-server traffic.
To use that new feature, please adjust a new parameter $TYPO3_CONF_VARS['SYS']['cookieSecure'] (through localconf.php file):
- integer "0" - current behaviour, transfer of cookies over any channel (default)
- integer "1" - server creates and transfers cookies only when accessed over a secured/encrypted channel; client is asked to send the cookie only over secured/encrypted channel (this setting enforces SSL)
- integer "2" - server will always create and transfer the cookie no matter which channel is used; if accessed over a secured/encrypted channel, the cookie will only be exchanged in an encrypted way.
Even if e.g. your TYPO3 Backend is accessible over SSL only, you won't be safe from cookies with session IDs transferred in an insecure manner and exposed SIDs as plain-text. So, whenever using SSL with TYPO3, please make sure to be familiar with that new feature and its options.
