這一系列文總共有三篇,這是最後一篇。
Funliday 重磅推出新的 prerender 套件 pppr!這是一個 zero config 的 express middleware,只要 npm install pppr,然後在 app.js 裡面加一行 app.use(pppr()) 就可以直接拿來用了。
---
原本在使用 prerender.io 這個套件有時候會出現 504 timeout 的問題,後來發現這個套件用的是比較底層的 API (Chrome DevTools Protocol, CDP),研究它的原始碼後發現 render HTML 的 timeout 判斷上有些怪怪的,本來想試著去改這塊,但對 CDP 不熟,所以用 puppeteer 重寫一套 prerender service,pppr 也就應運而生。
簡單先解釋一下,puppeteer 是基於 CDP 封裝後成為比較容易使用的 API。因為 client side rendering (CSR) 的流行,所以現在要做網路爬蟲的話,愈來愈多會選擇用 puppeteer 來處理。這裡來分享一下在開發 pppr 的時候,有哪些東西要注意的。
1. 把 URL 放到像是 50 人的 LINE 熱門群組,prerender 會遭到大量的 request,因為每個使用者接收到這個訊息之後,因為要顯示 og data,所以就會去打一次 prerender。這裡姑且先稱之為 OG-DDoS 好了 XD,所以一定要做 cache,讓第一個 request 把 HTML 產生出來之後就放到 cache 裡面。然後可以用 LRU cache 來處理,因為這類 URL 都是短時間會被大量使用,之後就很少被用了,用 LRU cache 剛剛好。
1-1. 其實這一段實作還有一些問題,如果在第一個 request 還沒產生出 HTML 之前,第二個同樣 request 就進來了,這樣子 cache 可以說是根本沒作用,還要再找時間來處理 lock 機制才行。
2. 每一個 request 要新開一個 page 才行,如果沒有每個 request 都開新 page 的話,會造成 A request 還沒處理完,B request 就用同一個 page 做 render,這樣子 A request 就會 504 timeout 了。所以一定要記得每個 request 都要新開 page。
3. 因為 headless chrome 的 user agent 就叫做 HeadlessChrome,為了避免在 render 的時候會出現意料外的狀況,保險一點還是把 HeadlessChrome 改成 Chrome 會比較好。
4. 注意 redirect。因為 expressjs 跟 puppeter 是兩個不同的 context,對於 redirection 來說,expressjs 會回傳 3xx 系列的狀態碼,但 puppeteer 則會直接執行完成。所以把 puppeteer 放在 expressjs 裡面執行的話,必須要處理 redirect chain,讓 expressjs 能回給 client 正確的狀態碼才行。
5. pppr 因為是發想自 prerender.io,所以 interface 也一樣是 /render?url=https://example.com。 但有時候原始的 url 後面會包含 query string,所以 expressjs 要用 URLSearchParams 另外做些處理,才能取得完整的 url。
開發 pppr 基本要注意的事項大概就這樣,總之記得給星,有任何問題歡迎發 issue 跟 pr 喔!
#pppr #prerender #funliday
url redirection 在 iThome Security Facebook 的最讚貼文
網路安全專家劉俊雄先前曾經接受iThome的專訪,
分享他對於DDoS攻擊的觀察。
囿限於媒體篇幅和屬性,
劉俊雄趁著夜深人靜之際,
把他對於DDoS攻擊的觀察有更深入的分享!!
關注DDoS攻擊所有的資安與IT人員,
都不要錯過這一篇動人的分享!!
感謝奧天大大不藏私的經驗分享~~
[淺談 DDoS 攻擊]
幾個月前受訪談了些 DDoS 的話題,沒想到最近一連串爆發了這麼多事件,也讓個人淺見出現在幾篇 iThome 的報導
http://www.ithome.com.tw/news/109932
http://www.ithome.com.tw/news/110135
http://www.ithome.com.tw/news/110144
http://www.ithome.com.tw/news/110137
http://www.ithome.com.tw/news/111861
因訪談限制及媒體屬性,無法很完整的表達我的看法,趁著夜深人靜時整理一下 :
DDoS 大略可分為三個層級 - 網路層、系統層、應用層,
網路層為癱瘓目標頻寬,典型手法為 UDP/ICMP Flood、以及近年流行的各種 Reflection&Ampplification 洪水攻擊;
系統層為癱瘓目標的基礎建設或系統層,典型手法為 SYN Flood、Fragment Packet Flood、Connection Flood 等;
應用層為癱瘓目標的應用服務,典型手法為 SSL Flood、HTTP Flood、DNS Flood、Exploit、Slow Attack 等。
十多年前個人剛接觸 DDoS 的時候,盛行的是「細巧」的系統層/應用層攻擊,但近幾年因許多協定的 反射&放大 手法被開發、以及 IoT Botnet 的盛行,應該會有一段時間轉為 「爆量」 的網路層攻擊。
以開店作生意比喻 - 將店門口及前方道路視為網路出入口及上游,店裡設施和走道空間視為基礎建設,結帳櫃檯視為應用系統。則攻擊者可以堵住店門和馬路、可以塞爆店裡的走道和空間、又或者癱瘓結帳櫃檯。
而 DDoS 為何難防 ?
這與企業為何很難阻止駭客入侵的原因一樣,攻擊方與防守方處於不對等的立場,攻擊者有太多的方式可選擇,且可不斷的調整與嚐試,防守方卻礙於人力與預算限制,難以全天候對每一種手法都有良好的對應措施。
許多老闆總認為花錢買設備就可以了事,但偏偏這不是單一設備、單一解決方式可以完全處理的,應該沒有一家的服務或設備直接上架,完全不需調校就可以完美對應每一種攻擊手法,需要有經驗豐富的專業人士視實際攻擊狀況調校參數及規則。有如同一把大刀,在關公和小孩手上耍起來實有天壤之別啊!
以本次券商 DDoS 事件來說,由媒體報導看起來是屬於 [網路層] 的攻擊方式,但即使加大頻寬、或由ISP端阻擋住了,難保哪天不會出現針對系統層或應用層等更為精細、打得更為巧妙的手法,加上金融業幾乎全用 SSL 加密應用服務,會使中間的清洗商更難介入分析應用層攻擊(除非提交 SSL 金鑰)。
至於實務上應該要怎麼阻擋會比較理想?
我的看法是需 雲端清洗+本地防護,量大的攻擊由雲端或上游清洗處理,而細巧的攻擊可能穿過清洗中心,則由本地的防護機制處理,但絕對不會是由 "防火牆" 這萬年設備,至於用什麼設備可達到較好的阻擋效果請洽各大 SI。
另外若預算許可下,還可建立多個資料中心或介接多條 ISP 線路,配合 GSLB 機制快速切換 DNS ,讓攻擊者難以鎖定每一個出入口,可增加攻擊難度及應變時間。
另外真的遭遇 DDoS 攻擊時,個人的簡易 SOP 大概如下 -
1. 快速診斷,描述症狀由專業人士判斷(有側錄封包更佳)
2. 對症下藥
- 洪水攻擊 : 請求 ISP/清洗商 協助、Black Hole、更換 IP / Multi ISP / GSLB
- 系統層攻擊 : 更換撐不住的設備、關閉負載高的功能、調整系統參數延緩攻擊影響
- 應用層攻擊 : 增加服務能量、減少異常存取
3. 減少異常存取的方法:辨識特徵 + 過濾
- 網路層特徵 (IP/PORT/ID/TTL/SEQ/ACK/Window/...)
- 應用層特徵 (SSL/URL/Parameter/User-Agent/Referer/Cookie/Language/...)
4. 如果打到沒有特徵可過濾,則需靠應用層的機制來辨識真實使用者
- Redirection
- Challenge
- Authentication
5. 若無上述功能則儘快商調適合的設備。
以上是個人的看法,但我已經很多年沒直接處理 DDoS 的事件,也非任職於 ISP 方或 DDoS 防護服務廠商,只是單純的以技術角度分享,如有錯漏之處也請業界真正的高手不吝指教。
題外話,最近 DDoS 正夯,服務商們可仿效已有許多資安業者提供的 IR Retainer 服務,推出 DDoS Retainer,也許是不錯的商機 XD
[以上轉載請註明出處]
url redirection 在 payloadbox/open-redirect-payload-list - GitHub 的推薦與評價
Dangerous URL Redirect Example 2. ASP .NET MVC 1 & 2 websites are particularly vulnerable to open redirection attacks. In order to avoid this vulnerability, you ... ... <看更多>
url redirection 在 How do I redirect to another webpage? - Stack Overflow 的推薦與評價
... <看更多>
相關內容