文章專區

網頁程式技術探討

 延續本站先前討論過淺談網址 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就能判斷你是否為真人。     驗證碼的必要性 驗證碼已經漸漸融入各種網頁中,阻擋壞人進入,只讓好人通行的驗證碼漸漸的開始有被破解的危機,各大網站也開始慢慢研發不同樣式的驗證碼,但是驗證碼最初的用意是防止被惡意機器人的入侵,隨者人工智慧領域的研究成果越來越先進、驗證碼的升級,對使用者來說驗證碼漸漸以另一種更友善的形式存在,我們利用比較簡易的方式實現了這個功能。不再是麻煩的操作,對網際網路來說這個功能是具有有必要性,也很重要的安全指標。
SQL Injection 是網站系統中經常遇到的安全問題之一,利用SQL指令插入到表單並藉由特殊字元改變SQL語法結構,當這樣的命令被執行時攻擊者就可以直接對資料庫進行任何的動作。   假設現在有一個會員登入功能的網站,使用者登入時必須要驗證帳號、密碼,CommandText為「"select  *  from  member  where  account = '"  +  Request.Form["account"]  +  "'  and  password  =  '"  +  Request.Form["password"]  +  "'"」,帳號輸入「' or 1 = 1 --」,密碼隨意輸入,此時的指令就變成了「"select  *  from  member  where  account  =  ''  or  1=1 -- and  password = ''  "」,因為「--」為註解意思所以後半部的判斷式將不會被執行,而 1 = 1恆成立故駭客也就可以輕鬆登入。   SQL 攻擊就是如此簡單,僅需短短的指令就整個資料庫有極大的威脅,透過底下的防範方式可減少資料庫的傷害。     1.存取資料庫時給予帳號不同的權限   不應使用sa或是含有db_owner權限的帳號,如非必要不要賦予Create、Drop、Truncate table權限,可將成員資格限定為「db_datareader」、「db_datawriter」,   甚至可單獨對每個物件限定使用權限,但此種作法也比較累人就是。     2.過濾輸入的內容 在還沒有進行查詢前先把傳入的特殊符號如單引號(‘)、註解符號(--)、分號(;)過濾掉,亦可針對HTML或<script>標籤做些防範。 3.使用參數化查詢 存取資料時輸入的資料不是動態結合到SQL指令,而是透過參數來給值,資料庫在編譯SQL指令後才會套用參數。 SqlCommand cmd = new SqlCommand("select * from member where Account = @Account and Password = @Password", conn); cmd.Parameters.AddWithValue("Account", "admin"); cmd.Parameters.AddWithValue("Password", "admin"); conn.Open(); cmd.ExecuteNonQuery(); conn.Close(); 4.不要將錯誤訊息顯示於頁面上 如將 customErrors設定為off,頁面出錯時會直接把錯誤訊息顯示出來,那麼駭客就能利用這些漏洞攻擊。應建立錯誤頁面,並在網站發生錯誤時導向至該頁面 <customErrors mode="RemoteOnly" defaultRedirect="~/ErrorPages/ Error.aspx"/>    
      ASP為撰寫網頁程式的一種語言,使用環境需要架設IIS來模擬所需要的環境,為早期發網頁的主要語言,在日新月異的科技時代,眾多其他語言如雨後出筍般的出現,一來是為了能讓開發者能夠更快速或是更容易的撰寫出網頁,而有好的一面也會反映出不好的一面,當兩個不同的程式語言要呼相溝通時,這時候就會有困難,這時後你可能會知道有網路服務、Web Service等這些字眼。        什麼是Web Service?說實在可能每個工程師的解釋都不同,Web service算是一個軟體的服務元件,它透過標準的Web通訊協定及資料格式的共同標準來顯示,如像是HTTP或是SOAP等的應用服務提供溝、傳遞資料。說得有些模糊簡單講就是它是一個提供服務元件,它是以Web的資料開放標準。         以Web資料開放標準來制訂好處,能夠被廣泛的其他Web服務來使用,相對上具有良好的溝通性及支援性,能在不同平台上的語言能夠互相的傳遞、接收及回傳訊息,假設我們是製作一個旅行社的旅遊網站,網站本身除了自己的一些行程之外,有時候會包含了一些機場航班查詢、異地時間查詢及當地天氣等查詢服務,透過Web Service服務使用,不需要擔心上面提到的服務是使用什麼平台,對程式設計師而言,能夠輕易的將服務串接起來,可以快速輕鬆的將系統建置起來。Web Service基本架構是HTTP和XML,而核心元件是XML、SOAP、WSDL和UDDI,每個元件的詳細介紹及應用就不在此敘述。   以下範例由ASP簡單傳遞資料給Web Service及接收回傳資料:  '透過物件將參數宣告SOAP格式 Set oClient = Server.CreateObject("MSSOAP.SoapClient30") oClient.ClientProperty("ServerHTTPRequest") = True   '服務位置 ASPNetWebServiceUrl = "http://127.0.0.1/WebService.asmx" oClient.MSSoapInit ASPNetWebServiceUrl   '使用Web Service中的某個服務名稱及填入要傳遞的資料 '回傳訊息將會回給invoicenumber invoicenumber = oClient.function_name(data_xml)