<h1>事件簡述</h1>
這是一件發(fā)生在前段時(shí)間的事情，當(dāng)時(shí)的情況是這樣的：一個(gè)新的功能模塊上線之后粘驰，出現(xiàn)短信接口被惡意訪問調(diào)用的情況，請求數(shù)量很大，而且通過查看短信服務(wù)商控制臺(tái)也發(fā)現(xiàn)展东，短信發(fā)送量在飆升艺栈，看著統(tǒng)計(jì)曲線的增長捎泻，緊張的氣氛也漸漸變得更濃诬乞，很明顯，事情并不是遇到一個(gè)bug那么簡單慢叨，因?yàn)闋可娴椒?wù)費(fèi)用纽匙，需要立即解決。
當(dāng)然拍谐，接口被惡意訪問的這個(gè)問題已經(jīng)解決烛缔，因此寫了這篇文章馏段，可以做一下簡單的記錄，并且靜下心來分析一下其中的問題了践瓷，看完這個(gè)案例院喜，大家也可以一起討論討論。
<h1>問題分析</h1>
這是當(dāng)時(shí)的短信接口日志數(shù)量曲線晕翠，某一個(gè)時(shí)間點(diǎn)突然增長了起來并且沒有降下去的意思喷舀，通過日志分析發(fā)現(xiàn)，攻擊者用的不同IP淋肾、不同號(hào)碼進(jìn)行惡意調(diào)用硫麻，請求量較大，趕緊將事件做了記錄并通知了相關(guān)人員樊卓，和同事做了溝通后拿愧，大家也都提出了自己的意見：有人說趕緊修改前端功能，發(fā)一版新的APP碌尔，有人說修改后端代碼浇辜，緊急補(bǔ)救一下，也有人說要不要先關(guān)停一下服務(wù)......在網(wǎng)上技術(shù)論壇搜了一下相關(guān)問題唾戚，好像碰到這種事情的也不少柳洋，基本思路都是加驗(yàn)證碼，做好安全驗(yàn)證叹坦，被攻擊了無可奈何之類的云云熊镣。
簡單對各個(gè)方案做了整理：
- 修改url(APP已經(jīng)上線，暫時(shí)無法修改)立由。
- 添加驗(yàn)證碼驗(yàn)證(APP已經(jīng)上線轧钓，暫時(shí)無法通過這種方式來解決)。
- 停掉短信服務(wù)(不現(xiàn)實(shí)锐膜，其他功能模塊也需要調(diào)用短信服務(wù)，不考慮實(shí)施)弛房。
- 短信服務(wù)商自帶防攻擊道盏，等一段時(shí)間，讓攻擊者自己停止攻擊(雖然短信服務(wù)商自帶防攻擊文捶，但是依然會(huì)出現(xiàn)大量的垃圾請求荷逞，而且服務(wù)商只是針對次數(shù)和時(shí)間做了限制，一段時(shí)間后依然會(huì)發(fā)送短信粹排，因此种远，危害和損失還是不小的，問題依然急需處理掉顽耳，裝鴕鳥是解決不了問題的)
<h1>解決方案</h1>
在用戶交互界面攔截請求已經(jīng)不現(xiàn)實(shí)了坠敷，因?yàn)橐苿?dòng)端短時(shí)間內(nèi)是無法立刻升級的妙同，而等待攻擊停止的方案也不可取，選擇逃避和等待是解決不了問題的膝迎，因此最終的決定就是修改后端接口邏輯和代碼粥帚。找到最關(guān)鍵的問題，雖然存在網(wǎng)絡(luò)攻擊限次，但是真正需要立刻解決的是短信服務(wù)接口的調(diào)用問題芒涡，當(dāng)務(wù)之急是修改短信發(fā)送接口，盡快止損卖漫。
通過討論和簡單的分析费尽，最終是決定先修改后端邏輯緊急打一個(gè)線上補(bǔ)丁，移動(dòng)端也做同步修改羊始，等待發(fā)版依啰。
<h1>黑名單模式攔截</h1>
由于接口一直被調(diào)用，需要緊急處理店枣，減少短信服務(wù)費(fèi)用的損失速警，因此一開始的出發(fā)點(diǎn)放在了手機(jī)號(hào)碼上，針對手機(jī)號(hào)碼做驗(yàn)證鸯两，采用黑名單的模式闷旧，對于此接口中出現(xiàn)的號(hào)碼，在一定次數(shù)的請求后就立刻加入到黑名單列表中钧唐，再次請求時(shí)忙灼，如果是黑名單中的號(hào)碼，直接返回錯(cuò)誤碼钝侠，不做任何其他處理该园，也不會(huì)調(diào)用短信發(fā)送接口，這種方式可能會(huì)誤傷到真實(shí)用戶帅韧，但是情況比較特殊里初，因此就選擇了這個(gè)應(yīng)急方案，緊急修改了后端代碼忽舟，對部分代碼邏輯做了修改双妨，添加手機(jī)號(hào)碼的黑名單功能。在短信發(fā)送模塊中叮阅，對號(hào)碼進(jìn)行驗(yàn)證刁品，如果一段時(shí)間內(nèi)多次請求同一個(gè)號(hào)碼的話，將號(hào)碼存入數(shù)據(jù)庫視為黑名單中的號(hào)碼浩姥，不會(huì)發(fā)送短信挑随。
攔截了近700個(gè)手機(jī)號(hào)碼，這些號(hào)碼中應(yīng)該很多是空號(hào)吧：
<h1>請求驗(yàn)證攔截</h1>
上面的方法雖然起到了一定的作用勒叠，但是依然無法很好的解決掉問題兜挨，為什么這么說呢膏孟？因?yàn)榧词估昧撕诿麊文Ｊ剑谶M(jìn)入到黑名單列表之前暑劝，依然會(huì)發(fā)送短信骆莹，試想一下每分鐘1000次的惡意請求，即使拉黑了其中的一部分號(hào)碼担猛，還是會(huì)有一部分漏網(wǎng)之魚會(huì)被當(dāng)做正常數(shù)據(jù)幕垦，然后請求短信服務(wù)商接口發(fā)送短信，這也是一個(gè)不小的體量傅联，黑名單模式可以處理一些問題先改，但是只能起到微小的作用，還需要進(jìn)一步修改后端邏輯蒸走。
回到大家都提到的用驗(yàn)證碼做安全驗(yàn)證仇奶，前端雖然無法立即更新添加驗(yàn)證碼界面和處理邏輯，但是驗(yàn)證碼的設(shè)計(jì)就是識(shí)別正常請求和非法請求比驻，因此找到一個(gè)方法能夠識(shí)別請求是否非法即可该溯，并不一定非要添加驗(yàn)證碼功能。本模塊在設(shè)計(jì)接口之初别惦，就做了數(shù)據(jù)傳輸規(guī)定狈茉，移動(dòng)端向后端發(fā)送請求時(shí)，必須在請求頭中放入一些參數(shù)掸掸，這些參數(shù)本來是做分析用的氯庆，但是在這里起到了很大的作用，因此可以在請求對象request上做文章扰付，攻擊請求只是發(fā)送請求到url堤撵，攻擊者也只知道url并不知道請求參數(shù)設(shè)計(jì)，因此針對這點(diǎn)做驗(yàn)證羽莺，應(yīng)該可以攔截掉所有的惡意請求了实昨，甚至請求都不會(huì)到達(dá)黑名單驗(yàn)證環(huán)節(jié)就已經(jīng)被處理掉了。
再次修改后端代碼禽翼，由請求信息request對象入手屠橄，從請求對象request中提取數(shù)據(jù)做校檢，甄別是否為正常請求闰挡，如果是正常請求，數(shù)據(jù)中的參數(shù)不會(huì)為空且參數(shù)值是可控的礁哄，而惡意虛假請求中則不含有這些參數(shù)长酗，因此直接返回錯(cuò)誤碼不作處理即可，這個(gè)補(bǔ)丁打上之后桐绒，短信服務(wù)費(fèi)用的損失就不會(huì)再增加了夺脾。
非法請求不做處理之拨，甚至都已經(jīng)不需要黑名單攔截了。
當(dāng)時(shí)的短信發(fā)送量統(tǒng)計(jì)咧叭，在做了驗(yàn)證之后蚀乔，直接降了下去。
<h1>結(jié)語</h1>
不管是前端驗(yàn)證碼菲茬，或者這次采取的驗(yàn)證請求方式吉挣，都是一種驗(yàn)證方式，用來甄別是否為移動(dòng)端APP發(fā)送過來的正常請求婉弹，如果不是睬魂，就不做處理，通過日志和黑名單數(shù)據(jù)可以得出結(jié)論镀赌，短信發(fā)送的問題已經(jīng)解決氯哮。
這個(gè)事件也說明，安全驗(yàn)證不能掉以輕心商佛，也不能心存僥幸心理喉钢，一旦被心存惡意之人找到漏洞，還是挺難過的良姆。前端驗(yàn)證沒有完全考慮到肠虽，后端驗(yàn)證攔截也做的不到位，因此出現(xiàn)了這種情況歇盼，需要檢討和反思舔痕，而且處理方式也不是特別得當(dāng)，一開始的黑名單模式并沒有完全杜絕掉短信發(fā)送的問題豹缀，又去做了后面的補(bǔ)救伯复，當(dāng)時(shí)確實(shí)比較緊張，因此想到能用的方法就趕緊用在了修改上面邢笙。
為何說驚險(xiǎn)和緊張啸如，試想一下：周末剛剛在家里修整了兩天，周一的早晨氮惯，打完卡坐在工位上悠閑的喝著茶叮雳，悠悠的打開瀏覽器查看系統(tǒng)日志，忽然發(fā)現(xiàn)這個(gè)訪問量有點(diǎn)大呀妇汗，隱隱覺著不對帘不，認(rèn)真的查了一下發(fā)現(xiàn)，接口被攻擊了杨箭，而且是短信發(fā)送的接口寞焙，看著一條條的短信因?yàn)楣舳l(fā)送出去，那一條條的短信，是白花花的銀子啊捣郊，能不緊張嗎辽狈！什么感覺？吃著火鍋唱著歌呛牲，突然就被麻匪給劫了刮萌，跟葛大爺一樣，就是那種感覺娘扩。
至于說險(xiǎn)勝着茸，是因?yàn)?strong>雖然暫時(shí)解決了短信發(fā)送的問題，不會(huì)再進(jìn)一步的造成金錢的損失畜侦，卻存在另外一個(gè)問題：大量的惡意請求元扔。
首發(fā)于我的個(gè)人博客，地址在這里
