日本中文字幕视频在线看,国产三级欧美,午夜伦费高清在线播放

一問題：IBM AppScan 安全掃描提示：

二問題解決：

1. X-XSS-Protection

目的

這個header主要是用來防止瀏覽器中的反射性xss。現(xiàn)在，只有IE，chrome和safari（webkit）支持這個header。

正確的設(shè)置

0 – 關(guān)閉對瀏覽器的xss防護  
1 – 開啟xss防護  
1; mode=block – 開啟xss防護并通知瀏覽器阻止而不是過濾用戶注入的腳本。  
1; report=http://site.com/report – 這個只有chrome和webkit內(nèi)核的瀏覽器支持，這種模式告訴瀏覽器當(dāng)發(fā)現(xiàn)疑似xss攻擊的時候就將這部分?jǐn)?shù)據(jù)post到指定地址。

通常不正確的設(shè)置

0; mode=block; – 記住當(dāng)配置為0的時候，即使加了mode=block選項也是沒有效果的。需要指出的是，chrome在發(fā)現(xiàn)這種錯誤的配置后還是會開啟xss防護。  
1 mode=block; – 數(shù)字和選項之間必須是用分號分割，逗號和空格都是錯誤的。但是這種錯誤配置情況下，IE和chrome還是默認(rèn)會清洗xss攻擊，但是不會阻攔。

如何檢測

如果過濾器檢測或阻攔了一個反射性xss以后,IE會彈出一個對話框。當(dāng)設(shè)置為1時，chrome會隱藏對反射性xss的輸出。如果是設(shè)置為 1; mode=block ,那么chrome會直接將user-agent置為一個空值:, URL 這種形式。

參考文獻(xiàn)

Post from Microsoft on the X-XSS-Protection Header
Chromium X-XSS-Protection Header Parsing Source
Discussion of report format in WebKit bugzilla

2. X-Content-Type-Options

目的

這個header主要用來防止在IE9、chrome和safari中的MIME類型混淆攻擊。firefox目前對此還存在爭議。通常瀏覽器可以通過嗅探內(nèi)容本身的方法來決定它是什么類型，而不是看響應(yīng)中的content-type值。通過設(shè)置 X-Content-Type-Options：如果content-type和期望的類型匹配，則不需要嗅探，只能從外部加載確定類型的資源。舉個例子，如果加載了一個樣式表，那么資源的MIME類型只能是text/css，對于IE中的腳本資源，以下的內(nèi)容類型是有效的：

application/ecmascript  
application/javascript  
application/x-javascript  
text/ecmascript  
text/javascript  
text/jscript  
text/x-javascript  
text/vbs  
text/vbscript

對于chrome，則支持下面的MIME 類型：

text/javascript  
text/ecmascript  
application/javascript  
application/ecmascript  
application/x-javascript  
text/javascript1.1  
text/javascript1.2  
text/javascript1.3  
text/jscript  
text/live script

正確的設(shè)置

nosniff – 這個是唯一正確的設(shè)置，必須這樣。

通常不正確的設(shè)置

‘nosniff’ – 引號是不允許的  
: nosniff – 冒號也是錯誤的

如何檢測

在IE和chrome中打開開發(fā)者工具，在控制臺中觀察配置了nosniff和沒有配置nosniff的輸出有啥區(qū)別。

參考文獻(xiàn)

Microsoft Post on Reducing MIME type security risks
Chromium Source for parsing nosniff from response
Chromium Source list of JS MIME types
MIME Sniffing Living Standard

3. X-Frame-Options

目的

這個header主要用來配置哪些網(wǎng)站可以通過frame來加載資源。它主要是用來防止UI redressing 補償樣式攻擊。IE8和firefox 18以后的版本都開始支持ALLOW-FROM。chrome和safari都不支持ALLOW-FROM，但是WebKit已經(jīng)在研究這個了。

正確的設(shè)置

DENY – 禁止所有的資源（本地或遠(yuǎn)程）試圖通過frame來加載其他也支持X-Frame-Options 的資源。  
SAMEORIGIN – 只允許遵守同源策略的資源（和站點同源）通過frame加載那些受保護的資源。  
ALLOW-FROM http://www.example.com – 允許指定的資源（必須帶上協(xié)議http或者h(yuǎn)ttps）通過frame來加載受保護的資源。這個配置只在IE和firefox下面有效。其他瀏覽器則默認(rèn)允許任何源的資源（在X-Frame-Options沒設(shè)置的情況下）。

通常不正確的設(shè)置

ALLOW FROM http://example.com – ALLOW和FROM 之間只能通過連字符來連接，空格是錯誤的。  
ALLOW-FROM example.com – ALLOW-FROM選項后面必須跟上一個URI而且要有明確的協(xié)議（http或者h(yuǎn)ttps）

如何檢測

可以通過訪問test cases 來查看各種各樣的選項和瀏覽器對這些frame中的資源的響應(yīng)。

參考文獻(xiàn)

X-Frame-Options RFC
Combating ClickJacking With X-Frame-Options

4. Strict-Transport-Security

目的

Strict Transport Security (STS) 是用來配置瀏覽器和服務(wù)器之間安全的通信。它主要是用來防止中間人攻擊，因為它強制所有的通信都走TLS。目前IE還不支持 STS頭。需要注意的是，在普通的http請求中配置STS是沒有作用的，因為攻擊者很容易就能更改這些值。為了防止這樣的現(xiàn)象發(fā)生，很多瀏覽器內(nèi)置了一個配置了STS的站點list。

正確的設(shè)置
注意下面的值必須在https中才有效，如果是在http中配置會沒有效果。

max-age=31536000 – 告訴瀏覽器將域名緩存到STS list里面，時間是一年。  
max-age=31536000; includeSubDomains – 告訴瀏覽器將域名緩存到STS list里面并且包含所有的子域名，時間是一年。  
max-age=0 – 告訴瀏覽器移除在STS緩存里的域名，或者不保存此域名。

通常不正確的設(shè)置

直接將includeSubDomains設(shè)置為 https://www.example.com ，但是用戶依然可以通過 http://example.com 來訪問此站點。如果example.com 并沒有跳轉(zhuǎn)到 https://example.com 并設(shè)置 STS header，那么訪問 http://www.example.com 就會直接被瀏覽器重定向到 https://www.example.com 。  
max-age=60 – 這個只設(shè)置域名保存時間為60秒。這個時間太短了，可能并不能很好的保護用戶，可以嘗試先通過http來訪問站點，這樣可以縮短傳輸時間。  
max-age=31536000 includeSubDomains – max-age 和 includeSubDomains 直接必須用分號分割。這種情況下，即使max-age的值設(shè)置的沒有問題，chrome也不會將此站點保存到STS緩存中。  
max-age=31536000, includeSubDomains – 同上面情況一樣。  
max-age=0 – 盡管這樣在技術(shù)上是沒有問題的，但是很多站點可能在處理起來會出差錯，因為0可能意味著永遠(yuǎn)不過期。

如何檢測

判斷一個主機是否在你的STS緩存中，chrome可以通過訪問chrome://net-internals/#hsts，首先，通過域名請求選項來確認(rèn)此域名是否在你的STS緩存中。然后，通過https訪問這個網(wǎng)站，嘗試再次請求返回的STS頭，來決定是否添加正確。

參考文獻(xiàn)

Strict Transport Security RFC6797
Wikipedia page on Strict Transport Security (with examples)

5. Public-Key-Pins (起草中)

目的

有關(guān)這個header的詳細(xì)描述還在起草中，但是它已經(jīng)有了很清晰的安全作用，所以我還是把它放在了這個list里面。Public-Key- Pins (PKP)的目的主要是允許網(wǎng)站經(jīng)營者提供一個哈希過的公共密鑰存儲在用戶的瀏覽器緩存里。跟Strict-Transport-Security功能相似的是，它能保護用戶免遭中間人攻擊。這個header可能包含多層的哈希運算，比如pin-sha256=base64(sha256(SPKI))，具體是先將 X.509 證書下的Subject Public Key Info (SPKI) 做sha256哈希運算，然后再做base64編碼。然而，這些規(guī)定有可能更改，例如有人指出，在引號中封裝哈希是無效的，而且在33版本的chrome 中也不會保存pkp的哈希到緩存中。

這個header和 STS的作用很像，因為它規(guī)定了最大子域名的數(shù)量。此外，pkp還提供了一個Public-Key-Pins-Report-Only 頭用來報告異常，但是不會強制阻塞證書信息。當(dāng)然，這些chrome都是不支持的。

正確的設(shè)置

max-age=3000; pin-sha256=”d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=”; – 規(guī)定此站點有3000秒的時間來對x.509證書項目中的公共密鑰信息（引號里面的內(nèi)容）做sha256哈希運算再做base64編碼。  
max-age=3000; pin-sha256=”d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=”; report-uri=”http://example.com/pkp-report” – 同上面一樣，區(qū)別是可以報告異常。

通常不正確的設(shè)置

max-age=3000; pin-sha256=d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=; – Not encapsulating the hash value in quotes leads to Chrome 33 not adding the keys to the PKP cache. This mistake was observed in all but one of the four sites that returned this or the report-only header response.沒有添加引號，這樣的話chrome不會將這個key添加到PKP緩存中。我們的調(diào)查中發(fā)現(xiàn)有四分之一的網(wǎng)站存在此問題。

如何檢測

如果站點成功的將pkp哈希存入了客戶端緩存，那么使用和Strict-Transport-Security （STS）相同的方法查看pubkey_hashes 信息就可以了。

參考文獻(xiàn)

Public-Key-Pins draft specification
Chrome issue tracking the implementation of Public-Key-Pins
Chromium source code for processing Public-Key-Pins header

6. Access-Control-Allow-Origin

目的

Access-Control-Allow-Origin是從Cross Origin Resource Sharing (CORS)中分離出來的。這個header是決定哪些網(wǎng)站可以訪問資源，通過定義一個通配符來決定是單一的網(wǎng)站還是所有網(wǎng)站可以訪問我們的資源。需要注意的是，如果定義了通配符，那么 Access-Control-Allow-Credentials選項就無效了，而且user-agent的cookies不會在請求里發(fā)送。

正確的設(shè)置

* – 通配符允許任何遠(yuǎn)程資源來訪問含有Access-Control-Allow-Origin 的內(nèi)容。  
http://www.example.com – 只允許特定站點才能訪問(http://[host], 或者 https://[host])

通常不正確的設(shè)置

http://example.com, http://web2.example.com – 多個站點是不支持的，只能配置一個站點。  
*.example.com – 只允許單一的站點  
http://*.example.com – 同上面一樣

如何檢測

很容易就能確定這個header是否被設(shè)置的正確，因為如果設(shè)置錯誤的話，CORS請求就會接收不到數(shù)據(jù)。

參考文獻(xiàn)

W3C CORS specification
Content-Security-Policy 1.0

目的

csp是一些指令的集合，可以用來限制頁面加載各種各樣的資源。目前，IE瀏覽器只支持CSP的一部分，而且僅支持X-Content- Security-Policy header。相比較而言，Chrome和Firefox則支持CSP的1.0版本，csp的1.1版本則還在開發(fā)中。通過恰當(dāng)?shù)呐渲胏sp，可以防止站點遭受很多類型的攻擊，譬如xss和UI補償?shù)认嚓P(guān)問題。

csp總共有10種配置形式，每一種都可以用來限制站點何時加載和加載何種類型的資源。他們分別是：

default-src：這種形式默認(rèn)設(shè)置為 script-src, object-src, style-src, img-src, media-src, frame-src, font-src和connect-src.如果上述設(shè)置一個都沒有的話，user-agent就會被用來作為default-src的值。

script-src：這種形式也有兩個附加的設(shè)置。

1、unsafe-inline：允許資源執(zhí)行腳本。舉個例子，on事件的值會被編碼到html代碼中，或者腳本元素的text的內(nèi)容會被混入到受保護的資源中。  
2、unsafe-eval：允許資源動態(tài)的執(zhí)行函數(shù)，比如eval，setTimeout, setInterval, new等函數(shù)。

object-src – 決定從哪里加載和執(zhí)行插件。
style-src – 決定從哪里加載css和樣式標(biāo)記。
img-src – 決定從哪里加載圖片。
media-src – 決定從哪里加載視頻和音頻資源。
frame-src – 決定哪里的frames 可以被嵌入。
font-src – 決定從哪里加載字體。
connect-src – 限制在 XMLHttpRequest, WebSocket 和 EventSource 中可以使用哪些類型的資源。
sandbox – 這是一個可選形式，它決定了沙盒的策略，如何將內(nèi)容嵌入到沙盒中以保證安全。

當(dāng)這個策略被特定的url違反了，我們也可以用報告地址直接發(fā)送報告。這樣做有利于debug和當(dāng)攻擊發(fā)生時通知我們。

此外，我們可以定義Content-Security-Policy-Report-Only 的 header不強制遵守csp，但是會發(fā)送潛在的威脅到一個報告地址。它遵守和csp一樣的語法和規(guī)則。

正確的設(shè)置

View cspplayground.com compliant examples

通常不正確的設(shè)置：

View cspplayground.com violation examples

如何檢測

在chrome和firefox中打開開發(fā)者工具或者firebug，在控制臺查看是否有潛在的威脅。

AppScan 檢測到 Content-Security-Policy 響應(yīng)頭缺失，這可能會更大程度得暴露于各種跨站點注入攻擊

可以在Response中設(shè)置響應(yīng)頭Content-Security-Policy" value="default-src 'self';

在Web工程中可以使用filter過濾器來統(tǒng)一設(shè)置響應(yīng)頭：

/**解決Missing "Content-Security-Policy" header
    	 * Missing "X-Content-Type-Options" header
    	 * Missing "X-XSS-Protection" header導(dǎo)致Web 應(yīng)用程序編程或配置不安全
    	 * **/   
    	response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));
    	response.setHeader("Access-Control-Allow-Methods", "POST, GET");//允許跨域的請求方式
    	response.setHeader("Access-Control-Max-Age", "3600");//預(yù)檢請求的間隔時間
    	response.setHeader("Access-Control-Allow-Headers", "Origin, No-Cache, X-Requested-With, If-Modified-Since, Pragma, Last-Modified, Cache-Control, Expires, Content-Type, X-E4M-With,userId,token,Access-Control-Allow-Headers");//允許跨域請求攜帶的請求頭
    	response.setHeader("Access-Control-Allow-Credentials","true");//若要返回cookie、攜帶seesion等信息則將此項設(shè)置我true
    	response.setHeader("strict-transport-security","max-age=16070400; includeSubDomains");//簡稱為HSTS。它允許一個HTTPS網(wǎng)站，要求瀏覽器總是通過HTTPS來訪問它
    	response.setHeader("Content-Security-Policy","default-src 'self'");//這個響應(yīng)頭主要是用來定義頁面可以加載哪些資源，減少XSS的發(fā)生
    	response.setHeader("X-Content-Type-Options","nosniff");//互聯(lián)網(wǎng)上的資源有各種類型，通常瀏覽器會根據(jù)響應(yīng)頭的Content-Type字段來分辨它們的類型。通過這個響應(yīng)頭可以禁用瀏覽器的類型猜測行為
    	response.setHeader("X-XSS-Protection","1; mode=block");//1; mode=block：啟用XSS保護，并在檢查到XSS攻擊時，停止渲染頁面
    	response.setHeader("X-Frame-Options","SAMEORIGIN");//SAMEORIGIN：不允許被本域以外的頁面嵌入；

web.xml中需要進行攔截：

<!-- 用戶管理Filter -->
 	<filter>
		<filter-name>EncryptFilter</filter-name>
		<filter-class>com.inspur.tax.permission.base.CustomEncryptFilter</filter-class>
		<init-param>
			<param-name>servicePrex</param-name>
			<param-value>/service</param-value>
		</init-param>
	</filter> 
<filter-mapping>
		<filter-name>EncryptFilter</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>

一個朋友新做的公眾號，幫忙宣傳一下，會不定時推送一些開發(fā)中碰到的問題的解決方法，以及會分享一些開發(fā)視頻。資料等。請大家關(guān)注一下謝謝：

本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點擊舉報。

免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

1. X-XSS-Protection

2. X-Content-Type-Options

3. X-Frame-Options

4. Strict-Transport-Security

5. Public-Key-Pins (起草中)

6. Access-Control-Allow-Origin