I have a code that is unique to my organization that was supplied by a third party, think coupon code. What i am wondering is, is it possible for me to auto fill the required input box so that the user doesn't have to?
The site is a third party site which i don't have control over and the user would get to this site by clicking on a link on our internal intranet site. I can see this being considered a vulnerability and so prevented, but i was just curious to see if there were any options.
Whether this is possible depends on the site in question. Many sites will extract parts of the query string and populate form fields from them. For example, a link to https://www.google.com/?q=foo will populate the Google search box with the value "foo".
Check whether the site in question does something similar. A good way to do this might be by submitting invalid values to their form and looking for the value you submitted in the query string (this works more often than you might think).
There's no possibility to interact between pages on different domains.
The simpliest way is to embed an iframe but browser will prevent a communication if target is on a different domain.
As it was said in the comments only reconfiguring browser (probably Webkit has an adequate overrides) or UserJS/Greasemonkey are the only solutions if you have no access to the target site.
Related
Simple question here: I know there are lots of ways to detect a user is using adblock on the web using Javascript but I was wondering if there's a way to specifically detect when a user has whitelisted a website (as opposed to simply disable adblocking). I assume this varies based on the blocker but for the sake of simplicity lets just say AdBlock Plus.
Currently I can easily detect adblocking by simply seeing if my ads object has successfully loaded from an external script. I then store this boolean in localStorage so upon subsequent user visits I can detect if there's been a change in the user's adblocking. If so I thank them for disabling/whitelisting and update the localStorage. However it might be required to handle these two actions separately.
Any and all help appreciated. Thank you.
TL;DR : How can a user copy the current URL of an iFrame (cross-domain) ?
I want to insert in a webpage of my domain an iFrame to be able to browse other partner websites (different domains). When the user finds the page he is interested in, he needs to transfer the information (URL of the page) to my website somehow. It is fine to ask the user to do it manually, I'm just looking for the more convenient way to do that.
I am aware that cross-reference scripting restrictions to prevent XSS attacks limit what you can do with an iFrame & javascript.
I have looked at questions like this one, but the answers seem old, and from what I understand they are all trying to automatize this process with javascript, but in my case I don't need that
EDIT :
I accept a manual solution for the user. ie, a browser-specific procedure (a solution that works on Firefox/Chrome would be fine). For example, it's possible to have a look at the browser history... but I'm looking for better solutions.
Some stuff I found
Firefox
Browser history
All URLs browsed inside iFrames will still be added to the browser history
Element info
When right-clicking the iFrame, there is an additional submenu that opens in firefox (in French called "ce cadre", must be something like "this frame" in english). Then you can click on "information for this frame", and it will show many info including the URL.
I'm still looking for more convenient ways to retrieve the URL. Ideally, a shortcut would be nice !
You should be able to do something like this
jQuery("iframe").get(0).contentWindow.location.origin
Use jQuery to find the desirable iframe then use .contentWindow.location.origin to get the URL.
The Twitter input box is much more than your average INPUT or textarea. First off, it isn't an input or textarea at all. They are instead using a well crafted DIV with a "role" attribute. for the entire text; likely capturing keystokes as they occur.
If a user is logged in, they can compose a tweet. If during that very cautious 140 character sprint, they accidentally click somewhere on the page, the browser GETs another page.
But when the user hits "back", the DIV then repopulates (after a second), with the users partially drafted tweet.
In terms of browser capability, how is this "saved form field" being accomplished?
I'm guessing to achieve this, one could implement either:
local-storage
This would just involve writing to the local storage upon each keystroke. Upon loading the page, the JS populates the tweet composer with the session local storage. See a live example of utilizing local storage. This would be nice and slick, but a major limitation is that this is limited to HTML5 browsers.
AJAX callback
Similar to the first method, but instead of writing to local-storage, the draft tweet is written to a web service. Upon loading the page, a callback is made to retrieve the content; populating the tweet composer.
Cookie approach.
Similar to the local-storage, but would write to cookie cache. The benefit with this method might be more ubiquitous browser support.
I'd love for someone to explain the pro's/con's of each method along with some sample code. Bonus if it's under 140 characters for each code sample :) (j/k).
I have a requirement to paste text from a textarea into the DOM as a preview area, much like the one you get on Stackoverflow when you make a comment etc.
I allow users to insert any and all html tags, including javascript tags. I know this will allow embedded javascript and flash content etc, but I then remove all of this server side so no other user will see, they just see plain text.
However are there any security issues in letting the user insert these things in there own page?
My guess is there isn't otherwise tools like firebug would be a security risk, but I'm not sure.
However are there any security issues in letting the user insert these things in there own page?
I can't see any - the DOM is freely manipulable in the client's browser, anyway. Whether they do it using a tool like Firebug or your JavaScript function, doesn't matter.
As long as the data isn't shown unfiltered in other users' browsers, I think you're safe doing this.
Actually in rare set of circumstance, it might be an issue. It highly depends on how this particular feature works, but I can imagine making first use of CSRF to 'post' in the preview area some malicious javascript/ajax, and use that to steal cookies, change account password or whatever tickles your fancy.
So the attack would go something like this; I send a user a link to a 'legitimate' website. On that website there is a hidden payload (eg via img tag in case of GET, or hidden iframe with auto-submitting form for POST) which silently redirects the user to your website with the XSS payload, which then will be executed by the user through the injection in the preview area, for instance logging user's cookies, without him ever knowing.
Again it all depends how your preview feature works, and if you for instance use form tokens etc., but the point is that it in fact could be an issue.
I'm just looking for clarification on this.
Say I have a small web form, a 'widget' if you will, that gets data, does some client side verification on it or other AJAX-y nonsense, and on clicking a button would direct to another page.
If I wanted this to be an 'embeddable' component, so other people could stick this on their sites, am I limited to basically encapsulating it within an iframe?
And are there any limitations on what I can and can't do in that iframe?
For example, the button that would take you to another page - this would load the content in the iframe? So it would need to exist outwith the iframe?
And finally, if the button the user clicked were to take them to an https page to verify credit-card details, are there any specific security no-nos that would stop this happening?
EDIT: For an example of what I'm on about, think about embedding either googlemaps or multimap on a page.
EDIT EDIT: Okay, I think I get it.
There are Two ways.
One - embed in an IFrame, but this is limited.
Two - create a Javascript API, and ask the consumer to link to this. But this is a lot more complex for both the consumer and the creator.
Have I got that right?
Thanks
Duncan
There's plus points for both methods. I for one, wouldn't use another person's Javascript on my page unless I was absolutely certain I could trust the source. It's not hard to make a malicious script that submits the values of all input boxes on a page. If you don't need access to the contents of the page, then using an iframe would be the best option.
Buttons and links can be "told" to navigate the top or parent frame using the target attribute, like so:
This is a link
<form action="http://some.url/with/a/page" target="_parent"><button type="submit">This is a button</button></form>
In this situation, since you're navigating away from the hosting page, the same-origin-policy wouldn't apply.
In similar situations, widgets are generally iframes placed on your page. iGoogle and Windows Live Gadgets (to my knowlege) are hosted in iframes, and for very good reason - security.
If you are using AJAX I assume you have a server written in C# or Java or some OO language.
It doesn't really matter what language only the syntax will vary.
Either way I would advise against the iFrame methods.
It will open up way way too many holes or problems like Http with Https (or vice-versa) in an iFrame will show a mixed content warning.
So what do you do?
Do a server-side call to the remote site
Parse the response appropriately on the server
Return via AJAX what you need
Display returned content to the user
You know how to do the AJAX just add a server-side call to the remote site.
Java:
URL url = new URL("http://www.WEBSITE.com");
URLConnection conn = url.openConnection();
or
C#:
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://www.WEBSITE.com");
WebResponse res = req.GetResponse();
I think you want to get away from using inline frames if possible. Although they are sometimes useful, they can cause issues with navigation and bookmarking. Generally, if you can do it some other way than an iframe, that is the better method.
Given that you make an AJAX reference, a Javascript pointer would probably be the best bet i.e. embed what you need to do in script tags. Note that this is how Google embed things such as Google Analytics and Google Ads. It also has the benefit of also being pullable from a url hosted by you, thus you can update the code and 'voila' it is active in all the web pages that use this. (Google usually use version numbers as well so they don't switch everyone when they make changes).
Re the credit card scenario, Javascript is bound by the 'same origin policy'. For a clarification, see http://en.wikipedia.org/wiki/Same_origin_policy
Added: Google Maps works in the same way and with some caveats such as a user/site key that explicitly identify who is using the code.
Look into using something like jQuery, create a "plugin" for your component, just one way, and just a thought but if you want to share the component with other folks to use this is one of the things that can be done.