I have a PHP app that renders HTML pages for a social media application that I'm creating. Then, JavaScript initializes and makes things interactive. The PHP side of things logs into a separate webservice with curl.
Now, I can't figure out a way to share the session started in PHP with JavaScript, so when I make a AJAX request in JavaScript to the data server, its authenticated.
Is there a way to share a PHP session with JavaScript? Or to share authentication initially created with PHP with JavaScript?
I would say it sounds like there is something wrong with your architecture. In my opinion, the web server itself, should be the only peer providing data to the client/browser. It's a two party conversation only.
When trying to hit a third-party server from the browser, you violate the browsers Same-Origin Policy, unless you specifically allow CORS by explicitly setting various request and response headers. - and you would only do so in very special situations.
The best solution might be to create proxy services at the web server, that can be hit directly (locally) by the browser. The web server can then (acting as controller) forward the data-request to the data server (model) and finally return the response to the browser (view).
You can read out the session cookie set by PHP (SID I guess) through JavaScript containing the session ID.
When you make a query, use
http://example.com/?sid=SessionID
Related
We have a Javascript file that we have developed for our clients to use. The Javascript snippet takes a screenshot of the website it is run on and then sends it back to our server via jQuery.post()
The nature of our industry means that we have to ensure there is no way that the file can be tampered with by the client.
So the challenge is that we need to make sure that the screenshot was generated by the javascript file hosted on our server, and not one that's been copied or potentially tampered with in any way.
I know that I can get the script location using:
var scripts = document.getElementsByTagName("script"),
src = scripts[scripts.length-1].src;
But this won't help if a client tampers with that part of the SRC.
What methods can I employ to make sure that:
1) The post was made from the javascript file hosted on our server
2) The javascript was not tampered with in any way.
Short answer:
You can't.
You can't.
Both stem from the fact that once you hand over something to the client side, it's out of your hands. Nothing will prevent the user from putting a proxy between you and their machine, a process that intercepts content or an extension that tampers content, headers, cookies, requests, responses etc.
You could, however, harden your app by preventing XSS (prevent injection of scripts via user input), using SSL (prevent tampering of the connection), applying CSP (only allow certain content on the page), add CSRF tokens (ensure the form is authorized by the server) and other practices to make it harder for tampered content to get through.
But again, this won't prevent a determined hacker to find an opening.
I'm currently planning to develop a HTML5 app. The basic concept is the following:
A user should be able to create a profile with username and password. The Server should be implemented in Ruby on Rails providing a JSONP Api (for Cross-Domain issues).
So the App will send Ajax requests to the Server and get responses from it.
My idea was now to transmit a session_key (generated by server) on the first response back to the client. Then the client has to authenticate himself with this token.
But now i have some issues.
How can i secure the first call of the client (when he is transmitting user and password)?
How can i protect the Session-key from beeing spyed out?
I am a complety noob in security aspects. Therefore it would be great if i could get some hints where to look at.
Secure your connection with SSL. This should require no changes in your code apart from putting 's' after 'http' ;-).
I used add a checksum to the ajax parameters (calculated using the submitted data), and then to crypt the hole ajax request into one string.
Somthing like sRequest=459fdjnfdw4r908vn....
sRequests holds my data (sUser=user&sPass=pass&iCheck=34564).
Edit: My client code was not public, compiled to an app.
I am writing a Phonegap application that needs to be able to call remote webservices that are secured by CAS. The application will also be hosted on our webfarm (minus the hardware specific parts) as a mobile web site.
Our CAS server is hosted by server1 and our webservices are hosted on server2. The mobile web site is hosted on server2.
Any calls I make from Javascript get a cross-domain error. I realize this isn't an issue for the phone, but it would be nice to avoid it due to development being so much easier when running on the desktop.
Currently, I have a working setup that consists of the following:
Javascript calls a server-side script on server2 over https, including the username and password in the header.
The script calls CAS' RESTful api and gets a ticket granting cookie. The script creates a Set-Cookie header in the response or it reports back with a login error.
Javascript gets the response and creates the cookie (though this cookie is undetectable in Phonegap (nothing in document.cookie), even though it's getting passed around).
Javascript then calls a server-side script which calls a webservice for it, passing the cookie with the request (I had to manually insert the cookie into the request header, even though it automatically was passed in the request from javascript).
The server-side script sends the results to javascript.
Is there a better way to do this? I've seen mention of proxy tickets in CAS, but cannot find enough information to know whether it's what I need or how to use them.
Thank you.
I fear I may be trying to do something that certain security policies are specifically designed to forbid.
So there's a certain site with a certain AJAX-based chat application. It periodically polls the server and receives HTML fragments in return. I am looking to write an alternate mobile frontend that directly queries the existing backend using JS (i.e. does not use my server as a reflector).
Two main issues here that make this different from most such questions:
The server owner wouldn't mind me doing this but he's not going to go out of his way to help me, and so the format for talking with the server is not something I can change. That is, the server doesn't talk JSON let alone JSONP. It's HTML fragments but for my purposes that's essentially text.
I need to have the return value available to parse manually. It should not be automatically parsed/inserted/what-have-you through inclusion in the DOM or some other such mechanism.
If anyone has some advice on this matter, I would really appreciate it.
You could use a server side script to proxy it through your server.
You could use YQL as the middle man and use JSONP or CORS.
Tell the person on the other server to set up CORS for your server (tell them to add a header for each request, e.g. Access-Control-Allow-Origin: example.com).
could you create a php proxy,
ajax send url to fetch to local php(or other serverside script)
php uses curl to fetch that page and returns result.
This is probably a generic security question, but I thought I'd ask in the realm of what I'm developing.
The scenario is: A web service (WCF Web Api) that uses an API Key to validate and tell me who the user is, and a mix of jQuery and application on the front ends.
On the one hand, the traffic can be https so it cannot be inspected, but if I use the same key per user (say a guid), and I am using it in both then there's the chance it could be taken and someone could impersonate the user.
If I implement something akin to OAuth, then a user and a per-app key is generated, and that could work - but still for the jQuery side I would need the app API key in the javascript.
This would only be a problem if someone was on the actual computer and did a view-source.
What should I do?
md5 or encrypt the key somehow?
Put the key in a session variable, then when using ajax retrieve it?
Get over it, it's not that big a deal/problem.
I'm sure it's probably a common problem - so any pointers would be welcome.
To make this clearer - this is my API I have written that I am querying against, not a google, etc. So I can do per session tokens, etc, I'm just trying to work out the best way to secure the client side tokens/keys that I would use.
I'm being a bit overly cautious here, but just using this to learn.
(I suggest tagging this post "security".)
First, you should be clear about what you're protecting against. Can you trust the client at all? A crafty user could stick a Greasemonkey script on your page and call exactly the code that your UI calls to send requests. Hiding everything in a Javascript closure only means you need a debugger; it doesn't make an attack impossible. Firebug can trace HTTPS requests. Also consider a compromised client: is there a keylogger installed? Is the entire system secretly running virtualized so that an attacker can inspect any part of memory at any time at their leisure? Security when you're as exposed as a webapp is is really tricky.
Nonetheless, here are a few things for you to consider:
Consider not actually using keys but rather HMAC hashes of, e.g., a token you give immediately upon authentication.
DOM storage can be a bit harder to poke at than cookies.
Have a look at Google's implementation of OAuth 2 for an example security model. Basically you use tokens that are only valid for a limited time (and perhaps for a single IP address). That way even if the token is intercepted or cloned, it's only valid for a short length of time. Of course you need to be careful about what you do when the token runs out; could an attacker just do the same thing your code does and get a new valid token?
Don't neglect server-side security: even if your client should have checked before submitting the request, check again on the server if the user actually has permission to do what they're asking. In fact, this advice may obviate most of the above.
It depends on how the API key is used. API keys like that provided by Google are tied to the URL of the site originating the request; if you try and use the key on a site with an alternate URL then the service throws and error thus removing the need to protect the key on the client side.
Some basic API's however are tied to a client and can be used across multiple domains, so in this instance I have previously gone with the practice of wrapping this API in server side code and placing some restrictions on how the client can communicate with the local service and protecting the service.
My overall recommendation however would be to apply restrictions on the Web API around how keys can be used and thus removes the complications and necessity of trying to protect them on the client.
How about using jQuery to call server side code that handles communication with the API. If you are using MVC you can call a controller action that can contain the code and API key to hit your service and return a partial view (or even JSON) to your UX. If you are using web forms you could create an aspx page that will do the API communication in the code behind and then write content to the response stream for your UX to consume. Then your UX code can just contain some $.post() or $.load() calls to your server side code and both your API key and endpoint would be protected.
Generally in cases like this though you proxy requests through the server using 'AJAX' which verifies the browser making requests is authorized to do so. If you want to call the service directly from JavaScript, then you need some kind of token system like JSON Web Tokens (JWT) and you'll have to work out cross-domain issues if the service is located somewhere other than the current domain.
see http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx for more information
(How to do API Key Verification for REST Services in .NET 4)