雖然小魯的專長不是大型網站開發或資安滲透測試，
但是畢竟還是對資訊有一點興趣，在大三以後接觸了不少阿宅小知識，
對於今次的所謂「電子投票」(嗎?) 的許多爭議，潛在水裡看了看
覺得應該可以對該系統本身的設計、程式架構、安全性的眾多問題提出一些意見。
首先是看個影片。寫程式的阿宅總會想套用老梗「 hello world 」在初見的新玩意兒上。
我們可不可以請投票系統 hello world 一下呢？ (註: 該漏洞在投票前就已修正)
http://vimeo.com/96702478
就如影片當中所顯示的，只要投票者有心，並且他能在短時間內想辦法用 VPN
內網的裝置 (例如投票的平板) 快速輸入大約 170 characteres 的魔法咒語，
就可讓遠端伺服器執行任何你想要的指令。（例如 rm -Rf . 之類的）
這裡只是為了展示概念而簡單地 touch hello-world 一下，不需多做解釋；
總之在影片左上角可以看到 git repository 內容可以成功地被我們投票者修改。
不過 real world attackers 想要做的當然遠遠不止這些，
所有該 process uid 可以做的事情咱們都能做到... 這就要看人們的想像力了。
至於為什麼這個系統會有這樣的問題呢？鄙人認為有數個因素，在此列出幾小點。
1. 撰寫整個網站沒有善加利用已經存在的 Web development frameworks
想要使用 MVC ，但是對 PHP 不是太熟悉的話，就不應該徒手去刻。
自己刻的話，各種安全性議題的 edge case 要考慮全面是很辛苦的。
2. 系統設計看起來有許多邏輯上的問題、怪異之處
舉例來說「身份認證」不應該是隨便想一套算法，套個 MD5 就可以 work 的，
應直接找現有的方案來套用。數學系及資訊系都有人對資訊安全、密碼技術相當了解，
遇到問題時向他們咨詢也是需要的。
舉例來說，像是影片中的攻擊，之所以成立，
應該是因為有一個像這樣的奇怪的判斷條件可以被 bypass with arbitrary code：
f( some_constant || user_input_key1 ) === user_input_key2
其中 f 是一個 cryptographically insecure one-way function
這裡只是很簡單地描述而已，實際狀況比較複雜，可以直接參照 code 。
使用者輸入的這個 key1 值會一層層逐漸傳遞到投票系統的深處，最終被 git commit
如果使用者可以改 key1 的話，就會因為其他部分的疏忽，導致任意代碼執行的漏洞。
但是，為什麼使用者改了 key1 以後這個判斷條件還能成立？
這是因為 some_constant 不是未知的數值，
任何人只要計算 f() 馬上就可以推知 key2 了，這樣子檢查 key2 就沒有任何意義。
3. 這個系統的開發可能沒有得到足夠多人的協助、咨詢、review
如果有足夠多的 reviewer 的話，應該就不會允許那麼多 bad practice 四散各地，
該份程式碼有非常多潛在問題，不只是上面影片中提到的 exec() 問題而已。
允許 bad practice 是很不好的，今天程式跑起來沒有問題，但是隔幾個月後，
陸陸續續修改各個元件了，還能保證以後不會引爆出別的更嚴厲的漏洞嗎？
4. 這樣子的系統其實根本不算是合理的「電子投票」
現在我們看到的只是一個有電子設備輔助的投票流程，
而且這個「電子輔助」好像沒有帶給我們更多的方便。
如果只是想要咬文嚼字地片面解釋說這玩意兒就是「電子投票」當然也是可以...
但是一個正常運作的「電子投票」需要有一些良好的 "provable" properties
- 某些人想要作弊？數學定理告訴我們他做不到。
- 想要驗自己的票？可以。你可以確認自己的票是否正確地被計入。
- 想要驗他人的票？多給一些條件以後，這當然也有辦法做到。
如果一個系統運行的正確性，有很多部分可以被「驗證」的話，就更能被大家接受。
而不是完全黑箱，把所有奢求的正確性都壓在一個名為「相信選舉主辦方」的籃子裡。
這樣子的「正確性」是脆弱而難以被長時間考驗的。
其實最理想的情況下，應當是使用者直接安裝軟體，在手機/電腦上直接參與投票，
請計中(orz)協助線上身份認證，或者善用 NFC 學生證悠遊卡來幫忙投票的過程。
一個好的 protocol 可以讓使用者無法在他的終端作弊，而主辦方也沒有辦法作弊。
當然了，這是一個浩大的工程，要請更多專家來幫忙才行，並不是短時間可以做到的。
5. 開放原始碼的程度其實不夠完整，普通人難以直接參與其中
只有 GitHub 上這一部分的 php 程式碼，
對於普通的 programmer 來說，還是難以幫忙「開發」、「測試」的。
應加上如何部署一台伺服器的說明、資料該如何生成、資料庫應該要有怎樣的結構等。
降低協助測試的門檻，才會有更多志願者來幫忙開發。
辛苦的核心開發人員也就不用焦頭爛耳修 bug 寫新 features 了。
如果這個系統以後還想要被使用，必定是要經過「砍掉重練」等級的大幅度更動。
不過任何的新制度也都是如此，剛開始會衝突、有異議，
必須仔細接納不同的意見，經逐步地修正、成熟化，最終才能被廣泛地接受。
如果還有許多爭議、不同的聲音時，就表示有一些根本上的問題，
所以人們才沒有被說服，所以該制度、系統就還需要修正。
不過無論如何，我們都還是由衷地感謝許多台前台後參與、幫忙的人，
因為有你們默默地無償付出，我們才能夠享受到各式各樣的福利。謝謝你們！