Fix sentences to make better sence in english 09.1.md [en]

en/eBook/09.1.md

@@ -2,11 +2,11 @@
 
 ## What is CSRF?
 
-CSRF and XSRF stands for "Cross-site request forgery". It's also known as "one click attack/session riding" and short term is CSRF/XSRF.
+CSRF and XSRF both stand for "Cross-site request forgery". It's also known as a "one click attack" or "session riding".
 
-So how does CSRF attack work? Basically it's when an attacker trick a trusted user into accessing a website or clicking a URL that transmit malicious requests without the user’s consent to a targeted website. Here's an simple example: using a few social engineering tricks, an attacker could use the QQ chat software to find a victim and to send a malicious link to the victim targeted for the user's bank website. If the victim logs into their online banking account and does not exit, then click on a link sent from the attacker, then the user's bank account funds could likely to be transferred to the attacker specified account.
+So how does a CSRF attack work? A CSRF attack happens when an attacker tricks a trusted user into accessing a website or clicking a URL that transmits malicious requests (without the user’s consent) to a targeted website. Here's a simple example: using a few social engineering tricks, an attacker could use the QQ chat software to find and send malicious links to victims targeted at their user's online banking website. If the victim logs into their online bank account and does not exit, then clicking on a malicious link sent from the attacker could allow the attacker to steal all of the user's bank account funds.
 
-When under a CSRF attack, the end-user with an administrator account can threaten the entire Web application.
+When under a CSRF attack, a single end-user with an administrator account can threaten the integrity of the entire web application.
 
 ## CSRF principle
 
@@ -16,52 +16,51 @@ The following diagram provides a simple overview of ​​a CSRF attack
 
 Figure 9.1 CSRF attack process.
 
-As can be seen from the figure, to complete a CSRF attack, the victim must complete these two steps:
+As can be seen from the figure, to complete a CSRF attack, the victim must complete the following two steps:
 
 -1. Log into trusted site A, and store a local Cookie.
--2. Without existing site A, access to dangerous link to site B.
+-2. Without going through existing site A, access the dangerous link to site B.
 
-See here, the reader may ask : "If I do not meet the above two conditions in any one, it will not be CSRF attacks." Yes, it is true, but you can not guarantee that the following does not happen :
+As a reader you may be asking: "If I do not meet the above two conditions, I will will not be subjected to CSRF attacks." Yes this is true, however you cannot guarantee that the following does not occur:
 
-- You can not guarantee that when you are logged in a site, the site didn't lauch any hidden tabs.
-- You can not guarantee that when you close your browser, your cookies immediately expire and your last session has ended.
-- A trusted high traffic sites doesn't have hidden vulnerabilities that could be exploited with a CSRF attack.
+- You cannot guarantee that when you are logged into a site, the site didn't launch any hidden tabs.
+- You cannot guarantee that when you close your browser, your cookies will immediately expire and your last session will have ended.
+- Trusted, high traffic websites will likely not have hidden vulnerabilities easily exploitable by CSRF based attacks.
 
-Therefore, it is difficult for a user to visit a website through a link and know that they do not carry out unknown operations for a CSRF attack.
+Thus, it can be difficult for users to visit a website through a link and know that it will not carry out unknown operations in the form of a CSRF attack.
 
-CSRF attacks work mostly because of the process of Web authentication. Although you can guarantee that a request is from a user's browser, you can not guarantee that the user approved the request.
+CSRF attacks work mostly because of the process through which users are authenticated. Although you can reasonably guarantee that a request originates from a user's browser, there is no guarantee that the user granted approval for the request.
 
-## How to prevent CSRF
+## How to prevent CSRF attacks
 
-You might be a little scared after reading the section above. But terror is a good thing. It will force you read on how to prevent vulnerabilities like this from happening to you.
+You might be a little scared after reading the section above. But fear is a good thing. It will force you educate yourself on how to prevent vulnerabilities like this from happening to you.
 
-CSRF defenses can be built on the server and client side. A CSRF defense is most effective on the server side.
+Preventative measures against CSRF attacks can be taken on both the server and client sides of a web application. However, CSRF attacks are most effectively thwarted on the server side.
 
-There are many ways of preventing CSRF attacks are the server side. Most of the defensive stem from from the following two aspects:
+There are many ways of preventing CSRF attacks are the server side. Most approaches stem from from the following two aspects:
 
-1. Maintaining proper use GET, POST and Cookie.
-2. Include a pseudo-random number with non-GET requests.
+1. Maintaining proper use of GET, POST and cookies.
+2. Including a pseudo-random number with non-GET requests.
 
-In the previous chapter on REST, we saw how most Web applications are based on GET, POST requests, and that cookies where included with the request. We generally design application as follows :
+In the previous chapter on REST, we saw how most web applications are based on GET and POST HTTP requests, and that cookies were included along with these requests. We generally design application as according to the following principles:
 
-1. GET is commonly used to view information without changing values.
+1. GET is commonly used to view information without altering any data.
 
-2. POST is used in placing orders, change the properties of a resource or perform other tasks.
+2. POST is used in placing orders, changing the properties of a resource or performing other tasks.
 
-Then I will use the Go language to illustrate how to restrict access to resources Methods:
+I'm now going to use the Go language to illustrate how to restrict access to resources methods:
 
 	mux.Get("/user/:uid", getuser)
 	mux.Post("/user/:uid", modifyuser)
 
-After this treatment, because we define the modifications can only use POST, GET method when it refused to respond to the request, so the above illustration GET method of CSRF attacks can be prevented, but it can all solve the problem yet ? Of course not, because POST also can simulate.
+Since we've stipulated that modifications can only use POST, when a GET method is issued instead of a POST, we can refuse to respond to the request. According to the figure above, attacks utilizing GET as a CSRF exploit can be prevented. Is this enough to prevent all possible CSRF attacks?  Of course not, because POSTs can also be forged.
 
-Therefore, we need to implement the second step, the way in non-GET requests to increase the random number, this probably has three ways:
+We need to implement a second step, which is (in the case of non-GET requests) to increase the length of the pseudo-random number included with the request. This usually involves steps:
 
-- For each user generates a unique cookie token, all forms contain the same pseudo-random value, this proposal was the most simple, because the attacker can not get a third party Cookie ( in theory ), so the data in the form will construct fail, but it is easy because the user's Cookie XSS vulnerability because the site had been stolen, so this program must be in the absence of circumstances that XSS security.
-- Each request to use the verification code, this program is perfect, because many enter the verification code, so the user-friendliness is poor, it is not suitable for practical use.
-- A different form contains a different pseudo- random value, we introduce in section 4.4, "How to prevent multiple form submission" is introduced in this scenario, the relevant code reuse to achieve the following :
+- For each user, generate a unique cookie token with a pseudo-random value. All forms must contain the same pseudo-random value. This proposal is the simplest one because in theory, an attacker cannot read third party cookies. Any form that an attacker may submit will fail the validation process without knowing what the random value is.
+- Different forms contain different pseudo-random values, as we've introduced in section 4.4, "How to prevent multiple form submission". We can reuse the relevant code from that section suit our needs:
 
-Generate a random number token:
+Generating a random number token:
 
 	h := md5.New()
 	io.WriteString(h, strconv.FormatInt(crutime, 10))
@@ -86,11 +85,11 @@ Authentication token:
 		// Error token does not exist
 	}
 
-So basically to achieve a secure POST, but maybe you would say if you break the token algorithm does, in accordance with the theory, but in fact crack is basically impossible, because someone has calculated brute force of the string needs about 2 the 11 th time.
+We can use the preceding code to secure our POSTs. You might be wondering, in accordance with our theory, whether there could be some way for a malicious third party to somehow figure out our secret token value? In fact, cracking it is basically impossible -successfully calculating the correct string value using brute force methods needs about 2 to the 11th time.
 
 ## Summary
 
-Cross-site request forgery, that CSRF, is a very dangerous web security threats, it is Web security circles as "sleeping giant", the level of threat which "reputation" can be seen. This section not only for cross-site request forgery itself a brief introduction, also details the reason causing this vulnerability and then put some order to prevent the attack of suggestions, hoping for the reader to write secure web applications can inspire.
+Cross-site request forgery, otherwise known as CSRF, is a very dangerous web security threat. It is known in web security circles as a "sleeping giant" security issue; as you can tell, CSRF attacks have quite the reputation. This section not only introduced cross-site request forgery itself, but factors underlying this vulnerability. It concludes with some suggestions and methods for preventing such attacks. I hope this section will have inspired you, as a reader, to write better and more secure web applications.
 
 ## Links
 - [Directory](preface.md)