文章專區

網頁程式技術探討

      一夕之間引起全球資訊恐慌的勒索病毒「WannaCry」來勢洶洶,在網際網路開始發展至今其實一直都存在著各式各樣病毒,為什麼「WannaCry」卻會在這波攻擊下引起這麼高度的注意呢?在於它是針對大多數人所使用的微軟windows系統弱點進行研發,攻擊的方式並不是只在於破壞作業系統,不像一般病毒重灌作業系統後還能救回其他磁碟槽的資料,卻是會鎖住電腦中所有的檔案並予加密,讓你看得見檔案卻無法再開啟,並且進行勒索贖金,而最令機關行號擔心的是,此款病毒可以透過區域網路進行傳染攻擊,因此一台電腦中毒就等於其他電腦也有受到威脅的可能性,現實中已經影響到金融,能源,醫療等行業,校園網用戶首當其衝,受害嚴重的危機管理問題。            在網站的伺服器上,同樣也會面臨這樣的問題,尤其是許多私人架設或小型的網站伺服器,由於伺服器通常只用來穩定網站空間,因此用於實際作業與更新的機會上相較一般電腦的機會來的低很多,甚至使用較舊版本的伺服器作業系統會直接停止更新,這部分就會造成網站暴露在一個危險的狀態下甚至危險程度會大於一般常用的電腦,所以不論是私人架設的伺服器還是小型網站伺服器,在更新與程式版本升級還是有必要性的定期維護。  
    在網頁設計程式開發時,SQL Server 與 My SQL 都是在Windows較常見的資料庫,由於兩種語法較為貼近相似,所以在選擇上比較常拿來比較,大多數人都會覺得My SQL是免費型的資料庫,但這僅適用於個人網站或是小型簡易網站的應用,在商業性及進階的網站整合功能上,目前My SQL還是需要付費商業性的授權。       瞭解其實在完整的商業開發上,兩套資料庫都是需要授權上的費用後,我們可以由介面的友善及功能對應的完整性進行考量,由於SQL Server較其他資料庫不同的地方是,它只對應Windows系統,不能應用在其他如Linux或UNIX等的系統上,而Windows也是目前大眾較常習慣接觸使用的介面,所以在開發上它較能符合一般人的操作習慣,因此假設是在不熟悉Linux或UNIX等其他的系統時,會比較建議使用SQL Server,如果有考慮使用不同作業系統時便可以考慮 My SQL。       在架設網站類型時,可以參考網站的用途或內容方向來配合使用的語法與資料庫,普遍架設個人網站或較小型網站時訪間有許多PHP對應My SQL的開發模型及相關教學範例可以參考架設,所以架設基礎較為簡易開放,而考量使用在較商業化的網站開發時,需要較多元性的功能,大多是會使用.NET語法與SQL Server資料庫來配合功能較為複雜及多元的需求,SQL Server在安裝後其實有包含非常多的工具可以應用,如:報表、資料轉換(ETL)、商業智慧(BI)等,幾乎一應具全,這或也就是大多數人喜歡SQL Server的原因之一。       SQL Server 與 My SQL,兩套資料庫在語法上有較相近的與法與操作,也有適合不同層面的開發應用,因此在選擇資料庫的同時可以先瞭解架設時的需求及目標進行選擇使用。
 延續本站先前討論過淺談網址 HTTP 與 HTTPS 的差別 及 SSL/TLS與HTTPS的相關性和 SSL/TLS數位憑證該如選擇後,我們將可以正式為網站置入設定安全憑證囉,在設定SSL/TLS憑證時步驟較為繁瑣,本站將以較為主軸的步驟簡化來讓大家瞭解該往什麼樣的方向來操作。 我們瞭解了SSL/TLS憑證需要透過與具有公信力的憑證廠商(Certificate Authority)來核發後,首要我們需要先準備的是建立一個"憑證要求檔(Certificate Signing Request file,簡稱CSR檔)",這個憑證要求檔內容主要是需要填入關於您將要申請憑證的註冊資訊,一般主要為輸入需要SSL/TLS的網址及公司行號的名稱等相關資訊,而建立這個檔案便是要提供給憑證廠商對我們伺服器進行核對的一個驗證檔。   建立好CSR檔時,我們便可以開始購買選定好SSL/TLS憑證,在填寫資訊其中憑證廠商會需要您提供CSR檔進行驗證,在驗證無誤下,憑證廠商便會產生合法有效的憑證檔(CRT)給您,這當中廠商會給予"您伺服器的憑證"與"中繼憑證"和"根憑證"(如果使用的是較為知名廠商,根憑證都會預設內建在您的作業系統中,通常不用再安裝),將憑證根據廠商提供的路徑正確置入後,再驗證植入的正確性就可以確定是否安裝完全。 最後到SSL/TLS站台中選取"您伺服器的憑證",並將網址類型選擇為 https,確定即可將SSL/TLS憑證設定完成,開啟網站安全加密傳輸。以上文中及先前文章,本站主要希望提供大家能多瞭解HTTPS及網路連線安全加密的重要性及過程,希望使大家在網際網路暢遊的其中能多一份保障,以上較詳細的相關技術與其他需要服務的部分,歡迎大家透過連絡我們與本站來進行諮詢與提供服務。  
 在 Google Chrome 瀏覽器中,網站如果在沒有安裝 SSL 數位憑證保護下,瀏覽器會強制在網址欄位中明確標示不安全的標記,延續本站先前討論過淺談網址 HTTP 與 HTTPS 的差別 及 SSL與HTTPS的相關性,在瞭解了HTTPS需要SSL憑證後,一般人將會遇到另一個疑問,那便是該如何取得SSL憑證?多樣性的SSL憑證該如何選擇? SSL憑證有如識別證一般,在資料開始加密傳輸前,伺服器透過「有效」的SSL憑證來與用戶端識別確認是安全的伺服器,SSL憑證主要透過伺服器站台來產生,而在業界有著眾多的憑證廠商又該如何選擇呢?以下提供幾點可以依循的方向。   1.SSL憑證又分為「有效」與「無效」的憑證,「有效」的憑證主要是透過憑證廠商(Certificate Authority)對申請人做身份的核對確認再給予簽發,其中可以瞭解有些憑證廠商對於核發憑證的條件較為寬鬆,較能輕易取得憑證,看似方便卻隱藏著有心人冒用身分取得憑證或架設釣魚網站的疑慮,反觀面對核發條件越為嚴苛、安全機制較高的廠商便越能降低憑證冒用的風險。   2.根據外國帳戶稅收遵從法FATCA其中條例,在電子交易資訊上需要有效及具國際公信憑證資料的憑證廠商進行加密,因此選擇憑證廠商可以根據符合國際公信力的廠商為優先,選擇可靠的廠商可以保障網站的公鑰和SSL憑證能有效確保使用者和伺服器之間傳輸的資訊,同時,當用使用者在瀏覽網站時可以瞭解網站所使用的SSL機制,也可能提高使用者的信任與使用意願。   3.許多憑證主打輕鬆經濟方案驗證快速,但給予憑證的時效性卻是較為短暫,在考慮網站長期的經營與維護之下,就必須要不斷地去延長憑證時效或是更換其他憑證廠商,其中就可能需要再耗費些時間去檢視憑證、續約或找尋其他憑證廠商及更換的問題。 最後,根據不同類型的網站會需要不同的安全憑證,所以在選購憑證時,可以根據網站的需求適時挑選安全性較高的憑證,如:提供金流、刷卡機制服務及商業性相關的網站。憑證雖然有價格上的差異,但網站就如同一家公司的門面與形象,因此選擇安心可靠的廠商,有助網站永續經營、品牌形象的提升,也能為您避免些不必要的安全疑慮。  
     針對HTTP與HTTPS的差異,本站先前討論過淺談網址 HTTP 與 HTTPS 的差別,隨著網路的發達,資訊技術越來越透明,HTTP的開放明文顯得在網際網路中,不再是這麼安全的傳送協定,知名企業網站及全球級大型網站Google、Facebook等皆採用HTTPS加密,作為預設連線方式,因此也針對在有使用者登入系統或或存取到機密敏感資料頁面等有建立會員、購物車、金流、刷卡機制服務的網站選擇使用HTTPS的傳送協定。          HTTPS網站傳輸安全協定,主要是由網景公司(Netscape)開發並內建於其瀏覽器中,之後廣泛發展於網際網路上,用於對資料進行壓縮傳輸及傳輸後解壓縮回正確資訊的操作。HTTPS是以安全為目的得HTTP通道,經由網站傳輸協定進行通訊和利用SSL/TLS憑證來加密封包,簡單來說就是HTTP的進階安全版,由HTTP下加入SSL/TLS 層作為安全基礎。          SSL/TLS  (安全通訊端層) 憑證是網頁伺服器和瀏覽器之間以加解密方式溝通的安全技術標準,透過憑證內的公開金鑰加密資料傳輸至伺服器端,伺服器端用私密金鑰解密來證明自己的身份,取得有效憑證後在網際網路上傳輸加密過的資料以達到資安的目的。          透過HTTP下加入SSL/TLS層作為安全基礎的HTTPS,是網頁伺服器和瀏覽器之間以加解密方式溝通的安全技術標準,通信任務內含網路瀏覽、電子信件、際網路傳真、即時訊息、VoIP和等等其它資料傳輸,這個溝通過程能有效確保了所有在伺服器與瀏覽器之間通過資料的私密性與完整性,而SSL是一個企業級標準,用來保護網站與客戶的線上交易資訊,所以為了使用SSL/TLS安全連結,一個網頁伺服器便需要一個具有公信力的有效的憑證。  
 現今網際網路技術發展快速,許多資訊越來越透明,相對駭客破解密碼的技術也越來越高明,面對這樣的情況,密碼的安全編制與加密就不能像以往早期的這麼簡易,跟著安全技術的演進,我們可以大約瞭解大多數的密碼儲存有底下幾種方式 1.  明文儲存 明文就是沒有加密的文字,密碼採用明文傳輸或存放,駭客只要有監聽或入侵伺服器的動作,那麼駭客就能輕易的取走了所有人的密碼。將會有很多安全風險。 2.  對稱式加密演算法加密後儲存 對稱式加密是透過相同的金鑰來加、解密,如:DES、Triple DES、Rijndael(AES)等,即便是已加密過後的字串,但只要有人拿到加密的金鑰並依其可逆之特性還是能讓這些加密後的字串還原回來。 3.  雜湊(Hash)加密後儲存 雜湊式加密為以往較多人使用的加密方法,如:MD5、SHA1、SHA256等為不可逆之演算法,不像對稱演算法可以靠程式運算還原內容,但經過多方研究後,如果透過對照表(Rainbow Table)還是有機會對照出原始密碼。 4.  雜湊(Hash)並加鹽(Salt)加密後儲存 透過雜湊儲存密碼依然不夠安全,所以我們要再多加些鹽(Salt)來提升安全性,可以利用隨機函數產生Salt,這也是為了避免相同資料產生相同雜湊值。 加「鹽」(Salt)指的是,在密碼以雜湊(Hash)加密前,先在密碼的前面或後面或以特定規則於密碼中加入一些字元,而且這些被加入的字元以亂數產生,一方面增加密碼的長度,一方面因為這些字元是亂數產生,可大幅增加駭客破解的難度! 我們將原始密碼與鹽字元放在一起,明碼123456 + 鹽字元915430BB-165D-49A3-BAE3-329984CC47D3經過MD5雜湊後的結果是8775387801BDEE3123554D4EAE697C30,因密碼有用Salt且隨著鹽的複雜度增加,想利用Rainbow Table或自行撰寫程式等方式進行破解就更加有難度。                隨著網路平台日益發達,駭客攻擊手法也越來越多,如果可以一定要透過加密方式來保存機密資料以便保障使用者個資安全。  
交易的基礎 網頁設計開發交易平台作業時,會將多項工作連繫在一起。如同應用程式正在執行兩項工作,一開始會在資料庫中建立新的表格,之後呼叫特定物件來收集與格式化資料,然後將資料插入新的表格中。這兩項工作都是相關的,在單一交易範圍內執行這兩項工作,會將這兩項工作強制串聯在一起。如果其中一項工作失敗,另一項工作就會復原至建立新表格之前的時間點,簡單來說,確保一組相關工作會全部成功或失敗。   資料庫系統最主要的操作就是存取資料庫中的資料,如果有多個存取操作要執行,且這些操作視無法分割的單位,則整個操作過程,對於資料庫系統是一個「交易」(Transaction)。   基本資料庫單元操作(Atomic Database Actions) 交易是將資料庫單元操作的集合,視為一個不可分割的邏輯單位(Logical Unit)。並且使用並行控制(Concurrency Control)和回復處理(Recovery)機制來保障交易能夠成功的執行。資料庫單元操作只有兩種:讀取和寫入。   交易狀態 交易是將多個資料庫單元操作視為同一個不可分割的邏輯單元,這些資料庫單元的操作,只有兩種結果:一種是全部執行完成;另一種就是通通不執行,不可能有執行一半的情形發生。  交易狀態的種類 ◎啟動狀態:當交易開始執行,就是進入啟動狀態的初始狀態,依序執行交易的讀取或寫入。 ◎部分確認交易狀態:當交易的最後一個單元操作執行完後,也就是交易結束,就進入部分確認交易狀態。 ◎確認交易狀態:在成功完成交易進入部分確認交易狀態後,還需要確認系統沒有錯誤,可以真正交資料寫入資料庫。 ◎失敗狀態:當發現交易不能繼續執行下去時,交易就進入失敗狀態,準備執行回復交易。 ◎放棄或中止狀態:交易需要回復到交易前的狀態,在取消所有寫入資料庫操作單元操作影響的資料後,就進入此狀態。 交易停止執行的原因 ◎交易成功:就是正常結束交易的執行,指交易的資料庫單元操作全部執行完成。 ◎交易失敗:交易失敗是放出放棄指令(Abort或Rollback)來結束交易的執行。 ◎放棄交易:交意本身因為條件錯誤,輸入錯誤資料或使用者操作而送出放棄指令來放棄交易的執行。 ◎中止交易:因為系統負載問題或死結情況,由資料庫管理系統送出放棄指令,讓交易進入中止狀態。 ◎交易未完成:交易可能因為系統錯誤、硬體錯誤或當機而停止交易執行,因為沒有送出放棄指令,此時交易是未完成的中斷狀態。  
1.InProc:預設儲存方式,所有的session都會被儲存進iis processs裡面,當更新web.config、bin目錄下的dll或iis 重啟時都會造成所有session被清除。 2.StateServer:將session儲存於ASP.NET 狀態服務裡面,使用此模式可以確保應用程式重啟時得以讓資訊保留下來。使用此模式時需確保ASP.NET 狀態服務(ASP.NET State Server)為啟用狀態。  並設定web.config <configuration>     <system.web>         <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424"           timeout="20"/>     </system.web> </configuration> 3.SQLServer:儲存於SQL Server中,可以使用 Aspnet_regsql.exe 工具安裝資料庫(預設資料庫為ASPState),web.config設定如下 <configuration>     <system.web>         <sessionState mode="SQLServer" timeout="20" sqlConnectionString="Data Source=Server;Integrated-Security=SSPI;" />     </system.web> </configuration> 4.Custom:自訂一個儲存方式並使用此方式來存放session ※使用StateServer或SQLServer模式時,物件必須可序列化,只需要在類別前加上 [Serializable] 即可。  
 一般人並不會太注意網址開頭的http與https差異,甚至您會發現在Google瀏覽器Chrome上,網址連結為http開頭的網址還會將您自動縮寫,直接顯示http//後的連結網址。   但在網址連結上HTTP與TTPS的差別不單單只是1個英文字S的差異,這僅一個字母S的差別卻代表了網站使用編碼協定的安全性(secure),http://跟https://之間的不同在於網路文字傳送協定中標準的不同,您可以在Google瀏覽器Chrome上瞭解,在網址欄位上連結為https開始的網址會多顯示"安全"標示,讓您簡單的瞭解網站對於使用者的友善性。    http是網頁與您的電腦瀏覽器直接透過明文進行傳輸,以一般(非安全)模式下進行互動交談,所以在網際網路上內容有可能遭攔有心人士截竊聽的,HTTP協定不使用加密協定,其中原因包含:加密會多消耗許多運算資源,也會佔用更多的傳輸頻寬,而緩存機制跟著會失效。 反觀HTTPS協定,以保密為前提為研發,可以算是HTTP的進階安全版。是以加入SSL協定作為 安全憑證,因此網站透過協定上的加密機制後能夠防止資料竊取者就算攔截到了傳輸資訊卻也無法直接看到傳輸中的資料,也因此較大型有串聯金融信用機制會使用到較敏感度資料的企業網站多會選擇使用HTTPS協定,提供保障客戶在網站上的使用資訊。   現今隨著網路資訊的發達,技術資訊越來越透明,反觀卻增進了許多有心人士的好奇心,因此http的開放明文顯得在網際網路中,不再是這麼安全的傳送協定,所以也建議有建立會員、購物車、金流、刷卡機制服務的網站選擇使用HTTPS的傳送協定,如果對於這方面有興趣與疑問的情況下,歡迎大家使用聯絡我們與我們聯繫,將再詳細進解說。  
為何需要驗證碼? 現在網路上有許多功能必須要使用表單填入,因此網際網路上也越來越多暴力破解等其他網路機器人方式進行不斷的登陸嘗試,要如何避免防止被有心人士或網路機器人工具惡意註冊或者惡意填入大量垃圾資料,此時必須在加一道安全防護來避免,才能確保網站順利運作。 CAPTCHA 全名為「全自動區分電腦和人類的圖靈測試(Completely Automated Public Turing test to tell Computers and Humans Apart)」。在 CAPTCHA 測試中,作為伺服器的電腦會自動生成一個問題由用戶來解答。這個問題可以由電腦生成並評判,但是必須只有人類才能解答。由於電腦無法解答 CAPTCHA 的問題,所以回答出問題的用戶就可以被認為是人類。簡單的定義:「此問題必須只有人類才能解答,由於電腦無法回答出來,所以回答出正確答案的使用者就被認為是人類。」   驗證碼是在阻擋惡意機器人,還是增加使用者的麻煩 驗證碼技術是一種電腦技術發展下的矛盾產物,人類渴望電腦能夠通過自動化的過程完成更多的任務,卻同樣要防止電腦被利用在破壞與惡意的用途當中,從各方面來說驗證碼是為了防衛惡意機器人的入侵,但某種程度上對使用者來說仍造成不小的困擾,像是驗證碼常出現的「0(零)」跟「o(歐)」或是「1」跟「l」常常讓人無從分辨。在科技日新月異的現在,驗證碼漸漸以另一種更友善的形式存在,有如Siri等人工智慧領域的研究成果越來越先進,電腦將變得越來越通情達。   No CAPTCHA 在科技日新月異下,機器人也慢慢看得懂驗證碼了,根據Google研究,現在最高科技的人工智慧技術,可以讓機器辨識出 CAPTCHA 驗證碼內容,而且準確率可以到達99.8%,已經比真正的人類還更能看懂驗證碼了。 Google推出的No CAPTCHA不需要經過難解的扭曲文字照片,就能讓網站辨識出目前的使用者是真正的人,而非機器人。對於使用者來說,看到驗證碼時,只要「勾選」我不是機器人, Google就能判斷你是否為真人。     驗證碼的必要性 驗證碼已經漸漸融入各種網頁中,阻擋壞人進入,只讓好人通行的驗證碼漸漸的開始有被破解的危機,各大網站也開始慢慢研發不同樣式的驗證碼,但是驗證碼最初的用意是防止被惡意機器人的入侵,隨者人工智慧領域的研究成果越來越先進、驗證碼的升級,對使用者來說驗證碼漸漸以另一種更友善的形式存在,我們利用比較簡易的方式實現了這個功能。不再是麻煩的操作,對網際網路來說這個功能是具有有必要性,也很重要的安全指標。