I'm preparing some diagnostic tool. It operates on the website in the iframe - only by javascript.
Now what I need is to get rid of session cookie in the website that I have in my iframe. I just need to be logged out after performing some operations.
Unfortunately I cannot just drop the session cookie from javascript because it's mark with httpOnly flag. I did not found any way to open iframe in incognito mode either.
Now the rules for achiving this are following:
I can add any file to target website server
I can run any javascript on website domain
I can force user to use specified browser (it does not have to be cross-browser solution)
I can NOT modify website code
The solution have to be server and programming language independent
Any ideas for the workaround?
You just cant manage httpOnly cookies from javascript.
But I think that you want to analyze the page, but also with js. So why use iframe ?
You can fetch content of page that is to be analyzed from outside of html or javascript:
do ajax request to your application proxy
use html5 websockets as proxy server. I assume that websocket server is your. Websockets have also cross-domain ability.
You then just need to parse fetched DOM (i saw something builtin for this). And let analyzing to begin.
As far as I understand -
Given that - You will have a website with user login/logout implemented in it.
So if you can have some way for your diagnostic app to have the logout url of target website as a config var or some setting (by putting some js or file in the server) then this job can be very simple. Just let your diagnostic app load that logout url when needed.
If you simply want to prevent cookies being used in the iframe you could try using the sandbox attribute.
Seems like a very similar question to:
Disable Cookies Inside A Frame/Iframe
Hope I am understanding your question correctly.
You have JavaScript so just AJAX request to your server and tell it to unset the session variable.
Say IFrame references url: example.com/iframe.html.
Have it refer to cookieless.example.com/iframe.html instead and have a serverside reverse proxy rule setup that picks up that request and points it back to example.com/iframe.html.
Depending on how you set cookies serverside (i.e: '.example.com') cookies will only be set on www and root-domain
I think you will need some kind of server side proxy that records the cookie header value, and then resets this header value at a later stage based on a value in the request.
This shouldn't be too hard to write in any language, on IIS / .net framework for instance it would be an implementation of an IHttpModule.
The Only way is to Disable Cookies
Related
So I have 2 domains: http://domain1.com and http://domain2.com
domain1.com has a bunch of cookies for the user stored on it.
I want to access all of those cookies but from domain2.com (to keep them synchronized).
Is this possible in JQuery? I was thinking of making a Cookie php file and somehow connect to that file from domain2.php to pull all of the data in.
Thanks for any help
NOTE: These are NOT sub-domains but 2 completely different domains I Control
In a strict sense? No. It isn't. In a more loose sense, yes it is.
If you're storing all of your data in cookies, you're actually storing the data in the browser, which means that jQuery, Prototype, Mootools... can't help you because of browser security (unless you can turn their browser into a server (might work with a Firefox extension (I swear, FF could be an OS if needs be...), but that would be gratuitous)).
I said that in a loose sense it is possible because PHP lets you do two very important things. First, it lets you store your session in a database, and second it lets you assign the session ID directly. It is possible, then, to have two servers point to the same DB and then share SESSION data by switching the user's session ID.
no. this would violate the security model on which browser cookies operate.
to work around this you can implement an iframe (perhaps invisible to the user) on domain1.com which is served from domain2.com and pass data between the two sites with JS.
I would look at a server-side solution, creating a common database that all sites can access. When the user logs in, generate a time-sensitive, IP-keyed token that can be passed from site to site either in GET or POST. Then, validate each request on token, IP, and time. The combination of the three will resolve most security concerns.
or you can look at this SO question for ideas its in .Net though Store cookie for other site
I want to open an php page and inject a cookie on the fly because it uses that as id to fire an ajax call.
The challege is I don't 'own' or have access to the php page.
When setting cookies in JS, the process isn't exactly as easy as writing document.cookie="'name': 'value'". In fact, there are a lot of scripts that strive to simplify this process for setting cookies on the client side. Here is an answer I found that may help you get a simple version of that without having to extend any resources to calling external scripts.
The form for a cookie in JS is as follows:
<name>=<value>; expires=Mon, 16 Oct 2017 01:11:29 GMT; path=/
Notice the inclusion of expires and path. These are necessary when declaring a cookie on the client side.
Now, one thing to keep in mind is that if the page makes a JSON request to a different server, this won't work. This is because cookies follow a Same-Origin Policy to make cookie theft and other associated malicious code more difficult to successfully pull off.
To simplify, I mean that if you go to example.com but the server serves its resources from ajax.example.com and the cookies are for ajax.example.com, you will not be able to manipulate these cookies via javascript unless you can write HTML to some portion of the ajax.example.com domain.
The ability to set cookies without server-side interference is generally considered to be a risky security move, and some could view tampering of cookies by a user-submitted script as suspect, and possibly even an attempt to crack into a system's security. I strongly encourage you to try to have the backend changed so that the AJAX call ID is passed through some sort of GET or POST data. Either that, or have the backend manage the AJAX call ID altogether, possibly even passing an array of plausible IDs to the page for the script to use (e.g. var ajaxCallIds = [1337, 256, 11, 99].)
The way to solve your code issue is up to you, but do keep in mind that there's rarely if ever a situation that calls for client-side manipulation of cookies set and used by server-side application code.
Is there any alternative ways to secure cookies access other then domains?
in my application i am setting cookie on 1 fix domain (cookie.xyz.com) and i need to track user on any domain, basically we are SaSS company and our client will put our js code on his website(s), then we set and get cookie on our one cookie.xyz.com because client can put our js on multiple domains. (right now i am using iframe and window messaging to get/set cookies on cookie.xyz.com)
So now in my case anybody can steal cookie of end user using js and use that and he can himself became that end user.
So what could be solution this so only my code (running in context on any domain) can read and write cookie from particular domain (we do this because our client don't have one or fix domains).
Before downvote this question let me tell you.
I know its not possible, thats why i ask here to find possible or hacky solutions?
You are facing a Cross Origin use case where you want to give liberty on your origin domain BUT you want to add control on it.
Both cases are complicated to coexist.
A solution is to add on your back end webservice a control on the origin of the request such as :
header("Access-Control-Allow-Origin: http://origin.domain:port");
Access-Control-Allow-Credentials: true
And update your JS Call to add credentials to true.
We have a webservice that is mainly intended to be called from javascript, via jquery's $.ajax(). When we call methods from javascript, we set a security token in a request header. If it's not there, or if it doesn't validate, we return an unauthorized error.
And that's all working fine.
But now we're faced with returning image files. So instead of having javascript call $.ajax(), we're embedding an image tag in the DOM:
<img src='http://mywebservice/imagescontroller/getAnImage?imageid=123'/>
And when we do that, we don't have our security token in the request header. I can think of two "easy" fixes. 1., we simply allow anonymous access to our image URLs, or 2., we pass the security token as a URL parameter.
The first choice is, of course, not a good idea. The second is straightforward enough. But before I settle on this approach, I was wondering if there was some easy way of setting request headers on these sorts of requests, that I was missing.
Ideas?
Easy fix: Use session cookies. That is a cookie without a expiry date. It will automatically transmit with each request and go away as soon as the users closes the browser, or you delete the cookie via javascript.
You simply store your token there and get it delivered for free to your server code.
Have some demo stuff here:
How do I set/unset cookie with jQuery?
If you run the services on another domain, you will need to use CORS to make the AJAX running - otherwise your AJAX will run into the Same Origin Policy. With CORS you can even make the cookies work.
See here: CORS request - why are the cookies not sent?
If you do not want to use CORS, you could also incorporate the service domain into your own via reverse proxying. This will solve the SOP problem as well as make the use of cookies possible. Setting up a reverse proxy within Apache is pretty straight forward.
I want to store user-clicked data in a cookie which never has to go to the server. Its like a session-added data, which I want to persist over sessions, as in the data just keeps adding to the cookie, and it is stored for a long time, and only gets deleted when the user removes browsing history. The cookie is pure-client only cookie and it never has to go the server, as I don't need the user generated data at the server, so I want to get rid of the additional overhead the cookie creates in sending back and forth between browser and server. Is it possible to achieve this?
I know it´s a little late for you, but this answer is for all who have the same problem.
With HTML5 you can use web storage.
(Just an idea! - not tested!)
You could define a cookie (via javascript on client) and set the "secure"-attribute.
In this case, the cookie will only be sent to the server on HTTPS connections.
To make sure the cookie never leaves the browser, you just never open a HTTPS connection ;-)
EDIT
Now it´s 2022 and I would not recommend solution 2) anymore.
Instead of setting the secure flag on the cookie, set the path to a path on the server which is never used.
If browser compatibility is a concern you can use a some javascript to wrap around various different technologies. Older versions of IE support (supprise supprise) a proprietary version of localstorage called userData (I don't think it's exactly the same, but should do what you need).
A wrapper script like https://github.com/andris9/jStorage or https://github.com/marcuswestin/store.js should do what you need it to do.
I'm 100% sure that there is no way to force cookies to be client-side only, they are allways sent to server. There is however possible to do the opposite: server-side only cookies (not readable by javascript) by setting HttpOnly flag on cookie.
Use an impossible path to set the cookie:
document.cookie = "cookieName=...; expires=... ; path=/never_reached/ablkappmqlnahsuia";