Aggregator

OpenSSL 今天公告了一個極度嚴重的漏洞（CVE-2014-0160），被稱為「Heartbleed」，而他確實也如同心臟噴出血般嚴重。這個漏洞能讓攻擊者從伺服器記憶體中讀取 64 KB 的資料，利用傳送 heartbeat 的封包給伺服器，在封包中控制變數導致 memcpy 函數複製錯誤的記憶體資料，因而擷取記憶體中可能存在的機敏資料。記憶體中最嚴重可能包含 ssl private key、session cookie、使用者密碼等，因此可能因為這樣的漏洞導致伺服器遭到入侵或取得使用者帳號。

詳細的分析可以參閱 existential type crisis : Diagnosis of the OpenSSL Heartbleed Bug

• 軟體名稱：OpenSSL
• 影響範圍：1.0.1 至 1.0.1f / 1.0.2-beta ~ 1.0.2-beta1
• 修復版本：1.0.1g / 1.0.2-beta2
• 影響系統版本
  • Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
  • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
  • CentOS 6.5, OpenSSL 1.0.1e-15
  • Fedora 18, OpenSSL 1.0.1e-4
  • OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
  • FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
  • NetBSD 5.0.2 (OpenSSL 1.0.1e)
  • OpenSUSE 12.2 (OpenSSL 1.0.1c)
• 影響服務：HTTP、SMTPS、IMAPS、POP3S 等使用 OpenSSL 之服務

OpenSSL 的公告如下：https://www.openssl.org/news/secadv_20140407.txt

要如何測試自己的網站有沒有這樣的漏洞呢？可以利用以下的網站或工具直接查詢。

• Heartbleed test http://filippo.io/Heartbleed/

直接輸入 Domain 即可查詢，例如「fbi.gov」。

• 自我測試工具 http://s3.jspenguin.org/ssltest.py （或 http://pastebin.com/WmxzjkXJ）

使用方法直接執行「python ssltest.py ifttt.com」，或是用「-p」指定特定 SSL 連接埠。畫面上會顯示出記憶體資料，可能內含機敏資料例如 private key、session cookie 等。

原始碼如下：

• 自我測試工具 https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl

使用方法直接執行「perl check-ssl-heartbleed.pl mail.XXXXXX.gov.tw:443」，可在網域名稱後指定特定 SSL 連接埠。

使用說明：

如果發現自己的伺服器有這樣的漏洞，該怎麼辦呢？

1. 確認自己的 OpenSSL 版本是否在受害範圍
2. 使用 ssltest.py 檢測工具檢測是否含有漏洞
3. 更新 OpenSSL 至 1.0.1g 或 1.0.2-beta2
4. 重開所有與 OpenSSL 函式庫相關之服務
5. 重新產生 SSL Private Key (因為 Private Key 可能藉由漏洞外洩)
6. 將網站舊憑證撤銷
7. 清除所有目前網頁伺服器上的 Session （因為可能遭到竊取）
8. 必要時更換網站內使用者密碼，或是密切追蹤網站是否有帳號盜用的情況發生

詳細討論與建議可以參考 Heartbleed: What is it and what are options to mitigate it? http://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it

真的會有攻擊者利用這樣的攻擊手法嗎？目前在烏雲 wooyun平台上已經滿滿的資安研究員開始回報網站含有 OpenSSL 漏洞。也有駭客在嘗試撰寫更有效的攻擊利用程式，想要藉此把平常打不下來的網站一舉攻陷。

怎樣的站台會是重點目標呢？含有會員機制的網站特別如此，例如 Web Mail、社群網站等等。因此不少企業要多注意了，例如全世界最大的社群網站 Facebook、SlideShare、台灣知名電信公司網站、社交平台、網路銀行、NAS，都會在這波的攻擊範圍之內。如果沒有儘速修復，等到更有效的攻擊程式出現，就真的等著失血了。

就連 OpenSSL 這種歷史悠久而且重要的函式庫，都可能犯這種基本的 C 語言程式設計錯誤，老舊的程式碼一定有不少陳年遺毒，如果沒有徹底清查，類似的心臟噴血事件會不斷上演。大家快點止血吧！

還記得在上一篇 HTTP headers 的資安議題 (1) 文章中，我們提到了多種資安相關的 HTTP headers 嗎？接下來的幾篇文章我們會介紹幾個專門對付 XSS 的 HTTP headers，首先就由 Content-Security-Policy 打頭陣。

Content-Security-Policy（以下簡稱 CSP）是從 2010 年被提出來的一項 Web 規格，主要目的是用來防止 Cross-Site Scripting（以下簡稱 XSS）跟網頁樣式置換（例如科技部被惡搞就是一個最好的例子）。經過五年發展，CSP 1.0 已從 W3C 的 TR (Technical Report) 變成 Candidate Recommendation，應該不久就會將成為 W3C 推薦標準。新的 CSP 1.1 則仍在草案階段。

CSP 家族龐大，總共有三個類別，六個項目：

• Content-Security-Policy
• Content-Security-Policy-Report-Only
• X-Content-Security-Policy
• X-Content-Security-Policy-Report-Only
• X-WebKit-CSP
• X-WebKit-CSP-Report-Only

在 CSP 發展初期，主流瀏覽器並未全部依照同一標準來開發，因此發展成這三種類別。目前由於 CSP 1.0 即將成為標準，大多數瀏覽器已支援 Content-Security-Policy 這個類別，因此狀況已逐漸收斂。主流瀏覽器的支援列表如下圖：

從列表中可看到，只要使用 Content-Security-Policy 與 X-Content-Security-Policy 就已有很高的覆蓋率，除非要支援 Safari 6，否則不用特意使用 X-WebKit-CSP。更詳細的瀏覽器支援列表可參考 Can I use。

• 載入來源白名單

  宣告一組受信任的白名單與資源種類（如 JavaScript, CSS, image 等等），使瀏覽器只能從此白名單中載入資源，藉此防止攻擊者從外部引入含有惡意程式碼的資源。

  例：Content-Security-Policy: default-src ‘self’; script-src ‘self’ http://js.devco.re; style-src ‘self’ http://css.devco.re; img-src ‘self’ data:; frame-src ‘none’

  效果：限定 script 資源只能從 http://js.devco.re 載入；限定 style 資源只能從 http://css.devco.re 載入；限定 img 只能從相同 domain 載入，並且支援 data scheme；限定 frame 不能從任何來源載入；除了 script、style、img、frame 之外的資源，則只能從同樣 domain 以及同樣協定的來源載入。

• 禁止 inline 程式碼

  一般人開發網站時為求便利，經常會在 HTML 中寫入一些 inline 程式碼，但攻擊者意圖入侵網站時也常用此手法。然而瀏覽器其實無法分辨這些 inline 程式碼究竟是開發人員寫的，還是攻擊者植入的。因此 CSP 乾脆強迫開發者必須把所有 inline 程式碼移到外部檔案，完全杜絕在 HTML 中出現 inline 程式碼的狀況。因此除非你在 CSP 宣告時有註明 ‘unsafe-inline’，否則 CSP 預設禁止使用 inline script 或 inline CSS。

  例：Content-Security-Policy: default-src ‘self’; script-src ‘unsafe-inline’

• 禁止 eval 函式

  eval() 對許多開發者來說一直是個非常方便的函式，然而若缺乏資安觀念，使用此函式時很可能會導致潛在的 XSS 風險。因此除非你在 CSP 宣告時有註明 ‘unsafe-eval’，否則 CSP 預設禁止使用 eval() 函式。

  例：Content-Security-Policy: default-src ‘self’; script-src ‘unsafe-eval’

• 防止 sniffer

  由於 CSP 可指定載入資源時強制使用 https 協定，因此可降低被 sniffing 的機率。

  例：Content-Security-Policy: default-src http://devco.re; img-src https:

  效果：限定圖片只能從 https 協定載入，不限定 domain。而除了圖片之外的資源則可從任意來源載入。

下面這一段程式碼，使用 default-src * 讓相關資源可正常顯示：

接下來我們將 php header 的那一行程式碼修改如下並且 reload 瀏覽器頁面：

使用 CSP 限制 img 與 frame 的來源種類後，我們可以從上圖 Chrome Inspector 的紅字觀察到，網站的圖片與 iframe 影片已被瀏覽器擋掉，無法載入。

如果擔心直接使用 CSP 會影響網站營運，但又想嘗試 CSP，可以先使用 Content-Security-Policy-Report-Only，示範如下：

由上圖可以看到，此 header 不會直接阻擋不符合 CSP 規範的資源，但是會根據使用者所違反的規則發送相對應的 POST request 至指定的 URI，發送內容如下：

由發送內容可看出這個 request 因為違反了「img-src https:」規則而將「http://devco.re/」這個來源擋掉。經由此方式，可一邊修改網站一邊觀察是否仍有不符合 CSP 規範之處，等到所有違規的內容都修正完畢後，再將 CSP 套用到正式上線環境。

由於宣告方式非常多種，在這邊就不一一條列，若有興趣可前往 Content Security Policy Reference & Examples、Using Content Security Policy - Security | MDN 等網頁，有更完整的使用情境與範例可供參考。另外也有 Slide (by Ben Vinegar) 跟 YouTube 影片 (by Adam Barth) 可參考。

目前採用 CSP 的案例較少，比較知名的使用案例是 GitHub，在 2013 年 4 月 GitHub 還寫了一篇專文公告表示他們已開始採用 CSP。另外一個案例廠商可能較廣為人知，是在 2013 年當紅的免費儲存空間 MEGA。兩個案例的實際內容可見於下圖：

另一項知名使用案例是 Google 明定開發 Chrome Extension 時必須使用 CSP，以追求更高的安全性。Mozilla 也在 MozillaWiki 開了一頁存放相關技術細節。若您想觀察其他使用案例，可使用 Chrome Inspector 或 curl 觀察以下幾個網站：LastPass，Twitter，1Password。

• directives 後面不需加冒號

  錯誤：default-src: ‘self’

  正確：default-src ‘self’

• directives 之間以分號區隔

  錯誤：default-src ‘self’, script-src ‘self’

  正確：default-src ‘self’; script-src ‘self’

• 多個 source 之間僅以空白區隔

  錯誤：default-src ‘self’; img-src ‘self’, img1.devco.re, img2.devco.re

  正確：default-src ‘self’; img-src ‘self’ img1.devco.re img2.devco.re

• 某些 source 必須加冒號（https:、data:）

  錯誤：default-src ‘self’; img-src ‘self’ https data

  正確：default-src ‘self’; img-src ‘self’ https: data:

• 某些 source 必須用單引號括起來（’none’、’self’、’unsafe-inline’、’unsafe-eval’）

  錯誤：script-src self unsafe-inline unsafe-eval

  正確：script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’

使用 CSP 可以有效提升攻擊難度，讓許多常見的 XSS 攻擊失效，是一個非常推薦開發者使用的 HTTP header。但由於目前的開發者在 HTML 裡面寫 inline script 及 inline CSS 的比例非常高，同時也有一些網路服務預設都需要使用 inline script（例如 Google Analytics，相關解法可參考這裡），因此要享受這樣的安全之前，可能需要先付出許多時間與心力將網站大幅整理，套用 CSP 規範後網頁才能正常運作。

最近身邊的朋友不斷的收到 Gmail 中 Google 的警告：

駭客間的戰爭已經不只是個人對個人，而已經擴大成國家對國家。一個國家為了獲取他國的機密文件、情報、個人資料等，都會想盡各種辦法入侵帳號、寄送惡意郵件、釣魚盜取密碼等。而身為受害者的我們能做什麼呢？Google 官方提出的建議是：加強密碼安全、注意登入 IP 位址、更新自己使用的軟體、開啟二階段驗證。當然有良好的資安意識才是更重要的。

正好今天收到一個簡單的案例，提供給各位參考。

在信箱中躺著一封很像是國外客戶的信件「Company Profile / Order Details」。內容看起來也很正常，並且附上了公司的基本資料為附加檔案。

點開附件，會發現畫面先跳了 JavaScript 警告視窗後，隨即導向到 Google 登入頁面。

注意看，這個登入頁面是真的嗎？有沒有發現畫面上的「Stay signed in」前面的勾變成方框了？瀏覽器上的網址也是在本機的位址。想想看，怎麼可能點了附件之後，跳轉到 Google 登入畫面？

讓我們看一下原始碼，會發現他的 form 被改成一個奇怪的網址，看起來就是惡意網站。其餘網頁的部份都是從 Google 真實的登入頁面抓取下來修改的。因此只要一不注意，就會以為是真的 Google 登入畫面而輸入帳號密碼。

節錄部分 code 如下：

發現了嗎？其中 form 的 action 欄位被取代成「http://cantonfair.a78.org/yahoo/post.php」，而這個頁面會直接接收受害者輸入的帳號密碼，並且自動跳轉到真正的 Google 登入頁面。攻擊者從 a78.org 這個網站中直接取得所有被駭的人輸入的帳號密碼。

這是一個很簡單、典型、又易被發現的釣魚案例。如果一時不察不小心輸入了帳號密碼，下次帳號被盜的就是自己。建議大家在收取信件的時候遵循幾大原則：

1. 不隨便開啟附加檔案：附件常夾帶惡意程式、執行檔、惡意文件、釣魚網頁等，切勿隨便開啟。可使用 Google Docs 開啟附件文件防止惡意文件攻擊 Adobe PDF Reader、Microsoft Office 等程式。更常有把惡意程式加密壓縮後寄出，在信中附上密碼，借此規避防毒軟體的偵測，不可不慎。
2. 注意信件中的超連結 URL：釣魚信件常在超連結中使用惡意網站的 URL，在點選之前務必仔細檢查，更要小心「Google」及「Goog1e」之類的英文數字差異。
3. 注意信件中的語氣：有的時候攻擊者仿冒你身邊可信任的人寄信給你，但是語氣、用詞要非常精準。如果出現了「尊敬的用戶您好」你就會發現這個應該不太像是台灣本土的信件用語。
4. 不在信件中夾帶機敏資料：信件是不安全的，切勿在信中提到帳號、密碼、個資等機密資料。
5. 不回應陌生郵件：郵件中會夾帶自己的 IP 位址，回應信件可能讓攻擊者得到這些資料。
6. 使用安全的郵件軟體：若使用安全的郵件軟體、平台，例如 Gmail，遇到惡意郵件時，會即時阻擋並且警告用戶。如果使用自己的郵件軟體，就要特別注意釣魚等攻擊。

電子郵件的攻擊已經成為滲透攻擊主要的手法之一，不少國際資安事件都是肇因於惡意郵件。例如 2013 年韓國 DarkSeoul 事件，以及竄改交易匯款資料郵件詐取匯款等。身為目標的我們更要時時注意使用電子郵件時的安全事項。

使用第三方套件節省開發時間，已經是整個資訊產業的慣例。但是很多管理者可能不知道，使用第三方套件到底需要擔負多大的資安風險。你確定你用的套件是安全無虞的嗎？是否有經過嚴謹的安全測試？若有安全漏洞引爆，是否有廠商可以負責維護修補？廠商開發的程式碼品質是否穩定？這些都是在使用之前必須要考慮的。

在服務眾多客戶之後，我們深知這些問題的嚴重性。以下我們將就幾個經典的案例來說明使用第三方套件所要擔負的風險，並且分享我們對於第三方套件的安全建議。

程式碼的品質直接決定了系統的安全性。如果一個套件有以下幾點因素：

1. 程式開發已久難以修改
2. 開發人員無安全觀念
3. 大量整合外部套件，無法控管每個套件安全

可能就因為程式碼難以修改，形成漏洞百出的程式架構。若是之後陸續發生安全問題，儘管不斷的修補漏洞，但卻會因為程式碼的設計、架構等因素，造成日後依舊陸續有安全疑慮。

DedeCMS 是知名的內容管理系統，不少公司拿此套件架設網站、部落格等。但在這幾個月，在「烏雲平台」上陸續有人揭露 DedeCMS 的漏洞。包括大量各種 SQL Injection、Cross-Site Scripting 弱點等等，甚至還包括 Command Execution 問題。如果沒有即時修正這些問題，小則造成用戶帳號被盜，大則造成整台主機被入侵，取得作業系統權限。

什麼系統沒被找到漏洞過呢？有那麼嚴重嗎？但該系統已經不只一次出現重大漏洞導致企業遭到入侵，在今年一二月份更是遭揭露多達十數個高風險 SQL Injection 資料庫注入漏洞。此現象凸顯該套件的設計並未經過安全測試，並且採用不安全的程式撰寫方式，未來可能會有更多隱含的漏洞釋出。

在平台中搜尋關鍵字「DedeCMS」，會發現漏洞提報的次數相當多，在漏洞的評論中也有不少技術人員進行討論。但更多的疑惑是為什麼 DedeCMS 會一再的發生資安問題。例如以下漏洞：

• Dedecms某命令執行漏洞
• DedeCMS全版本通殺SQL注入(真正的無任何限制附官方測試結果)
• DedeCMS全版本通殺SQL注入(無任何限制)
• Dedecms某命令执行漏洞（续）

而於另一個「Sebug 安全漏洞信息庫」也可以看到不少 DedeCMS 的蹤影。

如果官方在第一時間就能接獲通報、了解問題並修正解決，提供更新程式給客戶更新，那安全的風險會小些。但在官方尚未釋出更新的這段時間，網站將完全的暴露在風險當中。有心人士看到套件的漏洞陸續被揭露，也會更有興趣尋找使用該套件的網站攻擊。

Joomla! 是另一套國際非常知名的 CMS 系統，因為其便利性，很多企業、學校、政府單位，都採用此套件建立網站。透過 Google Hacking 方式可以找到台灣非常多網站都使用 Joomla! 架站。

但是如果今天這個系統出了問題呢？「Joomla!」因為外掛、套件眾多，也經常成為漏洞發掘的對象。在 2014/02/05，國外釋出了一個 SQL Injection Exploit，可以導致網站帳號密碼直接被導出。

官方安全公告：http://developer.joomla.org/security/578-20140301-core-sql-injection.html

Secunia: Joomla! Multiple Vulnerabilities http://secunia.com/advisories/56772/

Exploit 位址：http://www.exploit-db.com/exploits/31459/

值得注意一看的是官方公告，上面標註著漏洞回報時間以及修補時間。2014/2/6 接獲回報，2014/3/6 修復。在這整整一個月的時間之內，所有適用版本內的 Joomla! 網站都將受此漏洞影響。因此套件廠商的反應修復速度越慢，顧客暴露在風險之中的時間越長。

這樣的情境你是否熟悉？

公司有一套客製化的系統需要建置，但是因為公司內部開發人員不足，因此把這個系統外包出去給廠商做。貨比三家不吃虧，比了 A B C 三家，發現 A 家最便宜實惠，交貨時間又短。決定就把這個系統發包給 A 廠商做。半年過去了，這個廠商順利交貨結案。

一年過後，發現這個系統竟然遭到入侵，主動攻擊內部其他伺服器。「不是有買防火牆嗎？怎麼還會被入侵？」老闆說。這可嚴重了，馬上找廠商來刮一頓。沒想到，A 廠商表示，該案已經順利結案，維護期也已經過了，沒辦法提供協助，除非繼續簽訂維護合約。問題總得解決，簽訂了維護合約之後，A 廠商也協助把病毒砍掉了。圓滿結束？事情有那麼簡單嗎？

過了兩天，系統又開始攻擊其他伺服器。「病毒不是已經砍掉了嗎？」老闆說。問題在哪大家應該都很清楚。在尋找資安廠商協助之下，發現主機是因為 A 廠商設計的系統含有漏洞，導致 SQL Injection 問題，遭攻擊者利用植入惡意程式。A 廠商百般無奈，摸摸鼻子把這個漏洞修補起來。又過了兩天，再度遭到入侵。看了看，發現又是另一個 SQL Injection 問題。在幾次與攻擊者的不斷角力之下，終於好像把問題都修完了。

過了一週，系統再度有惡意程式的蹤跡，A 廠商也無能為力。資安廠商表示，買這個就對了！在陸續被迫買了防火牆、WAF、IDS 等設備後，雖然問題貌似改善，但系統仍然零星有入侵事件發生。公司只好「斷然處置」，等待下次預算，另請廠商重新開發系統。

• 問題 1：該系統是否還有其他漏洞？
• 問題 2：公司的處置是否正確？
• 問題 3：A 廠商的其他客戶是否有類似的問題？
• 問題 4：不是有買資安設備？為什麼還會有資安事件？
• 問題 5：公司該如何自保？
• 問題 6：廠商該如何自保？

想一下以上各點問題。

• 問題 1：該系統是否還有其他漏洞？

如果一個在開發時期就沒有注意安全的系統，很有可能有更多不為人知的漏洞。如果被動依賴資安事件，發生一件修一個漏洞，那是永無止盡的。正確的方式應該是直接針對 A 廠商的原始碼進行黑箱滲透測試、白箱源碼檢測 (Code Review)，才能快速找出所有風險。

• 問題 2：公司的處置是否正確？

「貨比三家不吃虧」，節儉確實是美德，但是在資訊產業中，越便宜的系統可能代表著更多的 cost down，除了犧牲掉品質之外，可能帶給企業更多損失。在資安事件發生時，一定要找原本維運廠商負責，並且與資安顧問公司配合，協助廠商把問題解決。

• 問題 3：A 廠商的其他客戶是否有類似的問題？

羅馬不是一日造成的，不安全的系統也不是一個漏洞造成的。廠商通常是做出一份系統，客製化販賣給不同的企業用戶。如果在建置的過程中沒有注意安全問題，今天這家客戶有這個漏洞，別的客戶一定也會有。因此如果採用了不良的廠商實作的系統，下一個被駭的可能就是自己。

• 問題 4：不是有買資安設備？為什麼還會有資安事件？

「不是有買防火牆嗎？怎麼還會被入侵？」是很多傳統思維企業的共同心聲。防火牆不是萬靈丹，駭客也絕對不是電腦。並不是完全依賴資安設備就能夠避免資安問題。在駭客的手法中，更多是如何繞過各種防禦設備手段，甚至有些資安設備本身竟然含有資安弱點，企業反而因為資安設備導致系統被入侵。

正確的思維應該是從人開始做起，建立正確的資安觀念、資安思維，學習駭客的思維。建立正確的系統開發流程、建立正確的資安事件處理流程。尋找信譽良好的資安顧問廠商，定期針對企業內部各系統進行滲透測試、弱點掃描。安全的建立絕非一蹴可及，唯有一步步踏穩才能走得更遠。

• 問題 5：公司該如何自保？
• 問題 6：廠商該如何自保？

請看下一個章節「建議對策」。

一個安全的系統，絕對是由基礎建設開始，每個環節都兼顧到安全的設計，並且定期稽核程式碼安全，使用正確安全的方式開發。如果系統開發初期就沒有兼顧安全，後期不管怎麼修補，都還是會有漏洞讓攻擊者有機可趁。

企業該如何自保？使用 OpenSource 第三方套件或者是系統委外開發，是企業無可避免的。如果是第三方套件，平時可以多加注意套件的資安消息，如果一有新的漏洞被發現，將可以在第一時間應變。若沒有足夠人力密切注意資安消息，也可以委請資安顧問廠商協助，在得知資安消息的第一時間通報企業。委外開發的系統，企業可以要求廠商提出專業公正第三方資安公司進行檢測，並且提出安全報告，證明該系統有經過滲透測試等安全檢測，保障雙方的權利。

如果系統已經被入侵了，或者是被揭露了安全漏洞，該如何自保呢？在漏洞大量揭露的情況下，系統更會成為攻擊者的目標。因此要務必密切注意使用該套件的伺服器狀況，並且遵循以下原則：

• 密切注意官方的更新程式並立即更新
• 此台伺服器的帳號密碼切勿與他台共用
• 將此台伺服器與其他伺服器隔離，避免遭入侵時受害範圍擴大
• 異地備份伺服器的系統記錄，並定時檢閱記錄，觀察是否有可疑行為
• 考慮採用 Web Application Firewall (WAF)、ModSecurity 伺服器安全模組，增加攻擊難度
• 重新評估使用遭入侵套件的必要性以及安全考量，避免成為企業的隱含風險

使用第三方套件加速開發節省成本的同時，務必也要考慮安全的問題，才不會因小失大，造成企業更大的損失。同時企業也必須增加資安的素養以及了解攻擊者的思維，別讓自己的企業成為下一個資安事件報導的對象。

New standards for cyber security have been developed and agreed by operators of critical power infrastructure in New Zealand.

隨著駭客攻擊事件日益漸增，原本經常被大眾所忽視的網站資安問題，現在已經逐漸受到重視。但是，許多企業主或開發人員雖然很想強化網站的安全性，卻不知道該如何從何著手。

企業主通常想到的改善方案是添購資安設備，希望可以一勞永逸。我們姑且先不談「資訊界沒有永遠的安全」這件事，企業光是要買到有效的資安設備就是一件令人頭痛的事情，不但要花許多時間聽取廠商的簡報，耗費大筆的經費採購，購買之後還要請員工或原廠技術人員協助調校、設定或教學，否則買了等於沒買。

而對於技術人員來說，若要強化網站安全性，必須先了解駭客如何攻擊，才知道如何建立根本性的防禦機制。但是企業主通常捨不得送員工去參加專業的教育訓練，台灣員工拿的 22k 低薪也低得常常令人捨不得花錢去上課。

如果有一種方式可以增強網站的基本安全性，而且不需要花大錢，又可以讓開發人員不用大幅度變更程式，應該是個皆大歡喜的方案？

有的！目前各家瀏覽器 (Google Chrome、Firefox、Safari、IE) 其實已經支援許多種資安相關的 HTTP headers。開發人員若在伺服器設定加入某些 headers，瀏覽器收到 response 時就會執行相對應的防禦機制，如此一來可直接提升網頁應用程式的基本安全性。這些 HTTP headers 通常也已被許多常見的 framework 納入爲基本功能，即使開發人員不清楚如何修改伺服器相關設定，也可以依靠 framework 提供的方式來使用這些 headers。因此使用這些 headers 來提升網站安全性就成爲頗具 CP 值的方式。

目前最常見的資安相關 HTTP headers 可參考 OWASP 網站 所條列的內容：

• Content-Security-Policy (X-Content-Security-Policy、X-Webkit-CSP 都是同一系列)
• Strict-Transport-Security
• X-Content-Type-Options
• X-Frame-Options
• X-XSS-Protection

還有一些其他的資安相關 HTTP headers 也值得注意：

• Access-Control-Allow-Origin
• X-Download-Options
• X-Permitted-Cross-Domain-Policies

最後有一項比較特別的是 Cookie 的安全設定，由於 Cookie 也是 HTTP headers 的一部份，因此本文也將其列出：

• Set-Cookie: HttpOnly
• Set-Cookie: Secure

上述 headers 的數量是不是稍微超過你的想像？其實這些技術早已被很多大公司採用，像是 Google、Facebook、Twitter 等常見的網路服務都可看到這些 headers 的蹤影。下面這張圖片使用 Chrome 的 Inspector 來觀察 Twitter 的 HTTP response 內容：

從畫紅線的部分我們可看到 Twitter 在 Cookie 設定了 Secure 與 HttpOnly 這兩個屬性，並且採用了 Strict-Transport-Security、X-Content-Type-Options、X-Frame-Options、X-XSS-Protection 這幾種 headers。

如果覺得用圖形界面太麻煩，也可以使用 command line 的工具來觀察。下面這張圖片使用 curl 來觀察 Facebook 的 HTTP response 內容：

目前這些資安相關的 HTTP headers 想解決的問題主要可分為以下五大類：

• 防禦 XSS (Cross Site Scripting)：
  • Content-Security-Policy
  • Set-Cookie: HttpOnly
  • X-XSS-Protection
  • X-Download-Options
• 防禦 Clickjacking：
  • X-Frame-Options
• 強化 HTTPS 機制：
  • Set-Cookie: Secure
  • Strict-Transport-Security
• 避免瀏覽器誤判文件形態：
  • X-Content-Type-Options
• 保護網站資源別被任意存取：
  • Access-Control-Allow-Origin（此 header 若設定錯誤會適得其反！）
  • X-Permitted-Cross-Domain-Policies

其中 XSS 與 Clickjacking 是目前常見的攻擊手法，尤其 XSS 目前仍高居 OWASP Top 10 2013 的第三名，其嚴重性可見一斑。而在我們執行過的許多滲透測試案之中，被我們找出 XSS 弱點的網站高達九成！實在是不能輕忽這些問題。若能降低這些手法攻擊成功的機率，企業的利益就能有更多的安全保障，客戶對企業的信賴亦會更加穩固。

這麼簡便的基本防禦方式，理當廣為企業所採用，因此我們針對 Alexa Taiwan Top 525 中挑出 513 個可正常使用的網站（咦？一般不是 Top 500 嗎？我沒騙你，真的有 525），調查這些網站是否使用某些常見的 HTTP headers。結果相當令人失望，許多網站都未採用這些 headers。統計數據如下圖：

從統計結果中可發現最多人使用的 HttpOnly 只有 21.25%，排名第二的 X-Frame-Options 也只有 7.80%。而且這些數據尚未將 Google、Twitter 等大公司排除，若將前述國際公司排除後，這些比率恐怕會更低。

不過在上述網站中有不少入口網站、漫畫網站、色情網站，或是公司並非台灣企業，無法反應台灣的使用狀況。恰好在 2012 年 10 月台灣有許多網路服務公司一同成立了 TIEA 台灣網路暨電子商務產業發展協會，目前網站上的會員名單中有 116 個會員，其中不少頗具代表性，正好可觀察這些公司營運的網站是否有採用這些 headers。統計數據如下圖：

很可惜地，所有 headers 的採用率比起上一份數據都還要低。除非公司網站僅使用靜態頁面，網站上沒有任何商業邏輯、帳號、個資，否則應該都要使用合適的 headers 為你的資安防禦工事多築一道牆。

而且由於 meeya 目前沒有正式官網，是直接使用 facebook 粉絲頁作為官網，因此 Content-Security-Policy、Set-Cookie Secure、Strict-Transport-Security、X-Content-Type-Options、X-Frame-Options、X-XSS-Protection 等六項 headers 的統計數量都還要再減一，頓時 Content-Security-Policy 與 Strict-Transport-Security 的總數量皆降至 0 個。此狀況顯示出，即使是在一些台灣主流的網站中，相關營運人員在資安領域仍有許多努力與學習的空間。

許多台灣企業經常顧著衝業績、開發新功能、趕著讓新服務上線，卻忽略了非常重要的基礎資安建設，往往是在遭到攻擊後才大呼損失慘重，甚至是已被滲透了而不自知，其企業利益與民眾個資的保障皆相當令人擔憂。

接下來本文的續作我們會分幾個篇章詳談各種 headers 的使用方式並介紹實際案例，下一篇將會探討專門防禦 XSS 的 HTTP headers，敬請期待！等不及的朋友們就請先用上面的一些關鍵字自行上網查詢囉！

歡迎來到我們的技術文章專欄！

今天我們來談談「廣告顯示手法」。不少廣告商為了要增加廣告的曝光以及點擊率，會使用各種手法強迫使用者顯示廣告。例如彈出式視窗、內嵌廣告、強制跳轉等等。但這樣的手法有什麼好提的呢？今天有一個很特別的案例，讓我們來看看一個網站「1kkk.com 極速漫畫」。

這是一個常見的網路漫畫網站，接著點擊進去漫畫頁面。 網站中充斥著煩人的廣告，並且突然一閃而過 Safari 的「閱讀列表」動畫。怎麼會突然這樣呢？讓我們打開「閱讀列表」一探究竟。

打開閱讀列表之後，我們赫然發現裡面被加了非常多廣告的頁面！

可以看以下影片示範：

這是怎麼做到的呢？就是一種利用 JavaScript 控制滑鼠點擊的變形應用。點選「網頁檢閱器」或是「開發者工具」，會看到一段奇怪的 JavaScript 控制滑鼠的點擊行為。

分析節錄後的 code 如下：

利用「initMouseEvent」模擬滑鼠的點擊，在 URL 上按下 Shift 鍵點擊。在一般瀏覽器中是「開啟新視窗」，在 Safari 中則是「加入閱讀清單」了，因此形成廣告視窗不斷加入閱讀清單的現象。廣告商利用這種手法增加廣告的點擊率，只要瀏覽器沒有安裝阻擋廣告的套件或者是阻擋「彈出式視窗」，你就會成為流量的貢獻者。

經過我們的測試，Internet Explorer、Mozilla Firefox 不會受這類攻擊影響，Google Chrome、Opera 則會被內建的 Pop-up 視窗阻擋功能擋下。但若是直接模擬點擊，則全數瀏覽器都會受影響導向至 URL。雖然這種類型的攻擊不會造成實質上的損失跟危害，但若是結合其他惡意手法將可以造成攻擊。例如透過網站掛碼將使用者導向至惡意網站等等。

若要避免此類型攻擊，有以下幾個建議方案：

1. 安裝 NoScript 類型套件，僅允許可信賴的網站執行 JavaScript
2. 開啟「彈出式視窗」阻擋功能，並將網站安全性等級提高。
3. 安裝 AdBlock 等廣告阻擋套件（但會影響網站營收）
4. 使用最新版本瀏覽器以策安全

網頁型的攻擊越來越多樣化，除了依賴瀏覽器本身的保護並輔以第三方安全套件之外，更需要使用者本身的安全意識，才能安心暢快的瀏覽網路！