圖片拍攝於西安大雁塔廣場玄奘像
筆者目前做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
安全無小事，希望我們在做功能開發時把安全方面的思考也加進去，早日讓我們的系統百毒不侵。
本篇為安全整改的第一篇，后續會繼續整理輸出，敬請期待。
