I am looking for a way to use Jquery (or any other open source script) to pull the URL of a particular webpage. I am working on a service that will pull the original URL of any webpage - consider a scenario where I load google.com but have entered yahoo.com in the address bar (without pressing enter key) - the script should be able to validate if the the URL on the address bar is the same as the actual URL or if it is different.
There is no way to do this. And there better not be any in the making. There is no reason to need such information, and it's a violation of user privacy.
No dear, Absolutely no way to do this.
and i agree with #bjb568 , its definitely violation of user privacy.
you can get the current page URL in your script.
But why you need this kind of functionality.?
i will advise you to find any alternative of your requirement,
You can get the current location of the page using regular Javascript, but I do not think you can get the currently typed address bar, although I do not see where you should ever need to.
In response to everyone on here saying it is a breach of user privacy: I don't think grabbing the URL or the typed address bar on the current page is a breach of privacy or security unless you are somehow able to change the address bar to make it seem like you are on a different site - like being on Google.com and it saying you are on Yahoo.com. But, from the OP's original question, it just seems like he wants to get the information; not change it.
Using Javascript, you can use var location = document.location.href
The closest you can get to change the addressbar is window.history.pushState(), but browsers have a security settings that do not allow domains outside of the current domain to be used.
My first question that comes to mind: "Why on earth does he want to do that???" If it was possible you would have to interact with each browser directly which is not possible.
jQuery is just a client-language that interprets with each browsers "engine" (that handles rendering of html, javascript etc) and not the browser itself (menus, settings etc). Secondly, if it would work: How often would you check? Each keypress? Every 10 seconds? It would not be doable in a proper way - even if it was possible.
I think you should rethink your issue and try to explain why you want to do this. It might be other (better) solutions that would handle your issue in a better way.
Related
I'm getting Client DOM Open Redirect security issue on scan for the following piece of code.
The issue shows up where I'm initializing the variables 'myPath' and 'myHost'.
I'm not able to understand how is that open to phising attack and how do I fix it.
Could anyone please help?
var query = this.value;
var myPath = window.location.href.substring(window.location.href.indexOf("/myapp"), window.location.href.indexOf(".html"));
var myHost = window.location.href.substring(0, window.location.href.indexOf("/myapp"));
query = encodeURIComponent(query);
if(myPath!==null){
query = query + "mysite:" + myHost + myPath;
}
The problem is that you are taking user input (values from the url bar) and you redirect to it. This may or may not be exploitable in any meaningful attack, but static scanners don't understand your application logic - for a static scanner it's just user input that will directly be used in a redirect.
Based on the info in the question, I can't think of a valid attack, because I think it just makes the same url that the user already visited, without .html in the end, and also without the # part if there was any. So I think the user will be redirected to a page that he visited already. However, that doesn't at all mean there is no vulnerability, and it also depends on other related code. What happens when the user can access a page with this code without any .html in the url bar would for example affect the outcome, so would another vulnerability that allows (partial) control of the url bar, a possible scenario for something like an SPA. So there is not enough info in the question to decide whether it's actually secure or not.
As for the fix, make sure you only redirect where you want to, and not to any user input. For example the host part (maybe even the path) could be written in the page by the server, but I understand that would not be the case for something like an SPA. You could implement whitelist validation to ensure no rogue redirects happen. Maybe it's already good, in which case you can set this finding to mitigated in the scanner you used, but think about edge cases, and how this can be abused by an attacker. Can he trick this with # in the path? Can he load a page with this code from an url that doesn't have .html? Or has it multiple times? What if he registers a domain like someattack.html.hisdomain.com and has a valid user visit it? :)
The url bar is a tricky thing, because it's user input, but the attacker doesn't have full control - he must hit an application page, otherwise this javascript won't be loaded. Still the reason this is flagged by a static scanner is because an attacker may have some control, and in case of javascript-heavy single page applications, probably a bit more because of all the url bar manipulation going on.
I am wanting to set up a javascript to accomplish the following:
A user opens up a bookmarked webpage and the script checks whether or not it came from a referring domain (say, site.com) and if not redirects them automatically to anothersite.com. The goal is so that only when users come from the anothersite.com site will the site.com page come up. Hope this makes sense.
I would normally use PHP for this but can't for this project so we're stuck doing this with javascript.
Look into document.referrer to get the referrer's URL, extract the domain from it and then validate.
I didn't quite get the part of "opens up a bookmarked" since it has been said that knowing that much is not easily accomplished Is there a way to know if someone has bookmarked your website?
..but to inspect where it came from I would look into How do you get the previous url in Javascript?
plus then make your own if else stuff and use window.location.href = "your_site_url"; to direct him the page you wanted, job done!
I have a DNS, and each computer has a website to make different folders / documents accessible in a different way than just browsing to that computer. For example, \Media takes me to the media servers pages (Music, Movies, etc.), and \Aurora takes me to the media server's website. Instead of it displaying "Aurora" in the address bar, however, I would like to use a script to replace it with "Aurora - Media Server Website, (server information)." I would really like to learn this method, I tried to look somewhere and it mentioned JavaScript would probably be the easiest way to do this. This would be helpful if I actually knew JavaScript =p If there is an easier way to do this, that would also be much appreciated =]
In a nutshell, I want the address of a website, //Aurora, hosted on a local DNS server to appear as "Aurora - Media Server Website (server information)." What would be a possible way to implement this?
Just use the replaceState method of window.history in JavaScript like so:
window.history.replaceState({}, '', url);
(params are: data (object), title (string), url (string));
I do it all the time to modify the URL, to remove the query string when using AJAX.
If you want to change the hostname then you have to change the DNS so that the machine gets the name you want. You can't use spaces or parenthesis in hostnames though.
The closest you can come with JS is the history API which only lets you modify the local part of the URI.
It is not possible to change the contents of the address bar due to security reasons (Phishing websites would exploit this heavily).
I would suggest simply changing the title of the page.
<title>Title goes here</title>
If you want to change it using javascript (for some reason) you can do this:
document.title = "The new title goes here.";
I want to implement AJAX like facebook, so my sites can be really fast too. After weeks of research and also knowing about bigPipe (which is not ajax).
so the only thing left was how they are pulling other requests like going to page/profile, I opened up firebug and was just checking things there for what I get if I click on different profiles. But the problem is, firebug doen'tt record any such request and but still page gets loaded with AJAX and changes the HTML also, firebug does show change on html.
So I'm wondering, if they are using iframe to block firebug to see the request or what? Because I want to know how much data they pull on each request. Is it the complete page or only a part of page, because page layout changes as well, depending on the page it is (for example: groups, page, profile, ...).
I would be really grateful if a pro gives some feedback on this, because i cant find it anywhere for weeks.
The reason they use iframe, usually its security. iframes are like new tabs, there is no communication between your page and the iframe facebook page. The iframe has its own cookies and session, so really you need to think about it like another window rather than part of your own page (except for the obvious fact that the output is shown within your page).
That said - the developer mode in chrome does show you the communications to and from the iframe.
When I click on user's profile at facebook, then in Firebug I clearly see how request for data happens, and how div's content changing.
So, what is the question about?
After click on some user profile, Facebook does following GET request:
http://www.facebook.com/ajax/hovercard/user.php?id=100000655044XXX&__a=1
This request's response is a complex JS data, which contain all necessary information to build a new page. There is a array of profile's friends (with names, avatar thumbnails links, etc), array of the profile last entries (again, with thumbnails URLs, annotations, etc.).
There is no magic, no something like code hiding or obfuscation. =)
Looking at face book through google chromes inspector they use ajax to request files the give back javascript which is then used to make any changes to the page.
I don't know why/wether Facebook uses IFRAMEs to asynchroneously load data but I guess there is no special reason behind that. We used IFRAMEs too but now switched to XMLHttpRequest for our projects because it's more flexible. Perhaps the IFRAME method works better on (much) older browsers, but even IE6 supports XMLHttpRequest fine.
Anyway, I'm certain that there is no performance advantage when using IFRAMEs. If you need fast asynchroneous data loading to dynamically update your page, go with XMLHttpRequest since any modern browsers supports it and it's fast as HTTP can be.
If you know about bigPipe then you will be able to understand that,
As you have read about big pipe their response look like this :-
<script type="text/javascript"> bigpipe.onPageArrive({ 'css' : '', '__html' : ' ' }); </script>
So if they ajax then they will not able to use bigpipe, mean if they use ajax and one server they flush buffer, on client there will no effect of that, the ajax oncomplete only will call when complete data received and connection closed, In other words they will not able to use their one of the best page speed technique there,
but what if they use iframe for ajax,, this make point,, they can use their bigpipe in iframe and server will send data like this :-
<script type="text/javascript"> parent.bigpipe.onPageArrive({ 'some' : 'some' });
so server can flush buffer and as soon as buffer will clear, browser will get that, that was not possible in ajax case.
Important :-
They use iframe only when page url change, mean when a new page need to be downloaded that contains the pagelets, for other request like some popup box or notifications etc they simple send ajax request.
All informations are unofficial, Actually i was researching on that, so i found,
( I m not a native english speaker, sorry for spelling and grammer mistakes! )
when you click on different profile, facebook doesn't use ajax for loading the profile
you simple open a new link plain old html... but maybe I misunderstood you
So I have two documents dA and dB hosted on two different servers sA and sB respectively.
Document dA has some JS which opens up an iframe src'ing document dB, with a form on it. when the form in document dB is submitted to a form-handler on server sB, I want the iframe on page dA to close.
I hope that was clear enough. Is there a way to do this?
Thanks!
-Mala
UPDATE: I have no control over dA or sA except via inserted javascript
This isn't supposed to be possible due to browser/JavaScript security sandbox policy. That being said, it is possible to step outside of those limitations with a bit of hackery. There are a variety of methods, some involving Flash.
I would recommend against doing this if possible, but if you must, I'd recommend the DNS approach referred to here:
http://www.alexpooley.com/2007/08/07/how-to-cross-domain-javascript/
Key Excerpt:
Say domain D wants to
connect to domain E. In a nutshell,
the trick is to use DNS to point a
sub-domain of D, D_s, to E’s server.
In doing so, D_s takes on the
characteristics of E, while also being
accessible to D.
Assume that I create page A, that lies withing a frame that covers the entire page.
Let A link to yourbank.com, and you click on that link. Now if I could use javascript that modifies the content of the frame (banking site), I would be able to quite easily read the password you are using and store it in a cookie, send it to my server, etc.
That is the reason you cannot modify the content in another frame, whose content is NOT from the same domain. However, if they ARE from the same domain, you should be able to modify it as you see fit (both pages must be on your server).
You should be able to access the iframe with this code:
window["iframe_name"].document.body
If you just want the top-level to close, you can just call something like this:
window.top.location = "http://www.example.com/dC.html";
This will close out dA and sent the user to dC.html instead. dC.html can have the JS you want to run (for example, to close the window) in the onload handler.
Other people explained security implications. But the question is legitimate, there are use cases for that, and it is possible in some scenarios to do what you want.
W3C defines a property on document called domain, which is used to check security permissions. This property can be manipulated cooperatively by both documents, so they can access each other in some cases.
The governing document is DOM Level 1 Spec. Look at the description of document. As you can see this property is defined there and … it is read-only. In reality all browsers allow to modify it:
Mozilla's document.domain description.
Microsoft's domain property description.
Modifications cannot be arbitrary. Usually only super-domains are allowed. It means that you can make two documents served by different server to access each other, as long as they have a common super-domain.
So if you want two pages to communicate, you need to add a small one-liner, which should be run on page load. Something like that should do the trick:
document.domain = "yourdomain.com";
Now you can serve them from different subdomains without losing their accessibility.
Obviously you should watch for timing issues. They can be avoided if you establish a notification protocol of some sort. For example, one page (the master) sets its domain, and loads another page (the server). When the server is operational, it changes its domain and accesses the master triggering some function.
A mechanism to do so would be capable of a cross-site scripting attack (since you could do more than just remove a benign bit of page content).
A safe approach would limit to just the iframe document emptying/hiding itself, but if the iframe containing it is fixed size, you will just end up with a blank spot on the page.
If you don't have control over dA or Sa this isn't possible because of browser security restrictions. Even the Flash methods require access to both servers.
This is a bit convoluted but may be more legitimate than a straight XSS solution:
You have no control over server A other than writing javascript to document A. But you are opening an iframe within document A, which suggests that you only have write-access to document A. This a bit confusing. Are you writing the js to document A or injecting it somehow?
Either way, here is what I dreamed up. It won't work if you have no access to the server which hosts the page which has the iframe.
The user hits submit on the form within the iframe. The form, once completed, most likely changes something on the server hosting that form. So you have an AJAX function on Document A which asks a server-side script to check if the form has been submitted yet. If it has, the script returns a "submitted" value to the AJAX function, which triggers another js function to close the iframe.
The above requires a few things:
The iframe needs to be on a page hosted on a server where you can write an additional server-side script (this avoids the cross-domain issue, since the AJAX is pointing to the same directory, in theory).
The server within the iframe must have some url that can be requested which will return some kind of confirmation that the form has been submitted.
The "check-for-submitted" script needs to know both the above-mentioned URL and what to look for upon loading said URL.
If you have all of the above, the ajax function calls the server-script, the server-script uses cURL to go the URL that reflects if the form is done, the server-script looks for the "form has been submitted" indicators, and, depending on what it finds, returns an answer of "not submitted" or "submitted" to the ajax function.
For example, maybe the form is for user registration. If your outer document knows what username will be entered into the form, the server-side script can go to http://example.org/username and if it comes up with "user not found" you know the form has yet to be submitted.
Anything that goes beyond what is possible in the above example is probably outside of what is safe and secure anyway. While it would be very convenient to have the iframe close automatically when the user has submitted it, consider the possibility that I have sent you an email saying your bank account needs looking at. The email has a link to a page I have made which has an iframe of your bank's site set to fill the entire viewable part of my page. You log in as normal, because you are very trusting. If I had access to the fact that you hit submit on the page, that would imply I also had access to what you submitted or at the very least the URL that the iframe redirected to (which could have a session ID in or all sorts of other data the bank shouldn't include in a URL).
I don't mean to sound preachy at all. You should just consider that in order to know about one event, you often are given access to other data that you ought not have.
I think a slightly less elegant solution to your problem would be to have a link above the iframe that says "Finished" or "Close" that kills the iframe when the user is done with the form. This would not only close the iframe when the user has submitted the form, but also give them a chance to to say "oops! I don't want to fill out this form anyway. Nevermind!" Right now with your desired automatic solution, there is no way to get rid of the iframe unless the user hits submit.
Thank you everybody for your answers. I found a solution that works:
On my server, I tell the form to redirect to the url that created the iframe.
On the site containing the iframe, I add a setInterval function to poll for the current location of the iframe.
Due to JS sandboxing, this poll does not work while the url is foreign (i.e. before my form is submitted). However, once the url is local (i.e. identical to that of the calling page), the url is readable, and the function closes the iframe. This works as soon as the iframe is redirected, I don't even need to wait for the additional pageload.
Thank you very much Greg for helping me :)