2017年秋招季安全圈里不少人都盯上了滴滴出行安全崗的筆試。那會兒網(wǎng)約車業(yè)務(wù)正處在高速擴張期司乘安全、賬號安全、支付風(fēng)控全都在關(guān)鍵位置上所以這場筆試的題庫和市面上那種“背完OWASP TOP 10就能過”的通用安全筆試很不一樣——它更像一場“帶著業(yè)務(wù)場景做安全設(shè)計”的綜合測試。我當(dāng)年和幾個一起筆試的同學(xué)對過題大家都覺得考得偏實戰(zhàn)、偏業(yè)務(wù)很多人掛在場景分析題上。這篇文章把這套筆試的考點和題目做一次完整的復(fù)盤逐個題目講清楚考察點、答題思路、常見的失分原因給后來想沖出行領(lǐng)域安全崗的朋友做個參考。1. 筆試科目構(gòu)成2017年滴滴安全崗到底考什么1.1 整體題型分布與答題節(jié)奏先說說整張卷子的觀感。筆試時長大概兩小時題量不算少主要包括三類題型一類是選擇題考察安全基礎(chǔ)知識的覆蓋面一類是簡答題要求你把某個漏洞的原理講清楚還有一類是綜合分析題直接給一個和網(wǎng)約車相關(guān)的場景讓你寫防護方案。選擇題大致覆蓋了Web安全、密碼學(xué)基礎(chǔ)、操作系統(tǒng)安全、網(wǎng)絡(luò)協(xié)議安全這些常規(guī)方向。簡答題重點集中在Web漏洞原理與修復(fù)、Android客戶端安全、數(shù)據(jù)加密這幾個模塊。綜合分析題則基本圍繞“賬號安全”“支付安全”“反作弊防刷單”三個方向出。這里有個很重要的節(jié)奏問題選擇題千萬別戀戰(zhàn)。2017年那會兒不少同學(xué)剛考完一些大廠的筆試習(xí)慣性地在一道選擇題上糾結(jié)很久結(jié)果后面的綜合分析題來不及寫。綜合分析題分值占比往往超過40%而且答案相對開放只要思路清晰、方案完整基本都能拿不錯的分。我當(dāng)時給朋友的建議是選擇題控制在30到40分鐘內(nèi)簡答題控制在40分鐘內(nèi)剩下時間全部留給綜合分析題并且做綜合分析題時一定要先搭框架再寫細(xì)節(jié)別想到哪寫到哪。1.2 那一年出行場景的特殊考察傾向2017年滴滴的安全筆試有一個特點特別明顯安全能力必須和業(yè)務(wù)場景綁定。這個傾向在簡答題和綜合分析題里表現(xiàn)得很突出。同樣是考“越權(quán)漏洞”有些公司就考“商品訂單越權(quán)”而滴滴考的是“查看他人行程”?！靶谐獭边@個信息在出行場景里的敏感性極高不只是手機號、姓名這種個人信息還包括實時軌跡、出發(fā)地、目的地、常去的家與公司地點。這些信息一旦泄露不僅能定位到具體的人還能分析出生活習(xí)慣所以考這道題的時候不能只答“加上權(quán)限校驗”就完事還得考慮脫敏、風(fēng)控、告警等一整套機制。再比如“驗證碼安全”通用考法是問“圖形驗證碼和短信驗證碼有什么區(qū)別”滴滴則傾向于問“如果司機端登錄接口被短信轟炸怎么辦”。這背后其實是對業(yè)務(wù)敏銳度的考查司機端是高頻使用場景不能像普通用戶端那樣做太復(fù)雜的驗證流程否則會影響司機接單但司機賬號價值高又必須做足夠強的防護。合理的設(shè)計往往是在“驗證碼校驗”之外加入設(shè)備指紋、行為特征、頻控策略等多維風(fēng)控。1.3 一道開場必答題談?wù)勀銓Π踩睦斫膺@套卷子里有一個讓我印象很深的必答題問法大概是這樣“作為一個安全從業(yè)者談?wù)勀銓Τ鲂行袠I(yè)安全的理解以及安全團隊的價值在哪里?！焙芏嗳擞X得這種題是送分題隨便寫寫就行。但按照那年的判分情況來看這題反而是拉開差距的地方。只寫“安全就是防護黑客攻擊”這類空話肯定不行面題人想看的是你有沒有把安全當(dāng)成一個體系來理解。當(dāng)時我身邊一個拿到面試機會的同學(xué)他的答題思路大致是這樣的第一層是基礎(chǔ)安全包括網(wǎng)絡(luò)、主機、應(yīng)用、客戶端這些基礎(chǔ)設(shè)施的安全防護第二層是業(yè)務(wù)安全包括賬號安全、支付安全、反作弊、風(fēng)控策略第三層是數(shù)據(jù)安全與隱私保護包括敏感數(shù)據(jù)的分級分類、脫敏、權(quán)限管控最后一層是安全運營包括威脅情報、監(jiān)控告警、應(yīng)急響應(yīng)。這四層構(gòu)成一個閉環(huán)并且每一層都要結(jié)合出行場景來落地。這個答題框架很值得借鑒。它體現(xiàn)出答題者不只是一個會打漏洞的人而是能從全局視角設(shè)計安全體系的人。而2017年滴滴安全團隊恰恰處在快速擴充期需要的就是這種能搭體系、能落地的綜合性安全人才。2. Web安全與業(yè)務(wù)邏輯類真題還原2.1 SQL注入不只是“能用就注入”Web安全部分必考SQL注入這基本是當(dāng)時所有大廠安全崗的約定俗成。滴滴這年的考法不算偏但有個細(xì)節(jié)很值得注意它給了一段帶有過濾邏輯的代碼要求分析過濾是否能被繞過并說明修復(fù)方案。考察點可以拆成三層第一層是SQL注入的基礎(chǔ)原理第二層是繞過過濾的思路第三層是修復(fù)方案的完整性。先說基礎(chǔ)原理。SQL注入的本質(zhì)是程序把用戶輸入當(dāng)作SQL語句的一部分拼接執(zhí)行攻擊者可以通過閉合語句、注入子查詢等方式改變原有SQL語義。常見的注入類型包括字符型注入和數(shù)字型注入以及基于報錯、布爾盲注、時間盲注、聯(lián)合查詢的利用方式。代碼里的過濾如果沒有做“二次過濾”或者“黑名單覆蓋不全”通常都有繞過空間。比如過濾了空格可以用注釋符、Tab或URL編碼代替過濾了單引號可以嘗試寬字節(jié)注入這樣只要拼接時編碼不當(dāng)單引號就能逃逸出來。關(guān)鍵的固定寫法是無論輸入是什么都必須用預(yù)編譯語句PreparedStatement加參數(shù)化查詢來拼接這是最底層、最穩(wěn)妥的防御。不能只做黑名單過濾因為黑名單永遠(yuǎn)跟不上攻擊手法。輸出層面還要限制異常信息回顯防止基于報錯的注入被利用。這題想拿高分就一定要答出“縱深防御”預(yù)編譯是核心但前面要加WAF、輸入校驗等前置攔截后面要加權(quán)限最小化、數(shù)據(jù)庫賬號分離、日志審計來兜底。2.2 越權(quán)漏洞憑什么用別人的賬號查行程越權(quán)漏洞在出行場景里出得很自然。題目給出一個場景一個用戶訂單查詢接口前端通過接口傳入訂單ID后端直接拿著這個ID去數(shù)據(jù)庫里查并返回訂單詳情沒有校驗這個訂單是否屬于當(dāng)前登錄用戶。問存在什么漏洞可能造成什么危害如何修復(fù)。這是典型的水平越權(quán)問題——攻擊者可以通過遍歷訂單ID看到其他用戶的訂單信息。在出行行業(yè)訂單信息里包含真實姓名、手機號、上下車地點、行程軌跡數(shù)據(jù)泄露的后果比普通電商訂單嚴(yán)重得多。所以危害分析要分層寫個人隱私泄露、人身安全風(fēng)險可以實時掌握某個人的出行規(guī)律、合規(guī)風(fēng)險違反個人信息保護相關(guān)要求。修復(fù)方案也要分層。最直接的是加權(quán)限校驗查詢前判斷訂單的userId和當(dāng)前登錄用戶的userId是否一致。這是“對象級授權(quán)”的標(biāo)準(zhǔn)做法。但僅僅如此還不足以應(yīng)對復(fù)雜場景比如客服系統(tǒng)、司機端等不同的角色訪問同一個訂單數(shù)據(jù)時需要的權(quán)限邊界是不同的這就要引入基于角色的訪問控制模型來統(tǒng)一管理。從筆試角度還能加點分的是答出“對ID做不可預(yù)測化處理”——把自增ID替換成帶隨機性的業(yè)務(wù)單號降低枚舉風(fēng)險。同時接口要做風(fēng)控和審計發(fā)現(xiàn)某個用戶短時間內(nèi)大量查詢他人訂單要能自動觸發(fā)告警。2.3 支付金額篡改與“0元打車”支付安全在滴滴這類交易型平臺里是重中之重。這年的簡答題里有一道“支付金額篡改”題給了一個場景客戶端發(fā)起支付請求時把訂單金額傳給服務(wù)端服務(wù)端按客戶端傳的金額扣款攻擊者可以把金額改成0.01元甚至0元實現(xiàn)“低價打車”。這類題的套路性很強但很多沒接觸過支付系統(tǒng)的人容易踩坑只答“服務(wù)端要校驗金額”就結(jié)束了。實際上要從兩個層面理解。第一層是服務(wù)端信任邊界。任何從客戶端傳來的數(shù)據(jù)都不可信金額必須由服務(wù)端根據(jù)訂單信息計算不能以客戶端傳參為準(zhǔn)。這道題的關(guān)鍵修復(fù)點就在這服務(wù)端要做到“應(yīng)付金額以服務(wù)端訂單快照為準(zhǔn)客戶端只負(fù)責(zé)展示和發(fā)起支付”。更嚴(yán)謹(jǐn)?shù)淖龇ㄊ窍聠纬晒r服務(wù)端生成訂單快照并簽名支付時校驗簽名和金額。第二層是防重放與防篡改。即使服務(wù)端算好了金額攻擊者也可以把同一個合法請求重放多次所以要有冪等控制。當(dāng)時的答題里如果能提到“每筆訂單生成唯一的業(yè)務(wù)流水號支付回調(diào)時按流水號做冪等校驗”這題基本就是滿分水平。還有個容易被忽略的點是支付回調(diào)的安全。支付成功后第三方支付平臺會回調(diào)通知服務(wù)端這個回調(diào)必須驗簽、驗金額、驗商戶訂單號否則攻擊者可以偽造支付成功通知。把這個點答進(jìn)去能明顯體現(xiàn)你的真實業(yè)務(wù)經(jīng)驗。2.4 驗證碼與短信轟炸的攻防博弈短信轟炸題也是那年的高頻題出題角度很實際“注冊和登錄接口都接了短信驗證碼現(xiàn)在攻擊者用腳本調(diào)用接口給任意手機號發(fā)短信導(dǎo)致大量用戶被騷擾怎么防護”這道題考察的不只是驗證碼本身而是對“人機對抗”的理解?；卮饡r要區(qū)分“驗證碼防機器”和“頻控防濫用”兩個維度。驗證碼層面短信接口前面一定要掛行為驗證碼。用戶要先完成滑塊或者點選驗證證明自己是真人再觸發(fā)短信下發(fā)。這在2017年算比較成熟的方案了到今天也是標(biāo)配。頻控層面要分多個維度做限制同一手機號在單位時間內(nèi)的發(fā)送次數(shù)上限、同一IP的調(diào)用頻率限制、同一設(shè)備指紋的調(diào)用頻率限制、同一賬號的每日發(fā)送上限。這四個維度缺一不可單純限制手機號很容易被攻擊者換號繞過單純限制IP則防不住代理池。更高級的答法是把“陌生號碼”和“高頻異?！迸袛嗉舆M(jìn)去比如對未注冊的手機號做更嚴(yán)格的驗證或是在夜間等非正常時段加大頻控力度。這也是業(yè)務(wù)場景里的實際需要。3. 移動端逆向與客戶端安全真題還原3.1 APK靜態(tài)分析從反編譯到定位關(guān)鍵代碼2017年是移動互聯(lián)網(wǎng)安全崗考察Android安全的巔峰期滴滴的App天然是重點目標(biāo)所以筆試卷子里有一道APK靜態(tài)分析的題。題目會給你一個場景拿到一個APK需要分析它的某個關(guān)鍵邏輯比如簽名校驗、加密算法問用什么工具、走什么流程。常規(guī)工具鏈要寫全先是apktool解包拿到資源文件和smali代碼再用jadx或者jeb做反編譯從DEX字節(jié)碼還原出可讀性更好的Java代碼如果App用了加固可能還涉及脫殼那就要用到Frida或者Xposed來做運行時dump。定位關(guān)鍵代碼的方式也很重要。最快的方式是全局搜索字符串比如搜索“sign”“token”“secret”“signature”這些關(guān)鍵詞能迅速把分析范圍縮小到幾個關(guān)鍵類上。如果是找簽名校驗可以搜索包名、Signature類的getSignatures方法調(diào)用或者搜索PackageManager相關(guān)的API。從筆試判分的角度來看這題想拿高分的核心是“分析思路完整”拿到APK之后先看權(quán)限申請和組件暴露情況再看有沒有加殼、有沒有Native層最后才是具體的業(yè)務(wù)邏輯分析。這反映出分析者有完整的方法論而不是瞎猜。3.2 簽名校驗與重打包一道送分題和它的坑簽名校驗是移動端安全的傳統(tǒng)考點滴滴那套卷子里也出現(xiàn)在了簡答題中。題目問的是APK重打包后無法安裝或運行可能是什么原因如何分析如何繞過。核心原因就是簽名變了。APK的簽名相當(dāng)于應(yīng)用的身份證重打包后即使代碼邏輯改了簽名也和新版不一致系統(tǒng)安裝時就會校驗失敗。而很多App還會在代碼里做自校驗簽名不對直接閃退。分析方法是先把原APK和重打包APK的簽名信息都導(dǎo)出來對比一下MD5。如果App里做了自校驗就要找到校驗點看它是在Java層還是Native層做的。這道題的難點在于繞過。純Java層的簽名校驗相對好處理用Frida hook住PackageManager的getPackageInfo方法讓它返回原始簽名就行。但如果有Native層的校驗事情就變得復(fù)雜了需要動態(tài)調(diào)試Native代碼找到校驗邏輯后patch掉或者把正確的簽名信息傳給Native層校驗函數(shù)。這里筆試答題時一定要強調(diào)“重打包防護”的對抗思路而不是只講怎么繞過。一個完整的修復(fù)方案應(yīng)該是在Java層和Native層分別做簽名校驗并加反調(diào)試讓攻擊者定位校驗點的成本大幅提升。這才能體現(xiàn)你既會攻也知道怎么防。3.3 動態(tài)調(diào)試與反調(diào)試so層的攻防拉鋸動態(tài)調(diào)試那題更進(jìn)階考的是Native層的反調(diào)試對抗。場景大概是一個Android應(yīng)用把核心算法放在so文件里你在動態(tài)調(diào)試時發(fā)現(xiàn)進(jìn)程一掛上調(diào)試器就退出問為什么如何繞過。核心知識點是先答出幾種常見的反調(diào)試手段一是ptrace自跟蹤。Linux的ptrace有一個特性同一個進(jìn)程同一時刻只能被一個進(jìn)程跟蹤。App自己ptrace(PTRACE_TRACEME)調(diào)試器就無法再attach上來。這是最常見、也最經(jīng)典的反調(diào)試手段。二是檢測調(diào)試器狀態(tài)。通過讀取/proc/self/status文件里的TracerPid字段如果非零說明有進(jìn)程在跟蹤自己直接退出。此外android:debuggable標(biāo)志、Debug.isDebuggerConnected()、檢測daemons進(jìn)程里的jdwp線程都是在Java層常見的手?jǐn)?。三是對關(guān)鍵so文件做完整性校驗。用CRC或者哈希算法實時計算so文件在內(nèi)存中的哈希值和原始值比對不一致就退出。這種方式專門針對內(nèi)存patch型繞過。繞過反調(diào)試的常規(guī)思路也有幾個方向一是讓ptrace失敗比如先于App對自身做一次ptrace或者用gdb的set follow-fork-mode child這類操作躲開反調(diào)試二是hook住反調(diào)試函數(shù)直接讓檢測函數(shù)返回“正?！比莗atch關(guān)鍵跳轉(zhuǎn)指令把“檢測到調(diào)試器就退出”改成“檢測到調(diào)試器也繼續(xù)執(zhí)行”。其實這類題在筆試?yán)锟嫉牟皇悄阏娴默F(xiàn)場把so調(diào)通了而是你有沒有真正調(diào)過、知不知道常見的對抗點在哪。能答出幾種反調(diào)試原理和對應(yīng)的繞過思路就已經(jīng)是很好的答案了。4. 密碼學(xué)與安全基礎(chǔ)知識真題還原4.1 加密算法選擇題AES、RSA、哈希該怎么選密碼學(xué)這塊的選擇題考的通常不是讓你手算密鑰而是考察算法選型能力和基礎(chǔ)概念辨析。滴滴那次筆試?yán)锞陀幸坏篮芙?jīng)典的選型題給出幾個場景讓你選合適的算法。第一個場景是“登錄密碼傳輸”問用RSA加密還是用HTTPS。這道題的坑在于有些同學(xué)會認(rèn)為密碼傳輸必須用RSA加密。但正確的理解應(yīng)該是傳輸層安全優(yōu)先靠HTTPSTLS保證密碼字段本身再做一次加密屬于縱深防御如果只對密碼做RSA加密而不用HTTPS中間人依然可以替換整個請求加密強度再高也沒用。第二個場景是“用戶密碼存儲”選項里有MD5、SHA-1、加鹽哈希。正確答案是加鹽哈希最好用bcrypt、scrypt這類慢哈希算法。MD5和SHA-1都不是為密碼存儲設(shè)計的算得太快暴力破解效率太高這是2017年已經(jīng)反復(fù)被驗證過的教訓(xùn)。第三個場景是“數(shù)據(jù)完整性校驗”選項里有AES、RSA、哈希。正確思路是使用哈?；蛘咴趥鬏攬鼍袄镉肕AC消息認(rèn)證碼特別是帶密鑰的HMAC這樣才能防止攻擊者同時篡改數(shù)據(jù)和數(shù)據(jù)對應(yīng)的哈希值。4.2 密碼存儲為什么“加鹽”不是可選項簡答題里有一道關(guān)于密碼存儲的題題目直白得像送分“數(shù)據(jù)庫里用戶的密碼應(yīng)該怎么存為什么不能直接存MD5加鹽是什么意思鹽值應(yīng)該怎么處理”直接存MD5的問題在于用戶的密碼往往強度不高攻擊者拿到哈希之后可以做彩虹表查表或者直接用常見密碼字典批量跑。MD5算得太快一個GPU每秒可以算幾十億次即使不用彩虹表窮舉弱密碼也很快?！凹欲}”的意思就是在原始密碼后面拼接一段隨機字符串再做哈希。這樣即使兩個用戶密碼一樣加鹽后的哈希值也不一樣。更重要的是鹽值增大了彩虹表的構(gòu)建成本——攻擊者沒辦法提前為所有可能的“密碼鹽”組合預(yù)計算彩虹表。鹽值的設(shè)計有幾個關(guān)鍵點鹽值必須每個用戶獨立、隨機生成不能全局共用一個鹽鹽值長度要足夠長一般16字節(jié)以上鹽值本身不需要保密可以明文存儲因為它的作用是增加破解成本而不是隱藏信息。這時候用bcrypt、scrypt、PBKDF2這類慢哈希算法效果更好它們通過增加計算輪數(shù)把每次撞庫的時間成本放大到“不可接受”的量級。答題時要能把這個邏輯鏈說完整為什么不能直接存MD5因為算得快、有彩虹表加鹽解決了什么解決了同一密碼同樣哈希、彩虹表預(yù)計算為什么用慢哈希因為進(jìn)一步拖慢離線破解速度。4.3 數(shù)字簽名從網(wǎng)約車夜間出行資質(zhì)談起這套卷子里還有一道關(guān)于數(shù)字簽名的題出題角度很巧妙——它沒有讓你直接解釋“什么是數(shù)字簽名”而是結(jié)合了一個和出行服務(wù)相關(guān)的場景平臺和司機之間需要建立一種信任機制確保某些關(guān)鍵指令比如夜間出行資質(zhì)審核結(jié)果、緊急狀態(tài)下的報文確實來自平臺且未被篡改問你怎么設(shè)計。其實這就是數(shù)字簽名在真實業(yè)務(wù)里的典型應(yīng)用。用平臺的私鑰對報文內(nèi)容做簽名司機端拿到報文后用平臺公鑰驗簽。驗簽通過就能同時證明兩件事第一報文確實來自平臺身份認(rèn)證第二報文內(nèi)容沒有被中間人篡改過數(shù)據(jù)完整性。要強調(diào)私鑰只能保存在服務(wù)端公鑰分發(fā)到客戶端。如果私鑰泄露整個信任體系就崩塌了。在移動App場景里通常還會把公鑰固化到客戶端代碼里甚至放到Native層防止攻擊者直接替換公鑰做中間人攻擊。這道題想拿高分還可以結(jié)合“防重放”來答數(shù)字簽名本身能防篡改但防不了攻擊者把合法報文保存下來再次發(fā)送所以業(yè)務(wù)報文里要加入時間戳、隨機數(shù)或單調(diào)遞增的序列號服務(wù)端校驗這些信息來防止重放攻擊。5. 業(yè)務(wù)風(fēng)控與安全運營場景題5.1 刷單問題的風(fēng)控方案設(shè)計綜合分析題里最典型的一道是刷單反作弊網(wǎng)約車平臺存在司機刷單行為比如司機和乘客勾結(jié)制造虛假行程騙取平臺補貼問你怎么從安全角度設(shè)計風(fēng)控方案。這道題拼的不是單一漏洞利用能力而是方案設(shè)計能力。一個完整的反刷單體系至少要覆蓋“事前、事中、事后”三個環(huán)節(jié)。事前環(huán)節(jié)要做準(zhǔn)入風(fēng)控。新司機注冊時要做實名認(rèn)證、人臉核驗、設(shè)備指紋采集。同時要建立關(guān)系圖譜識別司機和乘客之間是否存在異常關(guān)聯(lián)——比如某個乘客長期只打同一個司機的車社交關(guān)系異常緊密這種單子的風(fēng)險就偏高。事中環(huán)節(jié)要做實時監(jiān)控。要在訂單流轉(zhuǎn)的關(guān)鍵節(jié)點埋點包括下單、接單、行程開始、行程結(jié)束、支付完成。每個節(jié)點都采集設(shè)備信息、GPS信息、操作行為、時間分布。通過特征工程提取異常指標(biāo)比如司機接單后長時間低速怠速行駛、同一批司機經(jīng)常在同一時間同一區(qū)域接單、司機端和乘客端的操作間隔異常短暫等。事后環(huán)節(jié)要做處置與舉證。確認(rèn)風(fēng)控模型命中之后不是簡單封號就完事要能提供完整的證據(jù)鏈用于人工審核和可能的申訴流程。這就要做好日志留存、軌跡回放和數(shù)據(jù)快照。這個答題框架比單純列舉某一種風(fēng)控策略要完整得多也更能體現(xiàn)出你做過反作弊或風(fēng)控相關(guān)的工作。5.2 撞庫與撞庫之后賬號安全三道防線賬號安全是出行平臺的重災(zāi)區(qū)因為用戶經(jīng)常用手機號注冊而手機號在其他平臺泄露的概率極高。筆試?yán)镉幸坏谰C合分析題給出的場景是發(fā)現(xiàn)大量賬號在短時間內(nèi)被異地登錄并且部分賬號出現(xiàn)了異常行程要求分析攻擊方式并提出解決方案。答案的核心是“撞庫”——攻擊者拿著從其他平臺泄露的賬號密碼拿到滴滴的登錄接口上批量嘗試。因為大量用戶習(xí)慣在不同平臺使用相同密碼撞庫的成功率相當(dāng)可觀。這個問題要從三道防線來設(shè)計第一道防線是登錄入口。要能識別“批量自動化登錄”的行為特征比如登錄頻率異常、IP集中但分布分散、User-Agent異常等。常用的手段包括設(shè)備指紋、行為驗證碼、IP信譽庫、頻率限制。第二道防線是風(fēng)險登錄后的二次驗證。當(dāng)賬號在異地、新設(shè)備上登錄時強制要求短信驗證碼或人臉驗證。這個策略在2017年已經(jīng)有不少應(yīng)用核心邏輯是“低頻正常用戶無感知高風(fēng)險登錄才觸發(fā)額外認(rèn)證”。第三道防線是登錄后的行為監(jiān)控。即使攻擊者突破了前兩道防線也不應(yīng)該暢通無阻。要用風(fēng)控模型監(jiān)測賬號的異常行為比如短時間內(nèi)大量叫車、連續(xù)修改支付方式、查看陌生人行程等。一旦觸發(fā)自動凍結(jié)或限制賬號部分功能。答題時如果能補充“撞庫之后的數(shù)據(jù)泄露閉環(huán)”加分很多——不僅要防撞庫還要假設(shè)撞庫已經(jīng)成功做好賬號異常后的通知、快速申訴、證據(jù)固定等措施。5.3 數(shù)據(jù)安全視角軌跡、手機號這些敏感數(shù)據(jù)怎么管數(shù)據(jù)安全題在2017年的安全崗筆試?yán)锍霈F(xiàn)頻率還不算特別高但滴滴這張卷子已經(jīng)把它放進(jìn)來了。題目很直接用戶行程數(shù)據(jù)中包含GPS軌跡、手機號、常用地址問這些數(shù)據(jù)在存儲、傳輸、使用環(huán)節(jié)分別要做哪些安全措施。存儲環(huán)節(jié)要強調(diào)分級分類與加密。GPS軌跡和手機號的敏感度不同要分開管理。手機號屬于直接個人敏感信息必須加密存儲GPS軌跡屬于高敏位置數(shù)據(jù)不僅要加密還要做權(quán)限管控只有特定角色才能解密訪問。建議用獨立的密鑰管理系統(tǒng)對不同級別數(shù)據(jù)使用不同密鑰并且定期輪換。傳輸環(huán)節(jié)要全程走加密通道內(nèi)部服務(wù)之間用mTLS雙向認(rèn)證。同時要防止日志側(cè)漏很多數(shù)據(jù)泄露不是數(shù)據(jù)庫被拖而是開發(fā)調(diào)試時把敏感字段直接打到日志里了。所以還要做日志脫敏手機號、身份證號這類字段在日志里必須打碼。使用環(huán)節(jié)要強調(diào)脫敏與審計。數(shù)據(jù)給到業(yè)務(wù)方使用之前能脫敏就脫敏比如手機號顯示前三后四不能脫敏的場景要有嚴(yán)格的審批流程和操作留痕誰在什么時間查看了哪段軌跡都要有完整審計。這是數(shù)據(jù)安全里比加密更難落地的一環(huán)。這道題要想拿高分還要點出“數(shù)據(jù)最小化”原則不該采集的不采集該刪除的定期刪除。行程軌跡在完成了安全事件溯源、客服仲裁等用途之后應(yīng)當(dāng)按生命周期策略自動清理。6. 考完復(fù)盤這種筆試題型背后的安全觀6.1 從真題倒推崗位畫像滴滴安全團隊想要什么人整套卷子做下來對“滴滴安全團隊想要什么人”這件事會越來越清晰。它要的不是只會挖洞的“漏洞獵人”而是能夠把安全能力植入業(yè)務(wù)鏈路的安全工程師。從題型占比能看出來純漏洞原理題并不是重點重點在于“業(yè)務(wù)場景安全方案”。越權(quán)漏洞不是考你“什么是水平越權(quán)”而是考你在“訂單查詢”場景里怎么防反作弊不是考你“什么叫風(fēng)控”而是考你在“司機刷單”場景里怎么設(shè)計策略。這說明團隊在選人時最看重的是候選人能不能把安全技術(shù)轉(zhuǎn)化成對業(yè)務(wù)的保護能力。Android安全題的占比高也映射出當(dāng)時客戶端安全在出行領(lǐng)域的重點地位。網(wǎng)約車的核心操作都在App上司機端、乘客端、管理端都是攻擊面所以團隊需要既懂逆向又懂業(yè)務(wù)的人而不只是會做滲透測試。6.2 針對出行場景的備考路線建議如果你現(xiàn)在準(zhǔn)備投這類出行領(lǐng)域的安全崗可以考慮把復(fù)習(xí)重點放在幾條主線上。Web安全方面SQL注入、XSS、CSRF、SSRF、越權(quán)這些常見漏洞的“原理修復(fù)”都要滾瓜爛熟尤其是越權(quán)和業(yè)務(wù)邏輯漏洞建議在本地搭個靶場實際跑一遍把漏洞從發(fā)現(xiàn)到利用再到修復(fù)的完整鏈路走通。移動端安全方面至少要能獨立完成一個APK的靜態(tài)分析和動態(tài)調(diào)試流程。熟悉apktool、jadx、Frida的常見用法知道簽名校驗、反調(diào)試、so層加固的基本原理這些都是2017年那場筆試的高頻考點也是移動安全崗的基礎(chǔ)功。業(yè)務(wù)風(fēng)控方面建議多看一些反作弊、反欺詐的案例重點理解設(shè)備指紋、關(guān)系圖譜、行為序列這些概念。不要只停留在概念層面最好能結(jié)合平時接觸的產(chǎn)品想想某個業(yè)務(wù)環(huán)節(jié)如果被攻擊攻擊面在哪里、防御點在哪里。數(shù)據(jù)安全方面要建立“生命周期”視角從數(shù)據(jù)采集、傳輸、存儲、使用到銷毀每個環(huán)節(jié)的安全措施分別是什么。這套思路在出行行業(yè)尤其受用。6.3 最后一點個人小心得我當(dāng)年給朋友復(fù)盤這套筆試題的時候說過一句話滴滴安全崗的筆試題表面考安全本質(zhì)上考的是你能不能站在業(yè)務(wù)方的角度思考問題。很多人在筆試時只想著“這道題漏洞原理我背過”卻忽略了題目給出的業(yè)務(wù)場景信息。比如越權(quán)題里特意強調(diào)了“行程信息可以定位到家庭住址”支付題里特意寫了“司機端是高頻使用場景”這些都不是廢話而是引導(dǎo)你把答案往業(yè)務(wù)方向上寫。我的建議是做這種場景題先花幾分鐘把業(yè)務(wù)角色梳理清楚誰能訪問什么數(shù)據(jù)、什么操作會觸發(fā)什么風(fēng)險、風(fēng)險發(fā)生之后用戶和平臺各自的損失是什么。把這三件事想明白了答案自然就有層次了。真正在工作里做安全也是這樣——先搞懂業(yè)務(wù)再去設(shè)計防御方案才能落到地上。