Ok, so somewhere on my site is a Javascript file that after a few seconds, injects an iframe to an unknown site into the page. What it injects fails miserably and the HTML is a bit messed up, but it's concerning because the iframe src has changed since the last time I checked.
Code Injected:
<divstyle="height:2px;width:111px;">
<iframe style="height:2px;width:111px;" src="http://nleskoettf.com/index.php?tp=001e4bb7b4d7333d"></iframe>
</divstyle="height:2px;width:111px;">
For an up-close and personal glance: http://caseconsultant.com is where it injects (see bottom of page). Don't worry, the URL in the iframe src is dead (downforeveryone.com/nleskoettf.com), it's not even a working website which is the really confusing part.
Anyone know how I can track back the injected HTML to the source?
Anyone able to do that?
You may use a tool like Noscript to block domains for scripting and localize the script that injected the iframe.
Then you will see that the iframe will not be present when you block twitter.com
There is a function inside http://caseconsultant.com/wp-content/plugins/contact-form-7/scripts.js?ver=2.3.1 (see the last line) that loads some JSON-data from twitter and creates the iframe(maybe using data from the twitter-response, may be a reason for the changing url).
This also may be interesting to you: Is this dangerous Javascript? (It's the same function)
I'm not sure if this is malware, maybe there is only a bug inside the function that creates invalid HTML/URL
But the function has nothing to do with a contact-form, and also isn't a part of the original scripts.js(you'll find it here: http://downloads.wordpress.org/plugin/contact-form-7.2.3.1.zip ), so I'm afraid the site has been hacked(except you put the function there on your own).
So what you can do:
Read this (removing the function will not be sufficient, as long as you didn't remove the vulnerability)
Check the Server-Logs, script.js has been modified on 11 Nov 2011 19:57:00 GMT , has there been something suspicious-looking? If not you may assume there is no server-side vulnerability(but server-logs can be modified too), ....
Change your FTP-Password
Scan your PC for malware
I'd recommend using Chrome's Developer Tools to figure this out. If you load your site in Chrome, you can then open the tools by hitting the wrench button, then Tools -> Developer Tools (Or Ctrl+Shift+I).
From there, you can use the Resources tab to see everything thats being loaded for that page, or the Scripts tab to focus on just javascript. For this problem, neither of those seem that useful, so I recommend a different method: breaking on DOM changes. Take a look in the Elements tab, right click on the <body> tag and choose Break on subtree modifications. Then, refresh the page (might need to refresh twice, Chrome bugged out for me on the first time).
You should arrive at a call to jQuery.append in the Scripts window (if not, hit F10 until you are, sometimes Chrome picks up on more or less modifications on load), and if you look at the a variable under Local in the Scope Variables sub-window, you'll see that this is trying to insert the offending div/iframe.
Now you can step through the javascript using the buttons at the top-right, or F10 and F11. If you hit F10 a few times ('Step Over'), you'll end up in the offending script, referred to by Chrome as '(program)' (means its been dynamically loaded). This has been obfuscated, so its a bit hard to read/understand, but you can use the console window to run things from the script.
For instance, the jsn function is being used to translate obfuscated text. You can use this to see all of the different strings it is using, for instance on this line:
jsg = jsn('Ch') + jsp(jsb).substring(0, jsa) + '.com/' + jsAJ($);
That constructs the url for the iframe.
This means we've identified the offending script for sure, but the fact that this is identified as '(program)' by Chrome means it has been loaded dynamically into memory to be run. This means the actual script part is most likely compressed and further obfuscated somewhere in your other script files. If you look through those script files in the Resources file, you should be able to find a line or lines that don't fit in, that look very obfuscated/compressed, and are perhaps inside of an inline function call, IE:
(function() { ... } )();
They may also look somewhat similar to the script file inside the '(program)' view. It can also help to search for things that would be hard to compress/optimize further, such as the obfuscated strings. I searched for one of those strings, haDWDosestnsdlDjfqcq, and found it at the bottom of scripts.js. Delete that line and your site should be fine!
I recently had this happen, iframe injections into the javascript files (and others!). First thing I did was a grep -n for the url on my entire server to find every instance of the injection. Just one line and fairly simple to remove. Then came the matter of tracking it down.
It turns out it was a rogue apache module that had been planted due to a vulnerability. In my case it was mod_aclr.so
Go through your /usr/lib/httpd/modules/ or /usr/lib64/httpd/modules/ directory and compare your list to the list of real apache modules here: http://httpd.apache.org/docs/2.2/mod/
If you have some modules that don't appear on that list, vi them to see what they contain, or simply do a google search to see if they are affiliated with actual modules. In my case, mod_aclr.so returned about 10 pages of Russian commentary, so I quarantined it and will be watching to see what happens now.
Here's a good writeup on the subject: http://blog.unmaskparasites.com/2012/09/10/malicious-apache-module-injects-iframes/
Related
I have a content script running inside the Gmail UI and I am injecting some new HTML at different points. This is all working, but to keep the code clean I wanted to insert pre-defined HTML markup into certain parts of the page in a single function call.
This all seems feasible using chrome.extension.getURL(), but when I was testing this, it looks like chrome.extension is undefined! I was unable to find anywhere in the documentation that says this shouldn't be defined and several places where it says it should.
I am using chrome Version 39.0.2171.95 (64-bit)
Here is what the chrome object looks like in the javascript console:
First off, anyone know why chrome.extension might be undefined? Secondly, is there another (perhaps better) way to do this? I'd rather not just programmatically inject a large amount HTML into the page in code using jQuery, etc. in the content script, but can resort to this if there is no other way.
If you're testing this in the console, you must be aware of the concept of the Isolated World. When you add a content script, it has a separate JavaScript context for itself that is isolated from the page.
At the top of the Console tab of Dev Tools, you'll see <top frame> in a dropdown. This is a dropdown that selects JS context it is executing in. It will list frames inside the document and all extensions that have content scripts injected.
The chrome object you show in the screenshot corresponds to what the webpage normally sees. If you switch context, you'll see a different picture:
In any case, if you are really executing chrome.extension.getURL() in the content script - it will be well defined.
Now, if you injected a <script> tag in the page and tried it in that code - it would fail again, since the code will be in the page context. See this question for this situation.
Finally, most of the Chrome API will not be exposed to content scripts for security reasons. If an API is undefined when it shouldn't be, you may need a background page to do the job for you.
I have spent 3 days trying to figure this SIMPLE problem out. All I want is for my whole website to remember the winversion global variable value and to be able to change it from within a function . ( YES I know global variables are more evil than darthwader but please that's the only good thing going on in my life)
I have one html file with an <iframe>, and as the user clicks inside, I load up different pages ( from my domain) into that <iframe>.
This is my index.html ( it has a few divs around the <iframe> but I’m pretty sure that’s irrelevant because everything else works, and javascript is ONLY for this <iframe>)
<script type="text/javascript" src='script.js'></script>
---------- ( some inner body html , not important)----------------
<iframe id="myiframe" src="mainproblems.html" >
The default iFrame page has this html code
<a href="#" onclick="setwinver('xp')";>I have Windows XP </a>
<a href="#" onclick="setwinver('win7')";> have Windows 7/Vista </a>
My script.js is this
// This is supposed to be my global variable to hold windows version value
var winversion ;
// This function (I officially hate it now) is supposed to change
// winversion variable based on what user clicked on the iFrame
function setwinver(ver)
{
//so now winversion should either have xp or win7 assigned
winversion=ver;
}
But later on, in the next <iframe> when I try to READ winversion in the same JavaScript file, it says undefined. This navigatenow() function is triggered when the user has selected windows version on page 1 and in the next html page click a link to launch msconfig description page( which is loaded in the <iframe> ).
function navigatenow()
{
if (winversion == "xp")
{
window.location.href=("msconfigxp.html");
}
else
{
window.location.href=("msconfig7.html");
}
}
I have tried:
Using /not using var.
using /notusing single quotes,double quotes( though It makes no difference I know).
reading up on a dozen articles on hoisting.
using persistjs for several hours.
meditating and praying!
NOTHING works. The damned winversion variable is still as undefined as the purpose of my existence.
All I want is for my html file to remember which windows version user chose( no I cannot detect the windows version programmatically, my purpose of asking the user the version is different) .
Any help would be greatly appreciated fixing this and if not, please suggest a suitable cliff where I can jump off from.
The page in the iframe is a separate window, it won't inherit the scope of the index page. You need to specify that you want to go to the parent window and use the script there:
window.parent.setwinver('xp');
And the same accessing the variable:
if (window.parent.winversion == "xp")
Here is a working example: http://jsfiddle.net/ga62A/
The index page loads this iframe: http://jsfiddle.net/cMDvc/1/
Then you go on to this igrame: http://jsfiddle.net/9qjaX/
LePrince, when you change pages, JS drops all memory of what the changes were.
JavaScript is read into the page, but you can not write back to the JS file, from the end-user's browser, because that would just be asking to have your life, your site and all of your money stolen.
All of the changes you make to the original code you read are stored in memory. That memory only lasts as long as the page lasts.
After that, it reloads the page again, the same as it always was.
If you need it to do more than this, the first place you can start is with document.cookie.
It's meant for storing very small bits of information, and it isn't fun to use, unless you write tools to get cookies and set cookies.
Next is localStorage, which is more useful and newer (but old IE doesn't support it, so people on XP with Windows 7 can't use it). But this is still only good for data for one user, and will not change anything for any other user.
If you want the ability to add... ...say, comments, or star-ratings, where other people can see posts and ratings and uploaded images, then you need to look into server-side programming.
Ruby(/Rails), PHP, Node.js and the like.
I'm trying to implement DoubleClick on a client's site and having a heck of a time. Part of the problem is that when things don't work, things just don't work. Nothing is logged to the console, no alert boxes appear, no uncaught exceptions are thrown, nothing. Nevertheless, through experimentation, I've managed to get things to the point where iframe tags are being inserted in the positions where the ads should be on the page; it just seems that the iframes aren't having src attributes given to them, so they're just appearing as blank areas on the page.
It would be wonderful if someone had an answer on how to solve that exact problem, but failing that, I'd settle for a way to coax the DoubleClick script into just making a bit more noise when something goes awry. When I look at the minified/obfuscated script being loaded from Google's servers, it does look like there's plain English strings woven in there representing various error cases, so I presume there's a way to make it display those strings to me…
From my understanding the iframes will not have src attributes... I think the reason they are used is as a form of sandboxing so that ads cannot interfere with the parent page in any way... an iframe allows different css, scripts etc without it conflicting.
If your ad units on your page are appearing blank then it is most probably because there are no line items that match... make sure you are using the build tags tool inside DFP... that hasn't failed me yet... also check out the debugging console, this should display any errors that you have with your page.
as obviously the css related to the page being injected is not loaded by Chromium. However, it is working well in IE8/O 10.x/FF3.6x.
Hence begs the question - my stupidity in html coding, Chromium bug or jquery bug? that is what I could think of.
this is the page in question, eliminated all non-essential js http://logistik-experte.gmxhome.de/test.html, navigate to resume and see the difference. It is basically driving me nuts as missing the point somewhere and hence any sound advice/help would be highly appreciated.
cheers
I agree with Buggabill: works for me in Chrome 5. (At least on the server; there may be issues with loading files from a local filesystem.)
However there are problems with your approach. By having page content loaded by script only, you have made your page inaccessible to non-JavaScript users, which includes all search engines. Also you can't use the back button and the pages are unbookmarkable, un-open-in-new-tab-able, and so on.
Basically you've reinvented all the problems of <frameset>, the reasons why no-one uses frames any more. You shouldn't really deploy this kind of solution until you are familiar with the ways accessibility and usability can be served. At the very least, you need to point the navigation links to the real pages containing their content. Then consider allowing hash-based navigation, so the dynamically-loaded pages have a unique URL which can be navigated between, and which will re-load the selected page at load time when the URL is first entered.
Also if you are loading content into the page you should take care to load only the content you want, for example using load('portfolio.html #somewrapperdiv'). Otherwise you are inserting the complete HTML, including <!DOCTYPE> and <head> and all that, which clearly makes no sense.
To be honest, as it currently is, I don't see the point of the dynamic loading. You have spent a bunch of time implementing an unusual navigation scheme with many disadvantages over simple separate navigable pages, but no obvious advantage.
I've read that it is better to place your <script> tags at the end of the document. The argument for doing this appears to be that the browser will stall rendering the page below a script tag until it has loaded and and executed the script. If your script tag is at the top of the page, rendering is stalled for a while, which is bad.
However, I am not sure if this is really true any more.
Looking around, I normally see the following locations...
In the <head> of the page or Just inside the <body> tag
Stackoverflow is an example of a site that puts the script tags in the head, and since they are normally rather obsessed with performance, I am starting to wonder if position in the page is important at all.
Last thing in the body element
The other common place to put javascript appears to be right at the very end of the <body> element. I am assuming this means that the page can render while the javascript downloads and gets on with doing its thing.
But which is better?
Does anyone have any thoughts or advice on this? I am looking to try and get our pages to perform and appear to the user as quickly as possible.
Does it matter? What are the advantages of being at the top of the page? Bottom of the page?
It really depends.
There is no catch all answer for this because it depends on what your javascripts are acting on.
Putting scripts at the end of the page is sometimes needed if your acting on a DOM element that needs to be loaded for the script to run. Say you want to focus on a control and your script is:
var mytext = document.getElementById("mytext2");
mytext.focus();
Well in this case you would want it to execute at the end of the page, after mytext2 control has already been loaded by the browser. This is less important for script blocks that only contain functions that are called by events.
If you have a big .js file that contains libraries of functions you may also want to put that at the end of the page so the browser will load the page faster before loading the large .js file.
Google analytics suggests putting their tracker at the end, to make sure the page has been delivered before you count the hits, but in some cases it suggests putting the script into the header too, it works both ways.
So, rule of thumb for me is, HEAD scripts for everything except things that execute in-line and act on DOM objects, or large scripts that you want to load after the page.
Rick Strahl just wrote a great blog on placement of Javascript in .net too:
The only validating way is to include it on the top (in the <head> section), but in the bottom will be faster to load - the rest of the page will load faster if you have script near the bottom, giving the user better response and making the experience better.
The problem is that most web browser stop rendering the HTML of the page until they've fetched and parsed all JavaScript code so far. So if you have a slow-loaded .js file included in the <head>, no HTML will be rendered and images will not even start to download before the .js have been downloaded and parsed, therefore frontend engineers propagate for putting the scripts as far down in the code as possible.
I usually just set a far-future Expires header for my .js files so they are cached in the browser for a long time and then include them in the <head> section. This gives good performance and doesn't look ugly :-)
But if you are serving external .js libraries (that are on other servers than your own), you will probably want them in the bottom because you can't change the Expires-header for other servers and you canät know that the other server always will be responsive.
yeah. Put Scripts at the Bottom
I think the size of the js file is much more important than the location of javascript. I always set highter number of the con-current connection to make sure they download in parallel.
I believe it's better to place script tags just before the closing body tag. Because:
Elements are blocked from rendering if they are below the script.
In IE6, IE7 resources in the page are blocked from downloading if they are below the script.
From this article. Also Yahoo's performance rule 6 is Move Scripts to the Bottom
Google Analytics always used to say to put the script tag at the bottom of the page. I believe the rationale was that if the Google servers ever went down, the page would fail to load if it were in the head (only for IE probably).