圖片拍攝於西安大雁塔廣場玄奘像
筆者目前做toB的業務，對接的客戶還包括一些toG性質的公司，這類公司對安全問題的關注度日益增長，面對這種情況，我們開發人員也需要做出一些改變，以前邏輯上正確就行，現在安全上也不能出紕漏。
接下來我闡述一下近期我們遇到的一些安全問題，以及一些整改措施。
問題1：密碼明文傳輸
漏洞等級：高危
漏洞詳情：輸入賬號密碼登入後攔截請求資料，發現使用者名稱密碼以明文的方式進行傳輸。
漏洞危害：攻擊者通過嗅探、中間人攻擊等方法能夠直接獲取使用者的賬號密碼。
如果是你看到這份報告你還會繼續使用自己花錢購買的這套軟體嗎？我估計大部人是不敢用了，這麼敏感的資訊居然在網路上裸奔，太嚇人了。
怎麼辦呢？說實話我第一眼拿到這份報告的時候也是有點悶逼的，以前確實沒處理過這類問題，或者說以前在某個環節上已經規避了這類問題，仔細一想我以前接觸過的系統全是https的，https已經幫我們做了加密，所以不需要這種擔心，這裡貼一張圖幫助理解。
圖片來源於bing
解決方式其實也比較明確了，將密碼加密傳輸就好了：
1.讓客戶升級https
2.使用非對稱加密演算法RSA對密碼進行加密
至於讓客戶升級https這件事來說，推動起來確實比較費勁，toB客戶的一個特點是決策週期很長，層層彙報下來不知道時間會花多久，所以我們還是選擇了第2種方式來實現，虛擬碼如下：
前端：引入jsencrypt.js
var rsaEncryptor = new rsaEncryptor("rsa 公鑰");
var password = rsaEncryptor.encrypt($("password").val());
後臺
RsaDecryptor = new RsaDecryptor("rsa 私鑰");
String password = RsaDecryptor.decrypt(password);
感興趣的同學可以去F12一下京東和支付寶的登入請求，也是使用了RSA加密這種方式，即使已經是強制https的情況下。
問題2：使用者投訴模組存在儲存XSS漏洞
漏洞等級：高危
漏洞詳情：投訴內容填寫攻擊指令碼<script>alert(document.cookie)</script>
管理員處理投訴，彈窗，洩露cookie，竊取使用者
設想一下如果把alert(cookie)換成將cookie傳送到黑客的伺服器，那使用者的session是不是被成功竊取了，這個後果不堪設想，可見XSS漏洞的威力，如果這是一個大型論壇，估計這個事件就要上頭條了，吃瓜的可以搜尋一下搜狐當年的XSS漏洞“SOHU視訊XSS漏洞導致其使用者成為DDOS肉雞”。
回到我們的場景來說，其實是因為開發人員在展示內容的時候使用了jquery的html導致的，當然這不是刷鍋給jquery，jquery已經在Api的說明文件中做了特別說明，只能怪我們使用不當。
文件明確的說“不要使用這些方法插入從不受信任的來源獲取的字串，例如 URL 查詢引數、cookie 或表單輸入。這樣做可能會引入跨站點指令碼 (XSS) 漏洞。在向文件新增內容之前刪除或轉義任何使用者輸入。”
理論說完了，其實具體改也就很容易了：
-
限制使用者輸入，對於一些特殊標籤直接禁止輸入；
-
對輸入轉義，比如<script>變成<script>；
-
展示的時候做轉義或者不要使用jquery.html這種可以執行指令碼的方法，比如使用jquery.text；
問題3：未設定httponly屬性
漏洞等級：中危
漏洞詳情：cookie的jsessionid未設定httponly屬性，該欄位是身份認證標識，如果有XSS漏洞可能會造成session洩漏
這個和上一個XSS漏洞可謂是環環相扣，只要有一個點被攻破，那黑客就會一點一點的滲入。
修復方式很簡單就是設定cookie時增加httponly屬性，這樣document.cookie就讀取不到了，貼一段developer.mozilla.org上關於httponly的介紹：
推薦閱讀：
1.xss漏洞介紹
https://developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#cross-site_scripting_(xss)
2.美團技術團隊如何防止XSS攻擊？
https://tech.meituan.com/2018/09/27/fe-security.html
安全無小事，希望我們在做功能開發時把安全方面的思考也加進去，早日讓我們的系統百毒不侵。
本篇為安全整改的第一篇，後續會繼續整理輸出，敬請期待。
