I notice that when I try to access Stackoverflow through the reddit toolbar, I get a popup that says "For security reasons, framing is not allowed". See here for an example.
What exactly are those security reasons?
I realize that this might be a question for meta, but it is really more of a general web security question, so I'm giving it a shot here.
Thanks.
You can check the story on that in here.
EDIT:
Ok, so quoting from the link the problem with framing is that it's the first step to clickjacking. How is that accomplished? You can have an apparently harmless page with links which have on top of it a frame with full transparency that was carefully positioned so that when you click the links of the page, you'll be clicking links or buttons of the framed page. Although you can't see the frame (due to full transparency), your clicks will be caught by it. This results in, while the user is lead to thinking that he's just navigating on a random page, he may be actually changing his twitter status, sending emails, doing something on facebook, clicking a paypall "Yes please donate it all" button, ... imagination is the limit.
To protect its users from click jacking attacks. In simple words click jacking works like this:
The attacker hosts the malicious html file
This file loads the 'attacked' website in the background using a frame and by overlaying elements on top of the 'attacked' website it tries to trick the users into clicking something they didn't want to.
If an evil website decides it's going to frame your website, you will be framed. Period
Wrong. Mechanisms like the one implemented here in stackoverflow protect websites from being loaded inside another possibly malicious page. This way the site protects its users against click jacking attacks.
f that is the case, why do it at all? Furthermore, the target of the attack is not necessarily the site being framed, it could be any site. So again, why bother busting the frame?
The frame is used to load the 'victim's website inside a page that will try to trick the users. Busting the frame means that the site is blocking these possible click jacking attacks. Or at least adding an extra layer of security since these 'filters' can also be bypassed.
Read the original research paper about click jacking
Apparently there is a tiny chance of a possible click-jack attack as demonstrated here:
http://dsandler.org/wp/archives/2009/02/12/dontclick
So I guess it kinda makes sense, but it is awfully inconvenient.
Related
If I display:none over a form wrapper on my website contact page will a spam bot still be able to submit it?
If no, then would a possible solution be to just place a link saying - send us an email - and when clicked it display:show the wrapper with the form thus this preventing spam?
Thanks,
-O
A spam bot is usually a script that is executed and run automatically. It's not an actual human being so the bot would not care if it is actually hidden by the style or not. You could add it to the DOM in the moment the user clicks a button if you wanted to prevent a "spam bot" to abuse it.
There are many different types of spam bot out there, and many different approaches used in filling in your form (and thus: sending you spam).
For the most part these are automated scripts which don't actually 'see' the page at all but simply use the markup it finds on-page. To that end, using CSS to hide a form won't stop them at all.
On the same vein: you'll find that there are a lot of bots out there which will scrape your email address and send you spam directly if you leave a mailto: link on your site.
There's no sure-fire way of stopping spambots I"m afraid. There are a lot of techniques that you could employ to reduce it though.
The most common is to use a captcha service like recaptcha although even this isn't a concrete guarantee that some spam still won't filter through.
The other trick I tend to employ is a Honey Pot input which is relatively easy to employ and seems to do a fairly good trick of keeping the spammers out.
Spambots are meant to be fast, and they don't parse CSS or JavaScript. If you want to protect against them you can include a CAPTCHA, even a simple one, like asking the user to write the sum or product of small numbers (obviously write the request in a sentence, using letters and not numbers). A cheap solution like this should prevent most spam, but it's easily attackable, if someone wants to target you.
I wouldn't suggest to create dynamically the form, since users that aren't capable to execute JavaScript wouldn't be able to see it.
If using a honey pot, which is the most user friendly, simple and extremely effective, try not to hide your input field with the css hidden command. Bots can see this if they are complex..
Position the field absolutely at the top of the form, to the left or right, have it with no border, and the background and text colour the same as the element the form is within.
I would like to know at which stage is it okay to start manipulating HTML elements/content using Javascript so as not to impair SEO?
I have read somewhere that HTML content that is hidden using the CSS property display:none is often penalized by Google crawlers, with good reason from what I'm led to believe...I ask this as I intend to have some div panels that are initially hidden, but shown once the user clicks on an appropriate link. My intention is therefore not to hide content from users entirely - just intially to give them a better user experience - I'm afraid Google may not see it that way!
My reason for doing this is to prevent the split second (or in some cases, a full 2 seconds) of ghastly unstyled html elements (positioning), before my Javascript comes in to position, hide and neaten everything up. So adding the display:none at the forefront, and then using Javascript to toggle visibility would have been ideal, but is apparently a no-no with Google Search Engine bot.
Do you experts have any advice? Thank you!
google can now crawl AJAX sites using a simple URL substitution trick; you might be able to take advantage of this to let googlebot see a plain html version of the page for indexing instead of your load-optimized page; see http://code.google.com/web/ajaxcrawling/docs/getting-started.html
If the content in question exists on the page in the html, and is accessible to the user by the time the page finishes loading initially, then you are okay. You want to make sure google can lead a user to your page and see the content in question without requiring further interaction. Adding new content to the html after the initial load (i.e. content from the server), can be problematic for SEO. However if all content is in the html by the end of the page load, then you shouldn't get docked. Keep in mind, good SEO strategy dictates using standard methods of usability so the web crawler can access your content.
Also, each page should follow a content theme. Example: Don't abuse users by hiding five different unrelated blocks of content "medical devices, kazoos, best diners, motorcycles, toxic waste" on one page. Theoretically you could take all of your site's content and lay it out on one page using javascript and 'display:none' waiting for an 'onClick', but that smells like spam.
EDIT, additional info as pertaining to the original question:
The search engine friendly way to display content dynamically is to load it, then hide it from the user.
Understanding all the security and UI concerns with iFrames, I am implementing a toolbar similar to the DiggBar or FacebookBar.
A top bar persists across the top 30 pixels of the screen, and an iFrame displaying external content fills up the remainder of the page.
When users close the toolbar, and thereby exit my little site to go directly to the third-party site, how can I bust the iFrame properly and display the right page? If the user clicks on even one link in the iFrame, I end up showing the wrong page.
Given my understanding of browser security, and coupled with how DiggBar and FacebookBar fail to do this accurately, I'm guessing it cannot be done.
But I was hoping the Stackoverflow coders are smarter and might have an answer? :)
Thanks!
You can't. Because of browser cross site-scripting security, your bar which sits in its own frame cannot access any other frames and determine their URLs.
Not to mention that'll you'll be sued by website owners for numerous things and that you'll piss off every hacker out there.
This is the last thing you want to do if you'd like to NOT in your our office as that one guy who wanted to include everyone elses web site in their website with the owners permission.
I wouldn't speak up at any of the conventions either.
I've also added the question: "Have you ever written code or worked on code that frames other sites?" to my list of questions to use to weed out job applicants.
How to login without leaving RP by showing the OP login window in iframe ?
I am using Openid Provider for the login in my Website.
how to implement the login window inside the iframe.
Using an iframe is hugely frowned upon, since the user will be entering their credentials on a page that looks like it is your RP but is supposedly their OP instead. It teaches users to be phished.
If you're going to use an iframe anyway, very little special work has to be done. There are a few approaches you can take though. If you're taking the OpenID Identifier from the user on the page and will display an iframe based on the user input, then the easiest way is probably to use JavaScript when the user clicks "Login" to create an iframe and direct it at http://yoursite.com/redirect.aspx?openid=userSuppliedIdentifier. That page will perform OpenID discovery on the identifier and do the standard redirect to the OP, which will be limited to the iframe since that is where the request came from. The openid.return_to that you send to the OP will have to be to a special page that knows how to "pop out" of the iframe back into your main window. It's really a very similar flow to the popup window approach which I point you to a demo to below, but instead of a popup, you do it in an iframe.
Rather than an iframe, the recommended way if you don't want to send the users away momentarily from your site, is to use a popup window. Just one such example of this is DotNetOpenAuth's ajax login sample, but there are other ways to do it. It's always complicated to get it working across browsers and working securely. We'd need to know what web platform you're using (ASP.NET, PHP, Perl, Python, etc.) before going much further.
(In response to Andrew Arnott's response) I'm bothered that popups are considered the norm for redirects. It's true that Facebook has adopted this approach, but I don't think it's the final solution. From a UI/UX pov in other applications, we've tried to move away from popup windows in favor of inline types of user experience. (popup ads, for instance are extremely annoying) Popups in general are just aggravating. Hence javascript library third-party widgets such as thickbox/lightbox/shadowbox. These solutions allow for iframe loaded content.
Plaxo and Google provided an experiment showing something like a 92% return rate for users who signed in with a two click OpenID process, so the question isn't about return rate, and yes popups can work in that scenario, however...
What I think hasn't been solved is adoption rate, and this comes down to basic usability and user experience, and what most engineers seem to be missing is the fact that users are completely driven off by popups.
It's true that phishing is a problem, but I think the onus and burden for better security lies with the developer on this one, and not the user. For this reason, I still think an inline experience is best, and, unfortunately, iframes are the only methodology currently employable. There are solutions, however, to prevent phishing.
I see that you are discussing usage of iframes for OP authentication. Have you considered the fact that clickjacking becomes possible when using iframes? In fact, many OPs do not allow their pages to be included in an iframe, e.g. VeriSign, Yahoo, myOpenID, etc. They break out of iframes using the HTTP header X-FRAME-OPTIONS, or JavaScript like this:
if (top.location != location) {
top.location = self.location;
}
Take a look at http://ajaxian.com/archives/busting-framebusters-clickjacking-is-still-a-big-issue for more information.
I have an ASP.Net application which as desired feature, users would like to be able to take a screenshot. While I know this can be simulated, it would be really great to have a way to take a URL (or the current rendered page), and turn it into an image which can be stored on the server.
Is this crazy? Is there a way to do it? If so, any references?
I can tell you right now that there is no way to do it from inside the browser, nor should there be. Imagine that your page embeds GMail in an iframe. You could then steal a screenshot of the person's GMail inbox!
This could be made safe by having the browser "black out" all iframes and embeds that would violate cross-domain restrictions.
You could certainly write an extension to do this, but be aware of the security considerations outlined above.
Update: You can use a canvas utility function to get a screenshot of a page on the same origin as your code. There's even a lib to allow you to do this: http://experiments.hertzen.com/jsfeedback/
You can find other possible answers here: Using HTML5/Canvas/JavaScript to take screenshots
Browsershots has an XML-RPC interface and available source code (in Python).
I used the free assembly UrlScreenshot.dll which you can download here.
Works nicely!
There is also WebSiteScreenShot but it's not free.
You could try a browser plugin like IE7 Pro for Internet Explorer which allows you to save a screenshot of the current site to a file on disk. I'm sure there is a comparable plugin for FireFox out there as well.
If you want to do something like you described. You need to call an external process that prints the IE output as described here.
Why don't you take another approach?
If you have the need that users can view the same content over again, then it sounds like that is a business requirement for your application, and so you should be building it into your application.
Structure the URL so that when the same user (assuming you have sessions and the application shows different things to different users) visits the same URL, they always see same thing. They can then bookmark the URL locally, or you can even have an application feature that saves it in a user profile.
Part of this would mean making "clean urls", eg, site.com/view/whatever-information-needed-here.
If you are doing time-based data, where it changes as it gets older, there are probably a couple possible approaches.
If your data is not changing on a regular basis, then you could make the "current" page always, eg, site.com/view/2008-10-20 (add hour/minute/second as appropriate).
If it is refreshing, and/or updating more regularly, have the "current" page as site.com/view .. but allow specifying the exact time afterwards. In this case, you'd have to have a "link to this page" type function, which would link to the permanent URL with the full date/time. Look to google maps for inspiration here-- if you scroll across a map, you can always click "link to here" and it will provide a link that includes the GPS coordinates, objects on the map, etc. In that case it's not a very friendly url but it does work quite well. :)