前端開發常見的安全問題介紹
常見問題介紹:
(學習影片分享:程式設計影片)
1、跨站腳本攻擊(XSS攻擊)
XSS(Cross Site Scripting),跨站腳本攻擊。 XSS是常見的Web攻擊技術之一.所謂的跨站腳本攻擊指得是:惡意攻擊者往Web頁面裡注入惡意Script程式碼,使用者瀏覽這些網頁時,就會執行其中的惡意程式碼,可對使用者進行盜取cookie資訊、會話劫持等各種攻擊.
解決方案:
(1) 輸入過濾。永遠不要相信使用者的輸入,對使用者輸入的資料做一定的過濾。如輸入的資料是否符合預期的格式,例如日期格式,Email格式,電話號碼
碼格式等等。這樣可以初步對XSS漏洞進行防禦。上面的措施只在web端做了限制,攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制,修改請求注入攻擊腳本。
因此,後台伺服器需要在接收到使用者輸入的資料後,對特殊危險字元進行過濾或轉義處理,然後再儲存到資料庫中。 (2) 輸出編碼。伺服器端輸出到瀏覽器的數據,
可以使用系統的安全函數來進行編碼或轉義來防範XSS攻擊。在PHP中,有htmlentities()和htmlspecialchars()兩個函數可以滿足安全要求。對應的JavaScript的編
碼方式可以使用JavascriptEncode。 (3) 安全編碼。開發需盡量避免Web客戶端文件重寫、重定向或其他敏感操作,同時要避免使用客戶端數據,這些操作需盡量在服
務器端使用動態頁面來實現。 (4) HttpOnly Cookie。預防XSS攻擊竊取用戶cookie最有效的防禦手段。 Web應用程式在設定cookie時,將其屬性設為HttpOnly,
就可以避免該網頁的cookie被客戶端惡意JavaScript竊取,保護使用者cookie資訊。 (5)WAF(Web Application Firewall),Web應用防火牆,主要的功能是防範諸如網頁木馬、
XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發,在企業環境中深受歡迎。
2、跨站請求偽造(CSRF攻擊)
CSRF(Cross Site Request Forgery),即跨站請求偽造,是一種常見的Web攻擊,但許多開發者對它很陌生。 CSRF也是Web安全中最容易被忽略的一種 網站攻擊
CSRF攻擊的原理:CSRF攻擊過程的受害者使用者登入網站A,輸入個人訊息,在本地保存伺服器產生的cookie。然後在A網站點擊由攻擊者建立一條惡意連結跳到
B網站, 然後B網站攜帶著的使用者cookie訊息去造訪B網站.讓A網站造成是使用者自己造訪的假相,從而來進行一些列的操作,常見的就是轉帳.
解決方案:
(1) 驗證碼。在應用程式和使用者進行互動過程中,特別是帳戶交易這種核心步驟,強制使用者輸入驗證碼,才能完成最終請求。在通常情況下,驗證碼足夠很好地遏制
CSRF攻擊。但增加驗證碼降低了使用者的體驗,網站不能為所有的操作加上驗證碼。所以只能將驗證碼當作輔助手段,在關鍵業務點設定驗證碼。 (2) Referer Check。
HTTP Referer是header的一部分,當瀏覽器向web伺服器發送請求時,一般會帶上Referer資訊告訴伺服器是從哪個頁面連結過來的,伺服器來源此可以獲得一些資訊用於處
理。可以透過檢查請求的來源來防禦CSRF攻擊。正常請求的referer具有一定規律,如在提交表單的referer必定是在該頁面發起的請求。所以透過檢查http包頭referer的值
是不是這個頁面,來判斷是不是CSRF攻擊。但在某些情況下如從https跳到http,瀏覽器處於安全考慮,不會發送referer,伺服器就無法進行check了。若與該網站同域的
其他網站有XSS漏洞,那麼攻擊者可以在其他網站注入惡意腳本,受害者進入了此類同域的網址,也會遭受攻擊。基於以上原因,無法完全依賴Referer Check作為防禦CSRF
的主要手段。但是可以透過Referer Check來監控CSRF攻擊的發生。 (3) Anti CSRF Token。目前比較完善的解決方案是加入Anti-CSRF-Token,即發送請求時在HTTP 請
#求中以參數的形式加入一個隨機產生的token,並在伺服器建立一個攔截器來驗證這個token。伺服器讀取瀏覽器目前域cookie中這個token值,會進行校驗該請求當中的token
#和cookie當中的token值是否都存在且相等,才認為這是合法的請求。否則認為這次請求是違法的,拒絕該次服務。這種方法相比Referer檢查要安全很多,token可以在用戶
登陸後產生並放於session或cookie中,然後在每次請求時伺服器把token從session或cookie中拿出,與本次請求中的token 進行比對。由於token的存在,攻擊者無法再建構
出一個完整的URL實作CSRF攻擊。但在處理多個頁面共存問題時,當某個頁面消耗掉token後,其他頁面的表單保存的還是被消耗掉的那個token,其他頁面的表單提交時會出
#現token錯誤。
3、SQL注入攻擊
SQL注入(SQL Injection),應用程式在向後台資料庫傳遞SQL(Structured Query Language,結構化查詢語言)時,攻擊者將SQL指令插入到Web表單提交或輸入網域或頁面請求的查詢字串,最終達到欺騙伺服器執行惡意的SQL指令.
解決方案:
(1) 防止系統敏感資訊外洩。設定php.ini選項display_errors=off,防止php腳本出錯之後,在web頁面輸出敏感資訊錯誤,讓攻擊者有機可乘。 (2) 數據轉義。設定php.ini選項magic_quotes_gpc=on,它會將提交的變數中所有的'(單引號),」(雙引號),\(反斜線),空白字元等都在前面自動加上\。或採用mysql_real_escape()函數或addslashes()函數進行輸入參數的轉義。(3) 增加黑名單或白名單驗證。白名單驗證一般指,檢查使用者輸入是否為符合預期的類型、長度、數值範圍或其他格式標準。黑名單驗證是指,若在用戶輸入中,包含明顯的惡意內容則拒絕該條用戶請求。在使用白名單驗證時,一般會配合黑名單驗證。
#4、文件上傳漏洞
上傳漏洞在DVBBS6.0時代被駭客利用的最為猖獗,利用上傳漏洞可以直接得到WEBSHELL,危害等級超級高,現在的入侵中上傳漏洞也是常見的漏洞。該漏洞允許用戶上傳任意檔案可能會讓攻擊者註入危險內容或惡意程式碼,並在伺服器上執行。檔案上傳漏洞的原理:由於檔案上傳功能實作程式碼沒有嚴格限制使用者上傳的檔案後綴以及檔案類型,導致允許攻擊者向某個可透過Web 存取的目錄上傳任何PHP文件,並且能夠將這些文件傳遞給PHP 解釋器,就可以在遠端伺服器上執行任意PHP腳本。
解決方案:
# (1) 檢查伺服器是否判斷了上傳檔案類型及後綴。(2) 定義上傳檔案類型白名單,即只允許白名單裡面類型的檔案上傳。(3) 檔案上傳目錄禁止執行腳本解析,避免攻擊者進行二次攻擊。 Info漏洞Info漏洞就是CGI把輸入的參數原樣輸出到頁面,攻擊者透過修改輸入參數而達到欺騙用戶的目的。
詳細介紹:網站安全
以上是前端開發常見的安全問題介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章!

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

Go語言作為一種快速、高效的程式語言,在後端開發領域廣受歡迎。然而,很少有人將Go語言與前端開發聯繫起來。事實上,使用Go語言進行前端開發不僅可以提高效率,還能為開發者帶來全新的視野。本文將探討使用Go語言進行前端開發的可能性,並提供具體的程式碼範例,幫助讀者更了解這一領域。在傳統的前端開發中,通常會使用JavaScript、HTML和CSS來建立使用者介面

在使用C++實作機器學習演算法時,安全考量至關重要,包括資料隱私、模型篡改和輸入驗證。最佳實務包括採用安全庫、最小化權限、使用沙盒和持續監控。實戰案例中展示了使用Botan庫對CNN模型進行加密和解密,以確保安全訓練和預測。

為保護Struts2應用程序,可以使用以下安全性配置:停用未使用的功能啟用內容類型檢查驗證輸入啟用安全性令牌防止CSRF攻擊使用RBAC限制基於角色的訪問

Slim和Phalcon在PHP微框架的安全性比較中,Phalcon內建有CSRF和XSS防護、表單驗證等安全特性,而Slim缺乏開箱即用的安全特性,需手動實施安全措施。對於安全至關重要的應用程序,Phalcon提供了更全面的保護,是更好的選擇。

如何增強SpringBoot框架的安全性增強SpringBoot應用的安全至關重要,以保護使用者資料和防止攻擊。以下是增強SpringBoot安全性的幾個關鍵步驟:1.啟用HTTPS使用HTTPS在伺服器和客戶端之間建立安全的連接,防止資訊被竊聽或篡改。在SpringBoot中,可以透過在application.properties中配置以下內容來啟用HTTPS:server.ssl.key-store=path/to/keystore.jksserver.ssl.k

透過平衡安全需求和業務需求,Java框架設計可實現安全性:識別關鍵業務需求,優先考慮相關安全要求。制定彈性安全策略,分層應對威脅,定期調整。考慮架構靈活性,支援業務演變,抽象安全功能。優先考慮效率和可用性,優化安全措施,提高可見度。

SHIB幣對投資人來說已經不陌生了,它是狗狗幣同類型概念代幣,隨著市場的發展,目前SHIB的市值已經排名12了,可以看出SHIB市場的火爆,吸引力無數投資者參與投資。而先前市場的交易、錢包安全事件頻出,許多投資人對於SHIB的存放問題一直感到擔憂,不知道當下SHIB幣放在哪個錢包比較安全?根據市場數據分析來看,相對安全的錢包主要就是OKXWeb3Wallet、imToken、MetaMask錢包會比較安全,接下來小編為大家詳細說。 SHIB幣放在哪個錢包比較安全?目前來看,SHIB幣放在OKXWe

生成性AI的快速發展在隱私和安全方面帶來了前所未有的挑戰,引發了對監管幹預的迫切呼籲。上週,我有機會在華盛頓特區與一些國會議員及其工作人員討論AI與安全相關的影響。今天的生成性AI讓我想起80年代末的互聯網,基礎研究、潛在潛力和學術用途,但它還沒有為公眾做好準備。這次,不受約束的供應商野心,受到小聯盟創投的推動和Twitter迴聲室的激勵,正在快速推進AI的「美麗新世界」。 「公共」基礎模型有缺陷,不適用於消費者和商業用途;隱私抽象,即使存在,也像篩子一樣洩漏;安全結構非常重要,因為攻擊面
