最近在忙著實作我的一些小項目,沒有上來發文,但還是一直學習JS, 累積滿多經驗,也累積不少疑問。

之前站長阿川有跟我提到相關話題,也就是UJS,想說把它拿過來聊一聊。 剛好最近弄的東西,跟這個也有一些關聯性。

html與JS的交互關係。

Inline JavaScript是什麼呢?

就把JS寫在html裡面的一種手段,也就是onclick那些東西,在自學教材會學到唷:))。

其中也有個東西叫做JavaScript pseudo-protocol,他好像有點像是給一個js的前綴, 讓瀏覽器讀取html的時候知道要開始讀取JS了,用法如: <a href="javascript:alert(1)">my website</a>

這樣子的作法都讓JS侵入到html裡面,也就是行為跟結構沒有分離。

是否要UJS,站長上次有提到這可以看專案大小來區分,這篇閒聊開起來可以提供更多細節。


不過我不打算就此結束文章,我要額外分享與XSS相關的內容。 XSS其實是CSS,跨站指令碼Cross Site Script的意思,只是因為縮寫重複CSS樣式(Cascading Style Sheets )所以用X代替。 簡單理解它就是一種攻擊手段,讓別人網站上執行我的代碼。


有趣的事情來了,那html跟JS交互關係跟XSS又有什麼關聯呢? 想像一下,當今天小明要做一個討論區,讓使用者用html編輯打文章,就必須小心有人會放一些JS的代碼。 小明想說,我要過濾<script>標籤來保證他們乖乖地寫html。 請問這樣子是否就安全了呢?

答案是否定的,這時候使用Inline JavaScript會發生什麼狀況? 試想一下因為小明沒有CSP相關設定,防止使用者偷偷塞JS到html裡面,導致小明的壞朋友大胖, 可以直接寫一個<img src=x onerror="alert(1)">在留言區裡面, 完全沒有使用到<script>標籤,卻也能造成XSS。


關於防禦:

CSP

設定嚴格一點,可以阻止很多XSS,舉例來說文章一開始有href="javascript:alert(1)", 可以設定href後面只能接上http開頭的東西。

WAF

他是Web Application Firewall 的簡稱,中文通常叫作「網站應用程式防火牆」 可以建立及管理避免網際網路威脅的規則,包括IP 位址、HTTP 標頭、HTTP 主體、URI 字串、跨網站命令檔(XSS)、SQL 隱碼攻擊及其他OWASP 定義的漏洞。

自己建立fliter

自己過濾也是可行的(不建議),把字串符碼都轉成HTML Entities,例如把 (<)寫成 &lt; or &#60; ,透過這樣的過濾render出來的就不會是指令了。

為什麼不建議,是因為你過濾的東西有可能會被double encoded URL之類的手法繞過。 或是你覆蓋了document.write,以為安全了,但是我用孿生函數(twin function)的document.writeIn你可能就忘了過濾。

這剛好就是我最近在研究的東西。

相關討論問題:

1.對於文章的內容,有沒有什麼錯誤呢?或相關名詞想法想補充?

2.是否要UJS的實際使用,有哪些想法?或是有什麼經驗?

按讚的人:

共有 4 則留言

後記:看得出來資訊量頗大的,這幾天的確很充實,都在注意XSS相關資料ㄎㄎ。 希望不會太分散,如果主題會太發散,未來可以再開一篇XSS的(? 這篇就可以專注聊某一個部分~~

按讚的人:

UJS 這個名詞,我在前端社群其實沒有看過

查了一下,好像只有 Rails 社群會使用這個名詞

一般來說,軟體產業,比較常講 separation of concerns(關注點分離)

用來說明:將不同概念的程式部份,分開來,會讓程式比較好維護

按讚的人:

實務上來說,html 跟 js 程式碼,通通混在一起,當然會很難讀、很亂

不過,在 React 社群,大家所寫的 jsx,很多時候看起來又很像是把 html 跟 js 混在一起了

所以這個部份有點 tricky,在 React 社群,大家在乎的 separation of concerns 其實是「state 與 side-effects」而不是「行為與結構」

這相關的概念很進階,我這邊先不詳談,或許有機會再專文介紹

按讚的人:

很好的分享! 之後有人在網路上搜尋相關專有名詞,都有機會看到這串心得&討論,造福無數後人!

按讚的人: