Programming Language Notes

 互聯網的時代中我們幾乎都離不開網路，那如果能夠對於Web具備基礎的知識，就能夠讓我們在使用網路的過程中提升風險意識，以減少被竊取、盜用的風險，進而保護個人資產，因此多一份知識在身上也就等於多了一份防身的武器，一天學一點，透過 微習慣 讓我們享受複利的效應。 在前幾篇我們介紹了「 同源政策(Same Origin Policy) 」與「 Web - 跨來源資源共用（CORS） 」的基本概念之後，大致上已經了解瀏覽器如何做個守門員，攔截非法的請求/回應，接下來我們就來談談駭客如何繞過「 同源政策(Same Origin Policy) 」進行跨站請求偽造( CSRF )。 CRSF 全名為「 Cross Site Request Forgery 」中文為跨站請求偽造，相信我們都搭過交通運輸工具，那麼基本上的機制就是認票/卡不認人，假設我們的票/卡片在不知情狀況下被盜取，那麼對方就能直接進入，這套用到網站也是相似的概念，在還未登出的狀況下，Cookie(通行證)被盜用，就能進入你在瀏覽的網站，進而竊取個人資訊，進行下一次的滲透攻擊。 CRSF 攻擊示意圖 原則上HTTP是屬於無態的，因此正常狀況下，並不會將正常網站的資訊帶到偽造網站，但由於Cookie的特性，會被附加在每個HTTP的請求中，因此才會產生如下圖般被偽造的風險。 登入正常網站，並在未登出期間收到釣魚郵件或者訊息。 點擊該釣魚郵件或訊息所附帶的網址連結。 進入該網站之後，按下駭客所埋藏的偽造請求按鈕。 由於Cookie的特性，按下該按鈕後，釣魚網站透過夾帶Cookie的方式，連結到我們尚未登出的正常網站，此時若駭客掌握了重要資訊的位置，那麼將可以使用這樣的偽造身分方式竊取我們的重要資訊，進而進行下一步的攻擊。 如何防範 CSRF ？ 在談論如何防範 CSRF 時，我們將情境分為兩個部分，首先是使用者的部分，接著是網站開發者的部分，當然本篇文章並不會講述太多技術實作細節，著重在概念的貫通，有了概念，相信技術將迎刃而解。 ❗❗❗身為使用者可以做什麼防範？ 我們每個人在使用瀏覽器時所扮演的角色都是使用者， 因此了解以下防範方式，可以保護我們的資料減少被竊取的風險。 定期清除瀏覽器歷程(所有)，避免保留過多資料，萬一被竊取時，資料越多風險越高。 設定瀏覽器封鎖第三方Cookie，

  互聯網的時代中我們幾乎都離不開網路，那如果能夠對於Web具備基礎的知識，就能夠讓我們在使用網路的過程中提升風險意識，以減少被竊取、盜用的風險，進而保護個人資產，因此多一份知識在身上也就等於多了一份防身的武器，一天學一點，透過 微小習慣的積累 讓我們享受複利的效應。 CORS(Cross-Origin Resource Sharing) ，中文為跨網域資源共用，上一篇我們談到「 Web - 同源政策(Same Origin Policy) 」，概念很好沒錯，防止了一些惡意的攻擊，以一個國家來說，總不可能永遠封閉大門，拒絕對外交流，將所有其他來源都視為攻擊，因此才造就了 CORS ，透過有限度的開放，讓特定來源可以進入。 CORS 為 Same Origin Policy 的一種特別條款，簡單來說就是「我需要事前準備哪些東西？」才能跨越同源的限制，順利存取資源，就如同國家之間的入境一樣，需要事先準備護照，而根據政策的制定來檢核哪些國家的人能夠進入本國。 🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能挖礦打造被動收入 🔔 如何運作？ 首先在瀏覽器與Server之間的溝通時， CORS 規範允許Server端回傳一些Header，而 瀏覽器則根據這些Header來檢查是否可以跨越同源( Same Origin Policy )的限制 ，而最主要的一個Http Header就是Access-Control-Allow-Origin，這個標頭非常關鍵，藉由這個Header告訴瀏覽器我們允許哪些來源進入伺服器存取資源。 但是除了Access-Control-Allow-Origin之外還有以下兩個標頭也是檢查的重點： Access-Control-Allow-Methods： 伺服器允許存取的方法(GET、POST、...)。 Access-Control-Allow-Headers： 伺服器允許存取的標頭。 那麼在瀏覽器發送前會分為以下兩種請求，簡單請求(Simple)和預檢請求(Preflight)，為什麼需要特別區分呢？ 主要是檢查CORS的時機點在於伺服器回傳的時候，但試想，如果一個重要的命令(刪除)，在尚未檢查之前就執行，那麼這是一件非常危險的事情， 因此才會進行區分。 簡單請求(Simple Request) 這類型

互聯網的時代中我們幾乎都離不開網路，那如果能夠對於 Web具備基礎的知識 ，就能夠讓我們在使用網路的過程中提升風險意識，以減少被竊取、盜用的風險，進而保護個人資產，因此多一份知識在身上也就等於多了一份防身的武器，一天學一點，建立 習慣 讓我們享受知識複利的效應。 這也是第一篇在 PotatoMedia 撰寫的 Web知識篇章 ，主軸在介紹我們常常接觸的瀏覽器中具有哪些機制？ 而這些機制中可能存在著哪些弱點可能被攻擊，進而導致個人資訊被竊取，並說明如何注意與防範，期望這些知識能夠幫助到你我，免於遭受不必要的損害。 Same-Origin Policy 同源政策是Web Security中安全建立的基礎，用來限制不同網域之間的資源存取權，而這邊指的資源包括程式碼、圖片、影片、html...等。 Same-Origin Policy 主要目的在劃清界限，試想兩個國家之間，基於安全考量，通常不會共享重要資源(軍備、財務...等)吧！ 而 Same-Origin Policy 就是在制定這樣的政策，讓自己的網站自己管，試想，若自己的網站允許被其他網站存取，那麼在你的網站中的重要資訊也很容易被竊取，甚至鑽研漏洞，導致被攻擊，道理就跟國與國之間一樣，必須形成壁壘，保護重要資產。 像這樣的畫面，我們進行網頁開發時是不是常常看到這種狀況？ 這就是不同源存取的其中一個例子。 🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能挖礦打造被動收入 🔔 什麼是同源？ 又該如何判定？ 同源(Origin)主要由以下三個部分組成： Schema： URL的最初始位置，也就是 :// 之前的字段，也就是 http 、 https ...等協定。 Hostname(Domain)： 這裡指的就是full domain name。 Port： domain name後面接的port， 我們有時候沒有看到port號是因為http預設80 port而https預設為443 port。 上述三個部分只要有其中一個不相符，就屬於不同源，以下用簡單的例子來看看哪些同源，哪些又是不同源？ ❓ <https://www.domain1.com> =====================================================

  前一篇的「 Authentication、Authorization，傻傻分不清楚？ 」主要在介紹認證與授權的差異之處，而本章節著重於授權這部分，也使用了經典的 RBAC 模型進行說明。 概述 RBAC 模型（Role-Based Access Control：基於角色的訪問控制)， 認為可以抽象的表示： Who是否可以對What進行How的訪問操作 並針對這樣的邏輯進行求解的過程。 當然這樣的概念不僅限於軟體世界，套用到真實世界也是非常適合的，就以公司組織來說， RBAC 的公式就是非常貼近生活化的例子了。 誰可以對財務報表進行修改？ 誰可以對公司規章進行新增？ ... 🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能挖礦打造被動收入 🔔 基本模型的組成元素： RBAC0 根據權限的複雜程度， 又區分為 RBAC0 、 RBAC1 、 RBAC2 、 RBAC3 ， 但是不論如何都脫離不了以下的三個元素(用戶、角色、權限)來進行延伸， 也就是基礎的 RBAC0 。 用戶(User)： 每個使用者可以被賦予不同角色。 角色(Role)： 每個角色具有不同的存取權限。 許可權(Permission)： 訪問許可權。 實際案例 假設我們有管理者跟一般使用者， 分別操作權限有所不同， 如下圖，管理者具有所有的操作權限， 而一般使用者只有查看個人訊息、修改個人用戶名稱的權限。 角色分層模型： RBAC1 主要在角色中引入繼承的概念， 也就是替角色分組並區分等級， 每個等級所對應的權限也有所不同。 角色限制模型： RBAC2 RBAC2 是基於 RBAC0 擴展的， 增加了一些限制， 分別為： 靜態職責分離(SSD)： 約束於用戶與角色之間。 同一使用者不能擁有多個會發生權責衝突的角色。 互斥角色： 同一個用戶不能授予互斥關係的角色， 例如： 同一個員工不能同時為會計及研發。 基數約束： 一個用戶所被賦予的角色是有限的。 先決條件約束： 用戶想要擁有更高權限之前必須先具有前一級的權限。 動態職責分離(DSD)： 同一使用者可以擁有多個會發生權責衝突的角色。 實際執行時只能選擇其中一個角色來擔任。 RBAC 3 RBAC3 = RBAC1 + RBAC2 ，因此除了具備角

  JSON 全名 JavaScript Object Notation，其格式基本上就是 key: value 的組成如下：

 概念: 有限時間內可使用通行證來要求對應的操作權限。

  產生金鑰 首先要先在 Client 端設定一組金鑰。只要使用  ssh-keygen  指令就可以了，而這邊產生金鑰的方式，我們選擇 rsa 4096 的加密方式，此種方式目前強度較強，但缺點是產生出來的公鑰長度太長，另一種折衷的方式是 ed25519 ，取決於個人對資安的要求程度來決定使用哪一種加密方式。 ssh-keygen -t rsa -b 4096 產生鑰匙的過程中會詢問幾個問題，例如要放在哪裡： Generating public/private rsa key pair. Enter file in which to save the key (/home/noob/.ssh/id_rsa): 這些直接按下 Enter 保持預設值就可以了。另外也會詢問金鑰的保護密碼，由於我們是要達到免密碼登入，所以也直接按下 Enter 略過： Enter passphrase (empty for no passphrase): 最後則會看到產生的金鑰： Your identification has been saved in /home/me/.ssh/id_rsa. Your public key has been saved in /home/me/.ssh/id_rsa.pub. The key fingerprint is: SHA256:O92QuN2lx4vHmgVTHsnAKKWKp+dAdQKOOq6B09wfD9E me@My-Computer The key's randomart image is: +---[RSA 4096]----+ | . ..o. | | o . ... .o . | | . . o o. = | | . o = . . o . | |o o + E o o o | |o+ o o . = + * | |+.o + + + o +.+ | |.o = + . =o. | |. o . +o. | +----[SHA256]-----+ 放在使用者資料夾下的  .ssh  資料夾中，其中  id_rsa  為私鑰、 id_rsa.pub  則為公鑰。 上傳金鑰 接著要把你的金鑰上傳到你的遠端主機上，你可

  假設今天購買了10T的硬碟, 那麼可以用GPT的方式進行硬碟分割(大於2G), 我們可以先規劃一下， 大約切割一半一半，那麼步驟如下 # 查看硬碟 lsblk # 使用gdisk對該硬碟進行分割 sudo gdisk /dev/sda Command: o ↵ This option deletes all partitions and creates a new protective MBR. Proceed? (Y/N): y ↵ Command: n ↵ Partition Number: 1 ↵ First sector: ↵ Last sector: +5T ↵ Hex Code: ↵ Command: n ↵ Partition Number: ↵ First sector: ↵ Last sector: ↵ Hex Code: ↵ print # 確認完成後寫入 w # 再查看分割後資訊 lsblk sda 8:0 0 9T 0 disk ├─sda1 8:1 0 5T 0 part └─sda2 8:2 0 4T 0 part 資源參考 https://www.funtoo.org/Partitioning_using_gdisk

 由於Javascript本身設計就適合於單線程的應用, 但一般後端應用程式都會支援多個服務來處理client的請求, nodejs中也提供了 cluster 模組來達成此功能。

  早期的 nodejs 為了具有多線程的能力而引入了 cluster 模組, 但這種創建線程的方式會犧牲共享內存, 且數據通信必須透過 json 來傳輸, 因此具有一定的侷限性及性能問題。

 

 

  用omitempty來過濾掉空的property造成bool false被過濾掉

  注意 * 與誰結合。

  一般來說我們如果將程式運行在console上，只要用 ctrl + c 之類的強制中斷方式就能讓程式中止，但如果我們想要在程式運行到一半時，偵測到某些例外狀況就離開程式，可以怎麼做呢？