第25個冬天

  在有一篇簡單介紹了port 443的 https https://coolmandiary.blogspot.com/2021/02/https.html 和基礎密碼學概念 而一個對外網站通常也對於安全認證算是一個門面 就跟豬肉攤有無拿到標示國產標章是類似概念 約2018之後 沒有HTTPS認證的網站預設會被Chrome瀏覽器標記為不安全 這更會影響流量和讓人多願意停留在此網頁上瀏覽的時間 在此我們採用certbot這套工具 Certbot 可在託管主機上執行的指令 sudo add-apt-repository ppa:certbot/certbot sudo apt-get update sudo apt install python-certbot-nginx (舊指令) sudo apt install python3-certbot-nginx (新版本要用這只令) 最後 sudo certbot --nginx -d {domain name} -d www.{domain name} 透過指令會自動幫我們 修改nginx default file的port設定指向443 路徑:/etc/nginx/sites-enabled 將預設80改為443  當指令一下會有如下output 這裡要小心注意會有兩個問題回應 其中當問到有用戶想要透過 HTTP 80來進入網站時要做的事情 要輸入2 給他重新導向443 HTTPS前綴的網站路徑 此時將網頁重新刷新就會發現本來顯示不安全的 突然變為有憑證的鎖頭外觀 通常是3個月就到期 這裡用 sudo certbot renew --dry-run 測試印出是否會在到期時重新啟用另一個憑證 移除參數 --dry-run 就會正常執行，會覆蓋舊憑證。 完整經過certbot幫我們弄好的 nginx default file配置文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 6...

近期在專案偕同上被Checkmarx掃碼掃到高風險的程式片段 偵測到Deserialization of Untrusted Data (OWASP  2017第8點Insecure Deserialization) 因此要做程式碼安全品質的修正 情境: Call web api 回傳回來(讀取外部的json測試檔案)的json  字串要反序列化轉為DataTable for GridView Bind呈現 CheckMarx掃碼報告給的說明 ============================================================ Deserialization of Untrusted Data 風險: 對不受信任的資料進行反序列化，可能允許攻擊者提供惡意的物件給反序列化程式碼使用。如果危險物件被不安全地反序列化，則可能透過反序列化的過程中，呼叫可能可用的類別(Class)或方法(method)來執行程式碼或操作系統命令。 此外，反序列化可能會繞過邏輯驗證。由於反序列化通常使用自己的方法，從序列化資料中構造新物件，因此它可以繞過建構函數或setter中強制執行的檢查，這將允許攻擊者反序列化未經驗證不正確或完全惡意的物件。這可能會導致例外狀況，進而影響程式邏輯。 發生原因: 序列化和反序列化物件，對於遠端Web Service流程是不可或缺的，其中物件通過Web Service(例如透過網路)在程式碼實作之間傳遞。在反序列化期間，從Web Service上提供的序列化物件建構新物件；但是，如果被反序列化的物件不受信任，則可能包含意外或有潛在危險的物件。 如何避免: 盡可能不要在遠端Web Service之間傳遞序列化物件。相反地，請考慮在Web Service之間傳遞原始值( value primitives)，並使用這些值填入新建構的物件。如果需要，使用白名單方法傳遞物件。 務必確保傳遞的物件是已知的、可信的和可預期的。除非物件已經過驗證且屬於受信任的已知類型，並且不包含不受信任的物件，否則不要從任何來源動態建構物件。 ============================================================ 攻擊者在欲被反解譯(de-serialize)回物件的byte stream...

 由於很久沒有抓過了所以有點小忘記 這裡在Little Note一下 開啟vs2019後 選複製存放庫 在本機新建一個空目錄 TFS側欄選擇 原始檔控制總管 針對目標專案repo去選擇對應的Local空目錄 按下確定->對應 選擇是 就會開始抓下來

  在頁面中有時會需要填寫 聯絡資訊地址等等 而台灣地址縣市對應轉換鄉政跟郵遞區號 在過去要串可能要自己手工刻製很久 可能要去弄捨麼爬蟲爬取國家地址縣市鄉鎮資訊、資料庫儲存 定時還要更新..... 而如今有TWzipcode 幫助我們節省了不少時間 jQuery外掛官網 https://code.essoduke.org/twzipcode/ 範例: See the Pen twzipcode_example by Jacob ( @dryjoker ) on CodePen . Ref: 縣市升格與網站地址表單雜談 https://www.minwt.com/webdesign-dev/js/21756.html 台灣縣市鄉鎮郵遞區號 下拉選單外掛 TWzipcode 使用心得 https://www.wfublog.com/2017/08/complex-form-custom-grid-system.html https://www.wfublog.com/2017/10/taiwan-county-town-zip-address-twzipcode-jquery.html 如何設計購物網站的地址欄位？ https://www.astralweb.com.tw/shopping-site-address/ [外掛] jQuery TWzipcode 免資料庫，只需載入外掛模組，立即產生臺灣 3 碼郵遞區號 https://www.minwt.com/webdesign-dev/js/21756.html

  在網頁中有時可能會類似要設計到一種主檔明細的資料呈現 這時如果搭配Bootstrap可以透過jQuery套件 bootstrap-table.min.js bootstrap-table-filter-control.min.js multiple-select.min.js 範例 See the Pen bootstrap_masterdetail_table(sub) by Jacob ( @dryjoker ) on CodePen .

 Promise  代表一個async操作，主要是用來解決call-back函數地獄式嵌套問題(call back hell) 主要有三種狀態:pending(進行中) , resolved(已經成功) 和 rejected(已失敗) 一旦狀態改變就不會再變，任何時候都能獲取這結果。 Promise 本身就是一種object，因此我們可以直接去new它。 Promise物件的狀態改變只會有兩種結果 從pending變為resolved和從pending變為rejected ->  成功(resolve)/失敗(reject) -> 成功就決定去做這件事情 -> 失敗就放棄去做這件事情 //簡單寫法-直接new .ver1 new Promise(function(resolve,reject){ //resolve();//成功就決定去做這件事情,return 1 reject();//失敗就放棄去做這件事情,return 2 }).then(function(){ alert(1); },function(){ alert(2); }); //簡單寫法-直接new.ver2 ... catch new Promise(function(resolve,reject){ //resolve();//成功就決定去做這件事情,return 1 reject();//失敗就放棄去做這件事情,return 2 }).then(function(){ alert(1); }).catch(function(){ alert(2); }) 複雜寫法-實體化後用變數存.ver1 let promise = new Promise((resolve,reject) => { .... }) promise.then(res => { console.log('res => ' , res); },err => { console.log('err => ' , err); }) 複雜寫法-實體化後用變數存.ver2 let promise = new Promise((resolve,reject) => { .... }) promis...

  一般在網路OSI第七層應用層當中的HTTP，預設採用「明文」傳輸而這對於網頁上資料的交換過程來說是十分缺乏安全性的。因而會在HTTP多加上一層 SSL/TLS 使其可以將傳輸資料進行加密，傳輸「密文」變作為HTTP S (Secure HTTP) ，讓有心人士(駭客)即便中途攔截到這些資料也無法直接破譯。 總體來說 除http之外其他還有Telnet、Ftp也是會以明碼傳輸 因此 Telnet (明碼) - > SSH (密文) Ftp(明碼) - > SFtp(密文) http(明碼) -> https(密文) 密碼學概念: 明文:未被加密過的原始資料。 密文:明文經由某種加密演算法加密後的產物，密文也可被解密得到原始明文。 加解密演算法: 又細分成「可逆」及「不可逆」的加密演算法。 而針對可逆加密演算法又分為「對稱式加密」、「非對稱式加密」。 密鑰:為一種參數，於明文轉換為密文或於密文轉為明文的算法中輸入的特定參數。 又可細分為「對稱式密鑰」、「非對稱式密鑰」分別被應用於「對稱式加密」、「非對稱式加密」。 對稱式 加密:又經常被稱作私鑰加密，意思是指訊息發送方和接收方 使用同一把密鑰 去進行資料的加解密，特點是演算法都是公開的，加解密的速度也快。適用於針對大量資料的情況做使用。 (加密跟解密使用的是同一把) 常見的對稱式加密演算法:DES、ˇDES、TDEA、RC5、IDEA、Blowfish... 加密過程:明文+加密演算法+私鑰->密文 解密過程:密文+解密算法+私鑰->明文 非對稱式 加密:又常被稱作公鑰加密，相對於對稱式加密是較為安全的。 因為對稱式加密溝通傳輸過程當中雙方使用同一把密鑰，若其中一方的密鑰遭洩漏那整個傳輸通訊過程就會被破解。 至於非對式加密則是使用 一對密鑰 而非只有一把，分為公鑰與私鑰，且兩者成對出現。 私鑰是自己留存不可對外洩漏，而公鑰則是公開的密鑰，任何人都能獲取。 用公鑰or私鑰鍾任一個來作加密用另一個進行解密。 (加密跟解密使用的是不同把) 若是採用公鑰加密的密文則只能用私鑰解密 加密過程: 明文+加密算法+公鑰 -> 密文 解密過程: 密文+解密算法+私鑰->明文 若是採用私鑰加密過的密文則只能用公鑰解密 加密過程: 明文+加密算法+私鑰 -> 密文 解密過...

  近期在進行活動官網後台部落格系統設計時 遇到的問題 由於內文直接輸入的文字段落到了網頁後不會認識換行跟一些列表(1、2、...)、粗體、空格等等 樣式根本沒辦法自由設定 因此這裡找到了一款還滿老牌有名氣的 ckeditor 第三方套件來幫助我們達成 富文本編輯器的效果 (有點類似Blogger有很多基本樣式設定預設可以自行幫你添加一些html跟css樣式，不用要用戶自己還要去寫html tag之類的) 其為open source 授權採用GNU GPL v2 之後 https://ckeditor.com/legal/ckeditor-oss-license/ 到官方網站這裡我們挑選ckeditor4 (雖然最新有出到5不過據說功能不完全跟而且是類似完全翻新寫的沒有向下相容) https://ckeditor.com/ckeditor-4/download/?null-addons= 首先將解壓好的ckeditor  folder 整包放到專案目錄中js讀取的專屬目錄 在html一開始引入 js部分 是要把原本textarea的部分改成CKEditor的編輯器， 因此()裡面的內容一定要和textarea中id或者name屬性的內容一樣才行(這裡用content)。 效果 接著要來測試post到後端時能否抓地到CKEditor裡面的編輯內容 這裡輸入一段文字 在從資料庫儲存讀值並render到html後效果看起來沒有正確變成該有的格式.... 好像多出了雙引號 這裡經過修正 將EJS的綁定從 <%=.....%>  改為 <%- .....%>即可 在一般透過  ejs render到頁面中的若是純文字字串可以用<%=...%> 但若是要呈現出html效果就要用<%-....%>了 其餘的EJS綁定語法 <% 'Scriptlet' tag, for control-flow, no output <%_ ‘Whitespace Slurping’ Scriptlet tag, strips all whitespace before it <%= Outputs the value into the template (HTML escaped) <%...

  通常一個頁面上要呈現的表格資料 可能會用table、GridView來作呈現 只是畫面難免容易因為來自使用者無固定長度輸入的內容而有非預期的外觀跑版問題 此時解法可以透過 於PreRender事件動態註冊 以asp.net   gridview為例 1 2 3 4 protected void gvw_PreRender ( object sender, EventArgs e) { gvwData.Attributes.Add( "style" , "word-break:break-word;word-wrap:normal" ); } 或者也可以寫死在aspx中的gridview style 1 2 3 4 5 6 <asp:GridView ID= "gvwData" runat= "server" AutoGenerateColumns= "False" OnPreRender= "gvw_PreRender" style= "word-break:break-word; word-wrap:normal;" Width= "100%" EmptyDataText= "無資料" ShowHeaderWhenEmpty= "True" > </asp:GridView> 這裡 word-break : 設定瀏覽器要在什麼樣的情況下讓字串斷行 常見的設定主要分為兩種 分別是 (1)換行的時候要保持單字完整 (2)無論單字是否完整都直接換行 https://www.w3schools.com/cssref/css3_pr_word-break.asp Value Description normal Default value. Uses default line break rules break-all To prevent overflow, word may be broken at any character keep-all  Word breaks should not be...

  在上一篇 使用Digital Ocean超快速搭建出部屬NodeJs的主機 介紹到如何deploy你的NodeJs應用到數位海洋的Droplet 這次要介紹如何綁定域名 這次主要示範從GoDaddy上購買完一個doamin name之後如何轉移到digital ocean上 首先你必須先購買一個域名(可以透過GoDaddy或者NameCheap) 購買好之後 到Digital Ocean  Droplets側欄頁籤按鈕 配置頁面選擇Add Domain下拉選單進入到Networking的Domain Name 輸入完剛購買的域名後按下Add Domain進行創建 這裡建議除了預設@直接自己的網域之外 也加上www的子網域 預設Digital Ocean DNS 是這些預定內容 ns1.digitalocean.com ns2.digitalocean.com ns3.digitalocean.com 到GoDaddy 後台選DNS管理 選擇【我要用自己的名稱伺服器】 一筆一筆添加輸入儲存後儲存 等1至5分鐘之後就完成domain name的綁定 2023年補充若只是剛開始測試沒有打算添購域名 則可以暫時先來NoIp來申請一個免費(要每隔30天就啟用激活) 這邊去輸入你想客製化(不能有人用過必須唯一)的hostname 並挑選對應的次級域名 A紀錄是一種DNS紀錄類型，當架設一個網站後，網站主機商會提供您 一組IP位置，設定A紀錄。 主機名稱欄位不可輸入 ，除了 - (中線) 以外的特殊符號。 假設這裡配置的對應IP為此組 Ref: Connecting a GoDaddy domain with DigitalOcean droplet [Step by step guide with images] https://top5hosting.co.uk/blog/uk-hosting/361-connecting-a-godaddy-domain-with-digitalocean-droplet-step-by-step-guide-with-images 輸入網址 https://domain.com 無法瀏覽，但加上 www 即可瀏覽，原因 https://esupport.tw/site/%E7%B6%B2%E7%AB%99%E7%84...

通常在寫程式往往著重於功能實踐而遺忘了 程式夠不夠安全或者也不曉得如何去判定程式是否有合乎安全 而安全性指標較常在網頁應用系統中被人重視 全球知名的非營利OWASP組織(Open Web Application Security Project)專注在增進軟體安全。 網頁:https://owasp.org/ 就曾發起眾多與安全相關的專案 OWASP Top 10(十大網站安全風險) OWASP API Security Top 10 OWASP Mobile Top 10(十大行動裝置安全風險) OWASP Internet of Things Project (十大物聯網安全風險) Application Security Verification Standard(系統安全驗證) Software Assurance Maturity Model(軟體安全成熟度) OWASP Enterprise Security API (ESAPI) 本篇就只針對 2017 OWASP Top 10(十大網站安全風險) 進行一個筆記整理分享 1. Injection  ：注入攻擊 在網路應用程式，尤其以SQL Injection裡很常見。Injection之所以會發生，是因為使用者提供的資料傳輸到一個interpreter，沒有經過妥善的檢查、排除特殊符號或參數化查詢(Prepared statement)等處裡 使此輸入被當成指令（Command）或是查詢（Query）。攻擊者就能用惡意的資料欺騙interpreter，而達到執行指令或是竄改資料的目的。 (除了是 2017 版的第一名，同時也是 2013 版的第一名!) 除了SQL注入當然也包含其他種類注入，比如 XML Injection也算其中一種(就被歸類到第四名的 XXE , XML 外部處理器弱點) 攻擊手法: 1.有資料輸入欄位 2.使用網址列傳遞變數 3.未過濾特殊字元 4.顯示SQL錯誤訊息 以 .NET C# Code 來看實際程式發生案例 Bad 寫法 當有心人士輸入 Username: alice@bank.com Password: ' or 1=1)# 就可以進入本來應該只有 alice才有權限的頁面 改善方案: 使用過濾字串函數過濾非法的字元 使用 Prepared Sta...