Jsecure is a great start but it has a few potential areas of improvement:

1. OK it redirects the /administrator folder but because it does this just for the admin folder it tells the hacker that the site is using Jsecure.

I would like to see it trap all 404 errors for the site and redirect them to the root.


2. The documentation is another givaway, all a hacker has to do is type www.yourdomain.com/plugins/system/readme.jsecure.html

and not only does it confirm Jsecure is in use but it gives clues on how to hack it.

I would not include this file at all to the uploaded site.


3. Jsecure installs to common names and install folders which make it easier to hack.

I would like to see the install work in in two phases, first the upload, then the config which should ask you for an install directory, a key name and a name to rename the plug-in. It could collect an email and auto generate a long keynames such as fGYtEGJS9WWW, slkfvdtiII3, then create a folder called fGYtEGJS9WWW, rename jsecure.php to slkfvdtiII3.php, install it to the folder fGYtEGJS9WWW and modify all code to make it work. The email would be used to provide key confirmations/reminders and warn of attempt to hack the system.

4. The 404 message graphic is another giveaway, I would just use a system generated 404. For example if you enter

www.microsoft.com/dhfjgr

You get a message saying

We are sorry, the page you requested cannot be found. See below for search results close to your request, or try a new search.

I for Jsecure a parameter for the 404 text could be used with the default "We are sorry, the page you requested cannot be found." and a redirect to the root of the domain in 5 seconds.

Also if you must use a 404 graphic, install it in a random custom folder.


5. Help Page helps hackers

The help page helps hackers because it tells you not to use numbers, so if you say “what happens if I try” you get this

Illegal variable _files or _env or _get or _post or _cookie or _server or _session or globals passed to script.

So one wonders what PHP variables might be able to be used, could one use PHP injection or SQL injection?

Well the answer is to check inputs for potential errors and treat them as a 404.


6. Things missing from the help file

a. Note that plug in will appear on page 2 so set view on plugins to ALL.

b. It should tell you, 1 is to log out of admin before testing.

c. It would be helpful if it could give instructions on how to change things manually, for example changing the name of the PHP file in the config just stops jsecure from working and changing the jsecure.php file manually with FTP does not make it work either, so it would be useful to know what needs to be changed until you can provide the automatic random names I have suggested above.

I am no security expert, but what I do know is that you should try not to leave clues and you not introduce a system that potentially makes it easier to hack.

Is the PHP introduced by Jsecure more secure or does it have loopholes of it's own?

These sites seems to suggest that Joomla is vulnerable to hackers

www.packtpub.com/article/preventing-sql-...s-on-joomla-websites

www.chr00t.com/2009/02/joomla-hackers-command/

While this one give the SQL code required to find the Jsecure key

www.chr00t.com/2009/02/hack-joomla-jsecure-key/

So IF the jsecure login does not prevent injection then in theory the above exploits could be used.

Thanks for pointing all this information out in a forum that just about anyone can access. Although your point is valid, don't you think it would have been more prudent to PM or e-mail the developer rather than let everyone know about these potential exploits?

Hi,

Thanks for suggested points.


Thanks and Regards,
Bhavin Shah

bgorsky wrote:
Thanks for pointing all this information out in a forum that just about anyone can access. Although your point is valid, don't you think it would have been more prudent to PM or e-mail the developer rather than let everyone know about these potential exploits?

Actually I am doing them and any potential user a favour; users should not be lulled into a false sense of security and the author will have a better product by addressing any holes.

If S/he feels that my comments are inappropriate then they may move my post offline, I have no problem with this.

I did try to make the thing more secure manually but it did not response well.

I tried to rename the files and references to them in the PHP files. I moved the documention off OK, but could not lock down the system without breaking it.

TO be honest I would be happy to pay £20 for a version of Jsecure that has the issues raised aboved addressed. The current version could still be given away free.

All of the exploits are no further away than a google search, but anyone finding this product may think it makes their system safe when in fact it may introduce a risk.

Joomla has been around a long time and it has been made pretty secure, this add-on could undermine that security if it does not evaluate inputs for SQL injections.

For all I know it may be more secure than I think, that is for the author to answer.

I agree with the original poster - jSecure as currently implemented will keep the casual hacker away, but not anyone who is serious. I would also pay more for a more secure system (although prefer to pay in dollars, not GBP 8-)

As mentioned on other post on this forum this product is a lost opportunity. The new pricing model is completely wrong for Joomla market. They should make it free for personal use and charge $20 for a commercial license.

They are losing goodwill elsewhere on other sites and ruining the opportunity. It is only a matter of time before someone takes the code (available under GNU license) and forks it into another product.

Another option for the author would be to make the basic version free to business users but have a more secure version that costs $20.

I run over a hundred Joomla sites and I would not pay for an annual license because I don't need the hassle of managing licensing.

Until the owner wises up this is just a lost opportunity.