XD 姿勢佳 29 Jul 2007 10:47 pm
|
推到 Twitter!
推到 Plurk!
|
以 ROR 打造網站，設計盲點所引發的惡搞危機
[本篇採 CC-BY-NC-ND，可以轉錄但禁止於未經授權下的商業用途以及未經授權下的改作]
這篇文章裡的爆點，其實在七月初我就應該發表了。只是當初筆者在以其手法測試過幾個 site ，發現成果實在太驚人。因此決定也將爆點寫進在 HIT 2007 預備 present 的投影片裡，並將發表日期延後到 CONF 結束的七月底。
我在 HIT 2007 演講的主題，大致是以 Web 2.0 類型網站，揭露不管源自於使用者盲點、設計者盲點所產生的資料洩漏。使用者盲點這個在本站算老梗了，不是本篇重點。這次要揭露的是設計者盲點。
仔細觀察如今的社交網站，不難發現幾乎每個網站設計者都愛為使用者弄個「個人首頁」，當中除圍繞著個人資訊打轉，更詳細記載了他本身及其好友的資訊。我在使用者盲點相關的文章提過，不少人很喜歡將自己的隱私寫在首頁上，配合上好友關係社交工程的手段配合，真實資料幾乎無所遁形。
當然，以工人智慧逐一追蹤是不太困難，只是無法自動化實在令人渾身不爽快。若要用程式分析一個站的群眾關係以及資訊，常見的簡單手法是自己寫 crawler 將目標網站頁面爬回來庫存，再自己寫 paser 粹取資訊。不過原始手法說來簡單 ，但是少有人實做。較為主要的原因是難以藉括展式脈絡找到所有頁面（若使用者跟其他使用者絲毫無掛勾，機器有極大可能爬不到這筆資料）：擴展式 BOT 撰寫較複雜以及非為整個網站的完整樣本分析起來較無價值。
所以被鎖定蒐集資料的 Target Website，其網站網址大多長成這樣
http://xxxx.com/pages/profile.php?userid=2383
以 primary key： id 作為呼叫資料的參數。
明眼人一看就知道，為什麼這些網站是塊大肥肉？有心人可用很簡單的工具（類似 curl），就能把整站砍回家作資料分析。筆者觀察國內社群網站，不少廠商皆採用此撰寫方式。這樣寫有什麼壞處呢？除了容易被砍站外，也很容易被外部人監視商業機密。比如說總註冊人數有多少？資料成長筆數有多少？每個月的新註冊帳號數量。這些關係你網站賣價的商業機密，正大剌剌的在大門口暴露。
當然，這種事對於職業是網站滲透的人來說，應該也不是新聞了。但，如果這篇不是獨家新聞，我也不會寫在這裡丟臉了 XD
這個月初，我在 Twitter 上偷偷透露了 Twitter 註冊總人數是 71萬多人 （今天的數字大概是 78 萬多人），結果被 Mr.6 抓出來寫在文章裡爆料 XD。看到這裡，大家應該蠻好奇我怎麼拿到這個數據的。其實前一段就應該暴露了我是怎樣知道這個數字的。當然我是不曉得為什麼 TechCrunch 在 7/26 講的數字怎麼只有 30 萬這麼低。（是他太久沒 Update 資訊，還是我測出來的資料裡面含有大量測試帳號？）
寫到這裡，感覺好像還沒有什麼八卦。好，八卦就是：目前筆者檢測到的 ROR 社群網站，九成以上有這種問題 XD
ROR 最近很紅，相信它的歷史，不用我多說，你自己在維基百科上也查得到 …ROR 拿來打造網站太好用，開發速度也很快，好用到讓筆者自己也丟掉了 PHP 改寫 ROR 。
ROR 的精神是「慣例優於配置」，因為處處都是慣例與現成工具，開發網站非常快速（相反的，在 ROR 裡逆天而行就會處處碰壁），Web 2.0 風潮中，大家都想撈一票，以其他語言所撰寫的網站開發速度太慢，所以近期新推出的網站，以 ROR 撰寫的比例相當高。而最好賣的又屬社群網站。所以，這些新網站裡，社群網站又特別多。
為什麼會有上述我提到的這種問題呢？這要歸功於 三點
1. 慣例優於配置
2. 超強神兵：ActiveRecord
3. 框架太新，大家都照教學寫網站
當我一看到 Twitter 這麼容易就被我挖到商業機密，又多留意了一下網站配置，腦筋一轉，就暗叫糟 ….
Twitter 採用的是非常非常典型的寫法，使用 00X_create_YYYY.rb 建立模型之對應資料庫結構。ROR 的 ActiveRecord 非常貼心。當你在 rb 裡寫了
class CreateProducts < ActiveRecord::Migration
def self.up
create_table :products do |t|
t.column :title, :string
t.column :description, :text
t.column :image_url, :string
end
enddef self.down
drop_table :products
end
end
下了 rake: migrate ，資料庫裡就會幫你自動建一個對應 Table，裡有 id ( incresement primary key）、title、description、string。因為「慣例」，所以他會很貼心的幫你加 primary key 叫做 id，如果你不想要這種現成設法，還要自己去修改再做 mapping。（瘋了才會自己找麻煩）
所以萬物的 Table 都有 primary key 叫 id。這不是最糟糕的，糟糕的是大家寫功能愛寫成這樣
http://twitter.com/add/1234567 （這是加好友），而不是 http://twitter.com/add/username。
而會有這樣的寫作傾向，援自於 ROR 有個好用的東西叫做 scaffold，一行指令 ruby script/generate scaffold modelname controllername，就幫你輕鬆建立 CRUD （Create / Read / Update / Delete ）四大功能的 controller config。
以 scaffold 建立頁面的標準網址，通常是長這樣的 http://xxx.com/user/show/12345 （國內某家社群網站好像連改都沒改，user profile 頁面網址就是這樣 …）。因為這是一個很新的框架，在沒有多少參考範例的情況下，開發者在撰寫新功能時不是在 controller 改寫 scaffold 幫你自動建立的與法，就是照書或教學範例寫 code。結果造成了這樣的後遺症，從功能到 api 都長成這樣： http://xxx.com/model/function/numberid 。
下場是，抓資料不但很簡單，連惡搞都很方便。Twitter 傳送 direct message 都是採這種寫法（direct message 會送信到使用者信箱），大量寄送 spam 的門檻頓時變得非常非常非常的低，一行 curl 語法就能搞定 （不要寫信問我怎麼做 -_-）。
在以 ROR 設計的網站上，這種情形實在太普遍。在傳統上，我們以 php / asp 自己一行一行打造的 code 較會閃開這種盲點，但是在 ROR 慣例優於配置的精神下，稍有不慎就很容易暴露商業機密、或資料輕鬆被整套被人爬回家分析。特別撰寫此文的原因，便是因為手法簡單以及弱點明顯，卻少有人重視與討論，與大家共分享之。
—–
後記：以上的內容是 HIT 前發現的設計盲點。
在我個人的感覺，以 PHP 和 ASP 純手工寫的網頁，功能像是自已規劃設計後一行一行添上去的。ROR 就比較像是用一包一包疊的，一整套給你，不要的再拿掉。這當然各有開發上的利弊。ROR 開發快，但是如果拿掉的不乾淨，同樣會寫 ROR 的人很快就可以知道怎樣玩這個網站。
自己這幾天又發現的一個設計盲點，就大致屬於這一類。我這幾天玩到一個網站，站長還蠻有戒心的 (?)，show page 一律使用 username，又改了 mapping，想掃資料實在不好下手。最後是在一個地方破功：ROR 有一個好用的分頁功能 pagination，可以為輸出結果作分頁（各 ROR 網站常用這種設計）。這個網站也在它的排行榜採取了這種設計，而他設定了排行榜可以看前二十頁的使用者 …破功的地方在於他有鎖網站 bar 上秀出來可看的頁數（20頁），卻未從 controller 裡設 筆數 Limit。對全站排序卻未鎖 limit，如果我可以看到第21頁，就表示可以看第 XXX 頁。如此一來，對著頁數掃，全站使用者列表與全站人數照樣手到擒來，username 的限制便一點用處都沒有了，口桀口桀。
This
work is licensed under a
Creative Commons Attribution-Share Alike 2.5 Taiwan License.
[本文採 cc-by-sa 授權，白話意思就是可以直接轉走，但是要附出處與作者）]
28 Responses to “以 ROR 打造網站，設計盲點所引發的惡搞危機”
on 30 Jul 2007 at 12:31 am 1.cch said …
報告，太專業了，我看不太懂。囧rz
on 30 Jul 2007 at 12:34 am 2.xdite said …
這篇可能要有在寫網站的人才看得懂喔
on 30 Jul 2007 at 1:06 am 3.ddk said …
用Ruby開發網站時,不知mapping會有多麻煩??
如果很麻煩…看來還是用php OR asp 比較實在!!
on 30 Jul 2007 at 1:23 am 4.果汁店小弟 said …
回樓上..一點也不麻煩吧…幾行就解決了
至於XDITE提到的問題….那也是沒辦法的
畢竟開發速度還是最重要的問題
on 30 Jul 2007 at 2:34 am 5.xdite said …
mapping 不會很麻煩，很簡單喔
只是你要”知道”怎麼指，和”記得”去指 …
on 30 Jul 2007 at 2:46 am 6.大鳥 said …
這是HIT演講關於RoR的全部內容嗎?
當時有事沒去聽 真好奇有沒有別的漏洞 @@
on 30 Jul 2007 at 10:33 am 7.ericsk said …
其實我覺得這些問題，應該是各個「範例」的錯，好好地使用 RoR 也可以避免掉許多問題才對。
on 30 Jul 2007 at 10:50 am 8.ㄚ凱 said …
我想這大概是設計習慣的問題,若是開發的人習慣上就已經是用 id 來做的話,大概不管用 RoR 還是其他的都會這樣.
當然,我想大多的範例都沒有講到這部分怎麼處理,就會造成初學的人,都照著範例來做,所以就都會變成那樣了…
on 30 Jul 2007 at 12:38 pm 9.迷戀愛麗絲 said …
REST:
http://zh.wikipedia.org/w/index.php?title=REST&variant=zh-tw
on 30 Jul 2007 at 12:47 pm 10.s3p said …
> 這是HIT演講關於RoR的全部內容嗎?
當然不是, 至少笑話沒有出現在上面… XD
–
真的, 笑話才是重點.
on 30 Jul 2007 at 1:01 pm 11.BobChao said …
mmm… 這篇看到好玩的東西，「如果 CC 在版型裡寫死的話、要以另外的方式授權怎麼辦？」
(BTW, 我想你是想用 by-nc-nd 吧，sa 與 nd 不共存
)
on 30 Jul 2007 at 1:04 pm 12.xdite said …
我懶得找 plugin 並設定，所以乾脆寫死再用例外方式標明
on 30 Jul 2007 at 4:23 pm 13.ericsk's blog said …
現在用 RoR 開發上線網站 OK 嗎？…
RoR 在這一兩年間突然爆紅，我也 K 了一兩本書、試著開發一兩個網站，DRY 的精神的確讓我驚豔，透過 ActiveRecord 的 ORM，使我在網站時幾乎沒有寫到一行 SQL code（雖然我在 Hibernate 中也體驗過…..
on 30 Jul 2007 at 10:10 pm 14.phhuang said …
原來 讓我 Orz 再三的 ID RSS Feed 就是這樣來的 …
是這樣嗎 ??
大家可以 踹踹 皮克斯網到底使用人數長到多少了 …
on 31 Jul 2007 at 3:42 am 15.nign said …
關於 Twitter的會員數目，
我有一個自己無法驗證的揣測：
除了可能的測試帳號之外，
Twitter公布的會員數可能是 active member的數量，
而不是註冊者的總數。
根據我最近一個月到處亂看 public timeline上頭陌生人的 contact list和亂測 id的心得，
在去年底至今年初（三四月左右吧）期間註冊的人，
最後大部份都沒有留在 Twitter上頭，
主要的原因是沒有其它朋友加入；
這些 dead account的 contact list上的人數通常在三人以下。
而有在用 Twitter的人都知道，
Twitter就是要不斷收送信息加上使用者間不時公開互動、
鳥聲囀囀不斷才有趣，
這方面缺乏人際號召力的 early adopter只有被無聊死的份而沒有早來的好處，
加上 Twitter不刪舊帳號，
長期累積下來的廢帳號應該也不少。
這種東西只有人際號召力強的人多了、
可以來一個就拉一群的狀況不斷持續，
才能達到快速成長的 tipping point吧。
這是上周五 Wall Street Journal某篇 gadget review對於 Nokia N800的 sweet spot的形容，
我覺得也正好說中了 Twitter這類服務的市場利基：
In this new connected world we may want to switch off, but that doesn’t mean disconnecting. (In fact, I don’t think we’ve even come up with the right words for this new state.) We’d love to get away from the office, and our BlackBerrys, but that doesn’t mean we want to sever all digital ties. We don’t always want to be reachable, but we want to be in touch. We don’t always need or want a phone and we want to disengage from our laptops, but we don’t want to disengage from the Internet.
（因為這篇文章在 WSJ官網上只有訂戶才能看到，
所以連結用的是我另外咕出來的網站轉載。）
另外不知道日本人搞出來的這種頗受歡迎的 Twitter電子貓會不會也被算進 “active user”裡頭……
雖然牠是的確整天喵個沒完沒錯（public timeline塞滿滿啊），
但是其實是飼主一個人用兩個帳號，
嚴格說來是只有一個 user的。
on 31 Jul 2007 at 8:50 am 16.nign said …
BTW, 若 Twitter public timeline的運作一直是正常的,
那麼最近兩周的使用者數成長以及/或使用率變高了很多
一個月前三四分鐘內所有使用者送出的 twitter也不過三四頁
現在常常二十秒就六頁不止了;
雖然會有些 fluctuation,
但是整體說來 hyper activity發生的頻率是前所未見的高,
不知道是不是超過或快到爆炸性成長的 tipping point了…
on 31 Jul 2007 at 9:26 am 17.Mr. 6 said …
這篇文章語氣平和, 內容卻太驚人了…
小弟建議, 應立刻設法翻為英文廣為流傳
on 31 Jul 2007 at 10:33 am 18.william said …
說實在的，即使在 URL 裡面不洩露出流水序號，有心人士還是可以透過某些間接的手段，定期去 polling 系統列表（RSS、最新文章、最新使用者…），一樣可得到你所謂的「商業機密」。
如果「商業機密」的範圍只有這一點，那機密等級也未免太低了一點。
要預防你所謂的「職業是網站滲透的人」，或是獨孤木所自稱的「我們可是專門在抓資料抓了好幾年的人呀」(http://0rz.tw/f92Rr)，應該要用其他方法，而不是在序號上計較。
序號只是防君子，防不了小人… 喔，是防不了「職業是網站滲透的人」的。
on 01 Aug 2007 at 5:03 am 19.moming2k said …
知道流水號也不是問題，問題是保安問題了，如果權限沒做好，可以任意發 direct message 才會是大問題
至於知道流水號的問題，倒也不是今天才有，很多 php 網頁也有這個問題，不能單挑 Rails 來說呀，而且用了 REST ，標準來說也會用 id ，而不是用 name , 只能多花心思在防止惡意找取上
on 01 Aug 2007 at 9:09 am 20.xdite said …
樓上你誤會我的意思了，流水號問題在 ROR 是特別特別的嚴重，我才會拿出來講。這樣的情況下，要是什麼功能都喜歡用流水號來幹，如果在功能上寫作出了問題，很容易被人想怎樣玩就怎樣玩。
就如同 direct_message 是合法的，但如果以流水號設計，就變成了容易拿來發全站 spam …。（這時代反而又回到什麼都寄信的時代了，因為大家都綁 gmail，又都用 gtalk 做 alert …）
好吧扯遠了。我只是覺得太 REST 反而造成壞人有機可趁，而且有機可趁的門檻太低。
on 01 Aug 2007 at 9:11 am 21.Test said …
iGoogle哩, 給大夥講講吧. *怕您忘了*
on 01 Aug 2007 at 9:22 am 22.Test said …
Google服務「手機版」紛紛(在台灣)上線
http://taiwan.cnet.com/news/comms/0,2000062978,20121475,00.htm
on 01 Aug 2007 at 9:25 am 23.william said …
@19樓的：
REST 通常會帶個 id，但這個 id 不必然非得是流水號；可以是 name，可以是 hash，可以是 uuid，或是任何足以識別的東西。
on 06 Aug 2007 at 2:39 am 24.cahier lukhnos: codex formosus » Ruby Tuesday: 7/31錄音檔，8/14予告 said …
[...] 8/14號星期二，我們臨時更動節目。原本安排的「如何撰寫、包裝Ruby extensions，以及如何在C/C++程式中使用Ruby」的題目順延一次。我們8/14星期二將請到XDite來和大家一起討論「Rails app controler在設計上的安全考量」這個重要話題。XDite前陣子撰寫了一篇短文，立刻成為Rails社群（以及正在使用Rails做案子的公司或業主）所關心的話題。XDite除了將和我們分享短文所提及的各種技巧，我們也希望利用該場次，能讓大家有機會來討論，Rails app設計時，應該注意的地方或best practices。 [...]
on 07 Aug 2007 at 10:17 pm 25.Blog.XDite.net » ROR 的新手建議書單 said …
[...] 1. 酷，scaffold 真是帥氣啊。（到這裡四處向人推廣 ROR 了）。2. 哇，我會照書寫一個購物車了。3. 咦，怎麼自己不靠寫 C / R / U / D 啊？又 scaffold 在 controller 裡自動建立的 C / R / U / D 語法每一句的意義到底是什麼啊？4. 靠盃，這些在書上怎麼都找不到（我想是我眼殘沒看完整本吧…）。在不懂配置語法的的情況下，寫一個功能真是困難重重。——- 一些新手會死在 4，沒死的會繼續 5 ———5. 算了，在 google 上到處抄 code 完成專案比較要緊。6. 從大量的範例領悟到配置與實際寫作方法，此時才體會到 ROR 奧妙與 AWDR 精義（AWDR 對於很多小地方都寫得很細緻，問題是…在完全不懂他是怎麼運作的時候，看這些東西完全是天書）。這也是我在猜，為什麼會有上禮拜那篇文章提及的慘況了。（大家都只抄書與抄範例的下場） [...]
on 08 Aug 2007 at 4:16 pm 26.james said …
id曝光應該不是什麼大問題吧…個人覺得…
on 12 Sep 2007 at 10:16 pm 27.很久沒寫 blog | None said …
[...] Twitter，感覺上比個人版來得更直覺一點，於是又多了個碎碎念的地方，不過據說這種架構很容易被發 [...]
on 06 Oct 2007 at 6:11 pm 28.Rails: 建立Permalink，避免流水號洩漏網站資料 - Cyberpunk網際叛客 said …
[...] XDite曾經在「以 ROR 打造網站，設計盲點所引發的惡搞危機」這篇文章中提到Rails的scaffold所建立出來的程式（或說開發者很習慣直接以id操作Model），由於在URL上是直接以流水號的方式呈現，我們便可以利用一些簡單的程式爬完某個網站的特定頁面，來取得所有的文章、所有的使用者頁面。 [...]