When I am using iframes or frames (older sites), as a extra security precaution I use the JavaScript function:
<SCRIPT LANGUAGE="JavaScript1.1">
if (top == self) self.location.href = "../index.cfm";
</SCRIPT>
then another hidden check to see if the page is being called correctly....
<cfif (HTTP_REFERER DOES NOT CONTAIN "referer_page.cfm")
<cfabort>
</cfif>
It works great to keep visitors (hackers?) from opening and/or trying to post to the page.
The problem is that the JavaScript displays in source code and the less they know...
I know the JS is client side but is there anyway to create the function in the server side CF or otherwise hide from prying eyes?
I a running cf9 on my and most of my client sites.
Thank in advance
No, it is not possible for any server side language to tell if the client that requested a page intends on displaying it inside of a frame. The only way to tell that is to ask the browser once your page reaches it.
What's the concern with the Javascript being visible?
There is literally nothing you can do to permanently avoid clients from seeing your source HTML and/or Javascript. Any attempt at security on the client side is in the end futile. You will keep out casual (i.e. non-web developer or programmer) users, but that is all. Anyone with a rudimentary knowledge of HTML and access to Google (or Alta Vista or ask jeeves for that matter) will be able to circumvent your barriers.
The use of HTTP_REFERER is suspect here as well (I know I know... I'm a negative Nellie :). That CGI var is dependent on the browser and web server working together. It will not be reliable overall because it is dependent on the client side. Someone up to no good will have no problem circumventing your barrier by simply constructing requests with the appropriate referrer.
If you want server side security then you are forced to use some form of authentication and session. This is a growing field what with oAuth and the use of Google, FB, Twitter etc as federated authenticaiton services. But plain old usernames and passwords tied to login sessions works too :)
To be clear, #Luke is saying that some users properly using your site, viewing iframe content, may have problems if they have a security setting, like an anonymity program, blocking their data, like cgi variables.
The only real solution is proper authentication and filtering on every page. If a list shows content for a user and loads details into an iframe, the iframe's page must also check that the user has access. At that point, it doesn't matter if they can get at the url.
For instance, if you get a list of user images like this.
<cfquery name="getImageList">
select imageid,imagefilename_mini
from images
where userid = <cfqueryparam value="#session.userid#">
</cfquery>
Which loads an iframe to load full sized images, you still need the and subclause
<cfquery name="getThisImage">
select imagefilename from images
where imageID = ...
and userID = ...
</cfquery>
That way, even if someone changes the image id in the url, it still only lets them see content bound to the userID.
Also, modern browsers make altering the source of a live page all too easy. I don't mean that browsers can alter the server side file, I mean that contents of the DOM as delivered to the browser. It's an incredibly useful tool for developing and debugging, but it does make mischievous/malevolent activity easier.
In chrome and firefox, you can inspect an element, change the attributes and the page will change before your eyes. Here, that works for iframe src's, so it still is within the DOM it expects to be in.
You should regard client side UI as how you'd like the page to be presented, and the way it works best but use server side safeguarding (proper validation) because it's too easy to get around client-controlled data/elements.
Related
is there a function in ColdFusion that detects whether or not a browser window is the top window? (Similar to (if (window == window.top)) in JavaScript)
The reason I ask is because I would like to make certain page elements present when the page is directly accessed by the user, and not present if my page is iframed.
CFML code runs on the CF server, whereas any considerations about browser windows obviously run on the client. CF is completely unaware of the UI configuration of the client system, all it sees is "a request". Indeed the requests don't even come from the client, they come from the web server which acts as a go-between for CF-serviced requests: CF has no interaction with the client itself.
The only information the web server gives to CF that in any way relates to the client browser is some of the stuff in the CGI scope, and obviously that's limited. And none of it relates to the configuration of browser windows / iframes.
You will need to solve this with Javascript (which I will add to the tags of your question).
To trigger different code to execute on CF given a certain browsing situation, you are going to need to use Javascript to add some information to the request to identify the situation to CF. This could be adding a parameter on the query string, or something like that.
If someone was 'wrapping' one of my products I'd want to know who and how so I could improve the experience for the user and the site owner. With that in mind, what I would do is automatically break out of any frames by default. I would then create a simple api and provide instructions to other webmasters on the proper way to include your content. Display different content once you've determined if your content is PROPERLY being included in another site. For webmasters that want to include your content:
Provide recommended height/width for the iFrame so you can
include your logo or ads with the content.
Provide anything you want them to include in the query string to help track usage.
You could even add fun stuff to your api to make your content look more integrated into the including website like reacting to url.bgcolor or url.bgimage.
You could go as simple as looking for and recording the value of some url variable like url.remoteSiteAddress or as complicated as registering the site and providing unique key. Of course there are other considerations to take into account to enforce the key. Being that you don't really care that the content is being displayed on a remote site, I suspect just recording a simple url variable is more your speed.
If a different website is putting your page in an iframe on their website, then you could use the CGI.HTTP_REFERRER variable to check if the website domain is yours or not, and load content as desired.
Using javascript or flash, is it possible to log into websites and than pull content from that page?
I am trying to make a phone app that displays content from a site that requires log in.
To the extent that this is possible, it's almost certainly not a good idea. Your phone app then has brittle dependencies on the structure of the site from which you're pulling data, and you have no way except notification of failure to detect when those dependencies change.
Does the site from which you want to pull information provide an API? That would be a better solution.
Theoretically, yes, though depending on the browser, it may not allow cross-site scripting. The only way I can think of on a mobile site to do this is either with an ajax call to submit login credentials and grab data, or with an iframe. iframe would probably work better since ajax calls would probably not set the right cookies for session id maintenance. I dont know how elegant this solution would be.
I have a web page which needs to do the following:
dynamically create an HTML fragment using JavaScript
open a new window
display the HTML in the new window
My first approach used document.write to copy the HTML into the window. This works in most cases, but it causes problems with Internet Explorer when the original window has set document.domain. Plus document.write tends to be discouraged these days.
So my second approach was to put the HTML into a hidden form, set the form's target to the new window, and POST the form. This means I need a script on the server to respond to the form, by echoing the POSTed content.
But this is dangerous, since someone could make a request that includes <script> tags in the content. How can I avoid the potential XSS risk? I guess I could filter out things like <script>, although that seems clumsy. If I were creating the HTML on the server, I could encrypt it, or add some token that can only be verified on the server. But I'm creating it on the client.
EDIT: Thanks for the filtering suggestions so far. I may choose to go this route, but I'm wondering: what if I don't want any restrictions on the HTML I create? Is there any way I can validate that the document was created by my page?
Try HTML Purifier.
Edit:
"Is there any way I can validate that the document was created by my page?"
Not unless you create another copy of the html server-side and compare. Anything in your script can be viewed by the user, although you can make it difficult for non-technical users. Anything that client-side Javascript can do, a malicious user can do on a Javascript console.
Even if you somehow verified that the request came from your script, a malicious user can modify your script using a Javascript console by inserting lines of code that produce a dangerous request. All GET and POST data must be treated as malicious.
Try PHPIDS.
PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to. Based on a set of approved and heavily tested filter rules any attack is given a numerical impact rating which makes it easy to decide what kind of action should follow the hacking attempt. This could range from simple logging to sending out an emergency mail to the development team, displaying a warning message for the attacker or even ending the user’s session.
I am using ajax in my website and in order to use the ajax, I habe to write the name of the file for example:
id = "123";
$.getJSON(jquerygetevent.php?id=" + id, function(json)
{
//do something
});
how can I protect the url? I dont want people to see it and use it...
that is a limitation of using client side scripts. there is no real way to obfuscate it from the user there are many ways to make it less readable (minify etc) but in the end an end-user can still view the code
Hi Ron and welcome to the internet. The internet was (to quote Wikipedia on the subject)
The origins of the Internet reach back to research of the 1960s, commissioned by the United States government in collaboration with private commercial interests to build robust, fault-tolerant, and distributed computer networks. The funding of a new U.S. backbone by the National Science Foundation in the 1980s, as well as private funding for other commercial backbones, led to worldwide participation in the development of new networking technologies, and the merger of many networks. The commercialization of what was by the 1990s an international network resulted in its popularization and incorporation into virtually every aspect of modern human life.
Because of these origins, and because of the way that the protocols surrounding HTTP resource identification (like for URLs) there's not really any way to prevent this. Had the internet been developed as a commercial venture initially (think AOL) then they might have been able to get away with preventing the browser from showing the new URL to the user.
So long as people can "view source" they can see the URLs in the page that you're referring them to visit. The best you can do is to obfuscate the links using javascript, but at best that's merely an annoyance. What can be decoded for the user can be decoded for a bot.
Welcome to the internet, may your stay be a long one!
I think the underlying issue is why you want to hide the URL. As everyone has noted, there is no way to solve the actual resolved URL. Once it is triggered, FireBug gives you everything you need to know.
However, is the purpose to prevent a user from re-using the URL? Perhaps you can generate one-time, session-relative URLs that can only be used in the given HTTP Session. If you cut/paste this URL to someone else, they would be unable to use it. You could also set it to expire if they tried to Refresh. This is done all the time.
Is the purpose to prevent the user from hacking your URL by providing a different query parameter? Well, you should be handling that on the server side anyways, checking if the user is authorized. Even before activating the link, the user can use a tool like FireBug to edit your client side code as much as they want. I've done this several times to live sites when they're not functioning the way I want :)
UPDATE: A HORRIBLE hack would be to drop an invisible Java Applet on the page. They can also trigger requests and interact with Javascript. Any logic could be included in the Applet code, which would be invisible to the user. This, however, introduces additional browser compatibility issues, etc, but can be done. I'm not sure if this would show up in Firebug. A user could still monitor outgoing traffic, but it might be less obvious. It would be better to make your server side more robust.
Why not put some form of security on your php script instead, check a session variable or something like that?
EDIT is response to comment:
I think you've maybe got the cart before the horse somehow. URLs are by nature public addresses for resources. If the resource shouldn't be publicly consumable except in specific instances (i.e. from within your page) then it's a question of defining and implementing security for the resource. In your case, if you only want the resource called once, then why not place a single use access key into the calling page? Then the resource will only be delivered when the page is refreshed. I'm unsure as to why you'd want to do this though, does the resource expose sensitive information? Is it perhaps very heavy on the server to run the script? And if the resource should only be used to render the page once, rather than update it once it's rendered, would it perhaps be better to implement it serverside?
you can protect (hide) anything on client, just encrypt/encode it into complicated format to real human
Okay, this just feels plain nasty, but I've been directed to do it, and just wanted to run it past some people who actually have a clue, so they can point out all the massive holes in it.....so here goes.....
We've got this legacy site & a new public beta-test one. Apparently it's super cereal that moving from one to the other is seamless, so in a manner of speaking, we need a single signon solution.
As we're not allowed to put any serious development into the legacy site (It's also in old school ASP, a language I don't care to learn.) I can't do a proper single sign-on solution, so I proposed the following: On login, the legacy site performs an AJAX post to the login controller of the new beta site, logging the user in there, it then simply proceeds with the login on the legacy site as normal. This may not be acceptable as there's code to prevent a user from being logged on twice, I'm not sure if it's been written to apply across sites.
The other idea I had was to pass a salted hash of the user's details across with their username when they try to access the 2nd site. If the hash matches the details of the user, then access is granted. This would need ASP development obviously as generating the hash on the client side would only serve to enhance the idiocy even further.
Does anyone have any thoughts?
The old ASP site must have some concept of a session if it requires a logon. You will, at a minimum, need to understand how to provide the session information to the legacy site and splice some code in to keep it copacetic if both sites need to be kept up indefinitely.
"Classic" ASP isn't so bad if you can read/write VB6, VBA, VBScript or VB.net. It probably won't be difficult to graft session initialization provided the code is half way decent.
Consider creating a common logon page for both sites + either an automatic redirect based on either the requested URL (I'm guessing the old and new sites have distinct URLs) or cookies passed with the request (the old site, if it used cookies, could identify a legacy user). This common logon page could initialize session on both the legacy site (only if required by user type) and on the new site. This will allow you to keep your new logon process unencumbered by the legacy process while maintaining the old as long as required.
Bear in mind that your first approach (AJAX request from one site to the other) won't work if the sites are on different domains, because of javascript security restrictions.
You might be able to work around this by using a hidden iframe for the post like this, but it's getting a little hacky.