ession Hijacking

We've already seen that the session plays an important role in keeping HTTP stateful. We also know that a session id serves as that unique token used to identify each session. Usually, the session id is implemented as a random string and comes in the form of a cookie stored on the computer. With the session id in place on the client side now every time a request is sent to the server, this data is added and used to identify the session. In fact, this is what many web applications with authentication systems do. When a user's username and password match, the session id is stored on their browser so that on the next request they won't have to re-authenticate.

Unfortunately, if an attacker gets a hold of the session id, both the attacker and the user now share the same session and both can access the web application. In session hijacking, the user won't even know an attacker is accessing his or her session without ever even knowing the username or password.

Countermeasures for Session Hijacking

• One popular way of solving session hijacking is by resetting sessions. With authentication systems, this means a successful login must render an old session id invalid and create a new one. With this in place, on the next request, the victim will be required to authenticate. At this point, the altered session id will change, and the attacker will not be able to have access. Most websites implement this technique by making sure users authenticate when entering any potentially sensitive area, such as charging a credit card or deleting the account.
• Another useful solution is by setting an expiration time on sessions. Sessions that do not expire give an attacker an infinite amount of time to pose as the real user. Expiring sessions after, say 30 minutes, gives the attacker a far narrower window to access the app.
• Finally, as we have already covered, another approach is to use HTTPS across the entire app to minimize the chance that an attacker can get to the session id.

会话劫持

我们已经看到会话在保持 HTTP 状态方面起着重要作用。我们还知道会话 id 用作用于标识每个会话的唯一令牌。通常，会话 ID 以随机字符串的形式实现，并以存储在计算机上的 cookie 的形式出现。现在，每次向服务器发送请求时，在客户端都设置了会话 ID，此数据被添加并用于识别会话。事实上，这就是许多带有身份验证系统的 Web 应用程序所做的。当用户的用户名和密码匹配时，会话 ID 会存储在他们的浏览器中，这样在下一次请求时他们就不必重新进行身份验证。

不幸的是，如果攻击者获得了会话 ID，攻击者和用户现在都共享同一个会话，并且都可以访问 Web 应用程序。在会话劫持中，用户甚至不知道攻击者正在访问他或她的会话，甚至不知道用户名或密码。

会话劫持对策

解决会话劫持的一种流行方法是重置会话。对于身份验证系统，这意味着成功登录必须使旧会话 ID 无效并创建一个新会话 ID。有了这个，在下一个请求中，受害者将被要求进行身份验证。（译者：每次登录前都要做个认证，而且每次会话id都变化）此时，更改后的会话 id 会发生变化，攻击者将无法访问。大多数网站通过确保用户在进入任何潜在敏感区域（例如从信用卡收费或删除帐户）时进行身份验证来实现此技术。

另一个有用的解决方案是设置会话的过期时间。不会过期的会话给攻击者无限的时间来伪装成真实用户。会话过期，比如 30 分钟，给攻击者一个更窄的窗口来访问应用程序。

最后，正如我们已经介绍过的，另一种方法是在整个应用程序中使用 HTTPS，以最大限度地减少攻击者获取会话 ID 的机会。

Cross-Site Scripting (XSS)

The final security concern we'll talk about, and a very important one for all web developers, is called Cross-site scripting, or XSS. This type of attack happens when you allow users to input HTML or JavaScript that ends up being displayed by the site directly.

For example, the form below allows you to add comments, which will then be displayed on the site.

跨站脚本 (XSS)

我们将讨论的最后一个安全问题，对所有 Web 开发人员来说非常重要，称为跨站点脚本或 XSS。当您允许用户输入最终由站点直接显示的 HTML 或 JavaScript 时，就会发生这种类型的攻击。

例如，下面的表格允许您添加评论，然后将显示在网站上。

Because it's just a normal HTML <textarea>, users are free to input anything into the form. This means users can add raw HTML and JavaScript into the text area and submit it to the server as well:

因为它只是一个普通的 HTML <textarea>，用户可以自由地在表单中输入任何内容。这意味着用户可以将原始 HTML 和 JavaScript 添加到文本区域并将其提交给服务器：

If the server side code doesn't do any sanitization of input, the user input will be injected into the page contents, and the browser will interpret the HTML and JavaScript and execute it. In this case an alert message will pop up, which is definitely not the desired outcome. Attackers can craft ingeniously malicious HTML and JavaScript and be very destructive to both the server as well as future visitors of this page. For example, an attacker can use JavaScript to grab the session id of every future visitor of this site and then come back and assume their identity. It could happen silently without the victims ever knowing about it. Note that the malicious code would bypass the same-origin policy because the code lives on the site.

如果服务器端代码没有对输入进行任何清理，用户输入将被注入到页面内容中，浏览器将解释 HTML 和 JavaScript 并执行它。在这种情况下，会弹出一条警告消息，这绝对不是预期的结果。攻击者可以巧妙地制作恶意 HTML 和 JavaScript，并对服务器以及该页面的未来访问者造成极大的破坏。例如，攻击者可以使用 JavaScript 获取该站点每个未来访问者的会话 ID，然后返回并假设他们的身份。它可能会在受害者不知道的情况下悄然发生。请注意，恶意代码会绕过同源策略，因为代码存在于网站上。（译者：当年在传奇网站上，挂马偷账户信息，是不是就用的这个。哭）

Potential solutions for cross-site scripting

• One way to prevent this kind of attack is by making sure to always sanitize user input. Eliminate problematic input, such as <script> tags, or disallowing HTML and JavaScript input altogether in favor of a safer format, like Markdown.
• The second way to guard against XSS is to escape all user input data when displaying it. If you do need to allow users to input HTML and JavaScript, then when you print it out, make sure to escape it so that the browser does not interpret it as code.

跨站点脚本的潜在解决方案

防止这种攻击的一种方法是确保始终清理用户输入。消除有问题的输入，例如 <script> 标签，或者完全禁止 HTML 和 JavaScript 输入，以支持更安全的格式，例如 Markdown。

防止 XSS 的第二种方法是在显示时转义所有用户输入数据。如果您确实需要允许用户输入 HTML 和 JavaScript，那么当您将其打印出来时，请确保将其转义，以便浏览器不会将其解释为代码。

Escaping

We mention the term "escaping" above. To escape a character means to replace an HTML character with a combination of ASCII characters, which tells the client to display that character as is, and to not process it; this helps prevent malicious code from running on a page. These combinations of ASCII characters are called HTML entities.

Consider the following HTML: <p>Hello World!<\p>. Let's say we don't want the browser to read this as HTML. To accomplish this, we can escape special characters that the browser uses detect when HTML starts and ends, namely < and >, with HTML entities. If we write the following: <p>Hello World!<\p>, then that HTML will be displayed as plain text instead.

转义

我们在上面提到了“转义”这个词。转义字符意味着用 ASCII 字符的组合替换 HTML 字符，这告诉客户端按原样显示该字符，而不是处理它；这有助于防止恶意代码在页面上运行。这些 ASCII 字符的组合称为 HTML 实体。

考虑以下 HTML：<p>Hello World!<\p>。假设我们不希望浏览器将其读取为 HTML。为此，我们可以使用 HTML 实体转义浏览器使用检测 HTML 何时开始和结束的特殊字符，即 < 和 >。如果我们编写以下内容：<p>Hello World!<\p>，那么该 HTML 将改为显示为纯文本。

Summary

In this section, we covered various aspects of security in web applications. Needless to say, this is a huge topic, and we've only scratched the surface of a few common issues. The point of this chapter is to reveal how fragile and problematic developing and securing a web application is, and it's mostly due to working with HTTP.

概括

在本节中，我们介绍了 Web 应用程序中安全性的各个方面。不用说，这是一个巨大的话题，我们只触及了一些常见问题的皮毛。本章的重点是揭示开发和保护 Web 应用程序的脆弱性和问题，这主要是由于使用 HTTP。

-- 翻译完了，提交了，结果浏览器崩溃了，谢谢你头条，让我重新从google 复制粘贴，发现google绝大多数情况下比我翻译的更精准。

ession Hijacking

We've already seen that the session plays an important role in keeping HTTP stateful. We also know that a session id serves as that unique token used to identify each session. Usually, the session id is implemented as a random string and comes in the form of a cookie stored on the computer. With the session id in place on the client side now every time a request is sent to the server, this data is added and used to identify the session. In fact, this is what many web applications with authentication systems do. When a user's username and password match, the session id is stored on their browser so that on the next request they won't have to re-authenticate.

Unfortunately, if an attacker gets a hold of the session id, both the attacker and the user now share the same session and both can access the web application. In session hijacking, the user won't even know an attacker is accessing his or her session without ever even knowing the username or password.

会话劫持

我们已经看到，是会话在让HTTP 变得有状态。我们也知道，会话ID 作为一个独立的秘钥（token）来识别每个会话。一般来说，会话ID就是一串随机的字符串，并被客户端的电脑以cookie方式存储。使用客户端会话id，每次一个请求发送到服务端，此数据会被添加，而且被用来识别这个会话。实际上，这就是很多带认证系统的web 应用程序做的事情。当用户的用户名和密码匹配，会话id被存储在浏览器上，下一个请求也不必要重新认证。

不幸的是，如果攻击者拿到了会话id，攻击者和用户共享同样的会话，而且都可以访问web应用。在会话劫持场景中，用户甚至不知道攻击者正在访问他或她的会话，攻击者并不需要提供用户名和密码。

Countermeasures for Session Hijacking

• One popular way of solving session hijacking is by resetting sessions. With authentication systems, this means a successful login must render an old session id invalid and create a new one. With this in place, on the next request, the victim will be required to authenticate. At this point, the altered session id will change, and the attacker will not be able to have access. Most websites implement this technique by making sure users authenticate when entering any potentially sensitive area, such as charging a credit card or deleting the account.

针对会话劫持的反击手段

一个流行的解决会话劫持的方案是重置会话。通过认证系统，这意味着，一次成功的登录必须使旧会话ID无效，并创建一个新的ID。当时能这个技术之后，另外一个新的请求，受害者会被要求重新认证。（译者：因为黑客访问过一次，已经让用户的上一个会话id无效了，并生成了一个新的id，保存在黑客的客户端中）这样，被修改的会话ID 会改变，这个时候攻击者就没办法访问了。绝大多数网站使用了这个技术，当用户访问某些敏感的数据的时候，让用户去做身份识别来确定身份，比如为信用卡充值，或者删除账号。

• Another useful solution is by setting an expiration time on sessions. Sessions that do not expire give an attacker an infinite amount of time to pose as the real user. Expiring sessions after, say 30 minutes, gives the attacker a far narrower window to access the app.
• Finally, as we have already covered, another approach is to use HTTPS across the entire app to minimize the chance that an attacker can get to the session id.

• 另一个有用的解决方案是在会话中设置一个超时时间。不超时的会话让攻击者无限的时间伪装成一个真实的用户。让会话在30分钟之后无效，让攻击者有一个窄的多的时间来访问APP。
• 最后，像上面我们已经介绍过的，另外一个方法是在整个APP 中使用HTTPS协议，减少攻击者拿到会话ID的机会。（译者：注意，这里只是减少，实际攻击场景中还有无数种方法来搞你，比如网站挂马）

Cross-Site Scripting (XSS)

The final security concern we'll talk about, and a very important one for all web developers, is called Cross-site scripting, or XSS. This type of attack happens when you allow users to input HTML or JavaScript that ends up being displayed by the site directly.

For example, the form below allows you to add comments, which will then be displayed on the site.

跨站脚本：

我们谈到的最后一个安全的担忧，针对所有web开发者来说很重要的，叫做跨站点的脚本执行，或者XSS.这种攻击会发生，当你允许用户把HTML 或者 Javascript 脚本在你的网站上直接展示。

比如说下图，表格本来的作用是让你添加评论，然后这个评论会被展示到站点上。

Because it's just a normal HTML <textarea>, users are free to input anything into the form. This means users can add raw HTML and JavaScript into the text area and submit it to the server as well:

因为这仅仅是一个普通的HTML 文本区域，用户可以随意的放任何东西到表格中。这意味着用户可以在文档页面添加裸的HTML 以及 Javascript，并提交到服务端。

If the server side code doesn't do any sanitization of input, the user input will be injected into the page contents, and the browser will interpret the HTML and JavaScript and execute it. In this case an alert message will pop up, which is definitely not the desired outcome. Attackers can craft ingeniously malicious HTML and JavaScript and be very destructive to both the server as well as future visitors of this page. For example, an attacker can use JavaScript to grab the session id of every future visitor of this site and then come back and assume their identity. It could happen silently without the victims ever knowing about it. Note that the malicious code would bypass the same-origin policy because the code lives on the site.

如何服务端不对代码做任何消毒，用户的输入会被插入到页面的内容中，而浏览器会解析HTML和javascript 并执行他。在上面的截图的场景，一个告警信息会弹出来，这当然不是一个被希望输出的正常结果。

攻击者们可以巧妙地制作恶意的HTML以及javascript， 这对于服务端以及未来访问这个页面的客户端都有很大的伤害（译者：在正常网站评论区，发一些js脚本挂马，之前很多坏人都干过）比如说，攻击者可以使用javascript来收集未来每个访问这个页面用户的会话id，并返回这个页面并假冒他们的身份。这个可以很安静的发生，甚至受害者都不知道这个情况。需要知道的是，恶意的代码可以跳过同源政策，因为这些恶意代码就存在源站上。

Potential solutions for cross-site scripting

• One way to prevent this kind of attack is by making sure to always sanitize user input. Eliminate problematic input, such as <script> tags, or disallowing HTML and JavaScript input altogether in favor of a safer format, like Markdown.
• The second way to guard against XSS is to escape all user input data when displaying it. If you do need to allow users to input HTML and JavaScript, then when you print it out, make sure to escape it so that the browser does not interpret it as code.

针对跨站脚本攻击的潜在解决方案

一种避免这种攻击的方法是不断地对用户输入进行“消毒”。删除一些有问题的输入，比如<script> 标签，或者把HTML 以及 Javascript 一起禁用，并使用一些健康的格式，比如markdown格式。

第二种防卫XSS攻击的方案是，当展示数据的时候，删除所有的用户输入。当你需要允许用户来输入HTML 和 Javascript，当你把用户的输入展示出来的时候，记得一定把他做转义，这样浏览器不会把他认为是代码。

Escaping

We mention the term "escaping" above. To escape a character means to replace an HTML character with a combination of ASCII characters, which tells the client to display that character as is, and to not process it; this helps prevent malicious code from running on a page. These combinations of ASCII characters are called HTML entities.

Consider the following HTML: <p>Hello World!<\p>. Let's say we don't want the browser to read this as HTML. To accomplish this, we can escape special characters that the browser uses detect when HTML starts and ends, namely < and >, with HTML entities. If we write the following: <p>Hello World!<\p>, then that HTML will be displayed as plain text instead.

转义：

我们上面提到的转义。对一个字符转义的意思是，用ASCII 字符的组合来替代HTML 字符，让客户端只展示这个字符本身，而不是去执行他。这可以避免让一些恶意的代码在页面上运行。这种ASCII字符的组合叫做HTML 实体。

考虑下面的HTML：<p> Hello World <\p> 。 如果我们不希望浏览器来读这个HTML，为了这样做，我们可以把特殊字符做转移，在这里是HTML 的开始和结束的特殊字符，也就是< 和 >字符，通过HTML 实体，如果我们写如下的信息：<p>Hello World!<\p>。 那这个HTML 会被作为纯文本做展示。

Summary

In this section, we covered various aspects of security in web applications. Needless to say, this is a huge topic, and we've only scratched the surface of a few common issues. The point of this chapter is to reveal how fragile and problematic developing and securing a web application is, and it's mostly due to working with HTTP.、

总结

在这个章节，我们包含了各种web 应用中各种安全相关的内容。必须说这个话题很大，我们只触及了几个常见问题的表面。本章节的目的是解释开发一个安全的web 应用有多么的脆弱以及有多么大的问题，这最大的原因就是用HTTP作为底层。

、受控组件

• 在 React 中，可变状态（mutable state）通常保存在组件的 state 属性中，并且只能通过使用 setState()来更新。
• state：唯一数据源
• 渲染表单的 React 组件还控制着用户输入过程中表单发生的操作。被 React 以这种方式控制取值的表单输入元素就叫做“受控组件”。
• 示例：

2、Textarea标签

3、Select标签

4、文件 input 标签

• 因为它的 value 只读，所以它是 React 中的一个非受控组件

5、处理多个输入

• 当需要处理多个 input 元素时，我们可以给每个元素添加 name 属性，并让处理函数根据 event.target.name 的值选择要执行的操作。
• 示例：

• 使用了 ES6 计算属性名称的语法更新给定输入名称对应的 state 值

6、受控输入空值

• 在受控组件上指定 value 的 prop 会阻止用户更改输入。如果你指定了 value，但输入仍可编辑，则可能是你意外地将value 设置为 undefined 或 null。
• 示例：

7、受控组件的替代品

• 使用非受控组件, 这是实现输入表单的另一种方式。

8、成熟的解决方案

• 包含验证、追踪访问字段以及处理表单提交的完整解决方案，使用 Formik 是不错的选择

关联文章：

• React笔记——核心概念：1.Hello World

• React笔记——核心概念：2.JSX简介

• React笔记——核心概念：3.元素渲染

• React笔记——核心概念：4.组件&Props

• React笔记——核心概念：5.State&生命周期

• React笔记——核心概念：6.事件处理

• React笔记——核心概念：7.条件渲染

• React笔记——核心概念：8.列表&Key