一、背景

隨著開發(fā)技術(shù)的發(fā)展及完善，一些網(wǎng)站系統(tǒng)會經(jīng)常遭到各類XSS攻擊、點劫持（ClickJacking、frame惡意引用等），從而造成重要信息的泄露以及服務器安全問題

二、http基本安全配置

2.1 host頭攻擊漏洞

該問題檢測點在于 檢測應用是否在請求目標站點時返回的URL是直接將Host頭拼接在URI前

該漏洞的防御主要是限制IP地址，

配置示例

通過指定一個SERVER_NAME名單，只有這符合條件的允許通過，不符合條件的返回403狀態(tài)碼

server {
        listen 7200;
        server_name 127.0.0.1 192.168.10.188;
        if ($http_Host !~* ^192.168.10.188|127.0.0.1$)
        {
            return 403;
        }                
    }

2.2 http method 請求方式攻擊漏洞

一般api接口配置，會要求使用某些指定的請求方式，比如post、get

配置如下示例

即僅僅讓GET、POST類型請求通過，其余的請求方式返回403狀態(tài)碼

if ($request_method !~* GET|POST) {
            return 403;
  }

2.3 點劫持漏洞（X-Frame-Options） 

X-Frame-Options HTTP 響應頭是微軟提出來的一個HTTP響應頭，主要用來給瀏覽器指示允許一個頁面可否在 <frame>, <iframe> 或者 <object> 中展現(xiàn)的標記。網(wǎng)站可以使用此功能，來確保自己網(wǎng)站的內(nèi)容沒有被嵌到別人的網(wǎng)站中去，也從而避免了點擊劫持 (ClickJacking) 的攻擊

點劫持概念：點擊劫持（ClickJacking）是一種視覺上的欺騙手段。攻擊者利用透明的、不可見的iframe，覆蓋在一個網(wǎng)頁上，此時用戶在不知情的情況下點擊了這個透明的iframe頁面。通過調(diào)整iframe頁面的css樣式，可以使用戶恰好點擊在iframe頁面的一些功能性按鈕上。

X-Frame-Options配置值釋義

• DENY：不能被嵌入到任何iframe或者frame中。
• SAMEORIGIN：頁面只能被本站頁面嵌入到iframe或者frame中。
• ALLOW-FROM url：只能被嵌入到指定域名的框架中。

配置示例

add_header X-Frame-Options SAMEORIGIN;
#add_header X-Frame-Options:ALLOW-FROM https://#baidu.com;
#add_header X-Frame-Options DENY;

2.4 X-Download-Options響應頭缺失

web瀏覽器在響應頭中缺少 X-Download-Options，這將導致瀏覽器提供的安全特性失效，更容易遭受 Web 前端黑客攻擊的影響。

配置示例

add_header X-Download-Options "noopen";

2.5 Content-Security-Policy響應頭缺失

HTTP 響應頭Content-Security-Policy允許站點管理者控制用戶代理能夠為指定的頁面加載哪些資源。除了少數(shù)例外情況，設置的政策主要涉及指定服務器的源和腳本結(jié)束點。
Content-Security-Policy響應頭的缺失使得目標URL更易遭受跨站腳本攻擊。

配置示例

add_header Content-Security-Policy "script-src * 'unsafe-inline' 'unsafe-eval'";

指令值示例 

指令值內(nèi)容組成

2.6 Strict-Transport-Security響應頭缺失

Web 服務器對于 HTTP 請求的響應頭中缺少 Strict-Transport-Security，這將導致瀏覽器提供的安全特性失效。 當 Web 服務器的 HTTP 頭中包含 Strict-Transport-Security 頭時，瀏覽器將持續(xù)使用 HTTPS 來訪問 Web 站點，可以用來對抗協(xié)議降級攻擊和 Cookie 劫持攻擊。

語法

1. strict-transport-security: max-age=<expire-time>
2. strict-transport-security: max-age=<expire-time>; includeSubDomains
3. strict-transport-security: max-age=<expire-time>; includeSubDomains; preload

釋義

• max-age=<expire-time>： 設置在瀏覽器收到這個請求后的 秒的時間內(nèi)凡是訪問這個域名下的請求都使用 HTTPS 請求。
• includeSubDomains ：可選，如果這個可選的參數(shù)被指定，那么說明此規(guī)則也適用于該網(wǎng)站的所有子域名。
• preload： 可選，加入預加載列表

配置示例

add_header Strict-Transport-Security 'max-age=15552000';

2.7 X-Permitted-Cross-Domain-Policies響應頭缺失

系統(tǒng)響應頭缺少X-Permitted-Cross-Domain-Policies，將會導致瀏覽器的安全特性失效

配置值釋義

• none：不允許使用loadPolicyFile方法加載任何策略文件，包括此主策略文件。
• master-only：只允許使用主策略文件[默認值]。
• by-content-type：只允許使用loadPolicyFile方法加載HTTP/HTTPS協(xié)議下Content-Type 為text/x-cross-domain-policy的文件作為跨域策略文件。
• by-ftp-filename：只允許使用loadPolicyFile方法加載FTP協(xié)議下文件名為 crossdomain.xml的文件作為跨域策略文件。
• all：可使用loadPolicyFile方法加載目標域上的任何文件作為跨域策略文件，甚至是一 個JPG也可被加載為策略文件。

配置示例

add_header X-Permitted-Cross-Domain-Policies 'none';

2.8 Referrer-Policy響應頭缺失

用來監(jiān)管哪些訪問來源信息——會在 Referer 中發(fā)送——應該被包含在生成的請求當中，增加隱私保護。

當我們點擊一個連接時，會產(chǎn)生一個http請求去獲取新頁面的內(nèi)容，在該請求的header中會有一個referrer用以說明該請求是從哪個頁面跳轉(zhuǎn)過來的。如果缺少該字段會導致瀏覽器的安全特性消失，使我們的系統(tǒng)更容易受到攻擊。

語法

1. Referrer-Policy: no-referrer
2. Referrer-Policy: no-referrer-when-downgrade
3. Referrer-Policy: origin
4. Referrer-Policy: origin-when-cross-origin
5. Referrer-Policy: same-origin
6. Referrer-Policy: strict-origin
7. Referrer-Policy: strict-origin-when-cross-origin
8. Referrer-Policy: unsafe-url

釋義

• no-referrer：整個 Referer 首部會被移除。訪問來源信息不隨著請求一起發(fā)送。 
• no-referrer-when-downgrade ：（默認值） 在沒有指定任何策略的情況下用戶代理的默認行為。在同等安全級別的情況下(HTTPS->HTTPS)，引用頁面的地址會被發(fā)送，但是在降級的情況下 (HTTPS->HTTP)不會被發(fā)送。
• origin：在任何情況下，僅發(fā)送文件的源作為引用地址。例如 https://example.com/page.html 會將 https://example.com/ 作為引用地址。
• origin-when-cross-origin：對于同源的請求，會發(fā)送完整的URL作為引用地址，但是對于非同源請求僅發(fā)送文件的源。
• same-origin：對于同源的請求會發(fā)送引用地址，但是對于非同源請求則不發(fā)送引用地址信息。
• strict-origin：在同等安全級別的情況下(HTTPS->HTTPS)，發(fā)送文件的源作為引用地址，但是在降級的情況下(HTTPS->HTTP)不會發(fā)送 。
• strict-origin-when-cross-origin：對于同源的請求，會發(fā)送完整的URL作為引用地址；對于非同源,在同等安全級別的情況下(HTTPS->HTTPS)，發(fā)送文件的源作為引用地址；在降級的情況下(HTTPS->HTTP)不發(fā)送此首部。
• unsafe-url：無論是同源請求還是非同源請求，都發(fā)送完整的 URL（移除參數(shù)信息之后）作為引用地址。 這項設置會將受 TLS 安全協(xié)議保

配置示例

add_header Referrer-Policy "no-referrer";

2.9 X-XSS-Protection響應頭缺失

HTTP X-XSS-Protection 響應頭是 Internet Explorer，Chrome 和 Safari 的一個特性，當檢測到跨站腳本攻擊 (XSS)時，瀏覽器將停止加載頁面。

X-XSS-Protection響應頭的缺失使得目標URL更易遭受跨站腳本攻擊。

語法

1.X-XSS-Protection: 0
2.X-XSS-Protection: 1
3.X-XSS-Protection: 1; mode=block
4.X-XSS-Protection: 1; report=<reporting-uri>

釋義

• 0：禁止 XSS 過濾。
• 1：啟用 XSS 過濾（通常瀏覽器是默認的）。 如果檢測到跨站腳本攻擊，瀏覽器將清除頁面（刪除不安全的部分）。
• 1; mode=block：啟用 XSS 過濾。 如果檢測到攻擊，瀏覽器將不會清除頁面，而是阻止頁面加載。
• 1; report=<reporting-uri> (Chromium only)：啟用 XSS 過濾。如果檢測到跨站腳本攻擊，瀏覽器將清除頁面并使用 CSP report-uri 指令的功能發(fā)送違規(guī)報告。

配置示例

add_header X-XSS-Protection '1;mode=block';

2.10 X-Content-Type-Options響應頭缺失

Web 服務器對于 HTTP 請求的響應頭缺少 X-Content-Type-Options，這意味著此網(wǎng)站更易遭受跨站腳本攻擊（XSS）。

X-Content-Type-Options 響應頭相當于一個提示標志，被服務器用來提示客戶端一定要遵循在 Content-Type 首部中對 MIME 類型 的設定，而不能對其進行修改，這就禁用了客戶端的 MIME 類型嗅探行為。

X-Content-Type-Options響應頭的缺失使得目標URL更易遭受跨站腳本攻擊。

配置示例

add_header X-Content-Type-Options 'nosniff';

nosniff 只應用于以下兩種情況的請求將被阻止：

• 請求類型是 style 但是 MIME 類型不是 text/css。
• 請求類型是 script 但是 MIME 類型不是 JavaScript MIME 類型。

2.11 會話cookie中缺少HttpOnly屬性

會話cookie中缺少HttpOnly屬性會導致攻擊者可以通過程序(JS腳本、Applet等)獲取到用戶的cookie信息，造成用戶cookie信息泄露，增加攻擊者的跨站腳本攻擊威脅。

釋義

• secure屬性當設置為true時，表示創(chuàng)建的 Cookie 會被以安全的形式向服務器傳輸，也就是只能在 HTTPS 連接中被瀏覽器傳遞到服務器端進行會話驗證，如果是 HTTP 連接則不會傳遞該信息，所以不會被竊取到Cookie 的具體內(nèi)容。
•  HttpOnly屬性如果在Cookie中設置了"HttpOnly"屬性，那么通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這樣能有效的防止XSS攻擊。

配置示例

add_header Set-Cookie "Path=/; HttpOnly; Secure";

注： 另一種配置是在ssl.conf或default.conf中添加下面的語法：

proxy_cookie_path / "/; HTTPOnly; Secure";

到此這篇關(guān)于一文了解nginx HTTP安全響應問題的文章就介紹到這了,更多相關(guān)nginx HTTP安全響應內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論