I use Django and Django-rest-framework about REST services from Back-end and Mobile Client Apps.
I would to have some responses with encrypted data. I have to return to my client some sensible and private data and I would to apply an additional security layer (in fact I already use SSL, but I would to disarm some attacks (like man in the middle) where some unwanted element can see some data contained in my responses).
I would to avoid this, so I thought to add in my response the encrypted data.
Does that make sense? Is there something similar in Django - REST- Framework?
A good encryption libary with various implementations is Keyczar.
What you would need to do is write a global interceptor on all incoming request to your backend application, and when responses are sent back they are encrypted using the Keyczar library.
On the consumer side (your mobile application) you would need to implement something similar that decrypts the responses from your backend.
BONUS: if you're not doing this already, you probably want to look at using 2-way SSL to ensure that you authenticate the client that calls your backend.
Related
I have a python application that needs to give users a JSON web token for authentication. The token is built using the PyJWT library (import jwt).
From what I have been reading it seems like an acceptable practice to give the token to a client after they have provided some credentials, such as logging in.
The client then uses that token in the HTTP request header in the Authorization Bearer field which must happen over TLS to ensure the token is not exposed.
The part I do not understand is what if the client exposes that token accidentally? Won't that enable anybody with that token to impersonate them?
What is the most secure way to hand off the token to a client?
You could encrypt the token before handing it off to the client, either using their own public key, or delivering them the key out of band. That secures the delivery, but still does not cover everything.
In short, there's no easy solution. You can perform due diligence and require use of security features, but once the client has decrypted the token, there is still no way to ensure they won't accidentally or otherwise expose it anyway. Good security requires both participants practice good habits.
The nice thing about tokens is you can just give them a preset lifespan, or easily revoke them and generate new ones if you suspect they have been compromised.
Token will be build based on user provided information and what you back-end decided to be part of the token. For higher security you can just widen your token information to some specific data of the user like current ip address or device mac address, this will give you a more secure way of authentication but will restrict user to every time use the same device, as a matter you can send a confirmation email when a new login happens.
I'm getting started out creating a website where users can store and get (on user request) private information they store on the server. Since the information is private, I would also like to provide 256 bit encryption. So, how should I go about it? Should I code the back end server stuff in node.js or Python, since I'm comfortable with both languages? How do I go about providing a secure server to the user? And if in the future, I would like to expand my service to mobile apps for Android and iOS, what would be the process?
Please try explaining in detail since that would be a great help :)
You don't need to create your own encrypted communication protocol. Just serve all traffic over https.
If you also wish to encrypt the data before storing it on a database you can encrypt it on arrival to the server.
Check out Express.js for the server, Passport.js for authentication and search for 256-bit encryption on npm. There are quite a few implementations.
This is a follow up question for this.
I'm using the latest Django OAuth2 Toolkit (0.10.0) with Python 2.7, Django 1.8 and Django REST framework 3.3
Some background:
When authenticating, the client receive a new AccessToken that he uses every time a makes a new request to the server. This AccessToken is owned by the client and being transferred using Authorization header upon request.
A simple test that I made was grabbing this access token from an authenticated client and send it in the Authorization header using a simple HTTP request from a different machine.
The result was that this new "client" is now authenticated just like the original client, and he can make requests as he pleased.
So the issue is:
The access token is not bind to any form of client validation (Like session id or client IP address). Any one that can get/find/steal/lookup the client's AccessToken, can be fake requests on behalf of this client.
I researched this issue allot but I couldn't find any one who addressed this matter. Maybe i'm doing something wrong in the from of authenticating the client? I would love some insights. Maybe its a simple configuration, out-of-the-box solution that I missed.
Thanks!
This method of attack is called replay attack. This video by Professor Messer explains replay attack.
You can't really implement anything client side (browser) to overcome this because of the transparency of web browsers.
What you can do is to implement a digest authentication using a nonce.
In cryptography, a nonce is an arbitrary number that may only be used once.
a basic implementation looks like this.
User requests API server.
API server responds with a HTTP 401 and a nonce in a WWW-Authenticate header [you have to keep track of nonces] (a JWT with nonce which is set to expire in a small window, may be 2 seconds or less would be better and stateless).
Client signs the request with received nonce, a client nonce and password and calls the resource again.
API server validates the signature, If the signature is valid the request is accepted.
Attacker captures the request and fakes the user.
Since nonce is expired/'used only once' the attacker's request is rejected.
I have a django project, in which i expose a few api endpoints (api endpoint = answers to get/post, returns json response, correct me if im wrong in my definition). Those endpoints are used by me on front end, like update counts or get updated content, or a myriad other things. I handle the representation logic on server side, in templates, and in some cases send a rendered to string template to the client.
So here are the questions im trying to answer:
Do i need to have some kind of authentication between the clients and the server?
Is django cross origin protection enough?
Where, in this picture, fit such packages like django-oauth-toolkit? And django-rest-framework?
if i don't add any authentication between clients and server, am i leaving my server open for attacks?
Furthermore, what goes for server-to-server connection? Both servers under my control.
I would strongly recommend using django-tastypie for server to client communication.
I have used it in numerous applications both server to server or server to client.
This allows you to apply the django security as well as some more logic regarding the authorization process.
It offers also out of the box:
throttling
serialization in json, xml, and other formats
authentication (basic, apikey, customized and other)
validation
authorization
pagination
caching
So, as an overall overview i would suggest on building on such a framework that would make your internal api more interoperable for future extensions and more secure.
To specifically now answer your question, i would never enable any server api without at least some basic authentication/authorization.
Hopefully i answer your questions on how you can deliver all of your above worries with a framework.
The django-rest-framework that you ask for, is also really advanced and easy to use, but i prefer tastypie for the reasons i explain.
I hope i helped a bit!
For my final year project I plan to code a cloud in Python. The client will be written in Java by the other member of my team. The client will have a tabbed interface and it will provide a text editor, a media player, a couple of small Java based games and a maybe a few more services.
The server will work like this:
1) Validate the user.
2) Send a file, called "dump" to the user. Dump will contain all the file names and file types that the user created by himself or the files which the user can read/write. This info will be fetched from the database.
3) The tabs in the client will display the file types associated with the tab application. e.g the media tab will only select and show the media files from the dump readable by user. The text editor tab will show only the txt files from the dump readable by the user.
4) A request to open the file will send the file back to client, which the associated application will open.
5) All the changes made to the files and all the actions (overwriting, saving, deleting etc.) will be sent back to the server along with the new object. Something similar will be done to the newly created objects.
My Questions are:
What are the best approaches for the communication between the client and the server. For the dump I plan to use some sort of encrypted XML file. For the other way round, I don't have a clue :/.
For easy integration with the database, I was planning to use Django (which I started few days back). How can I send my requests from the client to the server (without Django I'd use SQL queries) and the files from the server to the client? Maybe GET and POST will work for the former problem? Any other suggestions?
Q1: how should I transfer data between client/server securely
A: HTTPS to support encryption & JSON to serialise objects between languages (Python/Java) seems to be the most natural. You could experiment with XML-RPC over SSL or TSL if you want to be creative.
Q2: How do I send queries to the server's db?
A: My first response is to say talk to the person coding the server, and see what's easiest on that end. However, I think that your client should stick to HTTP. The server developer would ensure the server supports RESTful URIs. Then your client only access a URI and have the results processed by the server.
At its most raw, this could be implemented like this:
https://www.example.com/db?q="SELECT * FROM docs"
There are smarter ways to do it, but you get the idea.
If you're going to use a web framework on the server, it makes sense to use an HTTP-based protocol. The downside is that only the client can initiate a connection (e.g., the client needs to first ask for the "dump" file), but a simple GET request will suffice (remember, the server can send anything in the HTTP response, including your XML file).
Regarding encryption, it's best to use an existing protocol like HTTPS. There are well-vetted libraries that will correctly establish a secure connection between your client and the server.
Overall, I'm advocating the highest-level protocols that are appropriate for your application. HTTP(S) goes hand-in-hand with your web-based architecture, so make use of it.
Stick to Django. It's really productive. I would use JSON instead of XML. More convenient. import json. This should help you in communicating between client-server.
Also cloud computing is just a recent word that's just thrown around for (client+server+some services). Oh by the way all that you want to do can be completely done in Django itself. No need to go to JAVA.
Django is Cool :)