I would like to test out some interviewees by having them write some javascript that will make requests against my server. I don't want to give them write access to my code base. Javascript runs on the client side, so this should technically be possible. However I know there are browser restrictions that say that the javascript has to come from the server?
I apologize that this is a really dumb question, but how should I proceed?
Edit:::
Ok, so I failed to mention that the entire application is based off sending JSON objects to and from the server.
I think you're thinking of the javascript XMLHttpRequest object itself, in which case, yes the current standard is for browsers to block cross-domain calls. So, you can tell them to pretend they either have a separate proxy script on their own personal domain which will allow them to leap to yours, or to pretend they're building a page directly served from your domain. There's talk of browsers supporting trust certificates or honoring special setups between source and target servers, but nothing universally accepted AFAIK.
Javascript source itself does not need to come from the server, and in fact this is how you can get around this little XMLHttpRequest block by using json. Here's a simple json tutorial I just dug up from Yahoo. But, this calls for your server to provide a json format feed if your server is the intended target.
"there are browser restrictions that say that the javascript has to come from the server"
I'm not aware of any situation where that's the case, only a lack of a console. But...even in those cases there's the address bar and javascript:.
If I misunderstood and you're talking about cross-domain restrictions, then your server needs to support JSONP for the requests so they can make cross-domain calls for data.
You could POST the javascript to your server and then your server can send back some HTML that has the javascript inlined. Sounds like you're trying to set up something is, more or less, a homebrew version of http://jsfiddle.net/; AFAIK, jsfiddle just does a "POST javascript/CSS/HTML and return HTML".
Related
First of all, all of this might be a newbie stupid question.
I am developing a web application with Laravel but ended up using tons and tons of Jquery/javascript. I tried to think of all the possible security risks as I was developing but the more I research this topic, the more I am concerned about usage of Jquery/javascript. It seems that dynamic content loading using Jquery/javascript is overall a very bad idea...But I don't want to rework everything since that would take weeks of extra developing of what is already developed. A quick example
Let's say I have a method attached to my div like so
<div class="img-container" id="{{$file->id}}" onmouseover="showImageButtons({{$file->id}})"></div>
And then a part of Javascript
function showImageButtons(id)
{
console.log(id);
}
When I open this in browser, I am able to alter the value of parameter sent to javascript through the chrome inspector.
from this
to this
And it actually gets executed, I can see "some malicious code" being printed to console.
What if I had an ajax call to server with that parameter? Would it pass?
Is there something I don't understand or is this seriously so easy to manipulate?
There are two basic aspects you need to consider regarding web security -
The connection between the browser and your server should be secure (i.e. https), that way, assuming you configured your server correctly, no one can intercept the client-server communication and you can share data through AJAX.
On the server side, you should treat information coming from the client as hostile and sanitize it; That is since anyone can send you anything through your webpage, even if you do input validation on the client side since the your javascript code is executed by the client and therefore in complete control of the attacker. While implanting "malicious code" in the webpage alone is not an actual attack, if an attacker gets you to store that malicious code in the server and send it to other clients she can run her javascript on your other clients browsers and that is bad (lookup "cross site scripting / XSS").
As part of a thought experiment, I am attempting to ascertain whether there is any hope in a server providing a piece of data only for receipt and use by a browser environment, i.e. which could not be read by a bot crawling my site.
Clearly, if that information is sent in the source code, or indeed via any usual HTTP means, this can be picked up by a bot - so far, so simple.
But what about if the information was transmitted by the server instead as a websocket message: Wouldn't this be receivable only by some corresponding (and possibly authenticated) JavaScript in the browser environment, thus precluding its interception by a bot?
(This is based on my assumption that a bot has no client environment and is essentially a malicious server-side script calling a site over something like cURL, pretending to be a user).
Another way of phrasing this question might be: with the web implementation of websockets, is the receipt of messages always done by a client environment (i.e. JS)?
I can't answer about websockets, but a sufficiently motivated attacker will find a way to emulate whatever environment you require. By loading this content through ajax, you can eliminate the casual bots. You can eliminate well behaved bots with robots.txt.
Using WebSocket makes no difference. You cannot escape the following fact: you can always write a non-browser client that looks and behaves to the server exactly as any standard browser.
I can fake: any HTTP headers (like browser vendor etc) you might read. The origin header doesn't help either (I can fake it). Neither does cookies. I'll read them and give it back.
You might get away by protecting your site with strong captchas, and set cookies only after the captcha was solved. That depends on the captcha being unsolvable by bots ..
Given the simplicity of writing a server side proxy that fetches data across domains, I'm at a loss as to what the initial intention was in preventing client side AJAX from making calls across domains. I'm not asking for speculation, I'm looking for documentation from the language designers (or people close to them) for what they thought they were doing, other than simply creating a mild inconvenience for developers.
TIA
It's to prevent that a browser acts as a reverse proxy. Suppose you are browsing http://www.evil.com from a PC at your office, and suppose that in that office exists an intranet with sensitive information at http://intranet.company.com which is only accessible from the local network.
If the cross domain policy wouldn't exists, www.evil.com could made ajax requests to http://intranet.company.com, using your browser as a reverse proxy, and send that information to www.evil.com with another Ajax request.
This one of the reasons of the restriction I guess.
If you're the author for myblog.com and you make an XHR to facebook.com, should the request send your facebook cookie credentials? No, that would mean that you could request users' private facebook information from your blog.
If you create a proxy service to do it, your proxy can't access the facebook cookies.
You may also be questioning why JSONP is OK. The reason is that you're loading a script you didn't write, so unless facebook's script decides to send you the information from their JS code, you won't have access to it
The most important reason for this limit is a security concern: should JSON request make browser serve and accept cookies or security credentials with request to another domain? It is not a concern with server-side proxy, because it don't have direct access to client environment. There was a proposal for safe sanitized JSON-specific request methods, but it wasn't implemented anywhere yet.
The difference between direct access and a proxy are cookies and other security relevant identification/verification information which are absolutely restricted to one origin.
With those, your browser can access sensitive data. Your proxy won't, as it does not know the user's login data.
Therefore, the proxy is only applicable to public data; as is CORS.
I know you are asking for experts' answers, I'm just a neophyte, and this is my opinion to why the server side proxy is not a proper final solution:
Building a server side proxy is not as easy as not build it at all.
Not always is possible like in a Third Party JS widget. You are not gonna ask all your publisher to declare a DNS register for integrate your widget. And modify the document.domain of his pages with the colateral issues.
As I read in the book Third Party Javascript "it requires loading an intermediary tunnel file before it can make cross-domain requests". At least you put JSONP in the game with more tricky juggling.
Not supported by IE8, also from the above book: "IE8 has a rather odd bug that prevents a top-level domain from communicating with its subdomain even when they both opt into a common domain namespace".
There are several security matters as people have explained in other answers, even more than them, you can check the chapter 4.3.2 Message exchange using subdomain proxies of the above book.
And the most important for me:
It is a hack.. like the JSONP solution, it's time for an standard, reliable, secure, clean and confortable solution.
But, after re-read your question, I think I still didn't answer it, so Why this AJAX security?, again I think, the answer is:
Because you don't want any web page you visit to be able to make calls from your desktop to any computer or server into your office's intranet
I'm a bit embarrassed here because I am trying to get content remotely, by using the client's browser and not the server. But I have specifications which make it look impossible to me, I literally spent all day on it with no success.
The data I need to fetch is on a distant server.
I don't own this server (I can't do any modification to it).
It's a string, and I need to get it and pass it to PHP.
It must be the client's (user browsing the website) browser that actually gets the data (it needs to be it's IP, and not the servers).
And, with the cross-domain policy I don't seem to be able to get around it. I already knew about it, still tried a simple Ajax query, which failed. Then I though 'why not use iFrames', but the same limitation seems to apply to them too. I then read about using YQL (http://developer.yahoo.com/yql/) but I noticed the server I was trying to reach blocked YQL's user-agent making it impossible to use this technique.
So, that's all I could think about or find. But I can't believe it's not possible to achieve such a thing, that doesn't even look hard...
Oh, and my Javascript knowledge is very basic, this mustn't help either.
This is one reason that the same-origin policy exists. You're trying to have your webpage access data on a different server, without the user knowing, and without having "permission" from the other server to do so.
Without establishing a two-way trust system (ie modifying the 'other' server), I believe this is not possible.
Even with new xhr and crossdomain support, two-way trust is still required for the communication to work.
You could consider a fat-client approach, or try #selbie suggestion and require manual user interaction.
The same origin policy prevents document or script loaded from one
origin from getting or setting properties of a document from a different
origin.
-- From http://www.mozilla.org/projects/security/components/same-origin.html
Now if you wish to do some hackery to get it... visit this site
Note: I have never tried any of the methods on the aforementioned site and cannot guarantee their success
I can only see a really ugly solution: iFrames. This article contains some good informations to start with.
You could do it with flash application:
flash with a crossdomain.xml file (won't help though since you don't control the other server)
On new browsers there is CORS - requires Access-Control-Allow-Origin header set on the server side.
You can also try to use JSONP (but I think that won't work since you don't own the other server).
I think you need to bite the bullet and find some other way to get the content (on the server side for example).
I apologize that there is a similar question already but I'd like to ask it more broadly.
Is there any way at all to determine on the client side of a web application if requesting a resource will return a 401 status code and cause the browser to display an ugly authentication dialog?
Or, is there any way at all to load an mp3 audio resource in flash which fails invisibly in the case of a 401 status code rather than letting the browser show an ugly dialog?
The Adobe Air run-time will suppress the authentication if I set the "authenticate" property of the URLRequest object but this property is not in the Flash run-time. Any solution which works on the client will do. An XMLHttpRequest is not likely to work as the resources in questions will be at different domains.
It is important to fail invisibly because the application will have a list of many audio resources to try and it makes no sense to bother the user to try and authenticate for one when there are many others available. It is important that the solution work on the client because the mp3's in question come from various servers outside my control.
I'm having the same problem with the twitter api - any protected user requires the client to authenticate.
The only solution that I could come up with was to load the pages serverside and return a list of the urls with their http response code.
"Is there any way at all to determine on the client side of a web application if requesting a resource will return a 401 status code and cause the browser to display an ugly authentication dialog?"
No, not in general. The 401 response is the only standard way for the server to indicate that authentication is necessary.
Just wrap your access to the resource that might potentially require authentication to an Ajax call. You can catch the response code, and use javascript to do whatever you want (ie. play that sound). If the response code is however alright, then use javascript to forward user to the resource.
Most likely this approach will generate slightly more load on server (you might have to resort to loading the same resource several times in some circumstances), but it should work. Any good tutorial about how to use XMLHttpRequest should contain all you need. Take a look at for instance http://www.xul.fr/en-xml-ajax.html
If you are using URLRequest to get the files, then you are running across more than just elegant error handling, you are running into a fundamental difference in the Flash and AIR run-times.
If using the URLRequest object to retrieve files you are going to get a security error from Flash on every request to every server that has not set a policy file to allow these sort of requests. AIR allows these requests since it basically IS the client. This makes sense since it's the difference between installing an application and visiting a web page.
I hate to provide the non-answer, but if you can't make a server-side call, and you are hitting a range of "not-known" servers, it's going to be a tough road to hoe.
But maybe I misunderstand, are you just trying to Link to the files and prevent the user from getting bad links, or are you trying to actually load the files?