Citaat:
However, I'm still unclear as to how this exploit can be achieved? I gather admin user access is needed to do the attack. If anyone other than the site admin has gained admin rights, is it not fair to say your site is already hacked and they can do pretty much what they want? If so, why would they want to do this XSS attack? Or have I mis-understood?
What I getting at is how necessary is the upgrade in real terms? I know the official guidance is to upgrade straight away, but how much of a risk is this in real terms? Can my site, sat out on the Internet with no users logged in, realistically be attacked using this technique if :
a) Protector module installed
b) A good long admin password is in use
c) https used on all pages by default
etc etc?
(I only ask because something went wrong with my site last time, and a test on a beta site the other week from 1.2.2 to 1.2.3 reported a problem at the database update stage )
Ted
Citaat:
tedsmith wrote:
IPF quicksearch feature
What's that? I have the default search block on my site. Is that what you mean?
Or do you mean the 'Quick Search' facility found in the Content module homepage? I assume it is this search field that can be exploited, which requires site admin access anyway.
I don't use the content module at all.
The second thing tedsmith. Anyway, it's not only for the content module. It's also for system functions and other modules that rely on IPF and it's quicksearch functionallity.
IPF quicksearch feature
What's that? I have the default search block on my site. Is that what you mean?
Or do you mean the 'Quick Search' facility found in the Content module homepage? I assume it is this search field that can be exploited, which requires site admin access anyway.
I don't use the content module at all.
In this specific case it depends on the modules you're using. As soon as you have the IPF quicksearch feature on the frontend (available for anon-users as well) you will have an issue. Otherwise not.
The security issue identified with version prior to 1.2.4 I have Googled and read about on several sites (http://seclists.org/bugtraq/2010/Dec/213 , http://www.htbridge.ch/advisory/xss_vulnerability_in_impresscms.html).
However, I'm still unclear as to how this exploit can be achieved? I gather admin user access is needed to do the attack. If anyone other than the site admin has gained admin rights, is it not fair to say your site is already hacked and they can do pretty much what they want? If so, why would they want to do this XSS attack? Or have I mis-understood?
What I getting at is how necessary is the upgrade in real terms? I know the official guidance is to upgrade straight away, but how much of a risk is this in real terms? Can my site, sat out on the Internet with no users logged in, realistically be attacked using this technique if :
a) Protector module installed
b) A good long admin password is in use
c) https used on all pages by default
etc etc?
(I only ask because something went wrong with my site last time, and a test on a beta site the other week from 1.2.2 to 1.2.3 reported a problem at the database update stage )
Ted
Credit to Aphex for the original htaccess code
Yes guys - it was due to the xhld0 RSS News Feed module. I had a recent news block on the homepage. Since removing that, it all seems to be OK and the error is only received if the user chooses to navigate to that module from the menu.
So, I think I'm there - https all the way!
Many thanks for all your helps guys - couldn't have done it without you
Ted
PS - if anyone wants the IIS URL Rewrite code as interpreted by it of Davids htaccess code, just PM or e-mail me and I'll paste it back.
Do you have any images or scripts being pulled from an external non-https site, like Adsense or some other bit of javascript? That will give you that kind of warning.
(must be tired - had to retype the above text about 4 times before it made any sort of sense!)
Might be wrong - but could it be some of the links go to http:// pages ? such as the wf-channel one in the top paragraph?
Try changing all the links for the same site to the https version
Having had a go at Brashquidos way, I got nothing but 500 errors so I must have been doing something wrong somewhere. I tried adding extra tags (<rewrite><rules><rule></rule></rules><rewrite>) but nothing worked.
I found another way having Googled a bit more. I read that the URL Rewrite feature of IIS7 can accept Apache .htaccess files.
So I copied the .htaccess code provided by you guys and edited it for mysite site as follows :
nice. not heard from brash in a long while. let us know how u get on with it in case others want to achieve this on iis.
Thanks mate - a very useful and in depth article.
I have just searched Brashquido's own website in fact and found, ironically enough, an article titled "Redirect HTTP to HTTPS with IIS 7":
http://www.iis-aid.com/articles/how_to_guides/redirect_http_to_https_iis_7
Looks quite straight forward and easier solution than the htaccess file system, perhaps? I will try it later when I can get an FTP connection.
Ted
Give this a look http://bit.ly/d9wDYj
Guys
OK - I've copied the latest theme_blocks.php file overwriting my older version (as it's obviously been added to the latest ICMS ver and yes, I will upgrade from .2 to .3 soon).
I've changed the path in mainfile to https... and that works a treat. All the URLs automatically go to https.
Trouble is I am struggling applying the htaccess stuff that David posted so users can still access http versions of https content, including, for example, when they get to the site from Google that links to http version so the homepage at least is, by default, set to http until they click on one of the links on the site - I can't rely on users to do that.
I share the server with Brashquido and I'm sure he has enabled ISAPI-rewrite but I don't know how to use it. I will ask him via e-mail unless you guys know an easy way to apply that code using IIS7 and Win 2008.
Ta
Ted
Re. 1, there's a hard-coded http in the file theme_blocks.php that needs to be changed, see this thread
For the second thing, see the .htaccess stuff in post #16 and 20, that bounces people back onto https if they try to access the site via http. I have it installed and can't reproduce the problem.
Might be worth checking your site preferences too in case the anonymous user group is set as allowed to access the site when it is turned off.
Guys
Whilst going through the task of buying a proper SSL Cert, I've created a self-signed one on my beta for testing of the long term aim of converting my whole site to https.
I've discovered two things :
1) Changing the path in mainfile.php from http://www.mysite.com to https://www.mysite.com doesn't appear to be working. All the menu links etc still point to http://... Have tried deleting cache and templates_c but no change? Am I doing something wrong or is the http bit generally ignored and only the domain actually used?
2) (and more worryingly) - when a site is turned off, the "Site closed..." message appears fine for http://www.mysite.com, but all an anonymouse user has to do to access the 'closed' site is change http to https and they are shown the whole thing! Again, is this me or is this deliberate? I guess a site without a https cert will give an invalid page, but any site that does have one, it seems that this is a way to bypass the "Site closed" setting?
Ted
I am in the process of buying one from InstantSSL - their intermediate certificates are about £50-90 a year. I'm buying one for two years to start with at a cost of £150 or so.
Ted
By the way, if anyone is looking for free/cheap SSL certificates:
* Startcom offers free certificates, but I've had problems installing their intermediate certificates on the server.
* Comodo has a free 3 month trial, which is relatively painless to get going.
* Namecheap resells RapidSSL certificates for $11.
Kind of shocked at how much some companies want for what is essentially a text file full of random junk, blessed by their text file full of random junk :)