WHAT
專案中必須對應的隱性需求-安全漏洞修復
WHY
小時候下圍棋，總樂於持白子。因為我的打法是“從那裡來我哪裡堵”，在防守中尋找對方的漏洞。這種作戰方法是有底層的思想根因的：就是懶惰。不願意去主動思考佈局。
在這一思想的引導下，我目前正面臨著過去十多年積累起來的困境。記得大學之前，面對一個認識的人，我心裡是有預期的。我大體知道這個人在想什麼。慢慢的，除了我周圍的親人，其他人站在我面前我大腦一片空白。曾經以為這是因為我面對的環境更加複雜了。後來細想這不是本因，本因是我正一點點的失去獲得常識的能力。
小時候很愛大自己十歲的親哥哥，他不喜歡我，視我為資源掠奪者。我想當時是遇到過一些事情，但不至於是什麼忍受不了的大事。我卻選擇了逃避，在上大學時消除了自己的部分記憶。怕壓力，第一份工作在一個二線城市世外桃源一樣的大園子裡上班。後來想換地方，找了現在的老公先給我鋪路。因為畢業比同齡人略早些，所以在沒有結婚壓力的時候就結婚了，沒有生子壓力的時候就生娃了。仗著運氣好嫁對了人，萬事不操心，過著白痴一樣的生活。不知己之痛，更不知別人之痛。所以常識漸失。
電視劇《黃真伊》裡面一句話：藝術最重要的是痛苦。後來想痛苦大概是最重要一種能力。在設定專案計劃的時候，最重要的要解決痛點。很多人的成功都來源於夢想和渴望。而夢想和渴望就是求而未得之痛。下棋時更願意花心思去佈局的人必然是對成功渴望更大的人。棋未下，我已經輸了。
安全問題或許是一多半產品人員在提需求的時候都不會特意強調的東西，卻是對技術人員來說必須要考慮的常識。XXX被DDos攻擊，系統癱瘓。XXX資料洩露導致股價大跌，公司被起訴。最近風口浪尖上的臉書照片事件就是血淋漓的例子。一旦遇上，捲鋪蓋走人算是輕的了。如果技術人員不慎重對待，結果必然會如現在的我一樣，陷入作繭自縛的困境。
HOW
今天將一些產品或者上上下下都會考慮的顯性安全需求（如合規需求）排除在外，總結下開發人員必備的安全設計。在我看來，這個如限流、降級一樣，屬於系統的穩定性範疇，當然很多人將其獨立出來作為安全性範疇也是非常合理的。
這類設計總結來說是用來解決兩類問題。一個是自己不作死，另一個是不被別人搞死。
一.不作死
1.1 准入校驗
1.1.1 文字准入
1.1.2 操作合理性准入
1.2 資料處理
1.2.1 輸入轉義
1.2.2 輸出轉義
1.2.3 敏感資訊加密
1.3 許可權控制
1.3.1 杜絕批量操作
1.3.2 限制暴露範圍
二.不被搞死
2.1 應對程式碼注入
2.1.1 XSS攻擊
2.1.2 CSRF攻擊
2.1.3 mysql注入攻擊
2.2 漏洞補丁升級
2.2.1 弱口令漏洞
2.2.2 開原始碼漏洞
2.2.3 檔案上傳漏洞
2.3 基礎安全設施
2.3.1 WAF
2.3.2 安全審計
2.3.3 風控
2.3.4 安全監控
上面的目錄我先單獨列一下，希望大家可以記住。都是平時開發中需要考慮的。下面稍詳細的介紹一下。
1.1.1 文字准入
做業務需求有個常識，對於使用者輸入的每個欄位都需要和產品經理討論一下：什麼型別、長度多少、允許的字符集範圍、格式是否合法。這麼做一方面是設計問題，包括產品設計、資料庫設計，還有一部分是安全問題：一個數值型的欄位肯定比一個粗放的文字型欄位被攻擊的可能性小，起碼不會傳到後端之後被當成指令碼被執行。
1.1.2 操作合理性准入
比如一個普通使用者不能編輯另一個使用者的個人資訊。比如i申請公司伺服器，一次申請1萬臺機器。比如流量准入，一臺機器以超快的速度頻繁訪問一個網站的資訊資訊，就可能不是真實使用者操作而是爬蟲。以上都會對系統安全性產生極大的影響。
1.2.1 輸入轉義 & 1.2.2 輸出轉義
我在專案有個原則：儘量儲存使用者的原始資訊。比如使用者輸入一個頁面指令碼編寫方法的文章，在資料庫中儲存的時候，儘量只轉義sql關鍵字（apache 裡有現成的轉義方法）而不轉義html和js指令碼。html和指令碼在顯示再做轉義。
1.2.3 敏感資訊加密
最基本的使用者密碼必須密文儲存，並且不能明文出現在日誌中。 其他資訊如手機號、銀行卡號等不能全文顯示。一般的表示方法是XXX***XXXX。
1.3.1 杜絕批量操作
常規程式碼裡的操作都必須是點對點的。批量操作，查詢可以，只要能保證儲存壓力夠。要是批量的執行XXX，應用場景有：比如臨時的一次性操作。如果是常規操作，那就必須走審批，而且一次操作必須有個數限制，保證出了問題影響範圍也可控。
1.3.2 限制暴露範圍
開發一整套系統內部各個模組通常有內網域名、外網域名或者dubbo這種服務註冊發現機制。這種區分出了傳輸效率、成本、資源等考慮之外，還有一個很重要的因素就是安全。一個外網服務肯定要比一個內網服務更可能遭到攻擊。
2.1.1 XSS攻擊
XSS(Cross Site Scripting)攻擊全稱跨站指令碼攻擊，是為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆。它是一種在web應用中的電腦保安漏洞，它允許惡意web使用者將程式碼植入到提供給其他使用者使用的頁面中。
危害包括：
1>盜取各類使用者賬號，如機器登陸賬號、使用者網銀賬號、各類管理員賬號
2>控制企業資料，包括讀取、篡改、新增、刪除企業敏感資料的能力。
3>盜竊企業重要的具有商業價值的資料
4>非法轉賬
5>強制傳送電子郵件
6>網站掛麼
7>控制受害者機器想其他網站發起攻擊
2.1.2 CSRF攻擊
CSRF(Cross-site request forgery)，中文名稱：跨站請求偽造。也被稱為：one click attack/session riding。區別於XSS的利用站點內的信任使用者，它通過偽裝成受信任使用者的請求來達到目的。
常見特性：
1>依靠使用者標識危害網站
2>利用網站對使用者標識的信任
3>欺騙使用者的瀏覽器傳送http請求給目標站點
2.1.3 mysql注入攻擊
概念很好理解不多說。介紹一下種類：
1>GET注入：輸入引數通過URL傳送
2>POST注入：輸出引數通過HTTP正文傳送
3>COOKIE注入：輸入引數通過HTTP COOKIE傳送
3>HTTP Headers注入：通過HTTP提交應用程式使用的頭髮送
2.2.1 弱口令漏洞
弱口令(weak password)沒有嚴格和準確的定義，通過人為容易被別人猜測到或被破解工具破解的口令。主要類別有：
1>空口令或系統預設的口令
2>口令長度小於8個字元
3>口令為連續的某個字元或重複的某些字元
4>口令應該為以下四類字元的組合，大寫字母、小寫字母、數字和特殊字元。沒類字元至少包含一個。如果某類字元只包含一個，那麼該字元不應為首字元或尾字元。
5>口令不應漢堡本人、父母、子女和配偶的姓名和出生日期、紀念日期、登陸名、email等與本人有關的資訊，以及字典中的單詞。
6>口令不應該為用資料或符號代替某些字母的單詞
7>至少90天內更換一次口令，防止未被發現的入侵者繼續使用該口令。
記得很久之前在日本出差的時候，當地人都下班了，我們需要登入系統檢視東西。但是隻有當地人有密碼，還好有我。我在當時別人輸出密碼時記住了，省了大事兒。
2.2.2 開原始碼漏洞
舉幾個例子：
1>Jackson反序列化遠端程式碼執行漏洞
北京時間2017年4月15日，jackson框架被發現存在一個反序列化程式碼執行漏洞。該漏洞存在於Jackson框架下的enableDefaultTyping方法。攻擊者可以遠端在伺服器主機上越權執行任意程式碼，從而取得該網站伺服器的控制權。
2>Jboss遠端程式碼執行漏洞
Java應用裡都有特定的介面用於傳遞序列化物件資料，而在反序列化時沒有限制例項化物件的型別，導致可以任意構造用用中已經包含的物件利用反序列化操作進行例項化。
2.2.3 檔案上傳漏洞
這個獲得伺服器許可權的直接性就不多說了。說說工作中一般的預防措施吧。
1>客戶端校驗：規定上傳檔案的字尾
2>服務端校驗：主要是檔案頭校驗，如content-type等
2.3.1 WAF
Web應用防護系統(Web Applicatio Firewall)是通過執行一系列針對http/https的安全策略來專門為web應用提供保護的一款產品。主要特點是：
1>異常檢測協議
對http的請求進行異常檢測，拒絕不合符http標準的請求。也可以只允許http協議的部分選項通過，從而減少攻擊的影響範圍。
2>增強的輸入驗證
3>及時補丁
4>基於規則的保護和基於異常的保護
5>狀態管理
2.3.2 安全審計
是由專業審計人員根據有關的法律法規、財產所有者的委託和管理當局的授權，對計算機網路環境下的有關活動或行為進行系統的、獨立的檢查驗證，並做出相應評價。
靜兒接觸多的是金融方面的，太多合規操作：包括伺服器獨立部署、牌照、一清二清，做金融業務開發對比如8583報文、銀行釋出的各類檔案都要仔細研讀。
2.3.3 風控
風險控制的四種基本方法：風險迴避、損失控制、風險轉移和風險保留。金融的核心就是風控。
2.3.4 安全監控
安全監控通過實時監控網路或主機活動、監視分析使用者和系統的行為，審計系統配置和漏洞，評估敏感系統和資料的完整性，識別攻擊行為，對異常行為進行統計和跟蹤，識別違反安全法規的行為，使用誘騙伺服器記錄黑客行為等功能，使管理員有效的監視、控制和評估網路或主機系統。
總結
安全無小事，保持敬畏之心。
網際網路這個行業其實不怎麼缺學東西快的，缺有想法的。但是很多有想法的人需要經歷多次失敗才會成功。這些失敗就是碰上了安全等需要但是沒有考慮的釘子才成為成功之母的。