I have a site in modx, and it's been hacked twice by adding this file /modx/assets/images/files.php which contains
Linux+cfcd208495d565ef66e7dff9f98764da+01+[[]]
I've removed it and after it site removed from DBl(domain block list) but I want to know how can I solve this problem so it won't be repeated again?
You need to remove all malicious files, update your modx, update all plugins/extensions and change all passwords on site/db/ftp.
Related
I copied powertoolsinitialdata and made it my store after changing names.
Now I can go to localhost my site and see powertools products.
In site.impex , there is a part:
# CMS Site
INSERT_UPDATE CMSSite;uid[unique=true];theme(code);channel(code);stores(uid);contentCatalogs(id);defaultCatalog(id);defaultLanguage(isoCode);urlPatterns;active;previewURL;startingPage(uid,$contentCV);urlEncodingAttributes;defaultPromotionGroup(Identifier)[default=mysitePromoGrp]
;$siteUid;lambda;B2B;$storeUid;$contentCatalog;$productCatalog;$defaultLanguage;(?s).*;true;$storefrontContextRoot/?site=$siteUid;homepage;storefront,language,currency;
This is default from powertools.
So I have to go to
https://localhost:9002/mysite/en/USD/
instead of the only localhost.
For it, I deleted those parameters.
and made site.impex like this
# CMS Site
INSERT_UPDATE CMSSite;uid[unique=true];theme(code);channel(code);stores(uid);contentCatalogs(id);defaultCatalog(id);defaultLanguage(isoCode);urlPatterns;active;previewURL;startingPage(uid,$contentCV);urlEncodingAttributes;defaultPromotionGroup(Identifier)[default=mysitePromoGrp]
;$siteUid;lambda;B2B;$storeUid;$contentCatalog;$productCatalog;$defaultLanguage;(?s).*;true;$storefrontContextRoot/?site=$siteUid;homepage;;;
I deleted only last 3 parameters
storefront,language,currency;
which are urlencodinggatrributes.
Then I again made ant initialize (also I tried importing from console).
After clearing cache or going incognito, I see such a bottom of powertools
https://pasteboard.co/HqKOciV.png
Why is that? Why is it not proper? I want to remove those parameters. Should I remove from also somewhere else?
I don't want to do via WCMS or adding another Impex like
INSERT_UPDATE CMSSite;uid[unique=true];urlEncodingAttributes
I could not find any solution for that wish. I searched a lot but no solutiions for this.
You just need to remove these urlEncodingAttributes in either way from impex/hmc/backoffice and just do server up once. It will fix your issue. If you initialize, then again those impexes will be imported. You should do this after initialization.
Can you check from where this image is getting appended?
I created an admin section for a website of mine using PHPMaker - as I usually do. The website is made from scratch, no wordpress or anything else involved.
In some apparently "innocent" tables, if I try to edit them, I get a 403 error. It never happened, and I used PHP maker for at least 15 websites of mine, so I am puzzled.
It happens only on 2 tables out of 15, and as said, they are fairly innocent. Nothing fancy compared to the other ones.
This is what I've tried:
there was no .htaccess file in the admin directory, so I also tried to insert an empty one
clearing the cache
visiting the page in private mode
all file/directory permissions are ok
regenerating the project and uploading it again, to a different directory
What else can/should I check?
There is a .htaccess file on the root directory of the server to handle some "pretty url", but it should not matter since the admin section is under a specific directory. Or should it matter?
Thank you
At least, I found the problem: every time I was trying to insert an iframe or a script, somewhere somehow somebody (...) was parsing it and it was blocking it for - I guess - security issues, so I let the user to insert the script without the <script> tags, added later in PHP simply with:
print "<script>$readFromDB</script>";
In each insert action, PHPMaker will parse the word
<script
and converted to
<s<x>cript
You have either get the inserted rowid and update the value again OR each time you have to remove the '< x >' to view the value correctly.
Take a look at my answer here: PHPMaker issue
I just upgraded the Typo3 from 6.2.26 to 7.6.10, but the styles at the front page are all missing. Just the content and data from the DB shown on it. I guess maybe it was the loss of.
So, if there somebody met this question too, share your ideas with me. Looking for your advice, many thanks.
First you should check if your JS/CSS files are present in the source code of your page. If they are, there are two possibilities, imo:
your html is cached but the cache files were deleted/moved. Solution: clean your cache (the best is to clean it from the install tool -> "Important actions")
Your baseURL/absRefPrefix is broken. I would advice to use config.absRefPrefix instead of baseURL (https://docs.typo3.org/typo3cms/TyposcriptReference/Setup/Config/Index.html)
I don't understand the security patch from last week: https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2016-022/ . I have an old TYPO3 6.2 installation. I have truncated all cf_* tables and opened the pages with UID 2-6. No cHash. As a result I see 13 cf_cache_hash-entries.
Now I have opened a detail page from a listing page in frontend. I see some parameters in URL like action, controller, the UID of the current displayed record and of cause a cHash.
Then I have copied these parameters (excluding id=x) to the URL of my pages 2-6. In cf_cache_hash I have still 13 records. So, there is no cache flooding.
Or how I have to interprete this quote:
Links with a valid cHash argument lead to newly generated page cache
entries. Because the cHash is not bound to a specific page, attackers
could use valid cHash arguments for multiple pages, leading to
additional useless page cache entries.
Next problem:
If extensions like realurl are used, it is required to flush their
caches (and TYPO3 caches as well)
Can you please tell me WHICH tables I/we should clear?
tx_realurl_urldecodecache
tx_realurl_urlencodecache
are maybe OK. But what about tx_realurl_pathcache? Of cause, I can clear that, but what about older entries for earlier realurl configuration? If I truncate that table, these old entries are not valid anymore and they were not builded again. So, old Search Engine Results are invalid.
Question from one of our customers: Is it enough to clear system cache in backend or should he click on Clear all Cache in Installtool? Nice. IMO, it is not enough and the tables have to be truncated on DB directly. Right.
Next one:
This means if such URLs are indexed by a search engine, visitors from
this search engine will end up on a not properly working page.
Hey cool. And now? What is the solution? Keep it as it is? IMO it depends on an InstallTool setting called: pageNotFoundOnCHashError. Right?
Please tell us what to do and please add some more details how to handle that.
Stefan
For me it boils down to (after installing the updated TYPO3 version):
If you don't use realurl: enable
$GLOBALS['TYPO3_CONF_VARS']['FE']['cHashIncludePageId'] = true;
& and you are probably "done". Of course all old google hits will be done for, but on a "public" site it's quite probable you never cared about google anyway if you didn't run realurl (or similar)
If you use realurl 1.X on a 6.2
Don't enable the config (there'll probably never be a proper patch)
Two options:
take the risk of a DDOS
use the 1.x version from https://github.com/mogic-le/typo3-realurl
If I understand it correctly it will set TYPO3 to no_cache mode if there is no hit on the caching table; While that is a performance issue, it will prevent cache table entries being made (as a side effect)
If you run 7.6+ and realurl 2
Wait for realurl 2.1 (and take the risk?)
Change the caching
framework to something like memcached (it's somewhat suggested
between the lines: If you have a caching backend that cannot be used
for a DDOS, you don't really have to care)
Use the fork from
helhum (though I think that won't help you one bit regarding old
links)
Realurl >= 2.1.0 supports this core option. But you are recommended to update to at least 2.1.4 because that fixes various other cHash issues.
I've made a mess of MOSS (well not really, just that I've created some site columns that are now impossible to delete).
Is there any way I can revert to a default installation without reinstalling everything?
Failing that is there a way to force delete site columns?
Update
Basically another "typical day developing around Sharepoint..." moto, with Sharepoint it is 100% probable something will go wrong.
I have Site Columns that can't be deleted, because they're "bound to a content type, that I've already deleted"
If you are created custom columns on Document Library level you just need to delete Document Library
In case you created custom columns at site collection level you should delete your site collection and create a new one. New site collection will not be affected unless you made some non-supported customizations to "12 hive".
In both cases you can solve the problem without reinstallation.
Hope it helps,