I can't see from the docs how it should work. Debugging with Firebug did not help either. Maybe I would have to sit for some hours to understand it better.
The basic problem is, that I'd like to check the availability of various geo services (WFS,WMS). Due to the problem of XSS browser restrictions XmlHttpRequest did not work.
I guess the Socket interface is the proper one to use, since I am not able to implement some CORS scenarios because I have no influence on the external services.
Using the following code works fine and returns some requested data (Firefox popup for the downloaded XML response):
var socket = new easyXDM.Socket({
remote: "http://path.to/provider/", // the path to the provider
onReady:function(success) {
alert(success); // will not be called
}
onMessage:function(message, origin) {
alert(message, origin); // will not be called
}
});
However I did not find a way (trying with the onReady and onMessage callbacks) to somehow get to some HTTP status object that I can process to determine which kind of response, e.g. 200, 404, I got.
Maybe it's the complete wrong way to solve this?
Sadly even my bounty did not help to get answers so I took a quick look around to gather some more infos on the issue myself...
First...
the general problem of XSS
Looking at XSS and some related issues/links discusses more the problems than solutions (which is ok).
Looking at the related Firefox docs about the JavaScript same-origin policy it becomes clear that our global slogan Security over Freedom1 is also applied in this area.
(Personally I don't like this way of solving the problem and would have liked to see another way to solve these problems as described at the end of this answer.)
1: nicely attributed by Benjamin Franklins (founder of the US) statement: He who sacrifices freedom for security deserves neither.
the CORS solution (=> external server dependencies)
The only supported standard/robust way seems to be to use the CORS (Cross Origin Resource Sharing) functionality.
Basically that means the external server has to at least deliver some CORS-compliant info (HTTP Header Access-Control-Allow-Origin: *) to allow others (= the client browser) to request data/content/.... Which also means that if one does not have control over the external server there will be no general robust client-side/browser-way to do this at all :-(.
robust solution for server/client applications (if no external server control)
So if our external server does not support CORS or it is not configured to be usable by our requester origin (protocol/domain/port combination) it seems best to do this kind of access on our own applications server-side where we do not have these kinds of restrictions, but of course other implications.
client-side solution I would have liked to see
Some introduction first to understand the client-side world I experience browsing the web as a standard user ...
I personally do not like to be tracked when browsing the web nor do I like to be slowed down with poor hardware or network resources nor do I want to get exposed to simply avoided data security issues when browsing the web. That's why I am using Firefox with various useful plugins like RequestPolicy, AdBlock Plus, Ghostery, Cookie Monster, Flashblock ... . This already shows a complexity, no average user usually could/would handle. But especially looking at RequestPolicy it shows how access to external resources can be handled on the client-side.
So if e.g. Firefox (without these plugins) would support some functionality to show the user a dialog similar to RequestPolicy, that could state something like the following, we could loosen the one origin policy:
[x] 'http://srcdomain.com' (this site)
[ ] all sites (select to block/allow for all sites)
would like to request some data from
[x] 'http://dstdomain.com'
[x] 'http://dst2domain.com'
in a generally considered UNSECURE way.
You can selected one of the following options about how to proceed with
access to the selected sites from the selected sites:
[x] block always (generally recommended)
[ ] block only for this session
[ ] allow always (but not to subreferences) [non-recursively]
[ ] allow only for this session (but not to subreferences) [non-recursively]
[ ] allow always (and all subreferences) [recursively]
[ ] allow only for this session (and all subreferences) [recursively]
Of course this should be fomulated as clear as possible to the average user which I certainly did not do here and may be handled also by a default in the settings like the other existing technologies (Cookie Handling, JavaScript Handling, ...) do it.
This way I could solve the problem I have without much hassle, because I could nicely handle the amount of user setup required for this in my situation.
answer regarding easyXdm
I guess since they recommend CORS as well and depend on the browsers this is the only robust way although some workarounds may still exist depending on browsers/versions/plugins like Flash and so on may exist.
Related
I was wondering why alert() is quite often used to demonstrate XSS vulnerabilities. If I am not mistaken XSS means that the attacker should be able to establish two-way communication between infected client and attacker's server. It is just that this is a quite visual way to demonstrate that the attack is possible (as it uses the same characters as the actual payload would have) or is there something more? I tried to look it up online but found nothing...
You're overthinking it. it's demonstrated with an alert because when the alert is shown, it means the attacker was able to insert javascript code into your page and that code was executed as if you had put it there yourself. ... so from the perspective of the client (visitor) this code is coming from you, and they don't know anything about the attacker - which is what the attacker wants.
It's just like a "hello world" program but from the XSS world. It's easy to check, minimalistic, checking that you can at least execute some javascript function (alert). While you're looking for an XSS, the payload itself is not as important as the "can I actually inject some javascript here?" question.
Basically, it's a 2 steps approach.
Find a vulnerable parameter. (using alert or any other simple function)
Now let's have some fun with it.
If I am not mistaken XSS means that the attacker should be able to establish two-way communication between infected client and attacker's server.
Not always. Sometimes, 1-way communication is enough:
Just send data to your server, no response required. It's very useful for the stored XSS case (when let's say you can put random javascript code into a comment visible to other users)
You can inject some HTML asking the user to open another website and do whatever you want. (XSS + social engineering)
To summarise: alert is a simple function sufficient to check if you can inject javascript, like "hello world" to check that your setup is working. If you're successful -> it's time to make it more complicated.
Edit: in a real attack, people usually check more options, because the "alert" keyword is blocked by most security filters. It doesn't mean that the XSS is not there ;) But "alert" is a very convenient example for tutorials, so you'll see it everywhere.
I was wondering why alert() is quite often used to demonstrate XSS vulnerabilities.
Simply because the alert() method is the best option to show people that you are able to insert JS code into the page.
If I am not mistaken XSS means that the attacker should be able to establish two-way communication between infected client and attacker's server.
Kinda. XSS just means that the attacker is able to inject malicious JS into the page.
It is just that this is a quite visual way to demonstrate that the attack is possible (as it uses the same characters as the actual payload would have) or is there something more?
It's just the visual way.
However JS can be sandboxed in iframes etc. so the alert('XSS') is not the best method to show that you are able to inject malicious code.
The best way is to use some information from the page itself. For example
alert(`XSS attack on ${window.location.host}'s page: "${document.title}"`)
is a lot better way to demonstrate. It shows that you can have access to window properties (redirect) and document (modify) as well.
On this page it would display:
XSS attack on stackoverflow.com's page: "XSS, why is alert(XSS) used to find/demonstrate xss vulnerabilities? - Stack Overflow"
Is there any method to identify from which source an API is called? source refer to IOS application, web application like a page or button click( Ajax calls etc).
Although, saving a flag like (?source=ios or ?source=webapp) while calling api can be done but i just wanted to know is there any other better option to accomplish this?
I also feel this requirement is weird, because in general an App or a web application is used by n number of users so it is difficult to monitor those many API calls.
please give your valuable suggestions.
There is no perfect way to solve this. Designating a special flag won't solve your problem, because the consumer can put in whatever she wants and you cannot be sure if it is legit or not. The same holds true if you issue different API keys for different consumers - you never know if they decide to switch them up.
The only option that comes to my mind is to analyze the HTTP header and see what you can deduce from it. As you probably know a typical HTTP header looks something like this:
You can try and see how the requests from all sources differ in your case and decide if you can reliably differentiate between them. If you have the luxury of developing the client (i.e. this is not a public API), you can set your custom User-Agent strings for different sources.
But keep in mind that Referrer is not mandatory and thus it is not very reliable, and the user agent can also be spoofed. So it is a solution that is better than nothing, but it's not 100% reliable.
Hope this helps, also here is a similar question. Good luck!
In REST URIs should be opaque to the client.
But when you build interactive javascript-based web-client for your application you actually have two clients! One for interaction with server and other one for users (actual GUI). Of course you will want to have friendly URIs, good enough to answer the question "where am I now?".
It's easier when a server just respond with HTML so people can just click on links and don't care about structure. Server provides URIs, server receives URIs.
It's easier with desktop client. The same staff. Just a button "show the resource" and user doesn't care what the URI is.
It's complicated with browser clients. There is the address bar. This leads to the fact that low-level part of web-client relies on the URIs structure of a server. Which is not RESTful.
It seems like the space between frontend and backend of the application is too tight for REST.
Does it mean that REST is not a good choice for reactive interactive js-based browser clients?
I think you're a little confused...
First of all, your initial assumption is flawed. URI opacity doesn't mean URIs have to be cryptic. It only means that clients should not rely on URI semantics for interaction. Friendly URIs are not only allowed, they are encouraged for the exact same reason you talk about: it's easier for developers to know what's going on.
Roy Fielding made that clear in the REST mailing list years ago, but it seems like that's a myth that won't go away easily:
REST does not require that a URI be opaque. The only place where the
word opaque occurs in my dissertation is where I complain about the
opaqueness of cookies. In fact, RESTful applications are, at all
times, encouraged to use human-meaningful, hierarchical identifiers in
order to maximize the serendipitous use of the information beyond what
is anticipated by the original application.
Second, you say it's easier when a server just respond with HTML so people can just follow links and don't care about structure. Well, that's exactly what REST is supposed to do. REST is merely a more formal and abstract definition of the architecture style of the web itself. Do some research on REST and HATEOAS.
Finally, to answer your question, whether REST is a good choice for you is not determined by client implementation details like that. You can have js-based clients, no problem, but the need to do that isn't reason enough to worry too much about getting REST right. REST is a good choice if you have projects with long term integration, maintainability and evolution goals. If you need something quick, that won't change a lot, or won't be integrated with a lot of different clients and services, don't worry too much about REST.
Edit: To clarify, this question concerns building GUI applications on HATEOAS APIs, how to design interfaces built on hypermedia "discoverability" (ie. dynamic) principles, and specifically dealing with avoiding purely "modal" GUIs that "link" back to "home" for global functionality that should be "always on" (as represented by the hypermedia entry API point).
In a strict REST API implementation, utilising Hypermedia As The Engine Of Application State (HATEOAS), what patterns (if any) are used to indicate/represent globally "always valid" actions (if such a concept even truly exists for REST)?
The meta question is, can you at all 'factor out' repeated hypermedia?
By simplified example, lets say we have a resource /version with Allow: OPTIONS HEAD GET. This resource depends on nothing and is NEVER affected by any stateful transitions that may occur elsewhere.
Is the requirement that /version hypermedia are simply sent along with every single other resource request?
Or the alternate pattern, with Client behaviour to link back to Home (likely cached) and THEN trigger our always valid /version call? (A "modal" pattern in GUI terms - close this resource, return home, and move on)
Or is there some kind of method/pattern to create independent decoupled modules for any given application? (perhaps namespacing of some kind?)
In a complex, but loosely coupled API, option 1 ends up being buried in Hypermedia hell with 80-95% of your payload being repeated on each resource call. Which seems "right" but is so nasty. Option 2 leads to either strange quirks in GUI client behaviour (hiding valid elements until you 'return home' - modal type ops) OR lots of non-restful assumptions by the GUI client hardcoding out-of-band actions it "knows" are always valid.
Option 3 relates back to my initial question: is there a flag, or some other pattern for indicating globally valid actions that can be sent once (say with the root/home resource) and then "factored out" of subsequent responses?
Well, there's a couple of things going on here.
First, you could simply add a link to any of your common "global" resources. As much as I am loathe to compare a REST architecture to a web site, a web site is a fitting example here. Consider many of the resources here on SO have links to common, "global" resources -- such as the home page, /questions, /tags, /badges, and /users.
The fact that a resource is "static" and never changes has no affect on whether you make the resource available as a link via another resource as part of HATEOS, that's an orthogonal issue.
The second point is that there is nothing that says the entire service be continually accessible from every resource. You can have "well known" entry points in to your service, and these can be well documented (externally). The only downside is that if the URLs for a certain relation changes (/questions to /questions-2, say), then those URLs may not be picked up automatically by clients. But this it likely not an issue, since by changing the URL you are likely changing something else (such as the payload) that affects clients to the point that an older client may well be incompatible with the new URLs.
Having clients "know" where things are in a nested system is not an issue either. For example, if they "know", as documented, that they can only access /version from the /home resource, and every other resource has a path to /home, (either directly, or indirectly), then this is not a problem either. When it wants /version, it should have an idea of what the path is to get it.
As long as the client is traversing the graph based on what you tell it, rather than what "it thinks", then all is well. If the client is currently processing the /blog/daily_news/123 resource, and it has a link rel to "parent" which has a url of /blog, and /blog has a link rel of "version" to /version, then the client can walk the graph (traversing the parent rel to /blog, and the version rel to /version). What the client should not do (unless otherwise documented) is that it should not ASSUME that it can visit /version whenever it wants. Since it's not linked from /blog/daily_news/123, the client should not just jump over to it. The rel isn't there, so the client "doesn't know".
This is the key point. The fact that it is not there means it's not an option right now, for whatever reason, and it's not the client task to force the point, as the URL space is not in its hands, it's in the services hands. The service controls it, not the client.
If /version suddenly vanishes, well, that's a different issue. Perhaps they timed out and aren't allowed to "see" /version anymore, perhaps you deleted it. The client at that point will simply error out "can't find version rel" and then quit. This is an unrelated problem, just a truth of the matter (what else can you do when resources suddenly vanish behind your back).
Addenda for question:
Which, if I understand this means: if /home is not expired, and we
navigate to /blog (which contains a rel back to /home) then the rel
methods at /home are still immediately "accessible" from /blog right?
No, not really. That's the key point. Save for some global resource specifically documented (out of band), you should not traverse to any link not specified in your current resource. Whether /home is not expired or not is not relevant at all.
The server could certainly have sent appropriate caching instructions, letting you know that you could cache /home for some time, but you should still traverse through the rel to /home to get any links you think are there.
If /home is well cached on your client, then this traversal is effectively free, but logically and semantically you should stick with the protocol of traversing the links.
Because if it's NOT cached, then you simply have no idea what rels will be there when you get back. Yes, 99.999999% of the time it will always be the same, and shame on the server for not sending the appropriate caching headers, but by definition, the server isn't promising you anything, so both you, the client, and it, the server, eat the processing costs of hitting an effectively static resource over and over and over again.
By mandating your client follow the steps, perhaps with internal optimizations due to caching and pre-processing to make these static traversals quick and efficient, you stick with the model of HATEOS, and defer to the system to make it optimal rather than pre-supposing at the code level and jumping through rels you think you already have.
This way your code will always work, regardless of what the server does. Who knows when they may turn caching on or off, your code certainly shouldn't care, not at the level of deciding whether or not to dereference a link certainly.
The premise of HATEOS is that the server is in charge of, and mandates its URL space. Arbitrarily jumping around without guidance from the server is off spec, it's not your graph to navigate. REST is for more coarse grained operations, but proper caching and such can make jumping through these hoops quick and efficient for you the client.
Maybe I'm misunderstanding the question, but it seems like client-side caching should solve this. Look for the Expires and Cache Control headers.
I have what seems to be a fairly simple question about implementing a data access client that strictly adheres to REST architectural principles. To start, let's assume I have a well-behaving REST API that I want to consume using a Django application. I'll start by discovering what services are available (edited for follow-up):
GET example.com/services/ HTTP/1.1
HTTP/1.1 200 OK
<?xml version="1.0" encoding="UTF-8"?>
<services>
<service>
<name>Widgets</name>
<link>http://example.com/services/widgets/</link>
<item_link>http://example.com/services/widgets/{widget_id}/</item_link>
</service>
<service>
<name>Factories</name>
<link>http://example.com/services/factories/</link>
<item_link>http://example.com/services/factories/{factory_id}/</item_link>
</service>
...
</services>
Now, since I'm building a Django application based around consuming this API, how would I continue to keep exploring these services RESTfully? To adhere to REST principles, my application must be driven by the hypermedia received. I suppose the first step is easy enough -- interacting with a service by the name given. I set up a Django view as follows:
def get_service(request, service_name):
doc = etree.parse(urllib.urlopen('http://example.com/services/'))
uri = doc.xpath("service/name[.='%s']/following-sibling::*" % service_name)[0].text
...
From which I'll perform another request (edited for follow-up):
GET example.com/services/widgets/ HTTP/1.1
HTTP/1.1 200 OK
<?xml version="1.0" encoding="UTF-8"?>
<widgets>
<item_link>http://example.com/services/widgets/{widget_id}/</item_link>
<widget>
<id>1</id>
<name>Whizbang Foobar</name>
<link>http://example.com/services/widgets/1</link>
</widget>
...
</widgets>
Now I'll display a simple list of widgets in a rendered Django template. From here though, how do I continue to interact with this service RESTfully? Perhaps I've befuddled myself into confusion, but the only reasonable things I can come up with are implementing a numerous amount of application views or a thin Django data model to persist the service URI.
My main concern boils down to that this is trivial to do without strictly adhering to REST architectural guidelines, but I feel like I've missed the boat completely in trying to do so. I understand designing proper REST APIs and clients isn't "easy", but it seems that I'm in dire need of a similar example to work through the actual implementation.
I apologize for the length and verbosity of the question and the inevitable facepalming of wizened readers.
Follow-up:
Is the following a valid way (using URI templates) of implementing these interactions? For demonstration purposes (in lieu of a more abstract implementation), another Django view to retrieve a resource collection item:
def get_item(request, service_name, item_id):
doc = etree.parse(urllib.urlopen('http://example.com/services/'))
uri = doc.xpath("service/name[.='%s']/following-sibling::item_link" % service_name)[0].text
...
Then the subsequent request:
GET example.com/services/widgets/1 HTTP/1.1
HTTP/1.1 200 OK
<?xml version="1.0" encoding="UTF-8"?>
<widget>
<id>1</id>
<name>Whizbang Foobar</name>
<tags>foo bar baz ham eggs</tags>
<index_link>http://example.com/services/widgets/</index_link>
</widget>
My main concern boils down to that this is trivial to do without strictly adhering to REST architectural guidelines, but I feel like I've missed the boat completely in trying to do so. I understand designing proper REST APIs and clients isn't "easy", but it seems that I'm in dire need of a similar example to work through the actual implementation.
The best example I've been able to find is the Sun Cloud API. Most of the documentation describes the various media types used by the system, which seems to be the key to pulling this kind of thing off.
I find that it helps to be writing your client at the same time you're developing your API. That way you can spot what's likely to make your API a pain to code for right away and fix the problem.
It isn't easy. If you follow the HATEOAS constraint to its logical conclusion, each media type you define will be handled by one of a family of clients. To the extent that you can make all of your resources follow a similar pattern of behavior, your job of writing clients will become easier.
For example, you could define a media type 'Index' that simply lists related resources. Index defines links for pagination, getting items in the list, finding items by name, etc.
Then, you might define a base media type called 'Item'. Item has a link for displaying its parent Index, updating/deleting itself, etc. Your resource Widget could then be represented by two different media types - one Index and one based on Item.
You could begin by implementing a single class that handles the Index media type. Then you could write a base class that handles all common Item media type behavior. Finally, you could write a Widget client that handles all widget-specific behavior and which extends the Item client. These clients could expose their functionality (availability of more links and data fields) in an idiomatic way for the language they're written in.
Processing a response from your server would then be a matter of matching the mime type of the response to one of the clients you've written.
In other words, even though the client for your service as a whole would be made up of many clients of limited scope, they would each be based on common behaviors and so could be implemented in a DRY way.
From my experience the REST model makes much more sense if the representations and their contained links are translated directly to a client UI. In this scenario it is the user that directs the exploring of the REST interface.
Often I see people trying to use REST interfaces as a kind of HTTP based data access layer. With this mental model, hyperlinked data provides little more than structural data relationships. It becomes difficult to build application behaviour on top of that interface without violating RESTful constraints.
I like to think of a RESTful interface as delivering UI content to an application that is going to render that content with some arbitrary technology. Unfortunately, REST is frequently compared to web services which, in my opinion, fit in a different architectural layer. Web services deliver data that is to be processed by a client application. RESTful interfaces should deliver content that will be rendered to the user.
Sure you can use a REST interface to deliver data to remote applications but think of it as simplified screen scraping.
When writing a client for REST interface I find it useful to imagine that I am writing a custom web browser that only understands the media-types that are delivered by that RESTful interface and is hard-coded to start at a specific URL and there is no address bar!
Sun Cloud API documentation is a great example of a RESTful API, focusing on the media types.
If I understand your question correctly, you want to explore an unknown service, correct?
If so, then you could, for example continue with an OPTIONS request to the "widget" resource, to see which HTTP methods it supports (these should be listed in the Allow header of the response).
You can then do the same for all URIs found in <link rel="whatever"> elements. If a resource found this way indicates that it supports GET, then fetch it and repeat ...
This way you should be able to explore all nested resources.
This kind of exploration will of course only get you so far, because to really interact with the service, you will need to know about its media types (or representations), and what the different <link rel="whatever"> actions you found actually mean. This step can't be automated, you'll have to read the documentation for the service and build you client accordingly. I suggest reading the article "How to GET a Cup of Coffee", which I think explains this interaction very well.