文档章节

Secured RESTful API that can be used by Web App

freeroad
 freeroad
发布于 2014/09/28 23:49
字数 1819
阅读 100
收藏 3

You seem to be confusing/merging two different concepts together. We start of talking about encrypting traffic (HTTPS) and then we start talking about different ways to manage authenticated sessions. In a secure application these are not mutually exclusive tasks. There also seem to potentially be a misunderstanding how session management can impact authentication. Based on that I will provide a primer on web application/web api session management, authentication, and encryption.

Introduction Session Management

HTTP transactions are stateless by default. HTTP does not specify any method to let your application know that a HTTP request has been sent from a specific user (authenticated or not).

For robust web applications, this is not acceptable. We need a way to associate requests and data made across multiple requests. To do this, on initial request to the server a user needs to be assigned a "session". Generally sessions have some kind of unique id that is sent to the client. The client sends that session id with every request and the server uses the session id sent in every request to properly prepare a response for the user.

It is important to remember that a 'session id' can be called many other things. Some examples of those are: session token, token, etc. For consistency I will use 'session id' for the rest of this response.

Each HTTP request from the client needs to include the session id; this can be done in many ways. Popular examples are:

It can be stored in a cookie - cookies for the current domain are automatically sent on every request. It can be sent on the URL - each request could send the session id on the URL, not suggested since session ids will stay in the clients history It can be sent via as a HTTP header - each request would need to specify the header Most web application frameworks use cookies. However application that rely on JavaScript and single page designs may opt to use a HTTP header/store it in some other location that is observable by the server.

It is very important to remember that the HTTP response that notifies the client of their session id and the client's requests that contain the session id are completely plain text and 100% unsafe. To battle that, all HTTP traffic needs to be encrypted; that is where HTTPS comes in.

It is also important to point out we have not talked about linking a session to a specific user in our system. Session management is just associating data to a specific client accessing our system. The client can be in both authenticated and unauthenticated states, but in both states they generally have a session.

Authentication

Authentication is where we link a session to a specific user in our system. This is generally handled by a login process where a user supplies credentials, those credentials are verified, and then we link a session to a specific user record in our system.

The user is in turn associated with privileges for fine grained access control via access control lists and access control entries (ACL and ACE). This is generally referred to as "Authorization". Most system always have both Authentication and Authorization. In some simple systems all authenticated users are equals in which case you won't have authorization past simple authentication. Further information on this is out of scope for this question, but consider reading about ACE/ACL.

A specific session can be flagged as representing an authenticated user in different ways.

Their session data stored server side could store their user id / some other flag that denotes that the use is authenticated as a specific user Another user token could be send to the client just like a session id (which over unencrypted HTTP is just as unsafe as sending a session id unencrypted) Either option is fine. It generally comes down to the technology you are working in and what they offer by default.

A client generally initiates the authentication process. This can be done by sending credentials to a specific url (e.g. yoursite.com/api/login). However if we want to be 'RESTful' we generally would referencing a resource by some noun and doing the action of 'create'. This could be done by requiring a POST of the credentials to yoursite.com/api/authenticatedSession/. Where the idea would be to create an authenticated session. Most sites just POST the credentials to /api/login or the like. This is a departure from "true" or "pure" RESTful ideals, but most people find this a simpler concept rather than thinking of it as "creating an authenticated session".

Encryption

HTTPS is used to encrypt HTTP traffic between a client and server. On a system that relies on authenticated and unauthenticated users, all traffic that relies on a user being authenticated needs to be encrypted via HTTPS; there is no way around this.

The reason for this is that if you authenticate a user, share a secret with them (their session id, etc) and then begin to parade that secret in plain HTTP their session can be hijacked by man-in-the-middle attacks. A hacker will wait for for the traffic to go through an observed network and steal the secret (since its plain text over HTTP) and then initiate a connection to your server pretending to be the original client.

One way people combat this is by associating the requests remote IP address to an authenticated session. This is ineffective alone as any hacker will be able to spoof their requests remote IP address in their fake requests and then observe the responses your sever is sending back. Most would argue that this is not even worth implementing unless you are tracking historical data and using it to identify a specific user's login patterns (like Google does).

If you need to split up your site between HTTP and HTTPS sections, it is imperative that the HTTP traffic does not send or receive the session id or any token used to manage the authentication status of a user. It is also important that you do not send sensitive application data within non-HTTPs requests/responses.

The only way to secure data within web applications/APIs is to encrypt your traffic.

Your Topics One By One Basic-Http-Auth

Authentication: YES Session Management: NO Encryption: NO This is a method for authenticating by web resource only. Basic authentication authenticates uses by resource identified by URL. This was most popularly implemented by Apache HTTP Web Server with the use of .htaccess based directory/location authentication. Credentials have to be sent with each request; clients generally handled this transparently for users.

Basic authentication can be used by other systems as a mode of authentication. However, the systems that utilize Basic-Http-Auth are providing authentication and session management, not the Basic-Http-Auth itself.

This is not session management. This is not encryption; content and credentials are nearly 100% plain text This does not secure the contents of the application's HTTP request/responses. Digest-Auth

Authentication: YES Session Management: NO Encryption: NO This is exactly the same as Basic-Http-Auth with the addition of some simple MD5 digesting. This digesting should not be relied upon instead of using encryption.

This is not session management. This is not encryption; the digest is easily broken This does not secure the contents of the application's HTTP request/responses. OAuth

Authentication: YES Session Management: NO Encryption: NO OAuth just lets you have an external service validate credentials. After that it is up to you to manage/work with the result of authentication request to your OAuth provider.

This is not session management. This is not encryption; your sites traffic is still plain text. The authentication process will be secure due to HTTPS restrictions, but your application is still vulnerable. This does not secure the contents of the application's HTTP request/responses. Gangster Handshake / Custom HTTP header

Authentication: YES, potentially Session Management: YES, potentially Encryption: NO "Custom HTTP header" is a type of "Gangster Handshakes"; as such I will use the same section to discuss them. The only difference is that a "Custom HTTP header" is specifying where the hanshake (session id, token, user authentication toke, etc) will be stored (i.e. in a HTTP header).

It is important to note that these do not specify how authentication will be handled, nor do they specify how session management will be handled. They essentially describe how and where session ids/authentication tokens will be stored.

Authentication would need to be handled by your application or via a third party (e.g. OAuth). Session management will still need to be implemented as well. The interesting thing is you can choose the merge the two if you wish.

This is not encryption; your sites traffic is still plain text. The authentication process will be secure due to HTTPS restrictions if you use OAuth, but your application is still vulnerable. This does not secure the contents of the application's HTTP request/responses. What You Need To Do ...I highly suggest you make sure that you understand that a robust web application that is secure needs the following:

Encryption (HTTPS is pretty much your only choice) Session Management Authentication / Authorization Authorization relies upon Authentication. Authentication relies upon Session Management and Encryption makes sure the session isn't hijacked and that the credentials are not intercepted.

Flask-Login

I think you should look into flask-login as a way to avoid re-implementing the wheel. I have personally never used it (I use pyramid for web applications in python). However, I have seen it mentioned before in web application/python boards. It handles both authentication and session management. Throw your web api/application through HTTPS and you have all three (Encryption, Session Management, and User Authentication).

If you do not / can not use flask-login, be prepared to write your own, but do research first on how to create secure authentication mechanisms.

If at all possible, if you do not understand how to write an authentication procedure please do not attempt it without first learning how hackers use pattern based attacks, timing attacks, etc.

Please Encrypt Your Traffic

...move past the idea that you can avoid using HTTPS with some "clever" token use. Move past the idea that you should avoid using HTTPS/encryption because "its slow", process intensive, etc. It is process intensive because it is an encryption algorithm. The need to ensure the safety of your user's data and your applications data should always be your highest priority. You do not want to go through the horror of notifying your users that their data was compromised.

本文转载自:http://stackoverflow.com/questions/16400476/secured-restful-api-that-can-be-used-by-web-app-angul...

共有 人打赏支持
freeroad
粉丝 2
博文 8
码字总数 669
作品 0
海淀
私信 提问
Build RESTful APIs with Spring MVC:Security

Secures APIs We have configured Spring Security in before posts. In this post, I will show you using Spring Security to protect APIs, aka provides Anthentication and Anthorizati......

hantsy
2016/07/25
62
0
在Github中stars数最多的Go Web框架集合

Project Name Stars Forks Description beego 12195 2810 beego is an open-source, high-performance web framework for the Go programming language. gin 11602 1357 Gin is a HTTP web f......

终于19岁
2017/09/07
0
0
Using ransack and delegate in Rails

Personal page I have used Rails to develop web project for two years, But it's the first time to use ransack, a Gem base on Object searing. This note recording my experience of ......

hww_面条酱
2017/09/09
0
0
Flask-RESTful构建小型REST服务

Flask-RESTful构建小型REST服务 2015年6月18日 by debugo · Leave a comment REST是web services和APIs的标准架构,很多APP的架构基本上是使用RESTful的形式了。诸如docker daemon等服务都是...

openthings
2016/04/19
233
0
RESTful SPA 杂谈

RESTful SPA 杂谈 在从前的从前,Javascript还不是流行的时代,HTML语言可以说是浏览器的基础了,那时候,一个页面的HTML渲染,完全依赖于后端服务器,如JSP ,PHP等页面渲染技术。 后来Jav...

精通吹水
2016/01/16
181
0

没有更多内容

加载失败,请刷新页面

加载更多

centos7 Nginx+rtmp 搭建流媒体服务器

一. gcc 安装 安装 nginx 需要先将官网下载的源码进行编译,编译依赖 gcc 环境,如果没有 gcc 环境,则需要安装: yum -y install gcc gcc-c++ 二. PCRE pcre-devel 安装 PCRE(Perl Compatib...

legend3
29分钟前
2
0
“别更新了,学不动了” 之:全栈开发者 2019 应该学些什么?

转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具、解决方案和服务,赋能开发者。 原文转载自 公众号 infoqchina 对于什么是全栈开发者并没有一个明确的定义。但是,有一件事是...

葡萄城技术团队
46分钟前
6
0
OSChina 周五乱弹 —— 姑娘馋的口水都留下来了。

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @且无需多言 :分享Fall Out Boy的单曲《Disloyal Order Of Water Buffaloes》 《Disloyal Order Of Water Buffaloes》- Fall Out Boy 手机党...

小小编辑
今天
783
15
vue 对对象的属性进行修改时,不能渲染页面 vue.$set()

我在vue里的方法里给一个对象添加某个属性时,我console.log出来的是已经更改的object ,但是页面始终没有变化 原因如下: **受现代 JavaScript 的限制 (而且 Object.observe 也已经被废弃),...

Js_Mei
今天
2
0
开始看《Java学习笔记》

虽然书买了很久,但一直没看。这其中也写过一些Java程序,但都是基于IDE的帮助和对C#的理解来写的,感觉不踏实。 林信良的书写得蛮好的,能够帮助打好基础,看得出作者是比较用心的。 第1章概...

max佩恩
昨天
13
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部