Is there a way with javascript on a page to tamper http requests done by other scripts (on same page)? The other scripts can be from external domains.
Let's say on a page X a script loaded from an external domain performs an http get like GET http://www.example.com?foo=bar is it possible that a previously loaded script in the same page X can capture this request, and tamper with it so it becomes GET http://www.example.com?foo=qux?
In jquery i can achieve this by wrapping the ajax get post methods. But is this possible for plain javascript, no frameworks, working across all page and client's http requests?
It seems to me that for this to be done, the script must be able to override something very deep in the core. If i have to guess i would say it's not possible by design and because of security. What do you think?
p.s. no proxies, no external tools.
No you can't capture the HTTP request going out of your app, once it has gone out of your app.
However, there is one work around possible
if you want to alter some parameters before it goes of your app,
All the other request from your website are AJAX requests
They are invoking your custom method, say customAjax() which can
alter the parameters of the actual request that will go out.
Related
I'm attempting to create an app with Node.js (using http.createServer()) which will be a single page application with requests for data via XMLHttpRequest. To do this I need to be able to differentiate between a user navigating to my domain, and AJAX requests and requests generated by the browser for linked resources.
If the request is from the user I always want to return the index.html page which will handle requesting content but if the request is browser generated or AJAX and is for CSS, Javascript or other linked files I want to serve those files. Is there any way to detect this?
Looking at the request headers for the different file types I saw the referer header appeared when the request for content was generated by the page. I figured that was the solution I was looking for but that header is also set when a user clicks on a link to the page making it useless.
The only other thing which seems to change is the accept header which could sort of work but might not be a catch all solution. Any user requests always seem to have text/html as the preferred return type regardless of which url was entered. I could detect that but I'm pretty sure AJAX requests for html files would also have that accept header which would cause problems.
Is there anything I'm missing here (any headers or properties I can look for)?
Edit: I do not need the solution to protect files and I don't care about users bypassing it with their own requests. My intention is not to hide files or make them secure, but rather to keep any data that is requested within the scope of the app.
For example, if a user navigates to http://example.com/images/someimage.jpg they are instead shown the index.html file which can then show the image in a richer context and include all of the links and functionality to go with it.
TL/DR: I need to detect when someone is trying to access the app to then serve them the index page and have that send them the content they want. I also need to detect when the browser has requested resources (JS, CSS, HTML, images, etc) needed by the app to be able to actually return the resource not the index file.
In terms of HTTP protocol there are NO difference between a user-generated-query and a browser-generated-query.
Every query is just... a query.
You can make a query with a command line, with a browser, you can click a link, send some ascii text via telnet, request a proxy which will make the query for you, the server goal is never to identify how the query was requested by the user.
See for example a request made by a user on a reverse proxy cache, this query will never reach your server (response comes from the cache), the first query made to build this response could have been made by a real user or by a browser.
In terms of security trying to control that the user is never requesting data by-himself cannot be done by detecting that the query is a real human click (and search google for clickjacking if you want to be afraid). Every query that a browser can make can also be played by the user, every one, you have no way to prevent that.
Some browsers plugins are even doing pre-fetching, detecting links on the page and making the request before you do it yourself (if it's a GET query).
For ajax, some libraries like JQuery will add an X-Requested-With: XMLHttpRequest header, and this is used on most framework to detect ajax mode.
But it is more robust to depend on a location policy for that (like making your ajax queries with a /format/ajax, which could also be used on other ways (like /format/json, /format/html, or /format/csv).
Spending time on a location policy based routing is certainly more usefull.
But one thing can make a difference, POST queries are not indempotent, it means the browser cannot make a POST query without a real user interaction, because a POST query may alter the state of the session or the state of the server data (but js can make POST queries, this is just a default behavior of browsers). The browser will never automatically retrieve a POST query, so you could make a website where all users interactions are POST queries (via forms or via some js altering link clicks to send POST ajax queries instead). But I'm not that's your real goal.
Not technically an answer to the question but I found a simple solution which does what I want: prefix all app based requests with a subdomain eg. http://data.example.com/. It's then really simple to check the host header for that subdomain: if present send the resource else send the index page.
Is there any code in javascript like www.facebook.com.getElementById("some id").innerHTML;?
I was thinking if there's a way I could access the tags of another website (not written by me). I want to know if I can write a script, which when run, will,for example, fill the login form of a website.
Thanks!
No there is not.
If you would request another Website you should send an AJAX request.
To prevent cross-site-scripting, most modern browsers have disabled AJAX-requests to other Domains.
There would be the possibility that you request one php file on your own domain, which would request an external site and returns the external site to you.
Then you could perform these calls.
I have a web-page which content must be constructed on the fly. When user clicks some parts of the web-page, it must load information from the file which is placed on the server in the same directory along with web-page into special content <div>.
As far as I get it, with JavaScript, I must use ajax technology so I have a question: should I configure server so that he can handle ajax requests specifically, or is it just simple GET over HTTP request which should be supported by any web-server anyway?
And my second question - if ajax is technology, which will work out only if server is properly configurated, can I do what I need by simple GET from JavaScript somehow?
Also, if it is easier to use server-side scripting, how can it be done by VBScript?
AJAX requests are very much like usual HTTP requests. So you do not need to configure your server in any special way to make them work.
A usual server should already support at least GET and POST requests.
One thing, that might be important for you, however, is, that as long as there is no other "protection" for the files, everyone can access them directly, too. So in case the AJAX-loaded content contains some kind of user sensitive data, you should put some access control in place!
AJAX involves server side scripting, so it doesn't make sense to say it is easier to use server side scripting. Additionally, AJAX is nothing more than GET or POST requests that a script carries out for you asynchronously, allowing you to use the server responses in a document without reloading the entire page.
AJAX in and of itself is not so much of a technology as a technique. You can use AJAX, for example, without ever using the ubiquitous XmlHttpRequest object supplied by javascript.
With the jQuery AJAX methods, you can request text, HTML, XML, or JSON from a remote server using both HTTP Get and HTTP Post - And you can load the external data directly into the selected HTML elements of your web page...
and yes, no configa server properly
i suggest to you jquery framework (no server configure needed) (see also Sirko answer)
http://api.jquery.com/jQuery.ajax/
this is help you to load dynamic content see this
I'm working on the project where the client has the back-end code in ServerA, and my front-end code, which is supposed to talk to back-end via AJAX requests is on ServerB, and they are in different domains. Because of the same origin policy, I'm not able to make those requests successfully (neither POST nor GET). Is it possible to enable it somehow without changing the back-end code to handle the JSONP? eg., white list that particular domain, or something?
I tried to emulate this in my local network where the back-end code is running on 10.0.1.4 (different machine), and I'm accessing it from localhost (apache), but couldn't figure out anything that doesn't require using jsonp. When calls are made, I'm not even seeing anything in the logs in the back-end, but it works fine from the REST client and by just loading the URL for GET requests. How are public API requests implemented that are not using JSONP?
I need at least one method (POST or GET) to work. Thanks.
Is it possible to enable it somehow without changing the back-end code
to handle the JSONP? eg., white list that particular domain, or
something?
Yes, you could write a server side script on your domain that will serve as a bridge between your and the remote domain and then send an AJAX request to your script.
Don't expect miracles. If you don't have control over the remote domain you are busted. The same origin policy restriction that's built into browsers for security reasons busts you. Well, you could always write your own browser that doesn't implement this policy, but I think you get my point.
Common workarounds include JSONP and CORS but they involve control over the remote domain. If you don't have control then read the my previous sentence as well as my first sentence.
Here's a nice guide I invite you consulting that covers some common techniques allowing to achieve cross domain AJAX with jQuery. Then adapt the one that fits best your scenario. And there's always the heavy artillery solution that involves bridging the 2 domains with a server side script which works bullet-proof in 100% of the cases if none of the other workarounds help you.
Is it possible to enable it somehow without changing the back-end code to handle the JSONP? eg., white list that particular domain, or something?
Hmmm, mostly no. You must allow JSONP or "white list" things via CORS (which is very easy to do). Or you can use YQL as a cross-domain proxy.
Three solutions posted here:
http://devlog.info/2010/03/10/cross-domain-ajax/
I've tried the third option since it just worked for me.. and I didn't have to go through any extra stress as it just handled things just like a regular ajax call.
Updating answer as this was posted 2 years ago:
LINK ABOVE NO LONGER WORKS.
Server side proxy:
the old page also talks about using a server side proxy, which means your server makes a call to another server, grabs all the data and sends it off to a page resting on that server. There is no problem for one server to fetch data from another server. So then your page can make a regular ajax call to that server. I didn't go with this option as it required more manual labor. So I'd suggest going with the option detailed here:
JSONP with jQuery
Make sure the provider supports JSONP.
Set the dataType option to jsonp, and if the provider uses a different GET param other than 'callback', specify the jsonp option to that parameter name.
$.ajax({
// ... Use the AJAX utility as you normally would
dataType: 'jsonp',
// ...
});
jQuery will generate a unique callback name for this request (something like json1268267816). Thus, the reply from a web service would be something like:
json1268267816({'uid': 23, 'username': 'Chroder', 'name': 'Christopher Nadeau'});
But jQuery handles it all seamlessly, so you as the developer just handle it like a normal AJAX request using the same jQuery success/failure/complete callback hooks.
Drawbacks:
The first limitation to this method is that you have to rely on the provider to implement JSONP. The provider needs to actually support JSONP -- they need to wrap their JSON data with that callback function name.
Then the next limitation -- and this is a big one -- is that JSONP doesn't support POST requests. Since all data is passed in the query string as GET data, you are severely limited if your services require the passing of long data (for example, forum posts or comments or articles). But for the majority of consumer services that fetch more data than they push, this isn't such a big problem.
However,
Using a library like jQuery that supports JSONP, these details of inserting the special script tag and creating the special callback function are all taken care of automatically. Using a JS library, usually the only difference between JSONP and real AJAX is that you enable a 'jsonp' option.
I have an application on one domain which needs to get data from an application on another domain.
I would like to use an iframe based cross domain ajax tool such as porthole.js to implement the following:
My application loads a page on the other server in an iframe.
A message is sent using porthole to the iframe.
The page on the other server checks to make sure the calling url is valid, and reads in the url of the ajax request it will make from the message.
The remote page then uses the passed url to make an ajax request.
The results are passed back to my application.
This solution lets me use the remote json data without systematically altering all of the services, which are built and managed by another team. If it doesn't work, I would work with them to use a system that uses porthole.js or jsonp for cross domain scripting.
The point that concerns me, though, is step 4. Does this count as an ajax call from the remote document inside the iframe, which would be able to make ajax calls against it, or does it count as a call from the outer window, which can't use ajax to call that domain?
Jeez, just use CORS. It's a one-line change to the web-server config.