NO.12 最近跟AppScan幹上了

像我這種甲方的安全工程師檢測Web Application的安全性靠自己去做系統的滲透測試肯定是不可能的了，Web掃描器成為了我的依靠。

話說之前一直覺得免費的軟體肯定沒有付費的好嘛，那麼是不是從綠盟啊啟明星辰這種安全廠商購買的掃描器比AppScan好用呢？後來一想不對啊，AppScan也是IBM的付費軟體啊，查了一下一年的使用費也20多萬人民幣呢。只不過我用的破解版。。。

為了完成組織上交代的任務，修復掃描出來的這些漏洞，跟程序員大哥們和諧友好的磋商是不可避免的了。最近涉及到的幾個漏洞，為了去協助程序員大哥修復也好好的研究了一下AppScan的測試方式。

我接觸到的高危基本就這麼三類

1 SQL注入、盲nn注

2 XSS

3 被解密的登錄請求

第三個最容易理解了，就是登陸界面的用戶名密碼傳送給伺服器的過程中沒有任何加密。AppScan在測試的時候就是分析出哪裡是登陸頁面，哪些參數是用戶名密碼，一般就user、password這樣。然後對請求包進行抓包分析，默認AppScan填入的參數是1234.如果抓到發現就是裸的1234，那麼就會爆這個漏洞。修復方式當然最好是能做到HTTPS，但是總會因為各種各樣的原因不能做成HTTPS，於是程序員大哥選擇了前端JS腳本加密的方法。修復之後我自己拿burp抓包看是加密過的，但是再掃一遍還是會存在這個漏洞。而且查看AppScan抓到的請求包裡面還是明文。是因為AppScan只認HTTPS？還是它把前端JS腳本禁用了等於沒加密？不太懂這裡。

第二個呢 跨站腳本

這個不是AppScan測的是某程序員大哥用的某掃描器，但是讓我幫忙協助分析了一下。驗證漏洞的請求包如下：

date1=><ScriPt>alert(777)</ScriPt>&date2=2099-01-01&gglx=0&id=61234&loadnum=0&msg=61234&pageNo=1

掃描器在參數date1後面插入了腳本語句<ScriPt>alert(777)</ScriPt>，發送給了伺服器沒有收到任何阻攔。然後檢測伺服器的響應包，在包內發現了植入的危險語句，並且得到了瀏覽器的執行。說明伺服器端並沒有對危險語句進行過濾，而且會將該語句放在響應包內返回，由此得出該web存在跨站腳本漏洞。

：哥你得在伺服器端做過濾啊

：哦

第三個SQL注入、盲注

盲注放後面說先說【SQL注入】

在查詢數據的請求包里AppScan在用戶數據處插入了含有SQL命令的參數數據，然後在伺服器的響應包里發現了oracle的報錯信息。這說明AppScan所插入的命令確實被資料庫所執行了，雖然不是什麼有害信息只是一個報錯。但是伺服器理應發現用戶輸入包含有危險字元將其過濾，不應使其到達資料庫層。如果是精心設計過的注入語句，那麼將得到有害的執行。這說明該網站存在SQL注入漏洞。

：哥你得在伺服器端做過濾啊

：我們後台入庫都是用的java的PreparedStatement，這個本身就能防止參數的注入寫法。雖然能收到Oracle的報錯，但是是注入不進來的。

：哦。。。（PreparedStatement是啥...趕緊百度...）

使用PreparedStatement的好處是資料庫會對sql語句進行預編譯，下次執行相同的sql語句時，資料庫端不會再進行預編譯了，而直接用資料庫的緩衝區，提高數據訪問的效率，如果sql語句只執行一次，以後不再復用。

SQL注入 攻 擊 只 對 Statement有效， 對 PreparedStatement 是無效的；

PreparedStatement可以在傳入sql後，執行語句前，給參數賦值，避免了因普通的拼接sql字元串語句所帶來的安全問題，而且準備sql和執行sql是在兩個語句裡面完成的，也提高了語句執行的效率 比如單引號會給你加一個轉義，加個斜杠。

然後今天早晨在某網站上又掃到了兩個SQL盲注

SQL盲注和SQL注入有啥區別？SQL盲注是純手工測出來的，SQL注入不是？

那SQL注入AppScan也只是添加了危險字元引得資料庫報錯而已啊。AppScan的檢測方式上到底是什麼區分SQL注入和SQL盲注的呢。

盲注AppScan對參數修改了四次，發送了四次請求包，每個請求包都對在參數上添加的SQL語句進行了修改，多一個單引號，或者挪一下位置什麼的。然後拿他們的響應包與原始包（未經修改）的響應包做對比。然後說結果返回的包並不一樣，所以得出可能存在危險性有SQL盲注。蛋疼的是他喵的我肉眼觀察明明特么的就是都一樣啊！明明四個請求包的返回包一模一樣，琢磨了一上午也沒明白為什麼把這個漏洞標為盲注，有沒有路過的大哥能給我講個清楚。

看著HTTP包怎麼也想不明白的我拿Burp打算自己改包發送試試，然後有意思的事情來了，用戶名是x1aoh0n。我添加了x1aoh0n+轉碼後在burp里發了出去。然後有意思的事情不在返回包里，肉眼看到在網頁的文本輸入框內 出現了【x1aoh0n/+//】的字樣。。。是把單引號都轉義了啊。。。重點是你特么怎麼還給顯示出來了呢。。。然後百度如何繞過單引號轉義實現sql注入。修改語句後提交，boom，可能是成功了？【該網頁無法顯示】大概是被發現了之後，我的IP被屏蔽了吧。。。

話說現在專欄更新的速率就定位一個月一次了吧，3月份的話工作上不得不提的就是struts2 s2-045的漏洞了吧。為了這個漏洞貢獻出了我工作生涯中第一次加班：15分鐘。

遠程任意代碼執行漏洞，凶。覆蓋了目測超過10%的伺服器？凶。抓好時間差趕緊把struts2升級就行了，在升級之前接到好幾個補天白帽子提交的漏洞。大概因為漏洞類型是高危？每個獎勵的錢都還不少呢，早知道我也網上下幾個POC去找找。。。匿名領個幾百塊錢。。。

今天又出了S2-046，和S2-045危害一樣作用範圍一樣，修復過045的046面對就也是安全的。

嗯，沒啥想說的了，今天就這樣吧。

Engineer For The Win.

2017.3.21