Web安全：会话和令牌

Web security has turned into a major topic, it plays an important role in building applications that are secure, and don’t suffer external attacks like XSS. Over the years, web security has evolved drastically. It began with sessions, and is now based on tokens. In this post, you will read about the transition, and how web security is handled nowadays.

Web安全已成为一个主要主题，它在构建安全的应用程序中扮演重要角色，并且不会遭受XSS之类的外部攻击。 多年来，Web安全已发生了巨大的发展。 它从会话开始，现在基于令牌。 在这篇文章中，您将了解有关过渡以及当今如何处理Web安全性的信息。

饼干 (Cookies)

Cookies are small pieces of data, shared by a server with a client, who is accessing or logging into a service offered by the server over the web. The server uses “set-cookie” tag for inserting the cookie into the response.

Cookie是服务器与客户端共享的一小段数据，客户端正在通过网络访问或登录该服务器提供的服务。 服务器使用“ set-cookie”标签将cookie插入响应中。

Once the user has successfully logged into the server, every request sent to the server from the client will have either the session id, or a token, which is saved in the cookie.

一旦用户成功登录服务器，从客户端发送到服务器的每个请求都将具有会话ID或令牌，该令牌将保存在Cookie中。

Cookie的属性： (Properties of a Cookie:)

1. These are “string” type data structures.
   这些是“字符串”类型的数据结构。
2. Cookies are stored in the client side.
   Cookies存储在客户端。
3. Cookies are never safe, mainly because they are not encrypted, and can be read easily.
   Cookies从来都不是安全的，主要是因为它们没有加密，并且易于读取。
4. Cookies are small pieces of information, less than 4kB in size.
   Cookies是一小段信息，大小小于4kB。

An Analog to Cookies

模拟饼干

You can imagine Cookies as an Employee ID card. When you join a company, you will receive the ID card, with an Employee ID. Every time you wish to enter the company, the ID needs to be presented at the security gate. And, when you leave the company for good, you will no longer be related to the ID.

您可以将Cookies想象为员工ID卡。 加入公司后，您将收到带有员工ID的ID卡。 每次您希望进入公司时，都需要在安全门口出示身份证。 而且，当您永久离开公司时，您将不再与该ID相关。

届会 (Session)

In the beginning, the server used Session ID to authenticate every client, logging into the server. Once the authentication is done, the Session ID is shared by the client with the server, for authorization. Both authentication, and authorization are different use cases for the Session ID.

最初，服务器使用会话ID来验证每个客户端的身份，并登录到服务器。 身份验证完成后，客户端将与服务器共享会话ID，以进行授权。 身份验证和授权都是Session ID的不同用例。

会话的属性 (Properties of a Session)

1. Maintained at the server
   在服务器上维护
2. Sessions are encrypted, and stored safely in the server. They are stored only in a single server at a time.
   会话被加密，并安全地存储在服务器中。 它们一次仅存储在单个服务器中。
3. Sessions have an “Object” data structure.
   会话具有“对象”数据结构。
4. The lifetime of a session depends on the server coding.
   会话的生存期取决于服务器编码。
5. Sessions are generally an overhead. They are expensive to create, and store.
   会话通常是开销。 它们的创建和存储非常昂贵。

An Analog to Session

模拟会话

Looping into our previous example, the Employee Data and the ID generated is managed by the company. Details about the employee are linked to the ID, and they are stored securely. The overall duration of the link, and the way the link is destroyed depends on the company’s policies. As long as an employee works for the company, it would translate into a Session.

循环到前面的示例中，员工数据和生成的ID由公司管理。 有关员工的详细信息已链接到该ID，并已安全地存储。 链接的总持续时间以及链接被销毁的方式取决于公司的政策。 只要一名员工在公司工作，就会转化为会议。

认证方式 (Authentication)

During Authentication, the user enters a username, and password to log into the server. Now, the user would be issued a Session ID by the server, which will be sent to the client in the form of a cookie. The cookie is set using the following line:

在身份验证期间，用户输入用户名和密码以登录服务器。 现在，服务器将向用户发布会话ID，该会话ID将以Cookie的形式发送给客户端。 使用以下行设置cookie：

Set-Cookie: SessionID = abcdefg123456; Domain=example1.com

The above cookie is then stored in the client’s local or session storage.

然后将上述cookie存储在客户端的本地或会话存储中。

Local Storage keeps cookies available to all tabs that are open in the browser. These cookies don’t have any expiry time. Even if the browser closes, and your system shuts down — you will have the cookies in your local storage.

本地存储使cookie可供浏览器中打开的所有选项卡使用。 这些Cookie没有到期时间。 即使浏览器关闭并且系统关闭，您也将在本地存储中存储cookie。

Session Storage keeps cookies alive only until the browser instance is active. Once you close the browser, the cookie will be destroyed. Refreshing your browser will not destroy the cookie. But, opening and closing tabs will destroy the cookie. Hence, the server needs to recreate a new Session ID, attach it to a cookie and send it, everytime you open, or close the browser (or tab).

会话存储仅在浏览器实例处于活动状态之前使cookie保持活动状态。 一旦关闭浏览器，cookie将被销毁。 刷新浏览器不会破坏cookie。 但是，打开和关闭标签将破坏cookie。 因此，每次您打开或关闭浏览器(或选项卡)时，服务器都需要重新创建一个新的会话ID，将其附加到cookie上并发送给它。

授权书 (Authorization)

Once the server authenticates, and shares a session ID, the client needs to send this back to the server with every new request. Hence, the server would validate if the session ID is present or not. If it is present, and if the user is valid, the request will be processed successfully. In case, the session ID doesn’t match with any record in the server’s database, the request will be rejected. This is nothing but the authorization of an operation, which the user intends to perform.

服务器进行身份验证并共享会话ID后，客户端需要将其与每个新请求一起发送回服务器。 因此，服务器将验证会话ID是否存在。 如果存在，并且用户有效，则将成功处理该请求。 如果会话ID与服务器数据库中的任何记录都不匹配，则该请求将被拒绝。 这不过是用户打算执行的操作授权。

会议的缺点 (Drawbacks of Session)

The concept of using a session ID makes the entire architecture prone to attacks, and makes the web an unsafe place. Here are few reasons why:

使用会话ID的概念使整个体系结构易于受到攻击，并使Web成为不安全的地方。 原因如下：

1. Cookies with session ID are nothing but plain text. During an attack, hackers can misuse the errors in client side code, to extract the session ID from a client machine. Then, this session ID can be used by the hacker, to perform operations like someone else. This is also known as Cross Site Scripting (XSS).

   具有会话ID的Cookie只是纯文本。 在攻击过程中，黑客可以滥用客户端代码中的错误，以从客户端计算机中提取会话ID。 然后，该会话ID可以被黑客用来执行其他操作。 这也称为跨站点脚本(XSS) 。

2. In case the server architecture, splits and manages its functionalities in different servers — the client will need a unique session ID for every operation performed. For instance, if there are two servers, and the client raises requests to both these servers — two different session IDs will be created. This is definitely an overhead, when it comes to complex systems.
   如果服务器架构在不同服务器中拆分和管理其功能，则客户端将需要为执行的每个操作使用唯一的会话ID。 例如，如果有两个服务器，并且客户端向这两个服务器都发出请求，则将创建两个不同的会话ID。 对于复杂的系统，这绝对是开销。

JSON Web令牌 (JSON Web Tokens)

JSON Web Tokens (JWT) is an architecture used to overcome the problems faced by the Session. Just like Sessions, JWT also makes use of cookies. However, the kind of information sent in the response is different.

JSON Web令牌(JWT)是一种用于克服会话面临的问题的体系结构。 就像Sessions一样，JWT也使用cookie。 但是，响应中发送的信息类型不同。

JWT has a “JSON” object structure in the response sent by the server. The three attributes in this data structure are header, payload and signature. Each of these attributes are separated using a “dot”. These attributes are encoded using Base64URL.

JWT在服务器发送的响应中具有“ JSON”对象结构。 此数据结构中的三个属性是标头 ， 有效负载和签名 。 这些属性中的每一个都使用“点”分隔。 这些属性使用Base64URL编码。

1. The Header contains information about the type of token, and the signing algorithm. The RSA algorithm is often used to encode the Header.

   标头包含有关令牌类型和签名算法的信息。 RSA算法通常用于编码标头。

2. The Payload contains information about the user, claims and permissions. It is important to ensure that the payload does not feature any passwords, or client sensitive information.

   有效负载包含有关用户，声明和权限的信息。 重要的是要确保有效负载不包含任何密码或客户端敏感信息。

3. The Signature is a combination of the Header, Payload and a Secret. The Secret can be decrypted only with the key maintained by the server. It is crucial, because it authorizes if the request is raised by the actual client.

   签名是标头，有效负载和机密的组合。 只能使用服务器维护的密钥来解密机密。 这很关键，因为它授权请求是否由实际客户提出。

Image Credits: jwt.io

图片来源： jwt.io

对称JWT签名 (Symmetric JWT Signatures)

The JWT JSON object structure of having a Header, Payload and Signature is maintained in the symmetric signature. Here, the same secret key is used in all the servers. If the secret key is changed, all the JWT tokens will be modified.

具有Header，Payload和Signature的JWT JSON对象结构在对称签名中维护。 在这里，所有服务器都使用相同的密钥。 如果更改了密钥，则将修改所有JWT令牌。

However, the symmetric JWT signatures don’t resolve the second problem in sessions. The secret key has to be shared across servers. All the services need the same secret key to ensure on the integrity of the client request. It would work fine, if the key is shared within the organization. But, if the verification of the client’s identity needs to be done by a third party service, it introduces a good amount of vulnerability.

但是，对称的JWT签名不能解决会话中的第二个问题。 密钥必须在服务器之间共享。 所有服务都需要相同的密钥，以确保客户端请求的完整性。 如果密钥在组织内共享，它将很好地工作。 但是，如果需要通过第三方服务来验证客户的身份，则会引入大量漏洞。

Technically, the idea of sharing a single secret key across services in different servers is not recommended. This will cause maintainability problems in the long run, of the architecture of the server.

从技术上讲，不建议在不同服务器中的服务之间共享单个密钥。 从长远来看，这将导致服务器体系结构的可维护性问题。

非对称JWT签名 (Asymmetric JWT Signatures)

The Asymmetric JWT Signatures make use of a public-private key pair. The signature is generated using a private key. But, it can be verified easily using the public key. This solves the problem faced by the symmetric JWT signature. The public key can be shared across services. And, the private key will be kept safely in a common location. The Asymmetric JWT Signature reduces the chances of breaching a single-service architecture.

非对称JWT签名使用公私钥对。 使用私钥生成签名。 但是，可以使用公钥轻松地对其进行验证。 这解决了对称JWT签名面临的问题。 公用密钥可以跨服务共享。 并且，私钥将安全地保存在公共位置。 非对称JWT签名减少了违反单一服务体系结构的机会。

Sending the Public Key for Asymmetric JWT Signatures

发送非对称JWT签名的公钥

The Public Key can be shared with the client through the header of the response. Here, the client can decide if the key could be accepted or rejected. A drawback in this method would be malicious private keys being sent along with the token.

可以通过响应的标头与客户端共享公钥。 在这里，客户可以决定是否可以接受或拒绝密钥。 这种方法的缺点是将恶意私有密钥与令牌一起发送。

Secondly, the public key can be shared via a X509 certificate format. The authenticity of the certificate can be used to judge if the public key can be used or not.

其次，可以通过X509证书格式共享公钥。 证书的真实性可用于判断是否可以使用公钥。

Thirdly, the public key can be shared using a Key URL. The key url follows the X509 format. But, the client needs to validate and whitelist the Key URL. Once the Key URL is received, the client browser can cache it. As a result, the overall peformance of validating the response from the server would increase.

第三，可以使用Key URL共享公共密钥。 密钥URL遵循X509格式。 但是，客户端需要验证密钥URL并将其列入白名单。 收到密钥URL后，客户端浏览器便可以对其进行缓存。 结果，验证来自服务器的响应的总体性能将提高。

A common example for Asymmetric JWT signatures would be the OpenID Connect. This is an authentication protocol that allows clients to log into services using their Google, Twitter or other reputed channels. Now, the Private key will be stored safely by Google, Twitter or the chosen channel. When the client decides to log into a third party service, using the aforementioned accounts — Google/Twitter/other channel will engage in the verification. The algorithm, and private key will be unique to the service that authenticates and authorizes. This is famously known as Single-Sign-On (SSO).

非对称JWT签名的常见示例是OpenID Connect。 这是一种身份验证协议，允许客户端使用其Google，Twitter或其他知名渠道登录服务。 现在，私钥将由Google，Twitter或所选渠道安全地存储。 当客户决定使用上述帐户登录第三方服务时，Google / Twitter /其他渠道将参与验证。 该算法和私钥对于身份验证和授权的服务将是唯一的。 这就是众所周知的单点登录(SSO) 。

智威汤逊的特性 (Properties of JWT)

1. The JWT architecture comes with an expiration date, and time (exp). This ensures that the token expires after the given time.
   JWT体系结构带有到期日期和时间(exp)。 这样可以确保令牌在给定时间后过期。
2. The token comes with details of when it was created in the first place (iat). This helps in deciding if the token is fresh or not.
   令牌附带了最初创建时间的详细信息(iat)。 这有助于确定令牌是否新鲜。
3. The token has details of when it would become active (nbf). It cannot be used before the mentioned time.
   令牌具有何时激活的详细信息(nbf)。 在上述时间之前不能使用它。
4. The token helps in validating the issuer (iss). This is important when services are authorized by third parties, during operations like Single Sign On.
   该令牌有助于验证发行者(瑞士)。 在诸如Single Sign On之类的操作中，当服务由第三方授权时，这一点很重要。
5. The token has a way of targeting a specific group of audiences, or clients (aud).
   令牌具有一种针对特定受众群体或客户(aud)的方式。

代币流 (Flow of Tokens)

During the JWT request-response architecture, the client logs into the service with a username, and password. Then the server uses the user name, password and private key to create a signature. The header, payload and signature are then shared via a token back to the client. This token will be saved in the client machine.

在JWT请求-响应体系结构期间，客户端使用用户名和密码登录到服务。 然后，服务器使用用户名，密码和私钥创建签名。 然后通过令牌将标头，有效负载和签名共享回客户端。 该令牌将保存在客户端计算机中。

When the client raises a new request, the secret is shared, along with identity information of the client. Now, the server uses the public key to decrypt the signature. If the signature matches with the identity shared, the server continues with the operation. Else, the request is rejected.

当客户端提出新请求时，机密将与客户端的身份信息一起共享。 现在，服务器使用公共密钥来解密签名。 如果签名与共享的身份匹配，则服务器继续操作。 否则，请求被拒绝。

智威汤逊的优势 (Advantages of JWT)

1. No data is stored at the server level. This reduces the overall overhead. This also makes JWT a stateless.

   没有数据存储在服务器级别。 这减少了总体开销。 这也使JWT成为无状态的 。

2. The client request can be handled by any server. It doesn’t need to be confined to a single server. Hence, horizontal scaling becomes easier.

   客户端请求可以由任何服务器处理。 它不必局限于单个服务器。 因此， 水平缩放变得更容易。

3. The chances of XSS and CORS attacks are reduced in JWT. Remember, you cannot absolish the scope of an attack. But, it is significantly reduced.
   JWT中减少了XSS和CORS攻击的机会。 请记住，您不能放弃攻击的范围。 但是，它大大减少了。

结论 (Conclusion)

On the whole, web security has come a long way. It is no longer bound by cookies and sessions. Instead, it is more stateless and governed by the public/private key system. However, there is still a good amount of focus on “session” involved in the tokens. For instance, JWT tokens will expire after a point of time. And, it is upto the service to decide on what the JWT claims will be.

总体而言，Web安全已经走了很长一段路。 它不再受Cookie和会话的约束。 相反，它更是无状态的，由公钥/私钥系统控制。 但是，仍然非常重视令牌中涉及的“会话”。 例如，JWT令牌将在某个时间点后过期。 并且，由服务决定JWT的要求是什么。

翻译自: https://medium.com/swlh/web-security-sessions-and-tokens-6468c6feaa41