摘要：登錄注冊安全風(fēng)險(xiǎn)登錄注冊的風(fēng)險(xiǎn)點(diǎn)主要有四個(gè)暴力破解撞庫遍歷注冊用戶批量注冊。引入了驗(yàn)證碼機(jī)制同樣引入了額外的安全風(fēng)險(xiǎn)，比如短信驗(yàn)證碼的短信炸彈風(fēng)險(xiǎn)圖形驗(yàn)證碼的可繞過可識(shí)別等。

很多技術(shù)研發(fā)不了解安全，也不重視安全，只有在自己的服務(wù)器被黑掉、被掛馬、被脫褲才想起關(guān)注安全，但是這個(gè)時(shí)候，技術(shù)架構(gòu)已經(jīng)成型、代碼已經(jīng)在線上穩(wěn)定運(yùn)行，再亡羊補(bǔ)牢，改代碼、改策略，往往成本巨大、確收效很低。所以，開發(fā)安全，從娃娃抓起。。。
什么是信息安全？信息安全是一個(gè)龐大的概念，包含大量不同方向的分支技術(shù)，但是都涉及幾個(gè)概念：

機(jī)密性（Confidentiality），即保證信息在產(chǎn)生、傳輸、存儲(chǔ)、使用等環(huán)節(jié)不會(huì)被泄漏、被惡意竊取。在技術(shù)上典型的實(shí)現(xiàn)方式就是加密算法。加密算法主要分對(duì)稱加密和非對(duì)稱加密，對(duì)稱加密的加解密密鑰是一樣的，所以在密鑰在存儲(chǔ)、傳輸時(shí)會(huì)有一定泄漏的風(fēng)險(xiǎn)，但加解密效率會(huì)相對(duì)高一些。非對(duì)稱加密的密鑰不同，各自不會(huì)互相影響，所以相對(duì)安全，但同樣的，效率會(huì)低一些。因此，也隨之產(chǎn)生多種可變的方案，比如，使用對(duì)稱加密算法，密鑰通過非對(duì)稱加密算法進(jìn)行加密，可以在效率和安全性上取得一定的平衡。加解密是一門很深的學(xué)科，也是信息安全領(lǐng)域一個(gè)方向。

完整性（Integrity），即保證信息在產(chǎn)生、傳輸、存儲(chǔ)、使用等環(huán)節(jié)是真實(shí)完整的，不會(huì)被惡意篡改。在技術(shù)上典型的應(yīng)用有數(shù)字簽名、MD5、校驗(yàn)和等。其實(shí)在網(wǎng)絡(luò)協(xié)議誕生的初期就已經(jīng)存在完整性校驗(yàn)的概念，最典型的就是TCP/IP協(xié)議中各種報(bào)文的校驗(yàn)和。而現(xiàn)在互聯(lián)網(wǎng)產(chǎn)品，尤其是移動(dòng)端APP產(chǎn)品很多也都采用簽名的策略，通過將接口傳參、時(shí)間戳等進(jìn)行一次簽名，來防止業(yè)務(wù)數(shù)據(jù)在傳輸?shù)倪^程中被篡改。

可用性（Availability）即保證信息在產(chǎn)生、傳輸、存儲(chǔ)、使用等環(huán)節(jié)不會(huì)被破壞損毀。在技術(shù)上典型的應(yīng)用，安全方面當(dāng)然就是防DDoS了，DDoS攻擊成本低，效果好，無論大小企業(yè)，現(xiàn)在儼然已成為難題之一。DDoS又分很多種，防護(hù)起來十分復(fù)雜。

以上是信息安全的基本屬性，即CIA屬性。此外，后期還衍生出其他的屬性，如可控性、不可否認(rèn)性等，總之都是對(duì)信息安全概念的補(bǔ)充。
而安全人員的工作，尤其是做企業(yè)安全建設(shè)的工作，就是圍繞保護(hù)數(shù)據(jù)安全的過程，在事前、事中、事后三個(gè)階段，技術(shù)上建立掃描、發(fā)現(xiàn)、監(jiān)控、防御、應(yīng)急、加固等一系列措施，在管理上完善流程、制度、規(guī)范，從而使以上幾個(gè)安全屬性得到保障。
概念說了很多，落地到實(shí)際是什么樣子呢，簡單總結(jié)了一個(gè)安全架構(gòu)圖，比較全的涵蓋了企業(yè)安全建設(shè)的要點(diǎn)。

以上是宏觀層面，那具體到每個(gè)技術(shù)研發(fā)同學(xué)的身上，最常見的就是對(duì)各種安全漏洞、安全風(fēng)險(xiǎn)的處理修復(fù)。下面介紹開發(fā)過程中常見的安全風(fēng)險(xiǎn)點(diǎn)。

sql注入危害很大，也很常見，可以導(dǎo)致企業(yè)數(shù)據(jù)直接被泄漏出去。典型的sql注入漏洞是這樣產(chǎn)生的：

void doPost（HttpServletRequest request, HttpServletResponse response）{
     JdbcConnection conn = new JdbcConnection();
     final String sql = "select * from product where pname like "%” +      request.getParameter("name") + "%"";
     conn.execqueryResultSet(sql);
｝

在sql中直接拼接了字符串，導(dǎo)致用戶可以通過插入惡意代碼來控制sql執(zhí)行。比如這樣：

select * from product where pname like ‘%name%’;

qudian’;drop database;//
就變成了

那么怎么防御sql注入呢？最簡單正確的方式就是預(yù)編譯。為什么用預(yù)編譯，首先要了解sql注入的原理：sql注入產(chǎn)生在數(shù)據(jù)庫的編譯階段，拼接字符串時(shí)，sql和用戶可控的數(shù)據(jù)部分拼接到一起，一次發(fā)送到數(shù)據(jù)庫，數(shù)據(jù)庫編譯時(shí)就會(huì)把sql指令和數(shù)據(jù)編譯到一起，如果用戶可控的數(shù)據(jù)部分有非法的命令，也會(huì)被數(shù)據(jù)庫編譯執(zhí)行，這樣就產(chǎn)生了sql注入。而預(yù)編譯的方式，sql和用戶可控的部分是分兩次發(fā)給數(shù)據(jù)庫的，第一次發(fā)sql指令，也就是上個(gè)例子的select * from product where pname like ‘%name%’;，數(shù)據(jù)庫收到后先進(jìn)行編譯，第二次再發(fā)送數(shù)據(jù)qudian’;drop database;//，此時(shí)數(shù)據(jù)庫不會(huì)重新編譯第一次收到的指令，而是把指令和數(shù)據(jù)區(qū)分開，這樣不論用戶輸入的是什么非法數(shù)據(jù)，數(shù)據(jù)庫都會(huì)認(rèn)為是數(shù)據(jù)部分，也就不會(huì)產(chǎn)生sql注入了。上面的過程通過抓包可以看到。

預(yù)編譯的簡單寫法：

正常查詢 conn = createConnection(); String sql = “select name,password from manager where name=? and password=?"; stat = conn.prepareStatement(sql); stat.setString(1, name); stat.setString(2, password); stat.executeQuery(sql); 模糊查詢 conn = createConnection(); String sql = "select * from table where url like ?"; stat = con.prepareStatement(sql); String data="data"; stat.setString(1, "%"+data+"%"); stat.executeQuery(sql);

很多人不重視XSS，覺得XSS沒有大危害，“只是能彈個(gè)窗有什么用？”但實(shí)際XSS的危害甚至不弱于遠(yuǎn)程代碼執(zhí)行等。平時(shí)常見的XSS的危害場景：

盜取cookie

讀取用戶隱私

蠕蟲

DDoS

釣魚

鍵盤記錄

執(zhí)行代碼

等等

XSS是怎么插的？舉個(gè)簡單的例子。
通常正常的表單是這樣的：

`` www.qufenqi.com/1.html?name=abc

但是現(xiàn)實(shí)總是和理想有差距。黑客通常會(huì)這樣填充表單：

www.qufenqi.com/1.html?name=abc”/>//

這樣就造成了XSS，可以彈出一個(gè)窗口。
這種現(xiàn)象是產(chǎn)生的原因是由于服務(wù)端對(duì)用戶的輸入沒有做任何處理，因此在瀏覽器渲染時(shí)，用戶輸入的js代碼就會(huì)執(zhí)行。既然知道了原因，就不難修復(fù)，只要讓瀏覽器渲染時(shí)js代碼不會(huì)執(zhí)行就可以了。最完美的解決XSS的方案：

html標(biāo)簽之間：html實(shí)體編碼；

html屬性里：html屬性編碼HH; （以開頭，HH則是指該字符對(duì)應(yīng)的十六進(jìn)制數(shù)字，分號(hào)作為結(jié)束符）；

javascript里：javascrpt編碼xHH （以 x 開頭，HH則是指該字符對(duì)應(yīng)的十六進(jìn)制數(shù)字）；

css樣式里：css編碼HH （以 開頭，HH則是指該字符對(duì)應(yīng)的十六進(jìn)制數(shù)字）；

url里：url編碼%HH（以 % 開頭，HH則是指該字符對(duì)應(yīng)的十六進(jìn)制數(shù)字）；

Json里：response.setContentType(“appliaction/json”);

富文本里：過濾。

由于富文本中有需要用戶提交一些html、js、css標(biāo)簽，因此不能直接處理，建議除可能必需保留的標(biāo)簽外，過濾其他危險(xiǎn)標(biāo)簽。

dynsrc、src、action、href、background、bgsound、lowers、value、onmouse*

applet、blink、frameset、iframe、object、base、body、head、layer、style、basefont、embed、html、link、title、bgdound、frame、player、meta、script

vbscript、ms-its、firefoxurl、javascript、shtml、mocha、data、livescript

解決XSS通常有兩種誤區(qū)：
第一個(gè)，喜歡用過濾的方式。但是過濾不能完全避免XSS，通過轉(zhuǎn)義等很多方式可以繞過過濾的方法。比如這是正常的XSS語句，可以通過過濾關(guān)鍵字來解決。

 ``` 但是我把它變換一種形式，依然能夠達(dá)到效果，比如這樣：  

`
第二個(gè)，不論XSS輸出在哪，都用一種方式轉(zhuǎn)義。有時(shí)候開發(fā)會(huì)寫一個(gè)全局的轉(zhuǎn)義方法，之后不論什么時(shí)候在哪出現(xiàn)XSS，都調(diào)用這個(gè)方法，雖然暫時(shí)可行，但時(shí)間長了容易引入dom xss，不是一個(gè)完美的方案。

首先一個(gè)圖簡單明了的展現(xiàn)了CSRF的過程

簡單的說就是在用戶的某個(gè)網(wǎng)站cookie有效時(shí)，誘使用戶去請(qǐng)求黑客構(gòu)造好的惡意請(qǐng)求，就能在神不知鬼不覺的情況下進(jìn)行攻擊。一個(gè)發(fā)生過的經(jīng)典例子，某網(wǎng)站后臺(tái)管理員更改密碼的功能，沒有校驗(yàn)?zāi)壳笆褂玫拿艽a，可以直接設(shè)置新的管理員密碼。操作請(qǐng)求的參數(shù)只有一個(gè)新的密碼，所以構(gòu)造鏈接http://xxx.com/updatepass?new...，誘使管理員去請(qǐng)求，就可以默默的改變管理員密碼。
下一個(gè)問題就是如何誘使受害者去主動(dòng)請(qǐng)求惡意的鏈接，方式多種多樣，比如在自己的網(wǎng)站上插入這個(gè)鏈接，讓用戶訪問你的網(wǎng)站；在論壇里插入外鏈圖片，圖片鏈接是惡意的鏈接，這些都可以。除此之外，CSRF結(jié)合其他漏洞更能達(dá)到驚喜的效果，前幾年知名的新浪微博蠕蟲刷粉絲，可以短時(shí)間增長大量的粉絲，就是CSRF和XSS在一起的功效。
那么防御CSRF的方案呼之欲出，目前主流的兩種方案：1.讓黑客不能偽造惡意的請(qǐng)求;2.校驗(yàn)來源的請(qǐng)求是不是用戶正常觸發(fā)的。第一點(diǎn)，通常使用token校驗(yàn)。第一步，用戶登錄時(shí)，服務(wù)端生成token，保存在session中。第二步，token可以放在表單中或者h(yuǎn)ttp請(qǐng)求頭中。 第三步，客戶端帶著token發(fā)請(qǐng)求給服務(wù)端，服務(wù)端校驗(yàn)token。這樣通過客戶端和session中的token比較，就可以得知請(qǐng)求是否合法。由于token是隨機(jī)字符串，黑客無法獲取，也就無法構(gòu)造請(qǐng)求了。第二點(diǎn)，校驗(yàn)referer，這是一個(gè)比較簡單的實(shí)現(xiàn)方式，通過校驗(yàn)referer白名單也可以起到防御CSRF攻擊的作用。但是這里有個(gè)坑，很多開發(fā)寫正則來取referer，有時(shí)候就會(huì)造成各種繞過的姿勢，比如www.qufenqi.com.baidu.com這樣。因此在寫正則的時(shí)候一定要注意。

登錄注冊的風(fēng)險(xiǎn)點(diǎn)主要有四個(gè)：暴力破解、撞庫、遍歷注冊用戶、批量注冊。
首先登錄，三個(gè)必備的要素：用戶名、密碼、驗(yàn)證碼。驗(yàn)證碼是手機(jī)短信驗(yàn)證碼或者圖形驗(yàn)證碼。通過手機(jī)短信驗(yàn)證碼既可以識(shí)別用戶身份，為風(fēng)控提供基礎(chǔ)，又可以防護(hù)暴力破解、撞庫等批量的攻擊行為。圖像驗(yàn)證碼則可以人機(jī)識(shí)別，防護(hù)暴力破解、撞庫。引入了驗(yàn)證碼機(jī)制同樣引入了額外的安全風(fēng)險(xiǎn)，比如短信驗(yàn)證碼的短信炸彈風(fēng)險(xiǎn)、圖形驗(yàn)證碼的可繞過、可識(shí)別等。此外，也可以加入一些高級(jí)的安全策略，輔助分析防護(hù)安全風(fēng)險(xiǎn)，如異地登錄提醒、記錄非常用設(shè)備登錄、校驗(yàn)用戶歷史行為。
這里簡單說下校驗(yàn)用戶歷史行為。很多產(chǎn)品在設(shè)計(jì)需要校驗(yàn)身份的場景時(shí)，沒有完全的考慮各類安全風(fēng)險(xiǎn)，一個(gè)常見的例子就是通過短信驗(yàn)證碼來找回密碼，產(chǎn)品理想中的場景是短信驗(yàn)證碼只能用戶自己收到，所以可以確認(rèn)用戶身份，但實(shí)際有很多不可控的因素，比如，用戶手機(jī)丟失的情況。因此，在注冊登錄點(diǎn)需要綜合考慮各種情況。

剛才提到圖形驗(yàn)證碼，圖形驗(yàn)證碼如果設(shè)計(jì)開發(fā)的不當(dāng)就會(huì)形同虛設(shè)。一個(gè)完善的圖形驗(yàn)證碼流程是這樣的：
1.客戶端發(fā)起一個(gè)請(qǐng)求。
2.服務(wù)端響應(yīng)并創(chuàng)建一個(gè)新的SessionID同時(shí)生成一個(gè)隨機(jī)驗(yàn)證碼。
3.服務(wù)端將驗(yàn)證碼和SessionID一并返回給客戶端。
4.客戶端提交驗(yàn)證碼連同SessionID給服務(wù)端。 5.服務(wù)端驗(yàn)證驗(yàn)證碼同時(shí)銷毀當(dāng)前會(huì)話，返回給客戶端結(jié)果。

如果整個(gè)流程中的某個(gè)環(huán)節(jié)處理不當(dāng)，則會(huì)產(chǎn)生各種問題：
1.驗(yàn)證碼不過期，可重復(fù)使用。這是比例最大的驗(yàn)證碼安全風(fēng)險(xiǎn)，產(chǎn)生這種現(xiàn)象的主要原因是驗(yàn)證碼的刷新是在前端進(jìn)行，服務(wù)端的功能只有接收驗(yàn)證碼判斷對(duì)錯(cuò)，并沒有sessionid的機(jī)制，這樣只要攔截請(qǐng)求每次使用這個(gè)驗(yàn)證碼重新發(fā)包，就可以繞過驗(yàn)證碼的策略做各種攻擊嘗試。正確的做法是每次校驗(yàn)驗(yàn)證碼之后，服務(wù)端要重新生成驗(yàn)證碼。

2.驗(yàn)證碼輸出到客戶端。這種問題也很常見，很多驗(yàn)證碼的邏輯是在請(qǐng)求驗(yàn)證碼時(shí)，服務(wù)端不只返回驗(yàn)證碼圖片，還返回圖片里的內(nèi)容，這樣通過抓取返回中的驗(yàn)證碼內(nèi)容字段就可以繞過驗(yàn)證碼的人機(jī)識(shí)別過程。爭取的做法是服務(wù)端返回時(shí)，不要返回驗(yàn)證碼內(nèi)容，直接返回一張圖片即可。

3.驗(yàn)證碼前端生成，前端校驗(yàn)。這里涉及安全的一個(gè)原則：永遠(yuǎn)不要信任用戶端的輸入。所有前端的代碼都是可以被用戶修改的，因此如果在前端做驗(yàn)證碼處理，黑客則可以通過修改前端代碼自己生成，自己校驗(yàn)，完全繞過驗(yàn)證碼的邏輯。

4.驗(yàn)證碼可以被識(shí)別。這是目前驗(yàn)證碼的一個(gè)難題。現(xiàn)在圖像識(shí)別的技術(shù)非常成熟，前端的數(shù)字字符驗(yàn)證碼，即使增加了背景、干擾、粘連等措施，也可以被輕松識(shí)別。因此驗(yàn)證碼技術(shù)現(xiàn)在逐漸發(fā)展成通過用戶行為識(shí)別和找不同來做人機(jī)識(shí)別。比如滑動(dòng)驗(yàn)證碼、12306那類的驗(yàn)證碼。

很多產(chǎn)品避免不了和第三方產(chǎn)品的互相調(diào)用，但是在調(diào)用過程中如果不注意安全控制，很容易因?yàn)榈谌较到y(tǒng)的安全問題，導(dǎo)致自己的安全風(fēng)險(xiǎn)。以前遇到過一個(gè)例子，某電商網(wǎng)站擴(kuò)展二手回收業(yè)務(wù)，和某二手回收網(wǎng)站合作，會(huì)將自己的一些用戶信息傳給二手回收的系統(tǒng)，結(jié)果因?yàn)閷?duì)方的安全做的不夠完善，導(dǎo)致自己的大量用戶信息被泄漏。造成了很嚴(yán)重的影響。但是第三方的系統(tǒng)安全我們是控制不了的，因此我們只能互相調(diào)用的接口傳輸過程中加入安全策略。通常有以下幾種做法：
1.IP訪問控制（白名單）：這個(gè)是必需的，通常此類接口調(diào)用都不涉及很多的范圍，都是雙方之間的調(diào)用，需要做訪問控制來限制惡意來源的訪問掃描。

2.接口簽名：簽名也是現(xiàn)在普遍的做法，通過簽名可以確定接口傳輸?shù)男畔]有被惡意篡改。簽名的簡單邏輯是：簽名串=MD5(明文參數(shù)&密鑰)，然后將簽名串作為參數(shù)與原來的參數(shù)一起發(fā)給服務(wù)端。服務(wù)端收到明文參數(shù)后，同樣進(jìn)行一次MD5(明文參數(shù)&密鑰)，并于收到的簽名串做比較，即可校驗(yàn)是否被篡改。現(xiàn)在的簽名技術(shù)已經(jīng)相對(duì)完善。
3.敏感數(shù)據(jù)加密：敏感數(shù)據(jù)一定不要直接明文在互聯(lián)網(wǎng)傳輸，要通過加密。加密算法可以選擇對(duì)稱加密和非對(duì)很加密，加密算法可以選用對(duì)稱加密的AES或者非對(duì)稱加密的RSA，或者二者綜合使用。
簡單的介紹了線上常見的幾種安全風(fēng)險(xiǎn)，接下來說說幾點(diǎn)安全基本的原則，也是各種安全方案的思想。通過這幾個(gè)原則可以擴(kuò)展出很多成熟的安全方案。
1.不要信任用戶的輸入：從用戶端傳過來的任何數(shù)據(jù)都是不可信的無論是請(qǐng)求頭還是請(qǐng)求體，都是可以隨便更改的。因此，這里邊可能包含大量的惡意代碼。用戶傳過來的數(shù)據(jù)一定要做一些關(guān)鍵的過濾、校驗(yàn)。對(duì)參數(shù)的類型、長度等一定要有預(yù)期，不符合預(yù)期的要做處理。此外，關(guān)鍵的算法、邏輯操作和數(shù)據(jù)不要在js中處理。js是可以隨意更改的。一個(gè)典型的例子，大轉(zhuǎn)盤抽獎(jiǎng)一般是通過js實(shí)現(xiàn)，于是中獎(jiǎng)的規(guī)則也在js中一起實(shí)現(xiàn)，js判斷之后直接將中獎(jiǎng)結(jié)果通知服務(wù)端，這樣黑客就可以通過js隨意控制抽獎(jiǎng)的過程和結(jié)果了。

2.合理利用加密、簽名：加密和簽名是安全策略中不可或缺的一部分。關(guān)鍵敏感的數(shù)據(jù)和接口一定要做加密和簽名，加密和簽名算法的選擇又是一個(gè)龐大的話題，以后可以多帶帶細(xì)說。

3.關(guān)鍵操作的身份認(rèn)證：關(guān)鍵操作不做身份認(rèn)證就好像不問別人是誰就讓他進(jìn)你家門。在做身份認(rèn)證時(shí)注意的幾個(gè)要點(diǎn)：第一不要直接通過傳參數(shù)來判斷身份，比如userid，這是可以隨意更改的；第二不要通過cookie中的某個(gè)字段判斷身份，cookie中的信息也是可以隨意更改的。正確的做法是通過session來獲取用戶身份。

4.邏輯步驟：有時(shí)候有些邏輯步驟本可以一個(gè)步驟完成，卻分成兩個(gè)步驟，這種情況就有可能繞過第一個(gè)步驟直接判斷第二個(gè)。舉個(gè)簡單的例子，登錄時(shí)候輸入用戶名、密碼、短信驗(yàn)證碼，有的開發(fā)會(huì)先通過一個(gè)請(qǐng)求判斷短信驗(yàn)證碼是否正確，之后根據(jù)結(jié)果再發(fā)送請(qǐng)求。這時(shí)如果直接發(fā)送第二個(gè)請(qǐng)求就可以繞過短信驗(yàn)證碼的校驗(yàn)，產(chǎn)生安全風(fēng)險(xiǎn)。因此，無論需要檢驗(yàn)的參數(shù)數(shù)量有多少，都需要在一個(gè)步驟中做好所有的校驗(yàn)，之后再返回最終結(jié)果。

5.策略一致性：現(xiàn)在的產(chǎn)品大多有多個(gè)平臺(tái)，比如web端和app端。此時(shí)這兩個(gè)平臺(tái)的安全策略需要完全一致，才不會(huì)有疏漏。舉一個(gè)以前遇到的例子，XSS的處理，在web端做輸入過濾，在app端做輸出轉(zhuǎn)義，此時(shí)多帶帶在兩個(gè)平臺(tái)都無法XSS，但是如果在app端輸入，在web端輸出，就恰好繞過兩個(gè)平臺(tái)的安全策略，最終成功XSS。因此，多個(gè)平臺(tái)的產(chǎn)品，需要多個(gè)平臺(tái)保持一致的安全策略才行。