系列文章目錄

1. 信息服務(wù)上線滲透檢測網(wǎng)絡(luò)安全檢查報(bào)告和解決方案3(系統(tǒng)漏洞掃描、相對路徑覆蓋RPO漏洞、nginx漏洞修復(fù))
2. 信息服務(wù)上線滲透檢測網(wǎng)絡(luò)安全檢查報(bào)告和解決方案2(安裝文件信息泄漏、管理路徑泄漏、XSS漏洞、弱口令、邏輯漏洞、終極上傳漏洞升級)
3. 信息服務(wù)上線滲透檢測網(wǎng)絡(luò)安全檢查報(bào)告和解決方案

前言

漏洞掃描是指對網(wǎng)絡(luò)應(yīng)用、服務(wù)器等進(jìn)行全面的安全檢測，以發(fā)現(xiàn)其中存在的安全漏洞，從而及時(shí)修復(fù)，確保網(wǎng)絡(luò)系統(tǒng)的安全性。一種常見的漏洞掃描方法是黑盒測試，即對系統(tǒng)進(jìn)行模擬攻擊來發(fā)現(xiàn)潛在的漏洞風(fēng)險(xiǎn)。以下是一些常用的掃描工具：

1. Nessus：開源的漏洞掃描工具，可用于掃描多種操作系統(tǒng)和應(yīng)用程序漏洞，并提供了詳細(xì)的用戶和管理員報(bào)告。

2. Acunetix：自動(dòng)化的漏洞掃描工具，支持掃描 Web 應(yīng)用、網(wǎng)絡(luò)、API 等，能夠發(fā)現(xiàn)多種漏洞類型。

3. OpenVAS：基于 Nessus 的漏洞掃描工具，提供全面的漏洞掃描功能，支持命令行和 Web 界面使用。

4. Nikto：開源的 Web 服務(wù)器漏洞掃描器，可識別多種 Web 服務(wù)器與應(yīng)用程序漏洞。

5. Metasploit：針對滲透測試的工具，可以用于模擬攻擊，識別漏洞和提供漏洞修復(fù)建議。

一、網(wǎng)站風(fēng)險(xiǎn)等級評定標(biāo)準(zhǔn)

網(wǎng)站風(fēng)險(xiǎn)等級評定涉及到多個(gè)方面，不同的評測機(jī)構(gòu)等級評定不同：

1. 網(wǎng)站內(nèi)容：網(wǎng)站的內(nèi)容是否合法、合規(guī)，是否存在不良信息、欺詐信息等。
2. 用戶數(shù)據(jù)保護(hù)：網(wǎng)站是否對用戶數(shù)據(jù)進(jìn)行合理的保護(hù)措施，是否存在數(shù)據(jù)泄露等情況。
3. 安全性：網(wǎng)站是否存在漏洞、是否采取合理的加密措施等，是否可能給用戶帶來安全風(fēng)險(xiǎn)。
4. 廣告及推廣：網(wǎng)站是否存在虛假、欺詐性廣告及推廣信息。
5. 用戶體驗(yàn)：網(wǎng)站頁面是否易用、舒適，是否存在較多的廣告干擾或過渡的推銷信息等。

綜合以上因素進(jìn)行評估，常規(guī)的風(fēng)險(xiǎn)等級劃分可能包括低風(fēng)險(xiǎn)、中風(fēng)險(xiǎn)、高風(fēng)險(xiǎn)等級，具體評估標(biāo)準(zhǔn)還需根據(jù)不同網(wǎng)站類型進(jìn)行調(diào)整。

二、漏洞危害分級標(biāo)準(zhǔn)

三、漏洞安全建議

1.相對路徑覆蓋(RPO)漏洞

描述:

RPO（Relative Path Overwrite）相對路徑覆蓋，是一種新型攻擊技術(shù)，最早由Gareth Heyes在其發(fā)表的文章中提出。主要是利用瀏覽器的一些特性和部分服務(wù)端的配置差異導(dǎo)致的漏洞，通過一些技巧，我們可以通過相對路徑來引入其他的資源文件，以至于達(dá)成我們想要的目的。 就目前來看此攻擊方法依賴于瀏覽器和網(wǎng)絡(luò)服務(wù)器的反應(yīng)，基于服務(wù)器的Web緩存技術(shù)和配置差異，以及服務(wù)器和客戶端瀏覽器的解析差異，利用前端代碼中加載的css/js的相對路徑來加載其他文件，最終瀏覽器將服務(wù)器返回的不是css/js的文件當(dāng)做css/js來解析，從而導(dǎo)致XSS，信息泄露等漏洞產(chǎn)生。

參考：

• http://www.freebuf.com/articles/web/166731.html
• http://www.beesfun.com/2017/03/27/RPO攻擊/
• http://www.thespanner.co.uk/2014/03/21/rpo/
• https://lorexxar.cn/2018/01/02/34c3-writeup/#CSS-RPO
• https://github.com/eboda/34c3ctf/tree/master/urlstorage

解決方案:
因?yàn)橛|發(fā)這個(gè)漏洞有兩個(gè)基本的前提：

1. Apache 配置錯(cuò)誤導(dǎo)致AllowEncodedSlashes這個(gè)選項(xiàng)開啟（對Apache來說默認(rèn)情況下 AllowEncodedSlashes 這個(gè)選項(xiàng)是關(guān)閉的），或者nginx服務(wù)器。
2. 存在相對路徑的js或者css的引用。 所以首先需要開發(fā)人員注意代碼書寫規(guī)范，其次在頁面中避免直接使用相對路徑進(jìn)行靜態(tài)文件的加載。
   

2.敏感文件泄露

描述:

如 LOG 文件、數(shù)據(jù)庫文件、C# 代碼文件、備份文件等。這些文件可能是不小心留在虛擬目錄中，但是應(yīng)用程序任務(wù)可能并不需要它們。 【漏洞危害】 例如備份文件、打包文件、系統(tǒng)接口、保密文檔、管理后臺(tái)這些文件可能會(huì)泄漏一些敏感信息，幫助惡意用戶準(zhǔn)備進(jìn)一步攻擊。

解決方案:
建議在生產(chǎn)系統(tǒng)中刪除或限制訪問這些文件

3.管理后臺(tái)

描述:

網(wǎng)站后臺(tái)管理系統(tǒng)主要是用于對網(wǎng)站前臺(tái)的信息管理，如文字、圖片、影音、和其他日常使用文件的發(fā)布、更新、刪除等操作，同時(shí)也包括會(huì)員信息、訂單信息、訪客信息的統(tǒng)計(jì)和管理。將管理后臺(tái)暴露在外網(wǎng)，存在一定的安全風(fēng)險(xiǎn)。

解決方案:
建議將管理后臺(tái)放在內(nèi)網(wǎng)。并做好用戶的訪問權(quán)限控制，保證登錄密碼的復(fù)雜性。

4.發(fā)現(xiàn)低版本JQuery

描述:
檢測發(fā)現(xiàn)低版本JQuery,該版本存在多種已知漏洞。jQuery是一個(gè)快速、簡潔的JavaScript框架，是繼Prototype之后又一個(gè)優(yōu)秀的JavaScript代碼庫（框架）于2006年1月由John Resig發(fā)布。jQuery設(shè)計(jì)的宗旨是“write Less，Do More”，即倡導(dǎo)寫更少的代碼，做更多的事情。它封裝JavaScript常用的功能代碼，提供一種簡便的JavaScript設(shè)計(jì)模式，優(yōu)化HTML文檔操作、事件處理、動(dòng)畫設(shè)計(jì)和Ajax交互。例如，以下版本： jQuery >= 1.0.3 < 3.5.0 存在CVE-2020-11022/CVE-2020-11023漏洞

解決方案:
建議升級到最新版本，下載鏈接： https://jquery.com/download/

5.支持低版本TLS協(xié)議

描述:

在測試中發(fā)現(xiàn)服務(wù)器支持低版本的 TLS1.0和 TLS1.1協(xié)議，這些協(xié)議存在公開的漏洞建議，應(yīng)該禁止使用。 TLS 1.0和 TLS 1.1可能會(huì)受到FREAK、POODLE、BEAST和CRIME等漏洞的影響。

解決方案:
修改服務(wù)器配置，TLS協(xié)議僅支持TLSv1.2及以上。
1）nginx建議配置：

# Enable TLSv1.2, disable SSLv3.0, TLSv1.0 and TLSv1.1 
ssl_protocols TLSv1.2;
 # Enable modern TLS cipher suites
ssl_ciphers  'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';

# The order of cipher suites matters
ssl_prefer_server_ciphers on; 

2）apache配置

# Enable TLSv1.2, disable SSLv3.0, TLSv1.0 and TLSv1.1
SSLProtocol  all -SSLv3 -TLSv1 -TLSv1.1 
# Enable modern TLS cipher suites 
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 
# The order of cipher suites matters
SSLHonorCipherOrder     on 
# Disable TLS compression 
SSLCompression off 
# Necessary for Perfect Forward Secrecy (PFS) 
SSLSessionTickets off

6.檢測發(fā)現(xiàn)防火墻設(shè)備

描述:

經(jīng)檢測發(fā)送目標(biāo)站點(diǎn)可能存在防火墻設(shè)備，IPS/IDS/WAF的存在可能會(huì)使掃描結(jié)果不準(zhǔn)確，防火墻探測到掃描行為時(shí)可能會(huì)采取阻斷IP等方式對掃描進(jìn)行限制。

解決方案:
建議對掃描IP加白名單或者掃描內(nèi)部開發(fā)環(huán)境，避開防火墻的影響。

7.HTTP X-Permitted-Cross-Domain-Policies 響應(yīng)頭缺失

描述:
現(xiàn)代瀏覽器提供了許多可選的安全相關(guān)功能與特性，這些功能與特性通?？梢酝ㄟ^ HTTP 響應(yīng)頭來控制，使用這些功能，可以避免受到瀏覽器端的用戶受到類似 CSRF、XSS、Click Hijacking 等前端黑客攻擊的影響。Web 服務(wù)器對于 HTTP 請求的響應(yīng)頭中缺少 X-Permitted-Cross-Domain-Policies，這將導(dǎo)致瀏覽器提供的安全特性失效。 當(dāng)一些在線的 Web Flash 需要加載其他域的內(nèi)容時(shí)，很多 Web 會(huì)通過設(shè)置一個(gè) crossdomain.xml 文件的方式來控制其跨域方式。很有可能有些開發(fā)者并沒有修改 crossdomain.xml 文件的權(quán)限，但是又有和跨域的 Flash 共享數(shù)據(jù)的需求，這時(shí)候可以通過設(shè)置 X-Permitted-Cross-Domain-Policies 頭的方式來替代 crossdomain.xml 文件，其可選的值有： none master-only by-content-type by-ftp-filename all
漏洞危害：
Web 服務(wù)器對于 HTTP 請求的響應(yīng)頭中缺少 X-Permitted-Cross-Domain-Policies，這將導(dǎo)致瀏覽器提供的安全特性失效，更容易遭受 Web 前端黑客攻擊的影響。

解決方案:

修改服務(wù)端程序，給 HTTP 響應(yīng)頭加上 X-Permitted-Cross-Domain-Policies

• 如果是 java 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response.setHeader(“X-Permitted-Cross-Domain-Policies”, “value”)
• 如果是 php 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 header(“X-Permitted-Cross-Domain-Policies: value”)
• 如果是 asp 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 Response.AddHeader “X-Permitted-Cross-Domain-Policies”, “value”
• 如果是 python django 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response = HttpResponse() response[“X-Permitted-Cross-Domain-Policies”] = “value”
• 如果是 python flask 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response = make_response() response.headers[“X-Permitted-Cross-Domain-Policies”] = “value” 2）修改負(fù)載均衡或反向代理服務(wù)器，給 HTTP 響應(yīng)頭加上 X-Permitted-Cross-Domain-Policies
• 如果使用 Nginx、Tengine、Openresty 等作為代理服務(wù)器，在配置文件中寫入如下內(nèi)容即可添加 HTTP 響應(yīng)頭： add_header X-Permitted-Cross-Domain-Policies value;
• 如果使用 Apache 作為代理服務(wù)器，在配置文件中寫入如下內(nèi)容即可添加 HTTP 響應(yīng)頭： Header add X-Permitted-Cross-Domain-Policies “value”;

8.HTTP X-Download-Options 響應(yīng)頭缺失

描述:
現(xiàn)代瀏覽器提供了許多可選的安全相關(guān)功能與特性，這些功能與特性通?？梢酝ㄟ^ HTTP 響應(yīng)頭來控制，使用這些功能，可以避免受到瀏覽器端的用戶受到類似 CSRF、XSS、Click Hijacking 等前端黑客攻擊的影響。Web 服務(wù)器對于 HTTP 請求的響應(yīng)頭中缺少 X-Download-Options，這將導(dǎo)致瀏覽器提供的安全特性失效。 漏洞危害: Web 服務(wù)器對于 HTTP 請求的響應(yīng)頭中缺少 X-Download-Options，這將導(dǎo)致瀏覽器提供的安全特性失效，更容易遭受 Web 前端黑客攻擊的影響。 想了解更多安全相關(guān) HTTP 響應(yīng)頭的知識可以參考：https://www.owasp.org/index.php/OWASP_Secure_Headers_Project
解決方案:
修改服務(wù)端程序，給 HTTP 響應(yīng)頭加上 X-Download-Options

• 如果是 java 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response.setHeader(“X-Download-Options”, “value”)
• 如果是 php 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 header(“X-Download-Options: value”)
• 如果是 asp 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 Response.AddHeader “X-Download-Options”, “value”
• 如果是 python django 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response = HttpResponse() response[“X-Download-Options”] = “value”
• 如果是 python flask 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response = make_response() response.headers[“X-Download-Options”] = “value” 2）修改負(fù)載均衡或反向代理服務(wù)器，給 HTTP 響應(yīng)頭加上 X-Download-Options
• 如果使用 Nginx、Tengine、Openresty 等作為代理服務(wù)器，在配置文件中寫入如下內(nèi)容即可添加 HTTP 響應(yīng)頭： add_header X-Download-Options value;
• 如果使用 Apache 作為代理服務(wù)器，在配置文件中寫入如下內(nèi)容即可添加 HTTP 響應(yīng)頭： Header add X-Download-Options “value”

9.HTTP Referrer-Policy 響應(yīng)頭缺失

描述:
現(xiàn)代瀏覽器提供了許多可選的安全相關(guān)功能與特性，這些功能與特性通?？梢酝ㄟ^ HTTP 響應(yīng)頭來控制，使用這些功能，可以避免受到瀏覽器端的用戶受到類似 CSRF、XSS、Click Hijacking 等前端黑客攻擊的影響。Web 服務(wù)器對于 HTTP 請求的響應(yīng)頭中缺少 Referrer-Policy，這將導(dǎo)致瀏覽器提供的安全特性失效。 當(dāng)用戶在瀏覽器上點(diǎn)擊一個(gè)鏈接時(shí)，會(huì)產(chǎn)生一個(gè) HTTP 請求，用于獲取新的頁面內(nèi)容，而在該請求的報(bào)頭中，會(huì)包含一個(gè) Referrer，用以指定該請求是從哪個(gè)頁面跳轉(zhuǎn)頁來的，常被用于分析用戶來源等信息。但是也成為了一個(gè)不安全的因素，所以就有了 Referrer-Policy，用于過濾 Referrer 報(bào)頭內(nèi)容，其可選的項(xiàng)有： no-referrer no-referrer-when-downgrade origin origin-when-cross-origin same-origin strict-origin strict-origin-when-cross-origin unsafe-url 漏洞危害： Web 服務(wù)器對于 HTTP 請求的響應(yīng)頭中缺少 Referrer-Policy，這將導(dǎo)致瀏覽器提供的安全特性失效，更容易遭受 Web 前端黑客攻擊的影響。 想了解更多安全相關(guān) HTTP 響應(yīng)頭的知識可以參考：https://www.owasp.org/index.php/OWASP_Secure_Headers_Project
解決方案:
修改服務(wù)端程序，給 HTTP 響應(yīng)頭加上 Referrer-Policy

• 如果是 java 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response.setHeader(“Referrer-Policy”, “value”)
• 如果是 php 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 header(“Referrer-Policy: value”) 如果
• 是 asp 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 Response.AddHeader “Referrer-Policy”, “value” 如果是 python django 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response = HttpResponse() response[“Referrer-Policy”] = “value”
• 如果是 python flask 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response = make_response() response.headers[“Referrer-Policy”] = “value” 2）修改負(fù)載均衡或反向代理服務(wù)器，給 HTTP 響應(yīng)頭加上 Referrer-Policy
• 如果使用 Nginx、Tengine、Openresty 等作為代理服務(wù)器，在配置文件中寫入如下內(nèi)容即可添加 HTTP 響應(yīng)頭： add_header Referrer-Policy value;
• 如果使用 Apache 作為代理服務(wù)器，在配置文件中寫入如下內(nèi)容即可添加 HTTP 響應(yīng)頭： Header add Referrer-Policy “value”

10.點(diǎn)擊劫持：缺少X-Frame-Options頭

描述:
Clickjacking（點(diǎn)擊劫持）是由互聯(lián)網(wǎng)安全專家羅伯特·漢森和耶利米·格勞斯曼在2008年首創(chuàng)的。 是一種視覺欺騙手段，在web端就是iframe嵌套一個(gè)透明不可見的頁面，讓用戶在不知情的情況下，點(diǎn)擊攻擊者想要欺騙用戶點(diǎn)擊的位置。服務(wù)器端沒有返回X-Frame-Options頭部，導(dǎo)致該站點(diǎn)存在點(diǎn)擊劫持攻擊的威脅。X-Frame-Options HTTP 響應(yīng)頭，可以指示瀏覽器是否應(yīng)該加載一個(gè)iframe中的頁面。網(wǎng)站可以通過設(shè)置X-Frame-Options阻止站點(diǎn)內(nèi)的頁面被其他頁面嵌入從而防止點(diǎn)擊劫持。如果您確定不需要將網(wǎng)站內(nèi)容嵌入其他站點(diǎn)中，請開啟選項(xiàng)。

解決方案:

1. 在站點(diǎn)配置文件httpd.conf中添加如下配置，限制只有站點(diǎn)內(nèi)的頁面才可以嵌入iframe。 Header always append X-Frame-Options SAMEORIGIN 配置之后重啟apache使其生效。 該配置方式對IBM HTTP Server同樣適用。
2. 配置 Apache 配置 Apache 在所有頁面上發(fā)送 X-Frame-Options 響應(yīng)頭，需要把下面這行添加到 ‘site’ 的配置中: Header always append X-Frame-Options SAMEORIGIN
3. 配置 nginx 配置 nginx 發(fā)送 X-Frame-Options 響應(yīng)頭，把下面這行添加到 ‘http’, ‘server’ 或者 ‘location’ 的配置中: add_header X-Frame-Options SAMEORIGIN;
4. 配置 IIS 配置 IIS 發(fā)送 X-Frame-Options 響應(yīng)頭，添加下面的配置到 Web.config 文件中: <system.webServer> … … </system.webServer>
5. 配置 TOMCAT 如果是tomcat服務(wù)器，不可能在每個(gè)頁面去添加：　 response.addHeader(“x-frame-options”,“SAMEORIGIN”); 因此可以使用過濾器，代碼如下： HttpServletResponse response = (HttpServletResponse) sResponse; response.addHeader(“x-frame-options”,“SAMEORIGIN”); 配置后重啟服務(wù)器生效。

11.HTTP Content-Security-Policy 響應(yīng)頭缺失

描述:
現(xiàn)代瀏覽器提供了許多可選的安全相關(guān)功能與特性，這些功能與特性通?？梢酝ㄟ^ HTTP 響應(yīng)頭來控制，使用這些功能，可以避免受到瀏覽器端的用戶受到類似 CSRF、XSS、Click Hijacking 等前端黑客攻擊的影響。Web 服務(wù)器對于 HTTP 請求的響應(yīng)頭中缺少 Content-Security-Policy，這將導(dǎo)致瀏覽器提供的安全特性失效。 Content-Security-Policy 就是非常出名的 CSP 內(nèi)容安全策略，Web 服務(wù)端程序可以通過設(shè)置 Content-Security-Policy 頭的方式來控制瀏覽器只允許加載哪些資源，或者不運(yùn)行加載哪些資源，這通?？梢杂脕韺挂徊糠?CSRF、存儲(chǔ)型 XSS、JS Hijacking 等攻擊，其可選的值有： base-uri default-src script-src object-src style-src img-src media-src frame-src child-src frame-ancestors font-src connect-src manifest-src form-action sandbox script-nonce plugin-types reflected-xss block-all-mixed-content upgrade-insecure-requests referrer report-uri report-to 漏洞危害： Web 服務(wù)器對于 HTTP 請求的響應(yīng)頭中缺少 Content-Security-Policy，這將導(dǎo)致瀏覽器提供的安全特性失效，更容易遭受 Web 前端黑客攻擊的影響 想了解更多安全相關(guān) HTTP 響應(yīng)頭的知識可以參考：https://www.owasp.org/index.php/OWASP_Secure_Headers_Project

解決方案:

修改服務(wù)端程序，給 HTTP 響應(yīng)頭加上 Content-Security-Policy

1. 如果是 java 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response.setHeader(“Content-Security-Policy”, “value”)
2. 如果是 php 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 header(“Content-Security-Policy: value”)
3. 如果是 asp 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 Response.AddHeader “Content-Security-Policy”, “value”
4. 如果是 python django 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response = HttpResponse() response[“Content-Security-Policy”] = “value”
5. 如果是 python flask 服務(wù)端，可以使用如下方式添加 HTTP 響應(yīng)頭 response = make_response() response.headers[“Content-Security-Policy”] = “value”
6. 修改負(fù)載均衡或反向代理服務(wù)器，給 HTTP 響應(yīng)頭加上 Content-Security-Policy 如果使用 Nginx、Tengine、Openresty 等作為代理服務(wù)器，在配置文件中寫入如下內(nèi)容即可添加 HTTP 響應(yīng)頭： add_header Content-Security-Policy value;
7. 如果使用 Apache 作為代理服務(wù)器，在配置文件中寫入如下內(nèi)容即可添加 HTTP 響應(yīng)頭： Header add Content-Security-Policy “value”

12.Cookie沒有設(shè)置HttpOnly

描述:
COOKIE的HTTPOnly flag沒有設(shè)置，對于很多只依賴于cookie驗(yàn)證的網(wǎng)站來說，HttpOnly cookies是一個(gè)很好的修復(fù)方案，在支持HttpOnly cookies的瀏覽器中（IE6以上，F(xiàn)F3.0以上），javascript是無法讀取和修改HttpOnly cookies，這樣可讓網(wǎng)站用戶驗(yàn)證更加安全

解決方案:
建議盡可能給cookie加上HTTPOnly 屬性。

13.Cookie沒有設(shè)置secure屬性

描述:
cookie的secure標(biāo)志是一個(gè)選項(xiàng)，當(dāng)應(yīng)用服務(wù)器在http響應(yīng)中向用戶發(fā)送新cookie時(shí)，可以設(shè)置該選項(xiàng)secure標(biāo)志，目的是防止未經(jīng)授權(quán)的方由于以明文形式傳輸cookie而獲取到cookie。 為了實(shí)現(xiàn)這個(gè)目標(biāo)，支持secure標(biāo)志的瀏覽器只會(huì)在請求轉(zhuǎn)到https頁面時(shí)發(fā)送帶有secure標(biāo)志的cookies。換句話說，瀏覽器不會(huì)在未加密的http請求上發(fā)送設(shè)置了安全標(biāo)志的cookie。 通過設(shè)置secure標(biāo)志，瀏覽器將可以阻止通過未加密通道傳輸cookie。
解決方案:
建議對cookie設(shè)置安全標(biāo)志。

14.發(fā)現(xiàn)無效鏈接

描述:
無效鏈接也就是死鏈接，死鏈接是網(wǎng)站建設(shè)中專業(yè)術(shù)語。頁面的TCP協(xié)議狀態(tài)/HTTP協(xié)議狀態(tài)明確表示的死鏈，常見的如404。死鏈接[1] - 也稱無效鏈接，即那些不可達(dá)到的鏈接。一個(gè)網(wǎng)站存在死鏈接不是什么好事，首先一個(gè)網(wǎng)站如果存在大量的死鏈接，必將大大損傷網(wǎng)站的整體形象，再者搜索引擎蜘蛛是通過鏈接來爬行搜索(影響蜘蛛的爬取)，如果太多鏈接無法到達(dá)，不但網(wǎng)站收錄頁面數(shù)量會(huì)減少，而且你的網(wǎng)站在搜索引擎中的權(quán)重會(huì)大大降低.如果該網(wǎng)站出現(xiàn)死鏈接過多，網(wǎng)站URL打不開鏈接的現(xiàn)象，我們會(huì)怎么做？95%的人會(huì)離開該網(wǎng)站，去其他站點(diǎn)尋找信息。

解決方案:
建議做如下安全加固： 1.必需盡快找到死鏈接網(wǎng)頁，修改或刪除他。 2.利用Robost.txt文件屏蔽掉他，不讓搜索抓?。ㄟ@種方面是在找不到死鏈接網(wǎng)站后）。

15.發(fā)現(xiàn)手機(jī)號碼模式

描述:
查看請求的響應(yīng)內(nèi)容中是否存在手機(jī)號碼信息，如果存在手機(jī)號碼，則認(rèn)為存在。
解決方案:
建議如無必要，請刪除。

16.發(fā)現(xiàn)文件上傳點(diǎn)

描述:
測試發(fā)現(xiàn)WEB程序存在文件上傳功能，文件上傳可能會(huì)存在重大的安全隱患，在特定情況下會(huì)導(dǎo)致攻擊者上傳執(zhí)行任意代碼。

解決方案:
修復(fù)方案： 1.上傳文件的存儲(chǔ)目錄禁用執(zhí)行權(quán)限 2.文件的后綴白名單，注意0x00截?cái)喙?3.不能有本地文件包含漏洞 4.及時(shí)修復(fù)web上的代碼 5.升級web server

總結(jié)

永遠(yuǎn)在修復(fù)漏洞的路上。

@漏刻有時(shí)文章來源地址http://www.zghlxwxcb.cn/news/detail-519959.html

到了這里，關(guān)于信息服務(wù)上線滲透檢測網(wǎng)絡(luò)安全檢查報(bào)告和解決方案4(網(wǎng)站風(fēng)險(xiǎn)等級評定標(biāo)準(zhǔn)、漏洞危害分級標(biāo)準(zhǔn)、漏洞安全建議)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！