黑客攻防日記
小黑的日記 2010-6-22 晴
我最近發現了一個網站，是個博客平台，很火，大家都到那裡去寫註冊賬號，寫日誌。
我也好奇地去看了看，不過，我主要是想看看有什麼漏洞沒有，哈哈。
我發現他這個網站只用了HTTP協議，沒用HTTPS，換句話說，所有的數據都是明文傳輸的，包括用戶名和密碼， 我覺得機會來了。
我尊敬的大哥給了我幾台伺服器的信息，他說通過這幾台伺服器能夠偷窺，不，是監視發往博客平台伺服器的HTTP數據，還能通過這幾台伺服器當個中間人，攔截修改請求和響應， 這讓我喜出望外。
既然數據都是明文的，我就輕鬆地拿到了很多人的用戶名和密碼。更有意思的是，這些人的用戶名和密碼在很多平台都是一樣的，這下次發財了！
我把用戶名和密碼都獻給了大哥。
張大胖的日記 2010-6-23 陰
最近收到了不少投訴，都是說密碼泄露的問題，我覺得不可能啊，因為我根本就沒有明文存儲密碼！
有些人還不相信，我百口難辨。
在伺服器的資料庫里，我存的都是hash過的密碼，為了防止黑客破解， 每個密碼還都加了鹽(salt)以後才做的存儲。 密碼怎麼可能泄露？
想來想去，我覺得還是從瀏覽器到伺服器這一段出了問題，肯定是有人在偷窺， 老子一定要加密！
伺服器生成public key 和 private key ， 瀏覽器用JavaScript使用public key 對密碼加密， 然後伺服器端用private key 進行解密。 這樣，密碼在傳輸過程中就不會被竊取了。
小黑的日記 2010-6-24 多雲
我突然發現，好多密碼都被加密了！
我讓大哥看了看，大哥說沒有私鑰，我是無法解密的， 不過他建議我當個中間人，也生成一對兒public key 和private key ， 對博客網站冒充是瀏覽器， 對瀏覽器冒充是博客網站。
我把我的public key 發給瀏覽器，瀏覽器把加密後的數據發給我，我用我的private key 解密， 就拿到了明文密碼。
然後我還得用博客網站的public key 把密碼加密，發給博客網站，讓它渾然不知。
這件事難度不小，真是讓人興奮。
張大胖的日記， 2010-6-25 陰
MD, 密碼還是泄露，氣死老子了。
幸虧Bill提示我說可能有中間人，我怎麼忘了我和Bill 建立HTTPS的時候已經考慮到中間人這種情況了？
（碼農翻身註： 《一個故事講完HTTPS》）
中間人難於防範，還得搞數字證書證明身份，如果我把這一套都搞好，豈不是又實現了一遍HTTPS？ 重複發明輪子！
要不我也上HTTPS ，一勞永逸地解決問題？ 但是我這是個小網站，搞個正規的、瀏覽器不會提示安全風險的證書也不便宜吧？
真是煩人！
小黑的日記， 2016-6-26 晴
當中間人真是爽！
張大胖的日記， 2010-6-27 小雨
老子決定不再折騰HTTPS了！
Bill建議我可以對瀏覽器發過來的密碼加密， 其實也不是加密，而是做個Hash， Hash過的數據是不可逆的，不能恢復原始的明文密碼。
瀏覽器端：
hash(password,salt) -> hash_password
然後瀏覽器把（username, hash_password） 發給伺服器端。
伺服器端：
從資料庫獲得之前保存的hash_password
和瀏覽器傳遞過來的hash_password比較，看看是否相等。
從此以後，網路上傳輸的都是所謂hash_password，再也看不到明文密碼了， 讓那幫偷窺的孫子們哭去吧！
ps : 在瀏覽器中進行hash的時候，有一個salt參數， 這個salt從哪裡來？ 肯定是從伺服器端獲取的啊。
小黑的日記， 2016-6-28 晴
大哥猜對了，那傢伙果然對密碼做了hash，然後再發到伺服器端，現在我難於獲取明文密碼了。
不過，那傢伙還是留了一個大漏洞，既然我還能監聽到 user_name, hash_password， 我就重新發送一下到伺服器端，還是成功登陸這個博客系統了！ 哈哈！
張大胖的日記， 2010-6-29 中雨
焦頭爛額！
這個瀏覽器端的hash操作沒能發揮作用。今天研究了半天，才發現那些黑客可以重放攻擊。
Bill說主要的原因還是salt固定導致的， 我決定再增加一點難度，增加一點動態的東西：驗證碼（captcha）！
用戶登錄的時候，發個驗證碼(captcha)到瀏覽器，這個驗證碼每次都不一樣。
瀏覽器端：
第一次Hash:
hash(password,salt) -> hash_password1
第二次Hash:
hash(hash_password1,captcha) ->hash_password2
然後瀏覽器把（username,hash_password2，captcha） 發給伺服器端。
注意：hash_password1並不會發送給伺服器， 黑客們窺探不到。
伺服器端：
驗證captcha 是否正確
使用username從資料庫獲得hash_password
hash(hashed_password,captcha) -->hash_password3
比較hash_password2和hash_password3，看看是否相等。
如果相等，登錄成功，否則，登錄失敗。
hash_password2是使用一次性的驗證碼生成的， 即使被那幫孫子截獲，他也沒法展開重放攻擊，因為驗證碼已經失效了。
小黑的日記， 2016-6-30 陰天
那傢伙越來越聰明了嘛，增加了驗證碼，老子的重放攻擊也不管用了。
不過大哥真是威武，他告訴我要另闢蹊徑，想辦法攻擊博客系統的資料庫，只要把資料庫拿到了，用暴力的方法破解它！
今晚就開始行動！
張大胖的日記， 2016-6-30 多雲
Bill今天來了，他告訴我一件重要事情，不管你前端怎麼加密，後端的安全措施一點都不能少！
我決定，把用戶在瀏覽器中輸入的密碼做兩次hash, 一次在瀏覽器端做，另外一次在伺服器端做，把最終的結果作為密碼存到資料庫中。
瀏覽器端：
front_hash(password,salt) ->front_hash_password
發送(username,front_hash_password)到伺服器端
伺服器端：
back_hash(front_hash_password,salt) -> backend_hash_password
和資料庫保存的hash_password做比較， 看看是否相等。
這麼做的結果就是， 如果那幫孫子真的把我的資料庫給偷走了，他們也很難通過撞庫的方式破解其中的密碼。
因為他們通常會把常用密碼建立一個字典，然後通過hash演算法生成hash值，如果這個hash值和待破解資料庫的值相等，不就知道明文是什麼了嗎？
但是我的資料庫中的密碼是通過front_hash_password 作為明文密碼，再次hash計算出來的。而那個front_hash_password本身就是個散列值，毫無規則可言。假如它是個32位的16進位字元串， 那將會有16^32 中組合，這是個天文數字， 這樣字典也就難以建立了。
如果黑客把密碼也按照我的方式，把常用的密碼做兩次hash呢？
這也不怕，Bill說可以把瀏覽器端的hash演算法設置得複雜一點，增加破解的難度。 當然複雜的演算法比較耗時， 但是Bill說了： 瀏覽器是分布的，完全可以充分利用他們的計算能力嘛！
Bill真是個聰明的傢伙。
為了最終的安全，我想我還是上HTTPS吧！
小黑的日記， 2016-7-1 陰
終於把博客系統的資料庫給拖下來了，可是怎麼都破解不了。
大哥研究了一下說，這個網站可能用了複雜的Hash演算法, 破解起來太耗時間了，放棄吧。
更加悲催的是，我發現這個網站開始使用HTTPS了，真的難以下手了。
我還是去看世界盃去吧。
（完）
TAG:碼農翻身 |