後端開發都應該了解的資訊泄露風險
文章首發於公眾號 「會玩code」
在黑客攻擊中，資訊收集是進行攻擊的第一步，也是至關重要的一步。資訊泄露發生的途徑有很多，攻擊者可以根據介面返回資訊，分析前端程式碼，分析頁面文件資訊、甚至是開發人員或用戶在第三方網站上的資料託管，都能進行有效的資訊收集。作為開發人員，我們應該了解常見資訊泄露風險點並謹慎規避。
介面返回詳細報錯資訊
- 一些框架，如django，允許設置debug=true，在調用介面失敗時，會將程式碼堆棧資訊和一些環境資訊都列印在頁面上，方便調試；
- 業務開發時，有些同學可能習慣將err（包含程式碼調用堆棧資訊）直接返回給用戶。攻擊者通過這些資訊可以窺探程式碼邏輯，造成安全隱患。
以登錄為例子，用戶輸入帳號密碼後，後台會去資料庫中根據帳號查詢對應密碼，用資料庫中的密碼與請求攜帶的密碼對比。sql大致邏輯是select passwd from t_user where user_name = 'xxx'xxx即為我們傳入的帳號名。
如果後台是手動拼接構造的sql，就會存在sql注入漏洞。我們在用戶名位置輸入一個單引號(最後構造的sql: select passwd from t_user where user_name = '''),
sql執行報錯...MySQL server version for the right syntax to use near '''')'..., 這時介面把sql報錯資訊一路透傳返回前端，攻擊者可根據返回的報錯資訊推導得知系統存在sql注入漏洞，從而發起攻擊。
密碼明文存儲
這是個低級、但後果十分嚴重且普遍的安全問題，Google、FaceBook等大公司都曾被爆過明文存儲用戶密碼。由於明文存儲密碼導致用戶密碼泄露的事故也是屢見不鮮。
密碼應該使用哈希加密保存，這樣即使攻擊者獲取了密碼，也只是一串毫無意義的字元。當然，對於哈希密碼，攻擊者也能通過密碼字典的方式對哈希密碼進行「撞庫」破解，或構造彩虹表對密碼進行破解。
比如123456的哈希值是E10ADC3949BA59ABBE56E057F20F883E,可以在cmd5上很容易反查到哈希值的明文資訊。
所以為了加大密碼破譯難度，可以在哈希時加鹽處理，先密碼的特定位置插入特定的字元串(salt)，再進行哈希。
加鹽後的密碼經過哈希加密得到的哈希串與加鹽前的哈希串完全不同。為了進一步增加隨機性，可以每個用戶哈希保存密碼時使用的”鹽值”都不相同，比如使用用戶名或用戶id等用戶不可變屬性當作哈希時的”鹽”。
網站文件泄露
nginx可用於靜態資源伺服器，為了下載資源方便，可能會開啟目錄瀏覽(autoindex = true)的功能。
一旦不小心在目錄下存放了敏感文件資訊，就容易被用戶下載獲取。
為了避免隨意訪問資源，可以添加身份認證，在訪問前先進行帳號密碼認證。
更安全的做法是同時關掉目錄瀏覽功能，用戶只能通過完整資源路徑獲取指定資源。比如資源根目錄下有”xx.txt”, 用戶只能通過”//huiwan_code.com/xx.txt”獲取，而不能訪問”//huiwan_code.com”打開目錄頁面。再在頁面上點擊下載”xx.txt”。
過於詳細的robots.txt
許多網站都提供文件 /robots.txt 和 /sitemap.xml 幫助搜索引擎爬取其網站。搜索引擎可以通過robots文件可以獲知哪些頁面可以爬取，哪些頁面不可以爬取。
上面是百度的robots.txt內容，可以直接通過網站域名(wwww.baidu.com)後加robots.txt查看。robots可以針對不同的搜索引擎進行不同的頁面規則爬取限制。allow表示允許爬取；disallow表示不允許爬取。
如果robots.txt文件編輯的太過詳細，會泄露網站的敏感目錄或者文件。比如disallow: /admin/login、disallow/admin/register等，直接將詳細的後台路徑寫出來，容易被攻擊者收集利用。
可以通過正則通配符的方式，模糊的進行路徑匹配:
- User-agent:
*這裡的代表的所有的搜索引擎種類 - Disallow:
/admin/表示禁止爬尋admin目錄下面的目錄 - Disallow:
/?禁止訪問網站中所有包含問號?的網址 - Disallow:
/.jpg禁止抓取網頁所有的jpg格式的圖片
…
前端保存密鑰資訊
有時候，系統可能需要依賴第三方系統進行一些輔助功能，比如發簡訊、審批系統等。如果業務架構設計不合理，將這些第三方服務的密鑰key放在前端存儲，前端直接調用服務。攻擊者可以分析前端js程式碼獲取到密鑰，導致資訊泄露。
介面返回用戶敏感資訊未進行脫敏處理
當介面需要返回用戶敏感資訊(如：身份證、手機號、姓名、詳細地址等)時，需要對這些資訊進行脫敏處理。避免被攻擊者獲取利用。
過多返回用戶敏感資訊
有些時候，可能一個介面會被不同前端模組調用，但各個模組需要用到的資訊不同，比如A模組需要展示用戶的名稱，B模組需要獲取用戶的地址。介面把全部資訊返回，然後前端獲取介面全部欄位後按需使用。有些同學可能會說敏感資訊都已經脫敏處理了，即使全部返回也不會有風險了。
只能說too young too simple, 假設攻擊者拿到一個手機號後，根據微博、qq等社交軟體獲取到幾個可能是手機號號主姓名的名單，如何進一步確認呢？
相信大家都用支付寶轉過賬，通過手機號轉賬時，會顯示收款人的脫敏姓名，支付寶是實名驗證的，所以這是用戶的真實姓名脫敏資訊。
「點此驗證」還能輸入收款人的姓，進一步確認用戶姓名。
這裡並不是說支付寶有漏洞，畢竟這個泄露風險與用戶未經確認導致轉錯賬相比不值一提，只是想提醒大家，敏感資訊也有可能成為攻擊者的一個有用資訊。所以，介面應儘可能少的返回敏感資訊。
如果確實想要一個介面滿足多個數據要求，GraphQL是個不錯的選擇。後端先定義好數據格式和欄位。前端可按需請求需要的欄位資訊。
第三方平台泄露
資訊泄露也會發生在工作時使用的第三方平台網站上。
公司程式碼上傳到github
有意或無意。我們可能會將公司程式碼上傳到github上，如果程式碼中包含配置文件、資料庫帳號密碼等，會造成嚴重泄露後果。
除了加強培訓員工安全意識，強化公司管理制度，避免員工私自上傳程式碼。公司還可以利用Hawkeye等github泄露監控工具對github程式碼庫進行監控，及時發現員工託管公司程式碼到GitHub行為並預警，降低程式碼泄露風險。
工作筆記上傳到雲存儲工具
為了方便，有時候會將工作筆記、工作資料存放到網盤、雲筆記上，多端直接同步。但由此導致的安全問題也不可忽視。
拿印象筆記舉例，印象筆記提供了郵箱找回密碼的功能，一旦郵箱帳號和密碼被泄露，攻擊者可通過郵箱重置印象筆記帳號密碼，登錄用戶印象筆記。
寫在最後
喜歡本文的朋友，歡迎關注公眾號「會玩code」，專註大白話分享實用技術
