The Will Will Web

最近 Google 推出一套免費的 Web 安全評估工具，叫做 ratproxy，這套工具可以檢測、分析您的網站是否有安全性漏洞或網頁是否有被入侵，目前可支援 Linux, FreeBSD, MacOS X, 與 Windows (Cygwin) 等執行環境（反正就是 Unix-like 的環境啦）。

RatProxy 可偵測到的漏洞包括 Cross-site Scripting (XSS, 跨網站指令碼)、指令碼惡意置入(script inclusion issues), 惡意網頁內容(content serving problems), insufficient XSRF 以及 XSS 防護(XSS defenses) 等。

若要在 Ubuntu 的環境下執行的話，必須要先安裝以下套件才能將 ratproxy 編譯成功：

apt-get install make gcc build-essential libssl-dev ca-certificates

下載、解壓縮、編譯：

wget http://ratproxy.googlecode.com/files/ratproxy-1.51.tar.gz
tar zxf ratproxy-1.51.tar.gz
cd ratproxy
make

編譯成功以後，就可以使用了，功能挺多的：

# ./ratproxy -h
ratproxy version 1.51-beta by <lcamtuf@google.com>
./ratproxy: invalid option -- h
Usage: ./ratproxy [ -w logfile ] [ -v logdir ] [ -p port ] [ -d domain ] [ -P host:port ] [ -xtifkgmjscael2XCr ]
   -w logfile    - write results to a specified file (default: stdout)
   -v logdir     - write HTTP traces to a specified directory (default: none)
   -p port       - listen on a custom TCP port (default: 8080)
   -d domain     - analyze requests to specified domains only (default: all)
   -P host:port  - use upstream proxy for all requests (format host:port)
   -r            - accept remote connections (default: 127.0.0.1 only)
   -l            - use response length, not checksum, for identity check
   -2            - perform two, not one, page identity check
   -e            - perform pedantic caching headers checks
   -x            - log all XSS candidates
   -t            - log all directory traversal candidates
   -i            - log all PNG files served inline
   -f            - log all Flash applications for analysis (add -v to decompile)
   -s            - log all POST requests for analysis
   -c            - log all cookie setting URLs for analysis
   -g            - perform XSRF token checks on all GET requests
   -j            - report on risky Javascript constructions
   -m            - log all active content referenced across domains
   -X            - disruptively validate XSRF, XSS protections
   -C            - try to auto-correct persistent side effects of -X
   -k            - flag HTTP requests as bad (for HTTPS-only applications)
   -a            - indiscriminately report all visited URLs

由於 ratproxy 是屬「半自動」且「被動式」的偵測方法，使用 Proxy 的方式運作，並非主動連接到特定網站抓取所有網頁回來分析，所以啟動完該程式之後，會以 Proxy Server 的形式執行，你必須修改你瀏覽器的 Proxy 設定，將 Proxy 伺服器指定到 ratproxy 的 IP 與 Port（預設 ratproxy 啟動的 Port 埠號是 8080），才能讓 ratproxy 取得偵測的資訊，如下圖示：

若要啟動 ratproxy 伺服器，一段簡單的啟用指令如下：

./ratproxy -v /tmp/ratproxy -w ratproxy.log -d blog.miniasp.com -lextifscgjm -r

這代表你要將 ratproxy 服務啟動，預設監聽 Port 8080，並將偵測到的 Log 儲存在 /tmp/ratproxy/ratproxy.log 中，並且只分析連線到 blog.miniasp.com 網址的資料，並且將所有取得的網頁儲存成使用 -r 代表這個服務可以讓遠端主機使用（預設只會監聽 127.0.0.1 而已），如果你沒加上 -r 就無法用其他台機器連線。至於 lextifscgjm 這一串所代表的意義就請看 Help 說明吧。

最後，就是將取得的 ratproxy.log 產生報表網頁，並且查看你用 Browser 所逛過的網頁是否有潛在的安全風險或漏洞。你可以使用 ratproxy-report.sh 產生該網頁：

./ratproxy-report.sh ratproxy.log > report.html

產生的結果可以參考下圖：

相關連結

• ratproxy - passive web application security assessment tool
• RatProxy 說明文件

ApacheBench 工具程式是 Apache 網站伺服器軟體的一個附帶的工具軟體，專門用來執行網站伺服器的運行效能，特別是針對 Apache 網站伺服器 的效能分析。這支程式原本是用來檢測 Apache 網站伺服器(Web Server) 所能夠提供的效能，特別是可以看出 Apache 網站伺服器能提供每秒能送出多少網頁，當然的，也可以用在任何其他的網站伺服器，例如說：IIS 或 lighttpd。

你可以到 Apache HTTP Server 網站下載最新版，如果你要在 Windows 的環境執行 ApacheBench 可以直接下載 Win32 Binary 的版本就好，由於線上所提供的版本是 MSI 的封裝檔，安裝好之後也等同於在你的電腦內安裝了一套 Apache HTTP Server，如果你不需要多執行一套 Apache HTTP Server 的話，你可以在安裝好之後進入 C:\Program Files\Apache Group\Apache2\bin 目錄，找到 ab.exe 執行檔，複製出來後再移除 Apache 安裝即可，因為 ab.exe 是可以獨立執行的，不需要任何關連的 dll 檔。

底下是 ab.exe 的使用參數摘要說明，若要看詳細說明可以看這裡（或中文翻譯）：

C:\>ab -h
Usage: ab [options] [http://]hostname[:port]/path
Options are:
    -n requests     Number of requests to perform
    -c concurrency  Number of multiple requests to make
    -t timelimit    Seconds to max. wait for responses
    -p postfile     File containing data to POST
    -T content-type Content-type header for POSTing
    -v verbosity    How much troubleshooting info to print
    -w              Print out results in HTML tables
    -i              Use HEAD instead of GET
    -x attributes   String to insert as table attributes
    -y attributes   String to insert as tr attributes
    -z attributes   String to insert as td or th attributes
    -C attribute    Add cookie, eg. 'Apache=1234. (repeatable)
    -H attribute    Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
                    Inserted after all normal header lines. (repeatable)
    -A attribute    Add Basic WWW Authentication, the attributes
                    are a colon separated username and password.
    -P attribute    Add Basic Proxy Authentication, the attributes
                    are a colon separated username and password.
    -X proxy:port   Proxyserver and port number to use
    -V              Print version number and exit
    -k              Use HTTP KeepAlive feature
    -d              Do not show percentiles served table.
    -S              Do not show confidence estimators and warnings.
    -g filename     Output collected data to gnuplot format file.
    -e filename     Output CSV file with percentages served
    -h              Display usage information (this message)

而我經常使用的參數摘要如下：

1. 同時 10 個連線，連續點擊 10000 次 ( 每個 Request 執行完畢後都會自動斷線，然後再重新連線 )

ab -n 10000 -c 10 http://www.example.com/index.aspx

ab -n 10000 -c 10 -k http://www.example.com/index.aspx

3. 將測試的效能原始資料匯出成 CSV 檔

ab -e output.csv -n 10000 -c 10 http://www.example.com/index.aspx

   匯出的 output.csv 內容如下：

Percentage served,Time in ms
0,6.200000e+001
1,6.200000e+001
2,6.200000e+001
3,6.200000e+001
4,6.200000e+001
5,6.200000e+001
6,6.200000e+001
7,6.200000e+001
8,6.200000e+001
9,6.200000e+001
10,6.200000e+001
11,6.200000e+001
12,6.200000e+001
13,6.200000e+001
14,6.200000e+001
......

   上表所代表的每一列代表送出的百分比，第二個欄位是當下的 "Time per request" (每個要求所花費的時間)，單位是豪秒(millisecond)。

如何有效的檢視結果

壓力測試的核心在於如何分析結果，底下我用一個測試的結果說明每個欄位所代表的意義。如果你只要看重點的話，可以看 Failed requests、Requests per second、與 Time per request 這三個參數也就差不多夠了。其中的 Failed requests 的數量太高的話，很有可能代表你的 Web Application 的穩定度不夠，而導致使用大量要求時無法回應需求 。而 Request per second 代表你每表可送出的回應數有多少，代表你 Web Application 的承載量有多少（在不考慮頻寬限制的情況下）。

C:\>ab -d -e a.csv -v 1 -n 1000 -c 3 http://www.example.com/index.aspx
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.m-taoyuan.tw (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software:        Microsoft-IIS/6.0
Server Hostname:        www.m-taoyuan.tw
Server Port:            80

Document Path:          /index.aspx
Document Length:        25986 bytes

Concurrency Level:      3
Time taken for tests:   25.734375 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      26372000 bytes
HTML transferred:       25986000 bytes
Requests per second:    38.86 [#/sec] (mean)
Time per request:       77.203 [ms] (mean)
Time per request:       25.734 [ms] (mean, across all concurrent requests)
Transfer rate:          1000.72 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   4.4      0      15
Processing:    62   75   9.1     78     109
Waiting:       46   64   8.0     62     109
Total:         62   76   9.3     78     109

如上表顯示的結果來說明，我一個欄位一個欄位的講解如下：

• Server Software:    Web主機的作業系統與版本(若Web主機設定關閉此資訊則無)
• Server Hostname:  Web主機的IP位址(Hostname)
• Server Port:           Web主機的連接埠(Port)
• Document Path:     測試網址的路徑部分
• Document Length: 測試網頁回應的網頁大小
• Concurrency Level: 同時進行壓力測試的人數
• Time taken for tests: 本次壓力測試所花費的總秒數
• Complete requests: 完成的要求數(Requests)
• Failed requests:      失敗的要求數(Requests)
• Write errors:           寫入失敗的數量
• Total transferred:   本次壓力測試的總數據傳輸量(包括 HTTP Header 的資料也計算在內)
• HTML transferred:  本次壓力測試的總數據傳輸量(僅計算回傳的 HTML 的資料)
• Requests per second: 平均每秒可回應多少要求
• Time per request:  平均每個要求所花費的時間(單位: 豪秒)
• Time per request:  平均每個要求所花費的時間，跨所有同時連線數的平均值(單位: 豪秒)
• Transfer rate:         從 ab 到 Web Server 之間的網路傳輸速度

最後的 Connection Times (ms) 指的是壓力測試時的連線處理時間：

橫軸欄位的部分：

• min:       最小值
• mean:    平均值(正、負標準差)
• median: 平均值(中間值)
• max:      最大值

縱軸欄位的部分：

• Connect:     從 ab 發出 TCP 要求到 Web 主機所花費的建立時間。
• Processing:  從 TCP 連線建立後，直到 HTTP 回應(Response)的資料全部都收到所花的時間。
• Waiting:       從發送 HTTP 要求完後，到 HTTP 回應(Response)第一個 Byte 所等待的時間。
• Total:           等於 Connect + Processing 的時間（因為 Waiting 包含在 Processing 時間內了）

壓力測試的基本觀念

• 排除頻寬的限制
  • 做壓力測試通常不會考量「頻寬的限制」，所以一般來說不會將測試的主機擺在遠端機房、然後測試程式擺在公司內部的主機，而是會將壓力測試的 Client 跟 Web 主機擺在同一個網段下進行壓力測試。
  • 因為「頻寬」只要花錢就會有了，但是主機的承載量卻是有限的，從遠端進行壓力測試主要的限制是在「頻寬」而非「效能」，所以從遠端單點進行壓力測試毫無任何意義可言，這樣是測不出主機的效能極限的。
  • 如果你有能力與資源進行大規模（多點）壓力測試的話，透過遠端進行壓力測試才有意義。
• 壓力要循序漸進
  • 你不要一下字就執行同時連線數 100 人，而是要循序漸進的慢慢加同時連線數上去，才不會讓 Web Application 一下字承受過大的負載而導致效能的數據不正確（例如說 Failed requests 過高），但這只是建議，你也可以一下子操死你的主機，反正你在測主機的極限嘛！

參考網址：

• ApacheBench
• ab - Apache HTTP server benchmarking tool
• ab - Apache HTTP服务器性能测试工具 (簡體中文 GB2312 編碼)

基本上，網頁遇到「中文字」超過一行時都可以正常的斷字，只是若是英文字寫了一大串沒有空白的字，就會導致網頁版型被撐開，如下圖例就是因為網址過長而導致網頁被撐版，進而影響頁面的呈現。

IE 從 5.5 ~ 8.0 版的 CSS 都有支援一個 word-wrap 屬性，當你指定屬性值為 break-word 時就可以強迫瀏覽器進行斷字的動作，這樣就可以避免文字被斷行了。

不過要在 Firefox 中使用 word-wrap 就不可行了，一直到前天才正式發佈的 Firefox 3.0 也還是不支援 word-wrap 屬性，不過 word-wrap 屬性已經被編進 CSS 3.0 的規格中了，相信遲早有一天可以支援的。

不過在 Firefox 中也不是完全沒辦法，網路上有篇文章就有寫到如何在 Firefox 中實現自動斷字的方式，有興趣的可以上去看看。

我這裡摘要一下要達到目的必須的步驟：

1. 在 CSS 中定義一個 wordwrap 類別

.wordwrap
{
    word-wrap: break-word;
    -moz-binding: url('wordwrap.xml#wordwrap'); 

    display: block;
    overflow: auto;
}

這幾行 CSS 定義都是有意義的，內容這四行我大致解釋一下：

第一行：給 IE 看的，讓斷字產生。

第二行：給 Firefox/Mozilla 看的，透過 binding 的方式執行一段 JavaScript，當 Element 套用此 wordwrap 類別時讀取 wordwrap.xml 檔案，裡面有定義一組JavaScript程式可動態執行。

第三行、第四行：wordwrap.xml 裡面定義當 overflow 事件發生時執行一段程式讓文字斷行，所以 display 屬性一定要設定成 block 才有可能引發 overflow 事件（使用 inline 是沒辦法的），而最後的 overflow 就設定成 auto 即可。

2. 新增一個 wordwrap.xml 檔案

<?xml version = "1.0"?>
<bindings xmlns = "http://www.mozilla.org/xbl" xmlns:html = "http://www.w3.org/1999/xhtml">
  <binding id="wordwrap" applyauthorstyles="false">
    <implementation>
      <constructor>
        //<![CDATA[
            
            var elem = this;

            elem.addEventListener('overflow',
                function()
                {
                    var exp = /<&#8203;\/*[&#8203;_\s="'\w]+>/g;
                    
                    var txt = elem.innerHTML;
                    var chars = txt.split('');
                    var newTxt = chars.join('&#8203;');                    
                    newTxt = newTxt.replace(exp, reconstructTag);                    
                    elem.innerHTML = newTxt;
                },false);
                
                function reconstructTag(_tag)
                {
                    return _tag.replace(/&#8203;/g, '');
                }

            //]]>
      </constructor>
    </implementation>
  </binding>
</bindings>

內容我就不詳述，請自行到 Emulating CSS word-wrap for Mozilla/Firefox 閱讀相關說明。

3. 最後，到你的 HTML 中會破版的那個標籤套上 wordwap 類別即可。

<span class="url wordwrap">一個非常長的網址.....</span>

在我的例子裡，套用之後在 Firefox 中的顯示效果如下：

就這樣三個步驟就可以達成完美、跨瀏覽器的自動斷字功能。這裡有個線上的 DEMO，你們可以用 Firefox 去看看執行的效果如何。

相關連結

• MSDN Library - word-wrap Attribute | wordWrap Property
• Cascading Style Sheets (CSS), Level 3 (CSS3)
• Emulating CSS word-wrap for Mozilla/Firefox

如果你在網站使用過多的 JavaScript 就很有可能會讓你的網頁反應時間拖的很長，因為瀏覽器在頁面顯示的過程中只要遇到任何 JavaScript 都會等他下載完畢或執行完畢才會繼續顯示下面的資料，即便你網頁已經下載完了也有可能因為 JavaScript 的關係而讓頁面遲遲不出現，所以在進行網站設計的時候需要特別注意這部分，尤其是較大型的網站。

在我之前的一篇文章加速前端網頁效能的14條規則中的第 6 點的 Move JS to the bottom 就是說這點，將所有 JavaScript Include 都移至網頁最下方，如果你不將 JavaScript 檔放到最下方其實還有另一個小技巧，就是在 JavaScript 的宣告標籤裡加上 defer 屬性：

<script type="text/javascript" src="common.js" defer="defer"></script>

加上這個屬性就等於跟瀏覽器宣告說「不要等我，請先繼續顯示網頁」的意思。

不過這可不能亂用喔，如果你載入的 JavaScript 中有使用到 document.write 或是會影響到網頁 DOM 物件的地方，就很有可能會造成網頁大亂！因為加上了 defer 屬性後，瀏覽器會在 JavaScript 下載完的時候執行，你會變得無法掌控這個 JavaScript 到底何時才會執行。

例如我之前就有試著將 funP 與 HEMiDEMi 的部落格外掛改成 defer，結果就導致全網站變成只有 funP 的 Icon 而已，而有時又變成 hemidemi 的 Icon，反正就是後面執行的直接蓋掉前面輸出的網頁內容，這都是 document.write 將網頁覆寫掉的原因。

之前推薦過一套 MultipleIE 工具可以在同一台電腦同時安裝 IE 3.0, 4.0, 5.0, 5.5, 6.0, 7.0 等不同的版本，非常適合用來做網站的瀏覽器相容性測試。不過最近又發現另一套瀏覽器相容性測試的工具，叫做 IETester，這套 IETester 只能測試 IE 5.5 以上的版本，不像 MultipleIE 可以測 IE 3.0, 4.0, 5.0，不過現在還在用 IE 3.0, 4.0, 5.0 的人類應該不多了吧。

使用 IETester 還可以測試到 IE 8.0Beta1 的版本喔，除了支援多國語言，還支援軟體自動更新的功能，且瀏覽網站的方式是使用頁籤(Tab)的方式進行，與 IE 7 的瀏覽方式類似，不過整個介面做的就像是 Office 2007 的介面一樣，是使用 Ribbon 的選單，可以看看下圖：

不過各位安裝好之後，第一次執行的畫面會被「誤判」為「簡體系統」，你只要到「選項」修改「語言」即可：

我剛剛就大概測了一下我們之前做的網站，在 IE 8.0 Beta1 的版本，還真的版面都跑掉了，我想等過一段時間可能又有網站改版需求了吧，不知道是要感謝微軟不斷進步（改變）讓我們有「源源不絕」的案子，還是要討厭微軟每次軟體改版都不太相容讓我們每次都要改網頁改到三更半夜。不過這個問題我已經想通了，擁抱改變才能創造改變，接受改變只能適應改變，所以現在的我不害怕也不討厭，只要是好的東西都願意吸收並放棄既有的知識。

雖然這套 IETester 有些已知的問題，不過我覺得問題不大，因為其實你並不是要用這套軟體來瀏覽網站，而是用來「測試」而已，所以這些軟體的瑕疵我是還可以接受的，況且這些問題應該在日後會更新吧。

相關連結

• IETester
  http://www.my-debugbar.com/wiki/IETester/HomePage

先將我的執行環境說明一下：

• 我有兩個網站，網域分別為 www1.domain.com 與 www2.domain.com
• 自己實做單一簽入(Single Sign On, SSO)的機制，並透過 Web Service 進行網站會員登入、登出
• 兩個網站共用同一組 Cookie 用以儲存 SSO 的 Token，且明訂 Cookie 的 Domain 為 .domain.com

我今天聚焦在「登出」這個簡單的功能就好，實作登出是在簡單不過的機制了，就是把 Cookie 清除掉就好啦！不過要是跟我一樣遇到 ASP.NET 怎樣也清除不掉 Cookie 的情況，那就真的是「鬼打牆」了，而且若要問人家：「請問 Cookie 要怎麼樣才能刪除掉？」這種問題問別人真的會被笑，也不知道怎麼開口。

因為我要共用 Cookie 在兩個網域，所以我的 Cookie Domain 是 .domain.com，所以照理說清除 Cookie 的方法應該是：

Response.Cookies["Token"].Expires = DateTime.Now.AddYears(-1);

或者是

Response.Cookies["Token"].Expires = DateTime.Now.AddYears(-1);
Response.Cookies["Token"].Domain = ".domain.com";

或者是

Response.Cookies["Token"].HttpOnly = true;
Response.Cookies["Token"].Expires = DateTime.Now.AddYears(-1);
Response.Cookies["Token"].Domain = ".domain.com";

反正能試的都試了，而且以我對 HTTP 底層協定的了解，幾乎在 Web 領域沒有什麼問題是無法解決的，但今天遇到 Cookie 清不掉這個問題，真的讓我滿面愁容，程式越寫越氣，用 Fiddler2 看 HTTP 封包看了幾十遍，就是看不出有任何問題，但 Cookie 就是殺不掉。

但是這問題非得要研究出來不可，就因為這個「無法登出」的「小問題」搞了我快 5 個小時才弄清楚所有來龍去脈，所幸問題有被我追根究柢的解決了，以下是要解決此問題的完整解法：

• 若要清除跨 Domain 的 Cookie 必須清除兩次，例如說使用者在 www1.domain.com 要執行登出動作，必須要先將 Domain 為 www1.domain.com 的 Cookie 給清除掉，在接著將 Domain 為 .domain.com 的這個 Cookie 清除掉。
• 因為這兩個 Cookie 為「同名」，全部都叫做 Token，所以無法在一個 HTTP Request 中清除掉兩個同名的 Cookie，所以必須要在不同的兩個 HTTP Request 中個別刪除不同 Domain 的 Cookie。

例如說：你必須先連到 Logout.aspx 頁面，在此頁面先將第一組 Cookie 清除：

HttpCookie cookie = new HttpCookie("Token", ""); 

cookie.HttpOnly = true;
cookie.Expires = DateTime.Now.AddYears(-1); 
cookie.Domain = Request.Url.Host;
Response.SetCookie(cookie);

Response.Redirect("Logout2.aspx", true);

然後再轉址到 Logout2.aspx 將 Parent Domain 的 Cookie 給清除掉：

HttpCookie cookie = new HttpCookie("Token", ""); 

cookie.HttpOnly = true;
cookie.Expires = DateTime.Now.AddYears(-1); 
cookie.Domain = ".domain.com";
Response.SetCookie(cookie);

Response.Redirect("index.aspx", true);

這樣就可以徹底將 Cookie 給清乾淨了，這真是難得的經驗，從沒想到有這種解法，不知道網路上有沒有其他人遇過跟我同樣的問題？

而我的登出程式最後是改成以下這段 Code，濃縮再一支程式裡：

protected void Page_Init(object sender, EventArgs e)
{
    Response.Cache.SetCacheability(HttpCacheability.NoCache); 

    HttpCookie cookie = new HttpCookie("Token", ""); 

    cookie.HttpOnly = true;
    cookie.Expires = DateTime.Now.AddYears(-1); 

    if (Request.QueryString["domain"] == null)
    {
        cookie.Domain = Request.Url.Host;
        Response.SetCookie(cookie);
        Response.Redirect("Logout.aspx?domain=1"), true);
    }
    else
    {
        cookie.Domain = ".domain.com";
        Response.SetCookie(cookie);
        Response.Redirect("index.aspx", true);
    } 
}

今天看到一個好玩的東西，雖然不是很實用，但是有在玩 Linux 的人看到這個應該會覺得很有趣，叫做 Google command line shell

這可不是 Google 的新玩意，而是一個網友自己開發的一個小工具，可以在 Browser 中使用類似 Linux 下的 shell 環境，可以下指令進行 Google 各類服務的操作，例如說 Web 搜尋、圖片搜尋、新聞搜尋、Blogs 搜尋、影片搜尋、翻譯、讀取 RSS、......等等。

你只要進入 http://goosh.org/ 這個網址就會看到以下畫面（跟 Linux 指令列環境很像）：

輸入 h 就可以列出說明

例如你要搜尋 YouTube 上面的影片，可以輸入：v 馬英九總統就職演說

如果要用 Google 翻譯功能的話，可以輸入：t en zh Convergence

相關連結

• goosh.org - the unofficial google shell
• goosh, the Unofficial Google Shell - Slashdot

Google 從 2006 年開始在 Google Search 的結果中標示出有安全疑慮的網站，而且最近我也得知 Google 有提供一個「安全瀏覽」的查詢服務，只要透過 Google Safe Browsing API 提供網址就可以讓使用者查詢該網站被 Google 檢測過的結果與相關摘要，目前這個機制也有被整合進 Firefox 與 Google Desktop Search 當中。

如果要從瀏覽器直接查詢特定網址的安全狀況，只要輸入以下網址即可查詢：

http://www.google.com/safebrowsing/diagnostic?site=網站網址

例如說如果你要測試 http://www.yam.com 網址是否是安全的，就可以輸入以下網址：

http://www.google.com/safebrowsing/diagnostic?site=http://www.yam.com

而結果大概是這樣：

該網頁會告訴你該網址是否為安全的網頁，還有 Google 拜訪此站時的分析結果，如果是危險網頁的話，頁面只會顯示出網頁中惡意軟體所放置的網站位址，但卻不會說出該網站的哪一頁有這些惡意程式碼，例如：

雖然資訊不是很完整且我懷疑檢測的精準度可能也不夠，不過如果有檢測出問題的話，我想應該已經是很嚴重了，那這些網站還是最好不要去比較安全。

經我個人測試過發現，目前好像只有比較知名的網站才會有資料，大部分的中、小型網站都是尚未經過 Google 掃瞄過的，不過我還是建議各位可以把自己的網站網址打上去試試看，搞不好有意外的發現（希望是好的發現）。

相關連結

• Google Safe Browsing API
• Google Online Security Blog
  The latest news and insights from Google on security and safety on the Internet
• Google Safe Browsing for Firefox

JSON ( Javascript Object Notation ) 是一種很方便的資料格式，常用於 AJAX 的相關應用中，主要是可以將 JavaScript 的物件資料變成一種字串的格式，以方便網路傳輸，也是序列化的一種方式。

當然在 .NET 這個領域也少不了他，我之前就用過 Json.NET 1.3 版，真的是還蠻方便的，但因為當時文件不多，也只有提供一些範例程式而已，所以應用的範圍並不廣，不過還是幫我省去了許多 ASP.NET 與 JavaScript 之間交換資料的困擾。

新版的 Json.NET 2.0 除了提供相當完整的線上文件之外，還提供了 LINQ to JSON 的 LINQ Provider 可以更方便的存取 JSON 物件，今後將可比以往用更輕鬆的方式用 .NET 撰寫 JSON 相關的程式了，新版的 Json.NET 2.0 大概有以下特色：

1. 支援 LINQ to JSON
2. 快速的 JsonReader 與 JsonWriter 類別
3. 可透過 JsonSerializer 輕易且快速的轉換你現有的 .NET 物件為 JSON 格式（也可從 JSON 格式轉回 .NET 物件）
4. Json.NET 也可幫你將 JSON 字串格式化成有縮排的格式，用以方便除錯與檢視
5. 可設定 JsonIgnore 與 JsonProperty 屬性(Attribute)到你的類別中，用以宣告物件要如何序列化
6. 能夠將 JSON 轉成 XML 格式，也可將 XML 轉成 JSON 格式

如果要下載 Json.NET 2.0 可以到 Json.NET CodePlex Project 網站下載。

相關連結

• Json.NET 2.0 Released
• Json.NET on CodePlex - Json.NET 的專案網站(開放原始碼)
• Json.NET 2.0 Quick Starts & API Documentation - 很棒的線上文件
• James Newton-King's Blog - 作者的部落格
• Introducing JSON

Web 的開發工作千頭萬緒，什麼樣的鬼事都遇的到，什麼 CSS, DOM, JavaScript, ... 在每個 Browser 都有些小地方不太一樣，難怪很多學 Windows AP 或 Windows Form 的開發人員都不太願意轉到 ASP.NET 開發（至少我遇過好幾個不太想轉換的朋友）。

Google 最近推出了個名為 Google Doctype 的網站，目的是想創立一個所有跟 Web 有關的百科全書，所有跟 Web 安全、JavaScript 的 DOM 處理、CSS 的撰寫技巧、網頁效能、跨瀏覽器的議題，或其他所有跟 Web 相關的東西都會在這上面。

我自己上去看了一下覺得有些文章還蠻不錯的，都是非常實用的技巧與觀點，例如說 Web security。其實目前所看到的這些文章都是 Google 的員工（Googler）寫的，不過只要你有 Google 的帳號就可以參與創作，一起貢獻你的想法、發表你的開發技巧、評論現有的文章或修改現有的文章。

雖然目前 Google Doctype 上面的內容還不多，不過我想未來應該會有不少東西吧！

相關連結

• Introducing Google Doctype
• Google Doctype
• Browse Google Doctype