I have both a Django app and a Angular JS app hosted at different end-points. Obviously in order for XHR requests to work I need to set the csrf token within Angular, which is easy enough to do when Angular is served by Django, but not so much when independent.
Here is my code so far:
angular.module('App', [
'ngCookies',
])
.run(['$rootScope', '$http', '$cookies',
function($rootScope, $http, $cookies){
// Set the CSRF header token to match Django
$http.defaults.headers.post['X-CSRFToken'] = $cookies['csrftoken'];
// Bootstrap
$http.get('http://127.0.0.1:8000/test/').success(function(resp){
console.log($cookies['csrftoken']);
});
}
])
It seems that $cookies['csrftoken'] is always undefined, and I assume I have to retrieve this somehow but can't find any resources as to how this process works.
Can anyone point me in the right direction?
Cookies are only accessible on the same origin, so accessing from another domain won't share the CSRF Token through cookies, you're going to have to find another way to introduce the cookie (such as with Django's template tag).
Second, your example looks likes its trying to read a Cookie from the $http.get() call. The $cookie service collects Cookies from when the document is loaded (stored document.cookie) and the resulting cookies are not accessible from Ajax/XHR calls cross-domain.
You can use this:
app = angular.module("App", []);
app.run(function($http) {
$http.defaults.headers.post['X-CSRFToken'] = $.cookie('csrftoken');
});
where $.cookie comes from jQuery Cookie plugin.
Related
I wish to create a public area on a website containing standard Django and templates. When a user logs in to the members area, they are logged in to a SPA (using Vue.js) and Django Rest Framework. I will be using JWT's to handle authentication between the SPA and backend once the user has logged in to the members area.
This is the user journey:
User browses around the public areas of the site (served by normal Django and templates).
User decides to signup / login to the members area.
Django Rest Framework generates a JWT for the user and returns the token along with the index.html of the SPA
The user continues to use the SPA with the JWT
Is the above possible and how would it be done? More specifically, the issue is that the user is not logging in to the SPA and requesting a JWT. They are logging in to regular Django and getting returned a JWT along with the SPA. That JWT would then be used from that point onwards.
This is something that I've used with laravel, but the principle should be the same.
I've placed vue-cli generated code into the subfolder frontend.
This is trimmed content of the file vue.config.js, which you need to add manually to the vue-cli project root.
const path = require('path')
/*
vue-cli is initialized in project subfolder `frontend`
and I run `npm run build` in that sub folder
*/
module.exports = {
outputDir: path.resolve(__dirname, '../public/'),
/*
https://cli.vuejs.org/config/#outputdir
!!! WARNING !!! target directory content will be removed before building
where js, css and the rest will be placed
*/
assetsDir: 'assets/',
/*
Where `public/index.html` should be written
- this is example for the laravel, but you can change as needed
- .blade.php is laravel template that's served trough laravel.
So you could inject JWT into `index.html`
- Check https://cli.vuejs.org/guide/html-and-static-assets.html
for the syntax before adding values
*/
indexPath: path.resolve(__dirname, '../resources/views/index.blade.php'),
devServer: {
host: '0.0.0.0',
port: 8021,
proxy: {
/*
Proxy calls from
localhost:8021/api (frontend)
localhost:8020/api (backend)
*/
'/api': {
target: 'http://localhost:8020',
changeOrigin: true,
}
}
}
};
I am using Django + Django REST Framework in an environment where I cannot use cookie-based CSRF tokens; therefore I must run with CSRF_USE_SESSIONS = True.
The DRF web UI, however, depends on this cookie for all interactions. It appears this is set by reading the csrftoken cookie and settings the X-CSRFToken header on the subsequent request, which is then consumed by django.middleware.csrf.CsrfViewMiddleware.process_view() if the hidden field is not included in the request body. This is set in this code from rest_framework.templates.rest_framework.base.html:
<script>
window.drf = {
csrfHeaderName: "{{ csrf_header_name|default:'X-CSRFToken' }}",
csrfCookieName: "{{ csrf_cookie_name|default:'csrftoken' }}"
};
</script>
DRF forms that do not use POST do contain the CSRF token in the form body, so not having the cookie means the web interface does not have access to the CSRF token at all, causing all PUT, PATCH, and DELETE requests to fail with a 403 response.
I believe this is a bug in DRF, but it is possible this is intended behavior. Can someone explain how DRF is intended to be used with CSRF_USE_SESSIONS = True?
This was fixed in https://github.com/encode/django-rest-framework/pull/6207 and released as part of DRF 3.9.2. More complete context can be read at https://github.com/encode/django-rest-framework/issues/6206.
I want to pass info to React about the current authenticated user within an app that only uses social authentication on the backend (that is processed by social_django). All of my user and user token info is stored within django REST, and to access the tokens, I normally have to send POST requests to rest_framework.authtoken's obtain_auth_token view. My django root urls.py file looks like:
...
from rest_framework.authtoken.views import obtain_auth_token
urlpatterns = [
...
url(r'^obtain-auth-token/$', obtain_auth_token),
...
]
However, in order to actually get the auth tokens associated with the users in my database, I need to supply the username and password within my POST request. Social authentication automatically creates new users without assigning any passwords, so how do I get those tokens?
Have you got this working? If no, here is what I did. Hope it helps.
My Setup:
Django with Postgres
Django Rest Framework for REST API implementation
Python Social Auth (PSA) for Social Authentication (For now using Google+ libraries)
Reactjs frontend
While using Login for login, it translates to /login/google-plus/. This not only get's the acess_token but also creates a "social user" in your database. I used oauth 2.0 client side libraries in my case and roughly followed this approach to fetch the google user object with all the details on the client side. I replaced form in above link with ajax call which is more flexible and gives control to me to access tokens and other information necessary. The ajax call here ensures creation of social user in social auth table within the database.
<script type="text/javascript">
gapi.load('auth2', function () {
let auth2;
auth2 = gapi.auth2.init({
client_id: "YOUR CLIENT ID",
scope: "profile",
cookie_policy: 'single_host_origin'
});
auth2.then(function () {
let button = document.getElementById("google-plus-button");
auth2.attachClickHandler(button, {}, function (googleUser) {
// Send access-token to backend to finish the authenticate
// with your application
let authResponse = googleUser.getAuthResponse();
$.ajax({
"type": "POST",
"url": "/complete/google-plus/",
"data": {
"access_token": authResponse.access_token,
"CSRF": "{% csrf_token %}"
}
}).then(function(data){
console.log(data);
// Your success code
}).fail(function(error){
console.log(error);
});
});
});
});
</script>
Once you fetch the access_tokens you can store them in browser local storage till the user logs out. On log out you can delete them.
This method works well for me for the setup I mentioned. Also the problem of querying /obtain-auth-token with username and password is not there at all.
Would definitely be interested to know if there are other ways of accessing social auth tokens from PSA django. Cheers!
I am using EmberJS along with ember-simple-auth and ember-data to authenticate and retrieve data from my API. One of my models contains properties that point to image URLs. I'd like to display these images in my app. I can do this using
<img class="thumbnail" src="{{user.thumbnail}}" />
The problem is that the images are protected and need an "Authorization" header to be set without which the API returns a 401. I thought about adding the token to the URL as a query parameter and modifying the API to accept it but it seems like a bad idea because the auth tokens will be present in the logs. Is there an EmberJS way of retrieving an image from a secured API?
EDIT based on your comment:
This is a server side solution so it would leave your ember code the way it is.
The approach is to never send the actual token with the images but use the token on the server to generate session specific image urls.
This way you never expose the absolute paths to your images but rather create relative urls that resolve to the absolute ones. You can use the session token as a key to an encryption algorithm like md5 and create the relative urls which would hide the sensitive information (such as the token) from the client, thus you would never send the token as the query parameter.
Note that this does mean that if the user is logged in and shares those image links, the images would be visible to anybody using the link until the user logs out (and his session is destroyed).
Previous suggestion
You could make a small component that does this for you where you pass in the url and either also pass the token or get it through an auth service. Then you use a computed property to combine the two. Here's a rough example:
// components/auth-img.js
export default Ember.Component.extend({
// passed in
class: '',
url: '',
token: '',
// local
tagName: 'img',
classNameBindings: ['class'],
attributeBindings: ['src'],
src: Ember.computed('url', 'token', function() {
let { url, token } = this.getProperties('url', 'token');
// combine your url and token and return
return // ...
})
});
And usage:
{{auth-img class="thumbnail" url=user.thumbnail}}
Trying to learn about security. Curious about why in django when
submitting a form (a POST), there are 2 separate "elements" that
contain the same csrf token value:
- the csrftoken cookie:
COOKIES:{'csrftoken': '1effe96056e91a8f58461ad56c0d4ddc', ...
- the Form's hidden csrfmiddlewaretoken:
POST:<QueryDict: {u'csrfmiddlewaretoken':
[u'1effe96056e91a8f58461ad56c0d4ddc'], ...
If django is inserting the hidden csrf field/value to
the form when it sends it to the browser (GET), and expects the
same value back when receiving the POST, then why is it
necessary to also set a cookie?
A more general question, if either of them was missing (form, cookie),
could you provide a scenario that explains how this could be exploited
(security attack)?
By the way, I ran a couple of simple tests to make sure that
django was checking the validity of each one separately and
indeed it is:
if I change the form's csrf value before doing the POST,
I get this debug error back:
CSRF token missing or incorrect
if I delete the csrf cookie before doing the POST,
I get a different error back:
CSRF cookie not set.
I'm just familiar with basic csrf concepts and want to
learn how django helps protect against these types of attacks.
Thanks,
jd
update:
Although both answers (S.Lott and M. DeSimone) were informative and
make sense, I thought that there could be a more detailed explanation
for requiring the presence of the security value in both the form and
in the cookie. While searching outside stackoverflow.com, I came across
a blog post from...Jeff Atwood.
I have included a third answer (sorry to answer my own question but
I think that it is relevant supplemental info) that refers to a blog
post from Jeff and includes a quotation.
From Jeff Atwood's blog entry:
Preventing CSRF and XSRF Attacks
(Oct 14, 2008)
The original post
The Felten and Zeller paper (pdf) recommends the "double-submitted
cookie" method to prevent XSRF:
When a user visits a site, the site should generate a
(cryptographically strong) pseudorandom value and set it as a
cookie on the user's machine. The site should require every form
submission to include this pseudorandom value as a form value and
also as a cookie value. When a POST request is sent to the site,
the request should only be considered valid if the form value and
the cookie value are the same. When an attacker submits a form on
behalf of a user, he can only modify the values of the form. An
attacker cannot read any data sent from the server or modify cookie
values, per the same-origin policy. This means that while an
attacker can send any value he wants with the form, he will be
unable to modify or read the value stored in the cookie. Since the
cookie value and the form value must be the same, the attacker will
be unable to successfully submit a form unless he is able to guess
the pseudorandom value.
The advantage of this approach is that it requires no server state;
you simply set the cookie value once, then every HTTP POST checks to
ensure that one of the submitted values contains the exact
same cookie value. Any difference between the two means a possible
XSRF attack.
The cookie is there for AJAX support. Quoting the Django docs:
While the above method can be used for AJAX POST requests, it has some inconveniences: you have to remember to pass the CSRF token in as POST data with every POST request. For this reason, there is an alternative method: on each XMLHttpRequest, set a custom X-CSRFToken header to the value of the CSRF token. This is often easier, because many javascript frameworks provide hooks that allow headers to be set on every request. In jQuery, you can use the ajaxSend event as follows:
$('html').ajaxSend(function(event, xhr, settings) {
function getCookie(name) {
var cookieValue = null;
if (document.cookie && document.cookie != '') {
var cookies = document.cookie.split(';');
for (var i = 0; i < cookies.length; i++) {
var cookie = jQuery.trim(cookies[i]);
// Does this cookie string begin with the name we want?
if (cookie.substring(0, name.length + 1) == (name + '=')) {
cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
break;
}
}
}
return cookieValue;
}
if (!(/^http:.*/.test(settings.url) || /^https:.*/.test(settings.url))) {
// Only send the token to relative URLs i.e. locally.
xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));
}
});
Adding this to a javascript file that is included on your site will ensure that AJAX POST requests that are made via jQuery will not be caught by the CSRF protection.
They spot two different problems.
Cookie is to authenticate the client machine making the connection.
The hidden form field is to authenticate the source of the form.
Example Scenario: User A, on the client machine could bookmark the form. User B logs on, gets a valid cookie from today. User A could submit the invalid form field from yesterday when the browser has a left-over cookie from user B's session.
what client/browser resources are typically compromised,
None.
and how is it that these csrf fields help protect us from the forgery requests?
The CSRF tokens establish identity.
One (and only one) browser has a CSRF cookie token. But that browser could have multiple copies of a site open or bookmarked forms.
One (and only one) page form on that browser has a CSRF form token.
The browser and form cookies must match to assure one browser/one form.