文章首發於公眾號 「會玩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」，專注大白話分享實用技術
