黑客攻防日记---刘欣
我最近發(fā)現(xiàn)了一個網(wǎng)站，是個博客平臺，很火，大家都到那里去寫注冊賬號，寫日志。
我也好奇地去看了看，不過，我主要是想看看有什么漏洞沒有，哈哈。
我發(fā)現(xiàn)他這個網(wǎng)站只用了HTTP協(xié)議，沒用HTTPS，換句話說，所有的數(shù)據(jù)都是明文傳輸?shù)?#xff0c;包括用戶名和密碼， 我覺得機(jī)會來了。
我尊敬的大哥給了我?guī)着_服務(wù)器的信息，他說通過這幾臺服務(wù)器能夠偷窺，不，是監(jiān)視發(fā)往博客平臺服務(wù)器的HTTP數(shù)據(jù)，還能通過這幾臺服務(wù)器當(dāng)個中間人，攔截修改請求和響應(yīng)， 這讓我喜出望外。
既然數(shù)據(jù)都是明文的，我就輕松地拿到了很多人的用戶名和密碼。更有意思的是，這些人的用戶名和密碼在很多平臺都是一樣的，這下次發(fā)財了！
我把用戶名和密碼都獻(xiàn)給了大哥。
最近收到了不少投訴，都是說密碼泄露的問題，我覺得不可能啊，因為我根本就沒有明文存儲密碼！
有些人還不相信，我百口難辨。
在服務(wù)器的數(shù)據(jù)庫里，我存的都是hash過的密碼，為了防止黑客破解， 每個密碼還都加了鹽(salt)以后才做的存儲。 密碼怎么可能泄露？
想來想去，我覺得還是從瀏覽器到服務(wù)器這一段出了問題，肯定是有人在偷窺， 老子一定要加密！
我想用RSA這種非對稱的加密方式（碼農(nóng)翻身注： RSA的詳細(xì)解釋戳這里）：
服務(wù)器生成public key 和 private key ， 瀏覽器用JavaScript使用public key 對密碼加密， 然后服務(wù)器端用private key 進(jìn)行解密。 這樣，密碼在傳輸過程中就不會被竊取了。
小黑的日記? 2010-6-24 多云
我突然發(fā)現(xiàn)，好多密碼都被加密了！
我讓大哥看了看，大哥說沒有私鑰，我是無法解密的， 不過他建議我當(dāng)個中間人，也生成一對兒public key 和private key ， 對博客網(wǎng)站冒充是瀏覽器， 對瀏覽器冒充是博客網(wǎng)站。
我把我的public key 發(fā)給瀏覽器，瀏覽器把加密后的數(shù)據(jù)發(fā)給我，我用我的private key 解密， 就拿到了明文密碼。
然后我還得用博客網(wǎng)站的public key 把密碼加密，發(fā)給博客網(wǎng)站，讓它渾然不知。
這件事難度不小，真是讓人興奮。
MD, 密碼還是泄露，氣死老子了。
幸虧Bill提示我說可能有中間人，?我怎么忘了我和Bill 建立HTTPS的時候已經(jīng)考慮到中間人這種情況了？
（碼農(nóng)翻身注： 《一個故事講完HTTPS》）
中間人難于防范，還得搞數(shù)字證書證明身份，如果我把這一套都搞好，豈不是又實現(xiàn)了一遍HTTPS？ 重復(fù)發(fā)明輪子！
要不我也上HTTPS ，一勞永逸地解決問題？ 但是我這是個小網(wǎng)站，搞個正規(guī)的、瀏覽器不會提示安全風(fēng)險的證書也不便宜吧？
真是煩人！
當(dāng)中間人真是爽！
老子決定不再折騰HTTPS了！
Bill建議我可以對瀏覽器發(fā)過來的密碼加密， 其實也不是加密，而是做個Hash， Hash過的數(shù)據(jù)是不可逆的，不能恢復(fù)原始的明文密碼。
瀏覽器端：
hash(password,salt) -> hash_password
然后瀏覽器把（username, hash_password） 發(fā)給服務(wù)器端。
服務(wù)器端：
從數(shù)據(jù)庫獲得之前保存的hash_password
和瀏覽器傳遞過來的hash_password比較，看看是否相等。
從此以后，網(wǎng)絡(luò)上傳輸?shù)亩际撬^hash_password，再也看不到明文密碼了， 讓那幫偷窺的孫子們哭去吧！
ps : 在瀏覽器中進(jìn)行hash的時候，有一個salt參數(shù)， 這個salt從哪里來？ 肯定是從服務(wù)器端獲取的啊。
大哥猜對了，那家伙果然對密碼做了hash，然后再發(fā)到服務(wù)器端，現(xiàn)在我難于獲取明文密碼了。
不過，那家伙還是留了一個大漏洞，既然我還能監(jiān)聽到 user_name, hash_password， 我就重新發(fā)送一下到服務(wù)器端，還是成功登陸這個博客系統(tǒng)了！ 哈哈！
焦頭爛額！
這個瀏覽器端的hash操作沒能發(fā)揮作用。今天研究了半天，才發(fā)現(xiàn)那些黑客可以重放攻擊。
Bill說主要的原因還是salt固定導(dǎo)致的， 我決定再增加一點難度，增加一點動態(tài)的東西：驗證碼（captcha）！
用戶登錄的時候，發(fā)個驗證碼(captcha)到瀏覽器，這個驗證碼每次都不一樣。
瀏覽器端：
第一次Hash:
hash(password,salt) -> hash_password1
第二次Hash:
hash(hash_password1,captcha) ?->?hash_password2
然后瀏覽器把（username,?hash_password2，captcha） 發(fā)給服務(wù)器端。
注意：hash_password1并不會發(fā)送給服務(wù)器， 黑客們窺探不到。
服務(wù)器端：
驗證captcha 是否正確
使用username從數(shù)據(jù)庫獲得hash_password
hash(hashed_password,captcha) ?-->?hash_password3
比較hash_password2和hash_password3，看看是否相等。
如果相等，登錄成功，否則，登錄失敗。
hash_password2是使用一次性的驗證碼生成的， 即使被那幫孫子截獲，他也沒法展開重放攻擊，因為驗證碼已經(jīng)失效了。
那家伙越來越聰明了嘛，增加了驗證碼，老子的重放攻擊也不管用了。
不過大哥真是威武，他告訴我要另辟蹊徑，想辦法攻擊博客系統(tǒng)的數(shù)據(jù)庫，只要把數(shù)據(jù)庫拿到了，用暴力的方法破解它！
今晚就開始行動！
Bill今天來了，他告訴我一件重要事情，不管你前端怎么加密，后端的安全措施一點都不能少！
我決定，把用戶在瀏覽器中輸入的密碼做兩次hash, 一次在瀏覽器端做，另外一次在服務(wù)器端做，把最終的結(jié)果作為密碼存到數(shù)據(jù)庫中。
瀏覽器端：
front_hash(password,salt) ->front_hash_password
發(fā)送(username,front_hash_password)到服務(wù)器端
服務(wù)器端：
back_hash(front_hash_password,salt) -> backend_hash_password
和數(shù)據(jù)庫保存的hash_password做比較， 看看是否相等。
這么做的結(jié)果就是， 如果那幫孫子真的把我的數(shù)據(jù)庫給偷走了，他們也很難通過撞庫的方式破解其中的密碼。
因為他們通常會把常用密碼建立一個字典，然后通過hash算法生成hash值，如果這個hash值和待破解數(shù)據(jù)庫的值相等，不就知道明文是什么了嗎？
但是我的數(shù)據(jù)庫中的密碼是通過front_hash_password 作為明文密碼，再次hash計算出來的。而那個front_hash_password本身就是個散列值，毫無規(guī)則可言。假如它是個32位的16進(jìn)制字符串， 那將會有16^32 中組合，這是個天文數(shù)字，?這樣字典也就難以建立了。
如果黑客把密碼也按照我的方式，把常用的密碼做兩次hash呢？
這也不怕，Bill說可以把瀏覽器端的hash算法設(shè)置得復(fù)雜一點，增加破解的難度。 當(dāng)然復(fù)雜的算法比較耗時， 但是Bill說了： 瀏覽器是分布的，完全可以充分利用他們的計算能力嘛！
Bill真是個聰明的家伙。
為了最終的安全，我想我還是上HTTPS吧！
終于把博客系統(tǒng)的數(shù)據(jù)庫給拖下來了，可是怎么都破解不了。
大哥研究了一下說，這個網(wǎng)站可能用了復(fù)雜的Hash算法, 破解起來太耗時間了，放棄吧。
更加悲催的是，我發(fā)現(xiàn)這個網(wǎng)站開始使用HTTPS了，真的難以下手了。
我還是去看世界杯去吧。
總結(jié)
以上是生活随笔為你收集整理的黑客攻防日记---刘欣的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： vue3+ts 实现防抖功能
- 下一篇： ERP项目组员工年度工作总结2010(刘