The chrome "swap my cookies" extension allows you to swap between multiple 'profiles' in chrome, that span all sites.
I'm attempting to create something similar for testing my own web services, so I'd like to restrict it to only my domains.
What would be convenient, is to be able to do this from a small userscript using tampermonkey or greasemonkey to add a menu that would swap cookies etc.
Does anyone have any idea on how to get started? Or if it's at all possible?
If your cookies are not httponly you can load them with document.cookie, save them with GM_setValue('cookie_profile_a',document.cookie) and GM_getValue('cookie_profile_a') or in the localStorage with localStorage.setItem('cookie_profile_b',document.cookie) and localStorage.getItem('cookie_profile_b'). For creating a menu in Tampermonkey you can use existing solutions like GM_config (https://stackoverflow.com/a/14594346#43462416).
An extension can have access to all cookies from all domains but content scope script, like page scripts and user-scripts have access to its document cookies only for its domain. That is a security measure to prevent page scripts interfering with cookies from other domains.
Furthermore, page script have no access to browser profiles.
Therefore what you have asked for is not possible with any content/user script.
It is possible for a user-script that runs on multiple domains to read/write cookie data once injected into those domains.
Therefore, a script running on A, B, C domains can get/copy data from cookies from domain A after getting injected into A, then store the data and then write the data in cookies in domain B after getting injected into domain B.
Related
I want to deny access users to my web application when they are not in the company area ,so I can to enforce web browser to track the user location through django?
There are a few options:
Do this in the Web browser via JavaScript. You can receive the coordinates of the user there. The user has to agree, but you can refuse to show the content if they don't give the information - details would depend heavily on how your Web site works
If you want to limit it to specific offices and they have static IPs, you can restrict traffic to a list of predefined IPs in Django. This answer has some good approaches for that: Authenticate by IP address in Django
You can get the IP of the request and do a geo-lookup on the IP and use that to restrict the traffic. You likely will want to do this using middleware. Please note that this may add quite a bit of delay, so you likely will want to remember where a certain IP is, at least for a while, in some cache or datastore
My website uses _gs _gu _gw cookies
What are these cookies? Why are they used?
I tried looking for this information but can't seem to find it
This website lists all 3 cookies. It's a specific website policy, but as far as I can see those are cookies used by Getsitecontrol, so you can use that description for reference.
_gs Used to identify the users browser, operating system, IP address and the page on the website they are viewing.
_gu Used to distinguish users.
_gw Records widgets previously displayed to user.
I've recently seen XSSI mentioned on multiple pages, e.g. Web Application Exploits and Defenses:
Browsers prevent pages of one domain from reading pages in other domains. But they do not prevent pages of a domain from referencing resources in other domains. In particular, they allow images to be rendered from other domains and scripts to be executed from other domains. An included script doesn't have its own security context. It runs in the security context of the page that included it. For example, if www.evil.example.com includes a script hosted on www.google.com then that script runs in the evil context not in the google context. So any user data in that script will "leak."
I fail to see what kind of security problems this creates in practice. I understand XSS and XSRF but XSSI is a little mysterious to me.
Can anybody sketch an exploit based on XSSI?
Thanks
This is typically a problem if you are using JSONP to transfer data. Consider a website consisting of a domain A that loads data from domain B. The user has to be authenticated to site A and B, and because the Same Origin Policy prevents older browsers from communicating directly with a different domain (B) than the current page (A), the developers decided to use JSONP. So site A includes a script pointing to http://B/userdata.js which is something like:
displayMySecretData({"secret":"this is very secret", ...})
So A defines a function called displayMySecretData, and when the included script from server B runs, it calls that function and displays the secret data to the user.
Now evil server E comes along. It sees that A is including data from B using JSONP. So server E includes the same script, but defines its own displayMySecretData which instead steals the data.
The attacker then tricks the user into visiting his site. When the user goes there and he is logged in to B, the browser automatically sends the authentication cookies for B along with the request to fetch the script from B. B sees an authenticated user, and thus returns the script as expected. E gets the data, and presto...
Using JSONP to load confidential data from a different domain this way is thus really insecure, but people are still using it. Bad idea!
XSSI is not limited to jsonp responses. In some browsers you can override the Array constructor. If a Json response contains [...] and you include it as a script it will execute the new constructor instead of the builtin one. The fix is to insert something in the response that can't be parsed like ])}while(1);</x> and then use code to remove it before parsing it. An attacker can't do that since script inclusion is always the entire script.
More detail on the problem and this solution at http://google-gruyere.appspot.com/part3#3__cross_site_script_inclusion
XSSI is a fancy way of saying: you are including in your program, someone elses code; You don't have any control over what is in that code, and you don't have any control over the security of the server on which it is hosted.
For example, let's say i include in my html page
<script type="text/javascript" src="http://mymatedave.com/js/coolwidget.js"></script>
That script will run in my webapp with the same level of trust as any of my own javascript code. It will have access to the the full page content and DOM, it will be able to read all my app's cookies and read the users keypresses and mouse movements, and everything else that javascript can do.
If my mate dave, then decides to put something malicious in his cool widget (say, a sniffer/keylogger that sends all the user's cookies, form data and keypresses to his server) then I won't necessarily know. Also, the security of my app now depends on the security of dave's server. If dave's server gets compromised and coolwidget.js is replaced by the attacker, i again won't necessarily know and the malicious code will run as part of my app.
I would like to set a specific cookie domain for my cookies, because this might solve some issues our site seems to have with IE8. Django seems to have a setting called SESSION_COOKIE_DOMAIN which can be set to obtain this. The problem however is that our site contains multiple subsites which have alternative domain names. So my question is, how can I manage this? I would like to have a standard cookie domain per domain, because I fear browsers like IE8 will reject cookies which aren't from the same domain (quicker).
I will do research myself, but I wondered if anyone perhaps has experience.
Update:
What I actually want to do is to make django store cookies for domain1 when I visit domain1.com etcetera for the other domains. I think it should be as easy as to use the current client domain when storing cookies. I doubt however that django offers such functionality without modification... Maybe I could build a middleware class that changes the global setting to the current domain..
Update:
This question and answer helped me out:
Changing Django settings variable dynamically based on request for multiple site
Thanks for help :)
Cookies can't be stored or retrieved for other domain names. In other words, if I am at yahoo.com I can't get the cookie for google.com. However, foo.yahoo.com and bar.yahoo.com can both retrieve cookies saved at .yahoo.com.
If you are running a website with multiple subsites, if they all share the same basic domain (i.e. site1.domain.com, site2.domain.com, etc) you should use that domain for SESSION_COOKIE_DOMAIN. But if they have different domains, it's basically impossible for them to share cookies without using some other method of getting the cookies. You can, for example, include images or scripts that point to a central site, and that site can store and retrieve the cookies, which are made available to the rest of the page via JavaScript.
If you must keep these alternate domain names, you can always set your web server to redirect immediately from these alternate domain names to the shared standard domain. This is easy to do with mod_rewrite.
I have an interesting conundrum.
We have a site that is a completely separate domain, we'll say http://www.x.com and our own site that is http://www.y.com. The y.com site is actually a classic ASP site, and we aren't converting it to .NET at this time.
The problem is that there is a link on x.com that redirects to y.com from a members area. We want to "authenticate" the user to make sure they are a member from the other site. If they are, they are directed to a members area on y.com. If not, they have to provide login information on y.com.
Cookies obviously don't work due to the cross domain security, but is there a way around this? I've also looked at a service for tokens, but I'm not sure exactly how that works in Classic ASP. Any ideas or suggestions?
What I did when I needed to pass information cross domain what so hash the information into one variable and pass the url/page as another variable as a post into a page on the y.com. That page would unhash the data, set the cookies and session variables, and then do a redirect or server.transfer to the page that was passed. The same can work going from y.com to x.com.