Improving security in Joomla 1.7
marius
Because Joomla powers a large percentage of website on the internet
and it has thousands of 3rd party extensions it is very popular for
hackers to try and abuse Joomla. And although the Joomla core is
secure, your joomla website is only as secure as your weakest link
(usually an extension that does not filter input and allows for mysql
injection). If you look in "joomla vulnerabilities" in the online
databases (quite deceiving as IBM classes Joomla as a "vendor" for all
extensions) almost all of them are due to 3rd party apps not filtering
their input variables. And hackers can abuse google to find millions
of joomla sites and use automated attacks to see if their have
vulnerabilities.
Of course developers should always make sure all user input is
filtered properly in their applications. But why not provide some
default protection for this in the Joomla core itself. I have been
impressed by this simple plugin in blocking almost all injection
attacks on my sites (we have hundreds attempted attack per day).
http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/12731?qh=YToxOntpOjA7czozOiJzcWwiO30%3D
Its a very simple plugin that detects input that only can be used to
hack sites, blocks requests and can send an email to inform
administrator. There are some additional checks that I can think of
(encoding of injection code with chr() for instance). Its simple,
should not affect performance and could block most attacks being
successful. Its impossible to ensure developers use proper coding to
avoid hacks, but it is possible to make the Joomla core very hack
resistant with this.
My second idea is to improve login security. At the moment on 99% of
Joomla sites all usernames/password are send unencrypted. This allows
people to sniff out passwords (they search network traffic for post
requests with unencrypted passwords) and voila they have full access
to your site if that user is an administrator. Many other GPl
softwares protect to sniffing by default by encrypting the password on
the browser side to ensure sniffing is made almost impossible. There
have been white-papers submitted for Joomla 1.6 over a year ago that
details this (but nothing has been done with this so far).
Both of these ideas (in my opinion) can make Joomla much more secure
by default, do not affect backward compatibility and protect users
from the most common vulnerabilities. Eeven though this is not the
fault of the Joomla core, the core can ensure that most of these
attacks are stopped before they do any damage.
Would there any interest in feature patches for Joomla 1.7 for these 2
issues?
Thanks, Marius
Russell Winter
Regards,
Russ Winter
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
marius
> Whilst I am yet to review the source of the plugin, but...
>
> forcing https or alternative encryption on ALL users by default really is
> not a solution. Many many users cannot or will not expend the funds
> on certificates and self-signed certificates generate enough of their own
> issues. This would just add another hurdle to acceptance and implementation
> by the everyday user. So security would exceed it's usefulness, essentially
> limit the use of Joomla! for many users.
Because 99% of joomla sites do not use SSL, it is extremely worth
while to prevent plain text password submission ->without<- forcing/
using SSL. SMF for instance encrypts the passwords using javascript on
the browser side using the sessionid. That means the password is
already encrypted when it is send across the internet. It is not as
good as SSL, but it would be a major improvement to security, as like
you pointed out SSL is not achievable for a large number of users:
Here is the whitepaper from 2.5 years ago:
http://forum.joomla.org/viewtopic.php?p=1392618
The JED link to a secuirty plugin does something separate from the
plain password sniffer issue. A security plugin would prevent SQL
attacks, remote inclusion attacks by detecting and blocking these
hacks before they are even passed onto the extensions. This would take
away the majority of hacker tools that people currently use to try and
comprimise Joomla sites.
Thanks, Marius
marius
proposed in: http://forum.joomla.org/viewtopic.php?p=1392618
The aim is not to provide SSL type encryption handshakes for joomla
login for people without SSL (like sawasc aims). But to hash the
password before sending it using javascript. Here is how SMF does it.
It uses a javascript sha1 libary:
http://www.simplemachines.org/community/Themes/default/scripts/sha1.js
Then uses the function hashLoginPassword in
http://www.simplemachines.org/community/Themes/default/scripts/script.js?rc3
to encrypt the password into a separate field, then empty the
plaintext password field.
If you wish I can explain in more detail how such a system would work
for Joomla. It would be optional (if hashed password present use that,
otherwise look for plain password like is done currently), provide
secure login by default for the 99% of joomla sites that do not use
SSL and fully backward compatible with all login modules.
win-win-win situation if you ask me :)
Janich
Have you submitted it to the feature tracker?
On Feb 25, 12:41 pm, marius <mariu...@gmail.com> wrote:
> Please note that I am not advocating the implementation of sawasc as
> proposed in:http://forum.joomla.org/viewtopic.php?p=1392618
>
> The aim is not to provide SSL type encryption handshakes for joomla
> login for people without SSL (like sawasc aims). But to hash the
> password before sending it using javascript. Here is how SMF does it.
> It uses a javascript sha1 libary:http://www.simplemachines.org/community/Themes/default/scripts/sha1.js
B. Kimo Lee
proposing it!
Best,
Kimo
Marius van Rijnsoever
to the way Joomla salts passwords. In order to protect passwords on
non-SSL Joomla installs there needs to be a two-way
encryption/decryption. Joomla already has an encryption class
JSimpleCrypt. In order to use this function in the front-end the
encrypt function will need to be converted to javascript. The
encryption key can be stored using JSession to ensure the key does not
get send along with the encrypted string :)
I have not added it to the feature tracker yet. Wanted first to see if
new features are being accepted for Joomla 1.7 and if this is likely
to be accepted into the core. If it is likely to be accepted I will
happily implement this and submit a patch.
With regards to the SQL injection prevention plugin. I think the best
approach would be to approach the current developer the plugin
mentioned earlier:
http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/12731?qh=YToxOntpOjA7czozOiJzcWwiO30%3D
Refactor some of the code to be consistent with the Joomla core
standard and submit it as a patch in the feature tracker.
:) Marius
Emerson da Rocha Luiz
Emerson da Rocha Luiz
+55 51 9881-9146
eme...@webdesign.eng.br
http://www.fititnt.org | twitter @fititnt
Marius van Rijnsoever
<eme...@webdesign.eng.br> wrote:
> Also, if implement the SQL protections, just put as defalt on JRequest, but
> allow the developer explicit disable it, just to be sure that will not
> create big problems or make impossible to use Joomla Framework and force
> someone to use defalt PHP post and get, for example.
correctly. The malicious url protection would prevent the following
urls
1) local file inclusions
www.yoursite.com/index.php?option=com_example&task=../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ
00
2) SQL injections
www.yoursite.com/index.php?option=com_example&task=" = 1 AND UNION
SELECT password FROM jos_users WHERE id = 62.
3) Encoded PHP code injections
www.yoursite.com/index.php?option=com_example&task=${@passthru(chr(119).chr(103).chr(101).chr(116).chr(32).chr(45).chr(79).chr(32).chr(47).chr(116).chr(109).chr(112).chr(47).chr(100).chr(99).chr(46).chr(116).chr(120).chr(116).chr(32).chr(104).chr(116).chr(116).chr(112).chr(58))}
> +1 For this proposal. Its not the same time that I think about this too, but
> always remind the 'performance' factor... but... well, today maybe is best
> really the 'security' factor is more important than performance loose for
> the Joomla name.
As per the famous Mastercard TV advertisements:
loading regex to detect hacks, 50kb of memory
time to check for attacks, 10ms
protecting millions of Joomla sites against 90% of hacking techniques, priceless
Of course this should not go at the expense of performance. But these
basic testings on input variables should only take up minimal
time_memory (it is a simple regex on a short string).
> About encript login with javascript, lets think better about it. If at least
> is acceptable, I'm sure that someone will look around a better encription.
GPL RSA encryotion libraries are available that only take up 11 kb
(uncompressed). Would be a helpful addition, as the JSimpleCrypt does
not use the strongest encryption techniques (designed for light, fast
and simple encryption)
Thanks, Marius
Matias Griese
> JRequest already does a great job, ->if<- people use and and use it
> correctly.
function that raises an exception on invalid input (maybe a new
parameter to JRequest?). So instead of silently accepting invalid
Itemid, view, layout, task etc etc, Joomla would prevent those and
trigger an event making it possible to create a plugin which can then
take actions like logging and banning IP address.
Yes, there are plugins that will check for invalid input, but they are
not perfect as they do not know what's legal and what is not for every
component out there.
I've also noticed that many of the components are not using tokens to
protect tasks, especially in administration. It is very serious issue
especially if the site has forum software, where users can post remote
links to images. Image tags get automatically run, so just visiting a
page with malicious URL can be used to make many successful attacks --
if the right user happens to open the page, possibly while logged into
backend.
Easy example in Joomla 1.5.22 this one:
<img src="http://www.site.com/component/user?task=logout" />
causes every user visiting that page to logout from the site. Oops..
Yes, it can (and should) be prevented by making checks on the URLs,
but someone always complains as some perfectly legal images will
always get filtered..
Best Regards,
Matias @ Kunena.org
Marius van Rijnsoever
Here is an update on how to improve security in Joomla 1.6. Feel free
to add any other suggestions that you can think off.
1. Hijacking of cleartext passwords being submitted unencrypted
Its submitted to the feature tracker and awaiting more senior input
before I create the actual patch:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=25097
2. Cross Site Request Forgery Vulnerability logout
Many thanks for raising this issue Matias. This is a bug in my opinion
and I have submitted a patch to prevent sessions being destroyed by
rogue users.
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=25102
3. Spam bots abusing registration
Joomla is the best thing since sliced bread for spambots. There is no
captcha on registration forms, the "token" for form is easily
retrieved and automatically spamming Joomla sites is easy. If google
picks up that your site uses Joomla (just have com_blabla somewhere in
your links), be prepared to have dozens of spambots registering on
your sites (this is a real life issue and very common). Currently
users don't really know how to fix this (based on personal experience)
and if people know that they need captcha it takes them hours to
install it.
In the current web enviroment it is ->essential<- for Joomla to have
build in captcha protection on registration forms. This can be done as
a plugin, to ensure people still have the flexibility to have their
own captcha system, but will protect all Joomla users
"out-of-the-box".
4. No protection for brute force login attacks
Bots can submit millions of authentication requests to Joomla without
ever being detected or blocked. Most web software's have a 15 minute
lockout after 3 wrong login attempts to prevent this brute force
attacks. People have already submitted patches for this issue
(although they still need some work in order to considered for
inclusion in core)
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=25060
5. Detection and prevention of attacks
This is a more tricky topic like Matias pointed out. There are regex
available that detect these hacks (although SQL injection is much much
harder to catch). Joomla could detect these basic attack methods and
automatically sanitise them (by converting all special characters into
html equivalents). This would mean people creating an article on hack
methods would still work (characters are just replaced into html
equivalents and still displayed as intented), but the hack itself
won't work due to the hakc string
"../../../../../../../../../../..//proc/self/environ" now looking like
"..⁄..⁄..⁄..⁄..⁄..⁄..⁄..⁄..⁄..⁄⁄proc⁄self⁄environ".
This still needs lots more discussion before we can even consider
making a patch (due to the big implications in backward compatibility)
Anybody got any comments on these issues? Would love to hear your
opinions on these and other issues that can improve Joomla security,
Kind regards, Marius
Matt Thomas
Could reverse captcha be employed to resolve the Spam bot issue? It could be implemented in such a way so that it is randomized on page load to make it harder to circumvent. I've posted some other information about this is at https://groups.google.com/d/topic/joomla-dev-cms/bwMJLhPt7jY/discussion
Best,
Matt Thomas
betweenbrain | Construct Unified Template Framework for Joomla! 1.5, 1.6, Molajo and Nooku Server
geeffland
it is sent to Joomla. While on the surface it seems like a great
idea. I am not sure that it is anymore secure. As the hackers could
then sniff out the encrypted password and submit that to the website.
Is sniffiing out an encrypted password any more difficult then
sniffing out an unencrypted password?
Now what I think might be more secure is if the data was submitted in
two parts... one submission for the username and a second submission
for the password. This would definitely be more complicated to
implement but then the hacked would have to sniff two different
streams and determine which two streams went together... I am sure for
a professional hacker this may not be that much more secure either
though.
Niels Braczek
> I have thought about encrypting the password before for Joomla before
> it is sent to Joomla. While on the surface it seems like a great
> idea. I am not sure that it is anymore secure. As the hackers could
> then sniff out the encrypted password and submit that to the website.
> Is sniffiing out an encrypted password any more difficult then
> sniffing out an unencrypted password?
You're absolutely right - that would not bring more security.
> Now what I think might be more secure is if the data was submitted in
> two parts... one submission for the username and a second submission
> for the password. This would definitely be more complicated to
> implement but then the hacked would have to sniff two different
> streams and determine which two streams went together... I am sure for
> a professional hacker this may not be that much more secure either
> though.
You got the point. Without SSL, using 2 requests is the *only* way to
make password transmission secure.
Regards,
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Ian MacLennan
Mihai T. Lazarescu
> geeffland schrieb:
>
> > I have thought about encrypting the password before for Joomla before
> > it is sent to Joomla. While on the surface it seems like a great
> > idea. I am not sure that it is anymore secure. As the hackers could
> > then sniff out the encrypted password and submit that to the website.
> > Is sniffiing out an encrypted password any more difficult then
> > sniffing out an unencrypted password?
>
> You're absolutely right - that would not bring more security.
The server can provide the client a random token. The client
would mingle and encrypt it with the password. The server
would retrieve and check the token to validate the password
for that specific transaction.
I hope it make sense, I'm not a security expert.
Mihai
Marius van Rijnsoever
second step to submit the actual form. A random encryption key would
be generated together with the token. This would change every request
meaning resubmitting the same data would not work (encprytion key has
changed and won't result in the correct password). This means with my
proposal the encryption changes everytime and even if this is sniffed
it can not be used,
The current weakest point is the JSimpleCrypt, that is simple/fast but
has not got very strong encryption (but will stop 99% of script
kiddies). For this there is also a solution, which is to the the GPL
RSA library that offers very strong encryption.
Thanks, Marius
Niels Braczek
> The server can provide the client a random token. The client
> would mingle and encrypt it with the password. The server
> would retrieve and check the token to validate the password
> for that specific transaction.
>
> I hope it make sense, I'm not a security expert.
That will not work, because the passwords are stored with *individual*
salts. The latter preotect against use of rainbow tables. To perform a
client side encryption, the individual salt *and* a token is needed. To
obtain the individual salt, the username must be provided. So the
prodess will end up with the following steps:
JavaScript enabled:
1. display form with username field, password field and token
2. send username and token to get the salt
3. encrypt the password with the salt, then encrypt the result
with the token
4. on the server, encrypt the stored password with the token and
compare
JavaScript disabled (the way it is handled now):
1. display form with username field, password field and token
2. send username, password and token
3. on the server, encrypt the received password with the salt
assigned to the username and compare
That way, the user will have better security, when JS is enabled without
visible changes. Without JS, nothing will change.
Marius van Rijnsoever
> JavaScript enabled:
> 1. display form with username field, password field and token
> 2. send username and token to get the salt
> 3. encrypt the password with the salt, then encrypt the result
> with the token
> 4. on the server, encrypt the stored password with the token and
> compare
Clever out of the box thinking :)
Advantages:
1. only javascript hashing library required and no php decrypting library
2. one way only hashing, therefore minimal chance of discovering
cleartext password
Disadvantages:
1. methods requires additional http requests to get the salt after
username is typed
2. salts must be updated after each login to prevent the hash being reused.
3. the system could be abused to allow username discovery
At the moment I am experimenting with javascript RSA encryption to
secure the login:
http://shop-js.sourceforge.net/crypto2.htm
(note that the times mentioned on this page are for pentium-2
computers:) Also all the heavy lifting (generating public/private
keys) would be done by the server. On my browser the actual encryption
of the password takes 0.02 seconds (on a pentium 2 computer worse case
scenario is 2 seconds). This would be great to include as a class in
the Joomla framework. As this will allow for strong encryption to be
used in any joomla extension (not just for login) and will surely
appeal to business users/developers of Joomla.
For the captcha I like the structure used in:
http://code.google.com/p/joomla15captcha/
Captcha code is inside a plugin in order to allow anybody to create
their own captcha plugin and is fullt customisable in terms where and
how the captcha is used on standard Joomla forms. Please dont
joomla15captcha for the time being, as there is currently a LFI
exploit in the mp3 playing code. Just shows that people can be exposed
to more risk by relying on 3rd party extensions to solve their spam
issues. Other softwares have also successfully used this sort of
plugin structure to provide basic spam protection, while still
allowing for full override of the captcha system.
Kind regard, Marius
Niels Braczek
> On Tue, Mar 1, 2011 at 12:23 PM, Niels Braczek <nbra...@bsds.de> wrote:
>> JavaScript enabled:
>> 1. display form with username field, password field and token
>> 2. send username and token to get the salt
>> 3. encrypt the password with the salt, then encrypt the result
>> with the token
>> 4. on the server, encrypt the stored password with the token and
>> compare
>
> Clever out of the box thinking :)
Thanks; I discussed this problem with Herman Peeren at the last year's J
and Beyond. If not using SSL, there is no simple way to protect the
credentials.
> Advantages:
> 1. only javascript hashing library required and no php decrypting library
> 2. one way only hashing, therefore minimal chance of discovering
> cleartext password
> Disadvantages:
> 1. methods requires additional http requests to get the salt after
> username is typed
Correct, but the additional request will always be necessary, if the
passwords are stored with individual salts (which is very useful, see
latest activities of the Anonymous group - in short: rainbow table attack).
> 2. salts must be updated after each login to prevent the hash being reused.
Let's distinuish
- the salt (used to encrypt the password in the database),
- the digest (what I called token when describing the algorithm), and
- the token (what Joomla uses to prevent form misuse).
I said 'token' instead of 'digest' before, since the token was my first
idea to use as digest. That will work very well, because the user id is
used in generation of the token, so it changes after login.
> 3. the system could be abused to allow username discovery
Well, that's right, but the form token will protect this a lot.
Additionally, to make it more secure (and complicated), the username can
be encrypted salting with the form token; on the server side, *all*
usernames have to be encrypted with the token, too, for comparision.
Secure, but slow, if the number of users is somewhat bigger.
Mihai T. Lazarescu
> Marius van Rijnsoever schrieb:
>
> > On Tue, Mar 1, 2011 at 12:23 PM, Niels Braczek <nbra...@bsds.de> wrote:
>
> >> JavaScript enabled:
> >> 1. display form with username field, password field and token
> >> 2. send username and token to get the salt
> >> 3. encrypt the password with the salt, then encrypt the result
> >> with the token
> >> 4. on the server, encrypt the stored password with the token and
> >> compare
> >
> > Clever out of the box thinking :)
>
> Thanks; I discussed this problem with Herman Peeren at the last year's J
> and Beyond. If not using SSL, there is no simple way to protect the
> credentials.
Is it feasible a public key-based mechanism, e.g.:
http://shop-js.sourceforge.net/crypto2.htm
The server issues a public key and token to the client. The key
is used to encrypt the token with user name and password
before sending to server. The server uses the private key
to decrypt all to clear text. Checks the token to validate
the transaction. Salts/encrypts the password to compare with
its db for the user.
This is to avoid multiple transactions. The login form can
include the token and public key. The client javascript would
do the token mingling and encryption just before sending out
the user credentials. The server will do all checks to decide
whether to grant access.
Regards,
Mihai
Marius van Rijnsoever
> On Wed, Mar 02, 2011 at 05:47:17AM +0100, Niels Braczek wrote:
>
> Is it feasible a public key-based mechanism, e.g.:
>
> http://shop-js.sourceforge.net/crypto2.htm
For the PHP side there is also a GPL library:
http://stevish.com/rsa-encryption-in-pure-php
How I am planning that it will work in Joomla:
How to load the encrypt/decrypt javascript
<?php JHTML::_('behavior.jcrypt'); ?>
How to encrypt in the frontend:
$encrypted = rsaEncode($key1, $key2, document.form.password.value)
How to generate keys in backend:
import(joomla.jcrypt);
$JCrypt = new JCrypt();
$JCrypt->generateKeys();
$publicKey = $JCrypt->getPublicKey();
$privateKey = $JCrypt->getPrivateKey();
How to decrypt in backend:
import(joomla.jcrypt);
$JCrypt = new JCrypt($privateKey);
$decrypted = $JCrypt->decrypt($encrypted);
Still a work in progress, I'll let you know how things workout. Once
this class is ready it can be used to encrypt any traffic between the
Joomla frontend and backend.
Kind regards, Marius
Troy
CC like to a processor, the number and its verification data are sent
separately for just this reason.
Bear/N6REJ