::run, tempo, run::

剛參加完 UbiSunrise 的第二次資安聚會, 因為有點空, 所以貼一下我的心得..

UbiSunrise 是一個以工程師為主的聚會, 主辦人是高子漢學弟, 今年的 1 ~ 3 月是資安季, 議程有興趣的人可以參考 UbiSunrise 活動網頁..
以前都覺得台灣的 User Groups 活動好少, 現在真是越來越多, 我現在大概每個月都會固定參加 UbiSunrise/JUG/HappyWeb, 快要把週末都佔滿囉~~

這次的 UbiSunrise 是由 Birdman 與 Kuon 主講, 分別是 Windows 與 WEB/XSS 的資安問題..
因為我對 Windows 底層太生疏, 所以聽完 Birdman 演講後, 只覺得應該要把公司的電腦升級到 Vista 64bit / linux 了~~

Kuon 的演講我就比較懂囉..以下是幾點速記:

1. 要攔截瀏覽器的 HTTP Request/Response, Kuon 是用 burp 這個工具. 看起來還滿好的..
我自己是用 Fiddler 或是 WebScarab, 有興趣的人都可以參考看看..

2. 要在 client/server 傳遞被 md5 encode 過的資料, 請記得先將被編碼的資料先小小混淆一下, ex:
身分證 A123456789 要做 md5 encode, 可以改成這樣: md5(tempo_ + A123241130), 避免被有心人士試出來你的規則..

3. 如果你的服務同時提供了 WEB 與 client 端的程式, 且 WEB 端與 client 端有分享相同的 JAVA library, 而偏偏你的 WEB 端有揭露 class 的資訊, 如:

http://aaa.com/controller?action=net.diggirl.web.RecordLinkOperation

這樣有意者可以透過反組譯 client 的函式庫, 來猜測 server 端的漏洞..

4. 如果 server 端有某個 url 接收另一個 url 當作參數, for example:

http://aaa.com/convertJpeg?a=http://bbb.com/hacker.jpg

這樣可能會被有心人士修改後面的 url 參數, 將你的 server 當作跳板入侵其他人網頁的跳板..

其他則是一般性的 XSS 問題, 太多方法, 很難完全阻擋..
不知道有沒有人知道 open source 的 web inputfield 的過濾程式, 可以直接過濾掉 java script code, 保留下比較安全的 tags ?

tags: xss ubisunrise

Feb 11 2007, 06:59:29 PM CST Permalink 迴響 [0]

上星期舉辦 HappyWeb 4, 也說一下主辦者我的感想吧..

這次跟以往幾次不同, 我們請了四家新的網站來做個簡報, 外加 DEMO 秀..
看來反應相當熱烈, 不僅出席的人比想像中多很多, 有跟我交談的朋友也覺得這個模式很好..
其實這也是我們本來想要走的路囉~~
我想未來如果可能的話, 希望能夠繼續朝這個目標辦下去..

對於 4 個來報告的網站/團隊, 我個人覺得比較有趣的是 MeWorks..
怎麼說呢? 我覺得這應該是個很好的 business plan, 創投看到應該都會口水直流吧..
學弟產品也做的相當不錯..
重點是市場很廣, 而且看來是大家比較少涉足的領域 (雖然最近 Google/MS 有中小企業方案, 但我覺得與 MeWorks 的性質不同, 不可相提並論)

hehe .. 聽過很多創業故事都是無心插柳柳成蔭, 不禁好奇這個有好開始的學弟, 不知道未來會如何走?
我不是不看好這件事, 只是很有興趣知道他的未來..

至於 diggirl, 爭議很多喔, 不過很多人很看好呢..
當然純個人意見, 但就像表特版 (若表特的高人氣是 diggirl 想要追逐的目標) 一樣, 我覺得若是女生都會願意來這裡逛逛, 才能更上層樓吧..
大部分的人在 blog 上評論都不禁提到 10 禁或豬哥, 我想某種程度的差異化(?) 或許是 diggirl 可以再想想的..

MyEvents 與 PPolis 則是太早, 還不知道完成型態是怎樣..
期待早日看到他們的完成品..
PPolis 的 nchild 應該是少數在這個年代還在說 Java 多好多好的人, 給他拍拍手..:p

關於座位, 下次若報名人數還是這麼多, 我們會準備另一個教室一起..
還跟晚到的人說聲抱歉..

下次 HappyWeb 應該是 3/10, 希望大家能撥空再來參加囉~~

tags: happyweb diggirl meworks ppolis myevents

Feb 11 2007, 02:13:07 AM CST Permalink 迴響 [3]

最近火速看盤經歷一陣連續的大改版, 主因是 DB 越來越慢了, 解決方式是從 Hibernate 著手, 看看有沒有加強的空間..
速記下幾個最近才知道的事情, 供大家參考:

Statistics & Criteria
要做 tuning, 之前都是看資料庫的 slow queries 來挑, 雖然也是 ok, 但隨著 query 越來越多, 要從 db queries 去反推回是哪個 HQL/Criteria 還滿困難的..
另外也沒有辦法得到物件的存取資訊等, 在做 cache 時的判斷也很麻煩..

直到最近加入 Hibernate Statistics 的管理頁面, 才知道早該做這個功能..
要用 Hibernate Statistics 很簡單, 呼叫 sessionFactory.getStatistics() 就好了..
可以印出 Hibernate Entities, Collections, Queries 的使用次數與各種資訊..
我大概都看看呼叫次數與平均時間, 再依物件特性就可以決定是否需要使用 2nd level caches 或 query caches, 很方便..

不過因為要看 Hibernate Statistics, 也暴露了 Criteria 的一個嚴重缺點, 就是印不出 Criteria 的 query caches, 因為 Criteria 沒有文字的敘述..
Criteria 雖然可以加上 comment, 但也是大工程..
所以, 只好忍痛將所有 Criteria 改為 HQL, 這也就是會花這麼多時間的原因..

若你剛接觸 Hibernate, 建議你就不要考慮 Criteria 了..
雖然還滿高興自己總是能用 Criteria 兜出頗難的 query, 但, 為了未來監控, 還是改用 HQL 吧~~

Caches
雖然 Gavin King 說 Query Cache 沒啥用, 但我覺得怎麼會呢?
看到 Queries 數狂降, 也是心中一股 "早知道, 我就..."

至於 Cache 的選用..
因為我們的資料庫存取不僅是網域內, 也有可能是其他網路上的電腦, 所以使用 JbossCache 相當麻煩..
只好退一步, 選用 EHCache, 但相對的, 僅能 Cache "非常不常更新或不更新的資料"..
但對我的系統幫助也夠大了..

至於 Cache 怎麼設定, 我建議大家做幾個 Test Cases, 實際看看資料有沒有被 cache 起來..
因為實際上跟想的都有點些差距, 需要動手做看看比較清楚..
詳細的設定細節, 或許下次 JUG 再跟大家分享囉~~

Connection Pool
有些 Connection Pool 可能有提供狀態監控 (我是用 c3p0), 就可以順便監控即時的 DB 連線數..
前面提的監控網頁也可以加上這個, 我覺得很實用..
我之前一直滿困惑, 不知道 DB Connection 上限該設多少 (最後決定設 64 或 92)..
透過這個就可以正確的做個決定..

另外, 根據之前做壓力測試的心得, 雖然 c3p0 不是什麼太正式的 Connection Pool, 但是我測試的結果, 只有 c3p0 在 Connection 數到上限時不是直接丟 Exception, 而會有 wait for next available 的機制, 這個很重要..

Many to Many
雖然我知道這不可避免, 但使用 Many to Many, 對資料庫的複雜度都是個提升, 尤其是透過 hibernate 幫你產生 queries, 很可能會不經意產生讓你很吐血的 table join..
若您有使用 Many to Many 的關係, 建議你特別注意一下產生出來的 queries 效能..

Filter
Filter 跟上面一樣, 也是有可能會不按牌理出牌幫你 join, 請特別注意一下產生的 queries..

Transactions
我不知道曾經在哪裡讀到, 加 transaction 不會為系統增加多少負擔..
因為一直對 DB 這類東西沒啥興趣, 所以就照做, 不該加的地方也加了..
最近印出很多數據, 才發現 ... 涉世未深的我被騙了..

若是有大量 Queries, 看看有沒有辦法把 Queries 與 insert/update 做某種程度的分開吧..

tags: java hibernate

Feb 11 2007, 01:38:04 AM CST Permalink 迴響 [5]