淺談F5 BIG-IP ASM TS Cookie

關於Session ID的美麗與哀愁…

剛泡好咖啡。對著電腦,路上無車無人,夜深無聲。沉默太久,對Session ID的誤解也太重,我想該是和大家清楚說幾句話的時候。

猶記得行動應用基本資安檢測(簡稱MAS)基準中是這麼說的:

交談識別碼(Session Identification, Session ID)
指在建立連線時,指派給該連線之識別碼,並做為連線期間之唯一識別碼;
當連線結束時,該識別碼可釋出並重新指派給新之連線。

註:如果SessionID、Cookie、Session還傻傻分不清楚的人可以先看DEVCORE這篇回憶一下。

在中級以上必測的4.1.4.2.1.這個項目就是要測「 行動應用程式應避免使用具有規則性之交談識別碼」,所以我們首要工作就是要判斷何謂交談識別碼,也就是Session ID。


我們使用Burp Suite工具做側錄,可看到一個比較複雜的範例如下:

利用Burp錄到的某個POST Request

從上圖中我們可以看到Session Cookie(相對於Persistent Cookie而言),有這麼多個Session ID:

  1. TS015f9a94
  2. JSESSIONID
  3. INITSESSIONID
  4. dtCookie
  5. TS013f18f0
  6. TS01aae625

這麼多個,到底哪個才是《真‧Session ID》呢?讓我們來用刪去法吧!

dtCookie:經我研究後發現,這個是dynaTrace用的Cookie。

那些TS開頭的Cookie:其他那些TS開頭又臭又長的Cookie到底是什麼呢?這就是本文的重點了。

其實,簡而言之,他是 f5 所自動產生的BIG-IP ASM cookies

F5 BIG-IP ASM 系統架構圖

簡介一下,f5 BIG-IP ASM(Application Security Manager, ASM)是一個彈性的Web應用防火牆(Web Application Firewall, WAF)。而BIG-IP ASM cookies即屬於F5 WAF ASM底下的一種安全政策。

在BIG-IP ASM System Security Policy下有制訂兩種Cookies:

  • Main ASM cookie
  • ASM Frame cookie(範例沒用到,這次就不講了…)

我們上述範例使用到的就是所謂的 Main ASM cookie,預設600秒後失效(也就是 expiration time),而命名方式是以TS開頭再加上8位的亂數所組成(在BIG-IP ASM 11.4.0以後是8位,之前是6位),也就是 (TSxxxxxxxx)的形式,而ASM Frame cookie則是 (TSxxxxxxxx_d)的形式。

因為都是採用TS開頭(官方沒說為什麼,但我猜是 Terminal Server的縮寫),這些Cookie在f5的世界常常就叫做ASM TS Cookie,或直接簡稱為TS Cookie

以正規表示式來說,就是{^TS(?:[0–9a-fA-F]{6,8})(?:$|_[0–9]+$)}


你可能會好奇,f5多加這個Cookie所為何用?我也很好奇,官方網站沒有明說,但我猜想,是為了做CSRF防禦之用,加入ASM TS Cookie可以做到「Double-Submit Cookie Protection」的效果。

註:忘記CSRF是什麼的人趕快看一下OWASP下面這篇回憶一下…

因為是做CSRF Prevention之用,所以一旦竄改TS Cookie後再傳送,在f5 WAF那邊就會被檔下來了。但是這個Cookie的有無,並不影響會員登入狀態的判斷與否,因為會員登入狀態的檢查是寫程式並實作在AP Server端的。

這或許也可以合理解釋,為什麼拿這個TS Cookie去問送測方或開發者,對方可能也不熟也不理解他是什麼,因為如果對方只是一個單純的開發者、只需產出Application端的程式,不必理解和考慮整體系統架構的快樂程序員,壓根就不會知道有這個Cookie的存在,問他這個由f5自動產生的TS Cookie的任何問題,他大概只會回你黑人問號的表情:

而唯有對任何問題有刨根究底精神(像我吃飽太閒)的人,才會研究他的本質究竟是什麼?實質用途可能是什麼?而理解以後,下次再看到類似的就不會迷惘了,畢竟孔子說過 「蓋有不知而作之者,我無是也。多聞,擇其善者而從之;多見而識之,知之次也。」,我們不夠天才無法當「生而知之」的第一等人,至少要當個主動學習「學而知之」的第二等人,如果還是不夠積極,至少至少,也要當個「困而學之」的第三等人。


回到問題本身,我們理解了這些Session ID的生成和用途,刪去dtCookie,刪去TS開頭的Cookie,就剩下JSESSIONID和INITSESSIONID了,理解並刪去以上這些Cookie後,再做人工驗證登出失效的部分,便可以省去不少Trial & Error的時間。

然而,我們都知道,根據經驗法則, JAVA類的系統如使用Servlets/JSP程式撰寫並用Tomcat、WebLogic、 WebSphere或JBoss…等伺服器架站的Session ID,通常都會叫做JSESSIONID。而.Net類的系統的Session ID通常都會叫做ASP.NET_SessionId。這些就算是AP Server自動產生的Session ID,但實際上系統是否真的用這些Session ID當作登入狀態的判斷,還是要看開發者實際實作時的程式邏輯。畢竟還是存在有充滿創意與激情(天生反骨)的開發工程師,不喜歡使用內建好的輪子,喜歡自己重寫一個,覺得跑起來比較順。

總結一下,看起來疑似都是紀錄Session ID的Cookie,有可能是WAF自動產生的,有可能是為了網路監控而自動產生的,也有可能是AP Server自動產生的,更有可能是程序猿實作手工打造刻出來的。今晚,你選哪一道呢?


延伸閱讀:

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.