According to the Flask Documentation, I should be able to set a cookie with a domain path for domains besides my own like this:
resp = make_request(render_template(index.html))
resp.set_cookie('cookiekey', 'cookievalue', domain='notmydomain.example.com')
I was able to set cookies for my domain with just
resp.set_cookie('cookiekey', 'cookievalue')
and they were accepted by the browser (Chrome). However, when I try to set the domain, they don't appear in the browser. Further, testing with postman reveals that the Set-Cookie headers are sent, and are correct.
Does this mean the browser is simply ignoring my request, and if so how can I get it to accept my Set-Cookie headers?
TL;DR: you can't set cookies for domains completely separate from your current domain.
Setting cookies for domains outside of your control would pose an immense security risk. The domain attribute only allows you to set cookies for either the whole domain or a subdomain. This is how, for example, a system can log you in via a subdomain such as "auth.example.org" then redirect you to "example.org".
In practice, "unified" sign-in systems are complicated: challenges are used and data might be exchanged through a backend, not relying on the browser to properly allow other subdomains to access the original cookie.
Related
I am having a use case to get data from a specific site which needs to have requests via session every time. I have created the session in python and also cookies are set which contain my logged in details.
I am currently hosting my script on a data center but the account is getting blocked. I am thinking of requesting the data via proxy but still feel that if my session is created from a different machine and proxy is used to get data via session then what are the chances that the proxy ip is going to be black-listed?
What are the possible solutions here to cater this kind of problem.
Scenarios in Python Requests Session differs according to different regions,
Like in some countries some headers are not permitted in the request due to country laws.
Since you are already making logged in session that means your user-agent and other headers are being set according to the response from login request.
One of the solution might be using a proxy of a country which doesnot have strict rules of data extraction from that platfrom.
So I'm currently learning the python requests module but I'm a bit confused and was wondering if someone could steer me in the right direction. I've seen some people post headers when they want to log into the website, but where do they get these headers from and when do you need them? I've also seen some people say you need an authentication token, but I've seen some other solutions not even use headers or an authentication token at all. This is supposedly the authentication token but I'm not sure where to go from here after I post my username and password.
<input type="hidden" name="lt" value="LT-970332-9KawhPFuLomjRV3UQOBWs7NMUQAQX7" />
Although your question is a bit vague, I'll try to help you.
Authentication
A web browser (client) can authenticate on the target server by providing data, usually the pair login/password, which is usually encoded for security reasons.
This data can be passed from client to server using the following parts of HTTP request:
URL parameters (http://httpbin.org/get?foo=bar)
headers
body (this is where POST parameters from HTML forms usually go)
Tokens
After successful authentication server generates a unique token and sends it to client. If server wants client to store token as a cookie, it includes Set-Cookie header in its response.
A token usually represents a unique identifier of a user session. In most cases token has an expiration date for security reasons.
Web browsers usually store token as a cookie in internal cookie storage and use them in all subsequent requests to corresponding website. A single website can use multiple tokens and other cookies for a single user.
Research
Every web site has its own authentication format, rules and restrictions, so first thing you need to do is a little research on target website. You need to get information about the client sends auth information to server, what server replies and where session data is being stored (usually you can find it in client request headers).
In order to do that, you may use a proxy (Burp for example) to intercept browser traffic. It can help you to get the data passed from client to server and back.
Try to authenticate and then browse some pages on target site using your web browser with a proxy. After that, using your proxy, examine what parts of HTTP request/response do client and browser use to store information about sessions and authentication.
After that you can finally use python and requests to do what you want.
I am using Facebook's Tornado web engine for Python for a project I'm doing and was planning on implementing the XSRF protection, but it left me a little confused.
On a typical request it sets an "_xsrf" cookie to the user's browser if it's not found and then matches that with the value embedded in an HTML form value the browser has sent with the request.
Well let's say an attacker did something like this:
<img src="blah.com/transfer_money?account=0098&destination=0099&_xsrf=
(whatever the client's cookie contains)" title="cool image" />
What's to prevent the attacker from using the cookie outright? As far as I can tell the cookies used for XSRF are not "secure" both from the check_xsrf_cookie method and the xsrf_token method that actually generates the XSRF token. Am I missing something...?
If I understand you correctly, you are asking what prevents attacker from accessing user's cookie in given domain.
Well, the answer is: browser security policy. The script from one domain cannot access cookie from other domain (most of the time). More details here: http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
This can be circumvented by using XSS (Cross-Site Scripting) attack: injecting the script directly into the source of attacked page. Another approach is to break the client application (browser).
However, most of the time it is not possible for the attacker to retrieve user's cookie from other domain. Additional level of security would be to associate specific CSRF (or "XSRF") token with specific user (and to check it during validation).
title might be a bit of a misnomer.
I have two subdomains setup in a web application, one for the application frontend at www. (which is using a loose PHP router coupled with backbone, require, and jquery for UI) and a data tier setup at data. (built entire in python utilizing Werkzeug)
We decided to go to this kind of architecture since at some point mobile app will be integrated into the equation, and they can just as easily send HTTP connections to the data subdomain. The data subdomain renders all its responses in JSON, which the JS frontend expects universally as a response be it a valid query response or an error.
This feels like the most organized arrangement I've ever had on a project, until Facebook connect appeared on the manifesto.
Ideally, I'd like to keep as much of the 'action' of the site behind the scenes on the data subdomain, especially authentication stuff, so that the logic is available to the phones and mobile devices as well down the line if need be. Looking into the facebook docs, it appears however that the browser and its session object are critical components in their OAuth flow.
User authentication and app authorization are handled at the same time
by redirecting the user to our OAuth Dialog. When invoking this
dialog, you must pass in your app id that is generated when you create
your application in our Developer App (the client_id parameter) and
the URL that the user's browser will be redirected back to once app
authorization is completed (the redirect_uri parameter). The
redirect_uri must be in the path of the Site URL you specify in
Website section of the Summary tab in the Developer App. Note, your
redirect_uri can not be a redirector.
I've done this before in PHP and am familiar with the process, and it's a trivial matter of about 3 header redirects when the logic in question has direct access to the browser. My problem is that the way our new app is structured, all the business logic is sequestered on the other subdomain. What are my options to simulate the redirect? can I have the python subdomain send the HTTP data, receiving it from the www domain using CURL like all the other requests? Can I return a json object to the user's browser that instructs on doing the redirects? Will Facebook even accept requests from a data subdomain, whose redirect_uri is at subdomain www? I find that last sentence in the quoted section probably discounts that as a possibility, but I've looked through their docs and it doesn't explicity say that this would be treated as a violation.
Has anyone had any experience setting up something like this with Facebook with a similar architecture? Perhaps I should just fold and put the FB login logic directly into PHP and handle it there.
Thanks!
I have a series of different domain names that I would like to all point (via URL forwarding from my domain host) to a google app engine application that reads what the forwarding URL is. So if the domain typed in was original XYZ.com, then when I am forwarded to my application, I can return what that original domain name was. I'm using the python variant. How best can I do this without coding for each and every variant?
Generally, the target of a 301/302 redirect can't determine what URL issued the redirect. If the user is redirected by client-side code, the referring page should be present in the "Referer" request header. For server-side redirects, I don't believe it's standard for user agents to populate (or override) the Referer header.
If you want to point multiple domains to your App Engine app, try configuring them as custom domains rather than forwards. With this route, the custom domain would stay in the user's address bar, and you can simply check the host header to see which custom domain the visitor is using.
If by forwarding you mean HTTP redirection, you can check the Referer header.
If you mean DNS resolving (e.g. distinguishing between your application being invoked via your own domain and .appspot.com one), there is SERVER_NAME environment variable (os.environ["SERVER_NAME"]) that stores the domain (e.g. www.example.com) used to issue the request.
If you are using a javascript redirect, that you can just check the referrer:
http://en.wikipedia.org/wiki/HTTP_referrer
but this is not a 100% solution.
If you have multiple domains parked on one appengine instance and you just want to know which one the user is viewing, you can check the host name in the request object.