圖檔拍攝于西安大雁塔廣場玄奘像
筆者目前做toB的業務，對接的客戶還包括一些toG性質的公司，這類公司對安全問題的關注度日益增長，面對這種情況，我們開發人員也需要做出一些改變，以前邏輯上正确就行，現在安全上也不能出纰漏。
接下來我闡述一下近期我們遇到的一些安全問題，以及一些整改措施。
問題1：密碼明文傳輸
漏洞等級：高危
漏洞詳情：輸入賬号密碼登入後攔截請求資料，發現使用者名密碼以明文的方式進行傳輸。
漏洞危害：攻擊者通過嗅探、中間人攻擊等方法能夠直接擷取使用者的賬号密碼。
如果是你看到這份報告你還會繼續使用自己花錢購買的這套軟體嗎？我估計大部人是不敢用了，這麼敏感的資訊居然在網路上裸奔，太吓人了。
怎麼辦呢？說實話我第一眼拿到這份報告的時候也是有點悶逼的，以前确實沒處理過這類問題，或者說以前在某個環節上已經規避了這類問題，仔細一想我以前接觸過的系統全是https的，https已經幫我們做了加密，是以不需要這種擔心，這裡貼一張圖幫助了解。
圖檔來源于bing
解決方式其實也比較明确了，将密碼加密傳輸就好了：
1.讓客戶更新https
2.使用非對稱加密算法RSA對密碼進行加密
至于讓客戶更新https這件事來說，推動起來确實比較費勁，toB客戶的一個特點是決策周期很長，層層彙報下來不知道時間會花多久，是以我們還是選擇了第2種方式來實作，僞代碼如下：
感興趣的同學可以去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>變成&lt;script&gt；
展示的時候做轉義或者不要使用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
安全無小事，希望我們在做功能開發時把安全方面的思考也加進去，早日讓我們的系統百毒不侵。
本篇為安全整改的第一篇，後續會繼續整理輸出，敬請期待。