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