文章首發於公眾號 「會玩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", 用戶只能通過"http://huiwan_code.com/xx.txt"獲取，而不能訪問"http://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」，專注大白話分享實用技術
